When my brother and I were kids, we mapped the entire Car Wars turn structure onto a 2' × 3' sheet of paper. We began with the basic sequence and then expanded every box. Movement, firing, damage allocation, handling checks, vehicle-specific exceptions, optional rules: each one opened into further branches, nested conditions, and special cases. By the time we finished, the sheet was a dense thicket of decision trees.
We ran large games, often sixty cars or more. Once the full flowchart existed, the repeated patterns became impossible to ignore. The same low-value checks, the same special-case loops, the same mental overhead occurred for every vehicle on every turn. What had felt like normal complexity at the table revealed itself as structural waste under sustained load. The exercise changed how we saw the game. It also taught a lasting lesson: systems look cleaner until someone is willing to draw the whole decision path.
That practice remains underused in tabletop design.
In semiconductor engineering, flowcharting and cycle analysis are standard because every wasted step compounds across millions of operations. Tabletop games rarely face equivalent pressure. A ruleset that feels “good enough” in ordinary play can persist for decades even when its highest-frequency loops contain repeated, low-value branches. Players adapt. The friction becomes habitual and therefore invisible. Only when the process is externalized does the cost become countable.
Two prominent design cultures illustrate the problem from opposite directions.
In mainstream 5E, the skill system has been elevated from an occasional specialist tool into the primary interface for interacting with the world. Almost every attempted action is expected to pass through a named skill, then through feats, subclass features, buffs, and possible re-rolls. The checklist is short in isolation. Under the repeated load of a full session, it becomes a constant tax on attention. The character sheet turns into the default lens, and the fiction waits its turn. Mapping the decision path makes the cumulative cost obvious.
In much of the OSR, a different failure mode appears. Procedures that were present in early editions are frequently preserved less because they still produce the best current play experience and more because they were present in the original experience. Awkward resolution methods, high bookkeeping, and nested special cases are defended as authentic texture. Critiquing them is often treated as a failure to understand the tradition rather than an examination of whether the procedure still earns its complexity. Nostalgia becomes a preservative for inefficiency.
Both positions share a common weakness. They substitute identity or memory for structural analysis. One side treats expanded interface complexity as sophistication. The other treats inherited friction as heritage. In neither case is the highest-frequency loop forced to justify every branch under realistic session load.
A common reply is that games are not about optimization. They are about memories, feelings, and shared experience. The objection has force. No one sits down at a table primarily to maximize throughput. The goal is the chandelier swing, the desperate rescue, the moment the plan collapses into something better.
Yet repeated inefficiency is a poor substitute for those experiences. When a system demands constant returns to the character sheet, repeated inventory of modifiers, and nested special cases simply to resolve ordinary actions, it consumes the very attention and energy that should be available for the fiction. The mental effort spent sifting through rules and sheet references is effort no longer spent imagining the chandelier, reading the room, or deciding how to save the princess.
The point is not to turn play into an engineering exercise. It is to notice when the interface has begun to compete with the experience it is supposed to deliver. A procedure that once felt like part of the charm can, under sustained load, become an obstacle to the very memories and feelings the game exists to create.
The healthier approach is selective and diagnostic. Externalize the decision trees for the actions that occur most often. Count the low-value steps. Distinguish friction that creates meaningful decisions from friction that mainly survives on familiarity or scene loyalty. Keep what still serves the intended play experience. Be willing to retire what does not.
Flowcharting will not resolve every design disagreement. It does, however, make certain kinds of disagreement harder to sustain. Once the full path is visible, arguments that rest primarily on “this is how it was done” or “this is our style” lose some of their protective cover. The conversation is pulled back toward evidence: does this procedure still earn the mental effort it demands when it is repeated dozens of times in a single session?
Most published games still ship without anyone having drawn those trees for their core loops. The result is predictable. Inefficiencies remain invisible until someone finally maps them, at which point the patterns (whether industrial skill interfaces or nostalgic special cases) look remarkably similar. They are simply the shape of unexamined tradition under load.
No comments:
Post a Comment