“State” is a concept from computer science:
In computer science, the state of a computer program is a technical term for all the stored information, at a given instant in time, to which the program has access. [ref]
I feel like it is a useful concept to consider in games design.
All games require you to hold some state in your head. The best games ensure that mechanical game state is visible and apparent, and the game state that you are required to hold in your head is purely strategic.
In Chess, the position and relative capability of all the playing pieces are visible and apparent. Players need not memorise any aspect of the mechanical side of the game. Even the rules of castling require no recall. I can determine from the visible state of the game pieces whether or not my opponent has the opportunity to castle.
Chess does,however, require a player to hold a huge amount in their head. Chess requires you to hold a large number of chains of possible moves and outcomes. I’m led to believe that analysing, recognising and recalling these future states of the game is a key part of mastering the game. (I can only imagine this: I am not very good at chess). So chess demands the players hold state in their minds, but it is strategic game state, not mechanical game state.
Wargame are also filled with state. Wargames traditionally have some form of “damage” that must be tracked. Warhammer Fantasy Battle, for example, previously did it with a combination of wounds (which the game offers no solution to the tracking of) and models in a unit, which are tracked by the removal of the toy soldiers from the tabletop.
Warhammer actually did a good job of handling state. Outside of the odd spell buff, for which one could place the spell-card near the buffed unit, and ignoring multi-wound models, the majority of game state was visible and apparent, rather than opaque and recalled. The position and orientations of the units are visible and apparent. Each unit’s current remaining wounds are visible and apparent. Lots of game state is present and in plain sight, allowing both players access to the information they need to make strategic decisions, and allowing players to focus on the over-arching strategy or story of the game.
In Malifaux, by contrast, an array of counters, tokens and dry-wipe markers are required to maintain an understanding of the state of the game. There is a book-keeping phase at the end of every turn in which to adjust and record various important items of state. Like many players, I have a tin filled with custom counters, cards and dice all specifically assembled to track the various items of state in Malifaux: turn number, conditions, soul stones, model wounds, victory conditions, victory points, scheme markers, objectives, deployment zones, target numbers, the list goes on.
BendyBoards.co.uk – Steam Punk Counter Set
Malifaux is a game I like very much, but I think that there is too much mechanical state that the “out of the box” game doesn’t make visible and apparent. The players must improvise and invent their own ways to navigate and manage the high levels of opaque game state. I imagine that this is a deliberate compromise in the game design, as the inclusion of all the elements that generate this state all add to the richness of the game system, and the book-keeping remains just on the right side of onerous, compared with the reward that mastery of the game provides.
I think it is fair to say that I am not attempting to create a game with the same strategic depth as Malifaux. The design objectives of Gaslands are different: more focussed on fast play, new player friendliness, and multi-player fun. Malifaux-levels of state management would be unacceptable and stand in the way of the game’s vision.
However, currently Gaslands has a problem. The problem is that as players progress through the different phases of the turn, they have to remember which vehicles they have activated in this phase, and which are left to activate.
This has been clear in the playtest games I have been present for, and then I received exactly this feedback from a member of the playtesting community too:
“Players found it hard to keep track of the sub phase they were in; especially moving one car then having to wait before they move the second.”
Thanks Chronos, I think you’re right on the money.
To compound this problem, the unreleased v2 rules that I’m working on introduce the idea of changing gear. In order to make changing gear multiple times in a turn more risky and exciting: the player is asked to remember how many times they have changed gear this turn so far, as it affects their dice roll when determining success.
If each player is controlled a single car, this recall of state would probably be acceptable. When each player is controlling two or more cars, the complexity of the task of recalling mechanical game state quickly becomes unacceptable and not fun. Gaslands has to be fun; that’s design principle #1 (and also #5!).
In order to make the mechanical state visible and apparent, whilst keeping the core “cars move in more phases the faster they go” mechanic, I originally created a simple phase tracker. And the end of each phase, you move the counter to the next space, and the tracker makes the “current phase” state visible and apparent. Still, someone has to remember to move the tracker each phase…
The “number of stick shift attempts this turn” state is more difficult. One option is to use a tracker. Each car dashboard perhaps has a little track of boxes and I move a counter up and down the tracker to record the number of stick shifts I have done this turn. Perhaps there is an “upkeep” phase at the end of each turn when we all reset our trackers.
Another option would be to use an existing game component in a dual way. I very much like when games do this, as it feels efficient, but it can be hard to achieve. My favourite example of this is in Race For The Galaxy, where cards are both the options that you have available to build and also the resources that you need to build them.
In the v2 Gaslands rules, I have removed the “tyre points” resource, as the same game effect can be achieved by combining the concepts of tyre points and hull points: elimination a wasteful game element whilst creating a new tension between wanting to complete manoeuvres successfully and not wanted to take damage.
The game component that most directly relates to the “number of stick shift attempts this turn” is the “Handling” value. The Handling value determines the number of “Skid Dice” available, and so there are two pre-existing game elements that might be used to make the number of stick shift attempts this turn visible and apparent.
Perhaps the player starts with a number of skid dice equal to their handling and sets aside dice that have been used for stick shifts. This would likely required many more skid dice, and as custom dice this doesn’t seem helpful.
Perhaps a successful stick shift lowers your handling value for the rest of the turn, meaning that handling is a resource that dwindled across the course of a turn, resetting at the start of the next turn. Handling would then need a dice or similar to track it, but this would at least make it visible and apparent. The stick shift mechanic would then essentially be asking you to “spend a handling point” to make a stick shift attempt.
All of this just to provide some interesting transparency into the design process, and to provide an opportunity for me to express in words the approaches I am learning to use to tackle design issues.
If you have any thoughts or comments, please join us in the forums!