Game Design - State Space

NOTE: This is a cross-post from an entry I made at Delta Vector within the game-design forums.

In Regards to State Space

When designing a game I think there are several realms of concern in regards to state space, that abstract realm where information is kept for use by players in order to make wise decisions during a game.  These realms of concern are public vs. private information, presentation, state complexity, and hidden dependencies.

Public vs. Private Information

These are two different ways for presenting state information.

1. Public - Information that is public is displayed for all to see. This usually is information readily apparent to all players and typically presented between the each of them upon a game board or playing field. Public information is often made known with tokens or markers upon a track or made proximate to the physical thing to which is modifies or signifies. Ease of play is a feature of public information because what a player needs to know is visible before them.
2. Private - Information that is private is recorded for a single player to see; the one controlling the recording. This information usually is logged and is only available upon request to other players. There's some mechanical advantage here as well; a private ledger can keep track of a lot of information.
   
   As a result of the information being private, to request a value is a "slow mechanic" which makes a game take longer to play. because a communication sequence must be pursued.
   
   You can imagine this silly exchange between two players;
   
   [ Jim ] What is the status of your knight, is he wounded?
   [ Rob ] Yep.
   [ Jim ] How about on fire. Is he on fire?
   [ Rob ] Yep.
   [ Jim ] Charmed or not?
   [ Rob ] Not charmed.
   
   etc. essentially the players in the above exchange are doing some variation of Go Fish!

State Representation

State representation are common ways to show, typically, public information in some ubiquitous manner.

1. Presuming that a game design is a tactical boardgame, the one common bit of state information is the position upon a field of play. 
2. Some games allow a figurine to face forwards or backwards; their orientation informs others when a model becomes vulnerable to a bonus "stab-in-the-back" attack.
   
   -- Games like Strange Aeons allow models to face up or face down to show Knocked-out or Out-of-Action. Presuming they have a facing [ if they aren't Flying Polyps  ].
   -- Many games show status like "on fire" with strips of wool.
   -- Or, in Blackpowder; the rules use white cotton ball "puffs" to show that a model has fired its weapon.
   
3. In mostly boardgame designs, public information is shown upon tables or charts with tokens.
   
   -- In Advanced Civilization there exists the time track showing where a player's civilization is in position to another.
   -- In many heavy Euro-style games where each player presents a tracking board for their resources. Like in Power Grid.
   -- At the minimum there would be a victory point track.
   
4. In card games, the cards themselves become public information when played. They'll serve multiple state fields; as assets, as resources, as terrain, and as modifiers.

State Complexity

This is a combinatoric feature of a game design. The more discrete states there are, the more combinations there can be.

1. This is where, for me, a game becomes interesting because it allows opportunities for players to manage the "state space".
2. However, by having too many statuses, the game can become slower because the state space - the total matrix of state combinations - grows very large. This usually requires more time to think things out and for people who experience "analysis paralysis" this will cause them to utilize deeper mini-max optimization.
3. One thing which helps flatten the time to analyze state is the commonality of representation. A game board, especially a simple grid or open field with easily recognizable "terrain" is much simpler to parse by our ability to do visual pattern recognition. So though a battlefield for a tactical game is large, we don't usually think that it makes a game any more complex. Same goes with the orientation of a model, its facing, or whether it "on fire" or "has fired".
4. Other things are harder to parse, even when the presentation is clear and public. Such as weapon reach of 1-inch or 2.5-cm from the center of a model, or yaw and pitch or whether a model is flying at 4-Altitude or 5-Altitude without resorting to gimbaled telescoping flight stands.
5. Regardless, the more state the more interesting combinations there can be. "KO'd", "Fired", "Done", "Sprinted", "Hidden", "Facing", "Position", "Panicked". You can imagine the combinations here and how game play could change dramatically.
6. And with each state, there could be rules to manage those states. But too many states and then the game gets too complex to play quickly or to play at all.

Hidden Dependencies

Hidden dependencies are things that make the game operate as intended but are not declared explicitly with a rules set.

1. In well written rules for boardgames, there will be an inventory of all game assets similar to this list;
   
   -- 1 x battlefield
   -- 4 x dice "red", "yellow", "blue", and "green".
   -- 120 x models each with its own stat card.
   -- 32 x status tokens for "on fire", "hidden", and "panicked".
   
   Having something like that at the preface of a rules set is very nice. Maybe the rules might include something like this as well;
   
   "this game include 32 copies of a private ledger for recording and tracking campaign game progress. You are free to photocopy for your own non-commercial use".
   
2. What I see in tabletop miniatures games is usually something different. Typically there is nothing like an inventory at the start of the game rules. I think part of it is that the nature of the genre allows for some flexibility on which available models there could exist for play in the game, as well as what sorts of battlefield terrain such as buildings, trees, and hills could be available.
   
   However, it would be nice if I could see something like:
   
   "This game requires a minimum of 4 models per player, 8 pieces of terrain representing hills, trees, or buildings, and 10 six-sided dice."
   
3. Another category of hidden dependency is status tracking. It may not be until later in a particular set of rules I might read and discover that I need to somehow identify a model as a "Big Man" or that I have to track that a machine gun is "Out-of-Ammo" or that a unit is "Routed" or that a squad is "Suppressed".
   
   These are all interesting state complexity values with their own rules and I like it, but I'd prefer to have such things made known at the front of the game rules.

The Ledger

Lastly is the ledger, or commonly known as the record sheet. Some games just identify this is as "the log".

1. Games like Warmachine have explicitly available datacards for private information tracking which have stat lines, model-assigned-rules, and then a suite of checkboxes to mark damage received. These in principle I have no problem with regardless of how fiddly such a feature is because they are made known as a game feature within the rules by their very presence.
2. However, many games in order to reduce publicly represented state information clutter move that information into private control and management. This is a reasonable trade-off but what will happen is that the tracking of that information is often implicit (maybe through omission, maybe through intent) and also declared (if at all) late into the rules set.
   
   Or not; sometimes it seems that it is up to the consumer of the rules to decide and I think this is bad practice and also makes it harder to learn a game.
   
3. For example, a model might have 5 weapons each of which could be in these states;
   
   -- "Nothing changed",
   -- "Destroyed", or
   -- "Out-of-Ammo".
   
   For a single model, that is something like 0 to 10 statuses to track just for its weapons Where to display this information? Publicly? Nope, on a ledger. But for some games there is no ledger provided by the rules or indicated by the phrasing of the rules.

Trade-offs

I think that to limit a game design to some arbitrary fixed number of states active or otherwise is a designer's choice. There are always trade-offs.

1. Many games, card games especially, and in particular Magic: The Gathering; have dozens of states categorized into a dozen state fields with each field being something like "in hand", "discards", "in play", etc. 
2. The multiplier as a result of all these combinations can create humongous state spaces which are time-consuming to search through.  If players were to compartmentalize these using some sort of heuristic strategy for visiting and analyzing, then the game becomes manageable.
   
   So, for example, M:tG has this thing called The Layer System which groups states into categories of effects. Each category then groups state modifiers within them.
   
3. Something I think is already understood by most players if not most designers is that complexity (and time to resolve) increases with the number of players involved and the number of assets involved. It'd be nice to have a deeply intricate game allow inclusion of a third or fourth player, but it probably is too complex to resolve quickly.
4. The more assets (units, models, figures) which are in play also is a state field and also increases the complexity of the game. Imagine a game between two "flying battleships", each with detail on the level of Starfleet Battles.
   
   It might take 1 hour. Imagine such a game with 16 such vessels in play ... the game might take 1 hour or more likely ... ? 6 hours?  Take that an then divide those 20 ships across 10 players instead of two players; the game will definitely take longer because of at least two additional factors; transition of flow between more players is a friction because it is a physical/social mechanism.
   
   And the last is that the search space is larger since each player - were they computers or persons with "analysis paralysis" - would want to optimize their moves they'd have to regard additional combination.
   
   BTW, I did this last thing; 16 ships and 10 players using all of the Starfleet Battles rules we knew at the time. It took 6 hours. I think in SFB circles, this is a "medium length" game session. =)
   
5. I presume that game designers would want to have a sense of how much time they would want a standard game session to last. At that point, they scale down (or scale up) the available complexity in their design. Then they'd do some math regarding available assets and divide.
   
   For example, I'd rather that a game take at most 90 minutes per session for 5-11 units each player or about 16 units in total for all players. I'd want to have at least 5 player Turns each (5 Rounds), and so this would be 90 minutes divided by 5 Rounds is 16 minutes per round. Divided by 16 units means an average processing time of 1 minute per asset. That's about 8 minutes per player.
   
   Therefore if I can get move + combat down to that average per asset, then my design is as I have intended. If resolution time runs slower, then I need to trim my state space and reduce complexity by removing some statuses. If not, then I shouldn't be too surprised that it takes 6 hours.
   
6. If I were to want to make that Starfleet Battles game as fast as 90 minutes to resolve, then I'd need to remove or simplify lots of the features. I'd probably start by reducing the impulse chart from 32-impulses down to 8-impulse. Then the energy record sheet would need to be simplified. Then the Damage Allocation Chart would need to be simplified. Then the number of tactical options (HET, Wild Weasel, Transporter bombs, Boarding Parties, etc) would need to be trimmed. Etc.
   
   There's a lot of cruft to remove! It'd be a different game afterwards and maybe would require being given a new name, like "Starfleet Commander" or "Federation Border" or something.