Game Design - Tuning Expressive Economy System (Invoice System)
For an unannounced game project, I am designing the game’s economic system that functions to payout players in the game’s primary currency. This system, called the Invoice System, is the representation of the accounting that determines how much any given mission pays out to the player based on their play based choices.
Overview
Design Goals:
The design has convey the game’s rhetorical concepts
Clearly signal key early success heuristics
Deliver one of the game’s central challenge vectors - debt
Design Process:
SIMULATION - Because of the multi-variate factors that informs payouts, simulation will be the primary method of exploration. Though spreadsheets can reasonably capture the breadth of potential values, the combinatorial interactions make simulation a better approach to also be able to observe distributions - not just extremes and value ranges.
ITERATION - The rhetorical concepts leave room for interpretation, and pose potential internal conflicts and contradictions. Using iterative simulations or increasing fidelity, the details of the creative vision can be brought into focus as the tuning gets closer to the larger vision.
Design Requirements
Rhetorical Concepts:
The game has elements of a tongue-in-cheek lampoon of hyper-capitalist worker exploitation, and the Invoice System is the main representation of that exploitation.
Contracts for the mission will pay out companies hundreds of thousands to millions of dollars, however, players are rewarded hundreds every time they risk their lives.
Players take on the burden of the risk of the work, both physically, but also financially.
Players are nickeled-and-dimed for the means they use such as ammunition, revives, collateral damage, etc.
The perks offered for more dangerous missions are trivial, but the only means by which players can get “into the black”.
The game aims to invert typical action power fantasy and looter-shooter tropes for “sensible” and “prudent” reasons.
Wasteful use of ammunition can significantly affect a player’s bottom line
Revives, similarly, are treated as an expensive luxury and injudicious over-use can be catastrophic to the players’ final invoiced amounts
The perks typically offer the best payouts, but carrying loot and gold will slow the players down
As players push the limits of the difficulties they’re equipped to tackle, they also have to place deposits which puts them in greater financial jeopardy, but are essential to maximizing their take home pay whenever they succeed
Essential Player Heuristics:
Playing at higher difficulties is essential to earning more money
Playing at low difficulties will never be financially viable
Smart wagering (security deposit placement) can help them optimize their financial progress
The combat privileges success based on raw output and capability, but the Invoice System rewards judicious, tempered, and efficient play.
Process
Iteration 1: rudimentary simulation
In accordance with the game’s design document definition for how missions are categorized, a simple Unity Custom Editor utility was written to procedurally generate relevant mission parameter based on a given “mission rank”, in utility-adjustable batches.
Based on the varying mission parameters, mission run simulations were run, bracketed by “poor”, “tuned”, and “perfect” play. The simulations were bracketed so that spreads and distributions of outcomes could be observable across the player skill dynamic. For example - will the spread of values decrease at better or worse ends of the player skill spectrum?
Using bracketed simulation runs, an initial tuning for the game was developed based on diegetically meaningful values.
Result 1: not quite right
The initial tuning turned out fairly simple and boring.
Taking on the persona of a “fair” accounting system, most of the variables skilled linearly, meaning that the game’s dynamics were very predictable, and potentially uninteresting for players. The correct approach to success was easy to deduce.
Though the game could still work with this structure, since the game could impose a large skill hurdle between knowing the right answer and executing the right answer, it would show the hand of the rhetorical concept behind the game too early.
Lessons Learned 1: everything is linear
Linear equations have linear results
The previous system worked pretty well in simulating the designs’ results, but it made iterating a little too time consuming
Iteration 2: modularized simulation and permutational variance
Taking the best features from the first simulation’s implementation, I drafted a new system that did a few things better.
The tuning parameters were moved to its own class so that the variables could be changed independently from simulations -> this would permit easier AB testing.
A basic results plotting solution was added to be able to observe trends and distributions, besides just averages and ranges.
To create more complexity, the tuning was changed to include more conditional and play-outcome dependent variance in payouts.
Result 2: minor successes
Successes:
The new system was easier to change tuning values, and to do AB testing.
The new plotting system made it easier to observe dynamics across different vectors.
New Challenges:
The plotting system doesn’t have the flexibility of more fully baked solutions like spreadsheet applications.
Changing tuning values is easy, and comparing tunings is easy, but changing output dynamics requires an even more modular implementation. Possibly something as granular is dependency injection on a per-assessment level.
Lessons Learned 2: need for even more flexibility and dynamics assessment
The rhetorical concept is challenging to make nuanced because the goals are too vague.
Changing linear dynamics, even across highly variable game-play outcomes, but simple linear relationships still result in likely flat distributions.
Iteration 3: rhetorical refinement and specs definition
The biggest issue was that the expressive intent for this system was too loosely conceived.
This system represents what the company is paying the players out for their effort - but, what does their pay structure need to say?
At it’s core, the intent was to make the companies feel exploitative; to make it feel like the players were being taken advantage of. But how? The idea was to make the assessment criteria themselves do the work of conveying that the players were being “nickel and dimed”, but simply charging the players for the bullets they use isn’t enough of the impact of those costs aren’t meaningfully integrated into the greater whole.
So, the following expressive concepts were further defined to create another layer of meaning, and to create more specific goals for the system’s dynamics. To that end, a manual dynamics curve was defined to convey the following ideas:
At easier difficulties, it is impossible for players to get out of the red, but the trajectory clearly communicates that taking on higher difficulty missions will.
The punishment for failure also decreases as the game progresses to intermediate difficulty to reinforce the above idea.
The risks associated with failure also grows as game difficulty increases.
By the highest difficulty, failure is financially catastrophic with respect to progress.
The basic tuning features and relationships were replicated into a spreadsheet, and key graphs were exposed to make dynamics easier to observe.
Upsides:
It’s easier to make immediate changes and watch holistic impacts.
It’s easier to radically change assessment equations and revert those changes.
Downsides:
I’m back to observing averages and ranges.
Without more spreadsheets skills, it’s difficult to implement more robust permutational and distributive assessments, such as Monte Carlo simulations.
Results: close
By moving many of the dynamics to exponential and logarithmic functions, the basic shape was achieved according to the more detailed rhetorical goals.
By being able to more immediately observe holistic impacts to tuning values, it was easier to use more non-linear relationships, especially for assessment criteria that is meant to be more exactingly expressive without affecting the larger turning dynamics.
Example: The cost of bullets and revives goes up the more you use either, making charges from more challenging levels feel worse without negating the payout for winning.
Lessons Learned:
Starting with the fastest approach (for me, coding) was the right answer because it allowed to quickly narrow in on the scope of the problem.
In the future, defining systems dynamics with a sufficient level of detail should be done as soon as possible.
Starting in spreadsheets is the fastest to lock in larger averaged dynamics.
Using code-based approaches for permutational plotting is faster.
Overall, using a hybrid approach was necessary to get the designs iterating fast enough to yield desired results.
