Game Systems Design

Design the behavior of a game across time, not just a list of features. Connect the intended player experience to explicit state, rules, feedback, and evidence.

Remain engine-agnostic. Express behavior with state tables, equations, diagrams, transition rules, and pseudocode unless the user names an implementation environment.

Core Principles

• Treat the system boundary as a design choice made for a specific question and time horizon.
• Model parts by their state and behavior, then model the relationships that let those parts change one another.
• Distinguish reinforcing feedback, which amplifies change, from balancing feedback, which opposes deviation. Neither is inherently good or bad.
• Define a core loop as the repeated intent-action-state change-feedback cycle holding the player's immediate attention.
• Define a meta loop as a slower cycle that changes the conditions of future core-loop attempts, sessions, or chapters.
• Separate game truth, player-visible evidence, and the player's likely interpretation. A rule the player cannot infer cannot reliably support planning.
• Prefer a few reusable rules with meaningful interactions over many exceptions.
• Prototype the riskiest assumption before polishing or expanding the system.
• Treat playtest comments as evidence of an experience or problem, not automatically as the correct solution.
• Keep intent, model, prototype, implementation, and current evidence traceable to one another.