|||
State management is part of your game design whether you like it or not. In games, you can think of state as anything that you keep track of as a player which changes over time and is governed by the rules. As a simple example, the state of a chess piece is its position on the chess board. The board itself does not change. It is stateless.
Each piece of state has a different rate of change. In a role-playing game, armor class may not change from session to session, but hit points may change several times in a single encounter. Whenever you add state to your game, it’s more work for the players. Spare a thought for the weary - consider what your players must endure in order to run your game (looking at you Gloomhaven).
If you want to reduce a game’s cognitive overhead, an easy way to do it is to remove state from your design.
For example, imagine a game where each enemy has an amount of health. When the enemy reaches 0 health, they go from alive to dead. One way to simplify this design would be to assign each enemy a static toughness rating. When a character attacks the enemy, if they roll over the toughness rating, the target is dead. Now you’re tracking half as much state.
Other examples include encumbrance and ammunition. For better or worse, many players and designers remove these from the game rather than attempt to keep up with the extensive math required to manage this frequently changing state.
Sometimes, state is further complicated in attempts to simplify. Here’s the text of the usage die rule from The Black Hack, used for tracking arrows:
USAGE DIE
Any item listed in the equipment section that has a Usage die is considered a consumable, limited item. When that item is used the next Minute (turn) its Usage die is rolled. If the roll is 1-2 then the usage die is downgraded to the next lower die in the following chain:d20 > d12 > d10 > d8 > d6 > d4
When you roll a 1-2 on a d4 the item is expended and the character has no more of it left.
In a perfect world, this evokes the carefree feeling of having a ton of arrows, followed by anxiety as they rapidly become scarce. While that psychological sleight-of-hand may be desirable, you’re still tracking ammunition. This rule is meant to annihilate the nitty-gritty details that we don’t care to manage, like an exact number of arrows in your quiver. You need to ask the question: is the juice worth the squeeze?
Compare it to this:
At the end of any combat where arrows are used, roll a d10. If the result is a 1, you only have 1 left.
The depletion curve is sharper, but it’s also a lot less to track. You either have d10 or 1. Is the feeling the same?
State can also be managed as a series of changes to an initial value. Try formulating rules so that the referee can keep track of state by writing something down that they never have to erase and rewrite. Never erase, only append.
An example from role-playing games is managing the duration of a light source. You might be tempted to track a torch like hit points. Here’s an example from Jared Sinclair’s Anti-Sisyphus 1:
TIME AND LIGHT
Whenever a PC lights a candle, torch, or lantern, etc., roll its appropriate die in secret:Torch: d6
Candle: d8
Lantern: d12When the PCs enter a new room or have an encounter, tick each die down by one. When a die would tick down to 0, the light source goes out.
This has us updating the state of a light source every turn. Provided you are tracking time, you could instead load your light source mechanic onto that abstraction:
T5: Agrias lit torch, lasts 6 turns
A good stateful abstraction like Time can bear many loads:
T4: searched skull room
T5: Agrias lit torch, lasts 6 turns
T6: Buzrulf quaffed Potion of Growth, lasts until turn 9
T7: battle with catoblepas
It’s more writing, but less erasing and updating. Your T5 note never has to be changed. If you had to step away from the game and return to this event log, would you be able to tell at a glance if the players were illuminated or in darkness?
Tracking your state as a sequence of events yields useful properties. First, you can determine what the state was at any point in the sequence, which is useful if you’re trying to simulate a lot of entities in a living, breathing game world. Second, if you make a mistake, you can “rewind” to that point in time, make the adjustment, and then find out the consequences by replaying subsequent events.