# Game Design Guidelines ## Two-Player Zero-Sum Finite Deterministic Perfect-Information Games Version: 1.0-draft Purpose: design, generate, implement, filter, compare, and improve original strategy games at scale. --- ## 0. Design target This project focuses on games with all of the following properties: 1. **Two-player** — exactly two strategic players. 2. **Zero-sum** — one player's improvement is the other's loss; a convenient utility model is `+1 / 0 / -1`. 3. **Finite** — every legal play sequence must terminate, or a formal repetition/move-limit rule must convert otherwise-infinite play into a terminal result. 4. **Deterministic** — identical state + identical action always produces the same next state. 5. **Perfect information** — the complete decision-relevant state is visible to both players. 6. **Turn-based for v1** — players act sequentially. This is a project constraint for simpler implementation and analysis. Random draws, dice, hidden cards, secret simultaneous choices, fog of war, and unknown piece identities are outside v1. A draw may exist and still fit the target class. --- ## 1. The central design principle The desired shape is: > **low rule complexity + high consequence complexity** A player should be able to understand *what can be done* before they can reliably understand *what will happen*. The main source of uncertainty should not be missing information or randomness. It should be the depth of deterministic interaction: ```text clear current state + clear legal actions + deep future consequences = strategic uncertainty ``` This is the core design target. --- ## 2. Formal game model A practical machine-oriented representation is: ```text Game G = (S, s0, P, A, T, Z, U) S states s0 initial state P player to move A legal actions T deterministic transition function Z terminal-state predicate U terminal utility ``` Suggested engine interface: ```text initialState(config) -> State currentPlayer(state) -> Player legalMoves(state) -> Move[] applyMove(state, move) -> State outcome(state) -> Outcome | null stateKey(state) -> String | Hash ``` Recommended optional functions: ```text validateState(state) -> ValidationResult canonicalState(state) -> State features(state) -> FeatureVector evaluate(state, perspective) -> Number explainMove(state, move) -> Explanation ``` The last two are optional for the rules engine but useful for AI analysis. --- ## 3. Termination is a design requirement A finite board does **not** guarantee a finite game. Example failure: ```text A -> B -> A -> B -> ... ``` Every game spec must answer: > **Why can this game not continue forever?** Prefer a monotonic quantity whenever possible: - number of empty sites strictly decreases; - number of pieces strictly decreases; - available territory strictly decreases; - distance-to-goal has a one-way constraint; - blocked sites only increase; - a consumable resource strictly decreases. If no monotonic quantity exists, explicitly define one of: - threefold repetition; - positional repetition; - superko-like prohibition; - finite move limit; - no-progress counter. Termination logic must be tested. --- # Part I — Taxonomy ## 4. Treat a game as a vector of independent design axes Do not classify a game with a single genre label. Represent it as a combination of components: ```text board/topology + site model + starting state + action primitives + interaction mechanic + turn structure + objective + end condition + balancing rule ``` This allows systematic generation and comparison. --- ## 5. Board / topology axis Common topology families: | Family | Typical design effect | |---|---| | Line / path | race, opposition, blocking | | Ring | cyclic pursuit, timing | | Square grid | orthogonal/diagonal spatial tactics | | Hex grid | six-way adjacency, connection games | | Triangular grid | dense local connectivity | | Graph/network | explicit routes, hubs, bottlenecks | | Irregular region | territorial asymmetry | | Multi-layer | height, stacking, projection | | Dynamic board | topology changes during play | Also specify whether play occurs on: - `cell` - `vertex` - `edge` These are mechanically different and should be explicit in the spec. --- ## 6. Action primitive axis Useful rule primitives include: ```text PLACE STEP SLIDE JUMP HOP PUSH PULL SWAP ROTATE SHIFT STACK UNSTACK SPLIT MERGE BLOCK UNBLOCK CAPTURE FLIP CONVERT REMOVE CONNECT CUT ``` A design should usually begin with a small set. A strong default is: > 1 primary action + 1 interaction rule + 1 goal Examples: ```text PLACE + CONNECT + CONNECTION_GOAL MOVE + CAPTURE + TARGET_CAPTURE PLACE + FLIP + MAJORITY MOVE + BLOCK + REACH_GOAL ``` --- ## 7. Interaction / capture axis Interaction is a major source of depth. Candidate interaction mechanisms: - replacement capture; - jump capture; - custodial capture / sandwiching; - enclosure; - displacement; - push-off-board; - conversion / ownership flip; - line-of-sight threat; - blocking; - cutting a connection; - occupying a scarce site; - forced retreat; - resource denial. Interaction is preferred over two players independently maximizing separate scores. --- ## 8. Goal axis Major objective families: ### Alignment Create a line or pattern. Examples: - `N in a row` - exact-length line - multiple lines - shape completion ### Connection Connect target regions or edges. Variants: - two sides; - multiple terminals; - loop; - path of exact/limited length. ### Territory Control, surround, or enclose space. ### Capture / elimination Remove all enemy forces or enough of them. ### Target capture / checkmate Capture or immobilize a distinguished piece. ### Blockade Leave the opponent with no legal move. ### Race / reach Reach a destination first. ### Majority / scoring Have more controlled sites/pieces/territory at termination. ### Pattern Construct a particular graph or spatial form. ### Misère / avoidance A normally desirable event becomes losing. Example: - making the final move loses; - forming a line loses; - being forced into a region loses. --- ## 9. Turn structure axis Specify: - exactly one action; - compound move; - mandatory capture; - optional capture; - chained capture; - extra turn; - pass allowed; - pass forced only when no action exists. Every additional turn exception raises rules complexity. Default preference: ```text one turn = one clear decision ``` unless compound actions are central to the game's identity. --- ## 10. Symmetry axis A game may be: - fully symmetric; - symmetric rules, asymmetric position; - asymmetric pieces; - asymmetric objectives; - asymmetric turn capabilities. Symmetry is easy to explain but does not guarantee balance because moving first breaks symmetry. Asymmetry can increase strategic variety but is harder to balance and explain. --- # Part II — What makes a candidate strategically interesting? ## 11. Meaningful choice Do not optimize raw branching factor. Bad: ```text 17 legal moves 16 are obviously losing 1 is mandatory ``` Better: ```text 5 legal moves 3 plausibly useful each supports a different plan ``` Track both: - `legal_move_count` - `effective_choice_count` The second is more important. Operational approximation for automated testing: 1. evaluate all legal moves with a search agent; 2. find the best move value; 3. count moves within a configurable score margin of the best; 4. average across sampled states. This produces an approximate **effective branching factor** from the player's perspective. --- ## 12. Interaction Ask: > Can I ignore the opponent and simply optimize my own construction? If yes, the game may feel like parallel solitaire. Prefer mechanics where: - one move changes the opponent's options; - threat and response matter; - spatial plans collide; - tempo matters; - resources are contested; - a move can serve offense and defense simultaneously. --- ## 13. Tactical-strategic coupling Good games often support both: ### Tactics Short forcing sequences. Examples: - fork; - double threat; - sacrifice; - trap; - pin; - interception; - forced capture. ### Strategy Longer structural goals. Examples: - central influence; - connectivity; - mobility; - space; - reserve management; - route control; - shape quality. A candidate becomes stronger when short-term tactics serve long-term plans rather than existing as isolated tricks. --- ## 14. Emergent motifs Do not hard-code every interesting idea as a named rule. Prefer simple rules that cause players to discover recurring patterns such as: - fork; - ladder; - bridge; - blockade; - squeeze; - sacrifice; - zugzwang; - tempo; - opposition; - decoy; - overload; - escape route; - connection threat. A useful human playtest question: > Did players invent names for recurring situations? If yes, the rule system may be producing reusable strategic concepts. --- ## 15. Consequence permanence A strong move should usually matter for more than one ply. Avoid both extremes: ### Too reversible Every threat can be immediately undone at negligible cost. Result: - low tension; - little commitment; - noisy lead changes. ### Too irreversible One small early error permanently decides the game. Result: - low comeback potential; - weak endgame interest. Target: > consequences persist, but counterplay exists. --- ## 16. Uncertainty without randomness A deterministic perfect-information game can still be uncertain if the relevant search tree exceeds human calculation. Desired condition: ```text current rules are clear future winner is not ``` Uncertainty can emerge from: - interacting threats; - long tactical horizons; - transpositions; - competing strategic objectives; - dynamic mobility; - topology; - tempo; - local/global trade-offs. --- ## 17. Drama and comeback potential A losing player should sometimes be able to recover through superior play. However, frequent arbitrary lead switching is not necessarily desirable. Cameron Browne's LUDI work found human preference correlated with a combination including: - uncertainty; - permanence; - completion; - reasonable duration; - killer/strong moves; while excessive lead changes correlated negatively in the studied set. Design interpretation: > the game should remain contestable without making prior good play meaningless. --- ## 18. Decisiveness Avoid long "zombie phases" where the winner is effectively decided but the formal game continues. Measure: ```text decisive_point = earliest state where strong search predicts final outcome with high confidence tail_length = terminal_turn - decisive_point ``` Prefer shorter tail length. Solutions: - earlier terminal rule; - resignation support; - scoring threshold; - faster resource collapse; - remove redundant cleanup. --- ## 19. Phase progression A good game does not need explicit phases, but the *meaning* of decisions should evolve. Typical shape: ```text opening develop / claim / position midgame collide / threaten / trade / block endgame convert advantage / race / force termination ``` Warning sign: > The same local heuristic dominates equally from move 1 to the end. That can indicate shallow structure. --- ## 20. Strategy diversity Look for multiple coherent plans. Examples: - central vs edge; - expansion vs consolidation; - direct race vs interference; - material vs mobility; - connection vs territory; - fast attack vs delayed structure. Automated proxy: - cluster opening move sequences; - compare win rates of clusters; - inspect whether multiple clusters remain viable under stronger agents. --- ## 21. Clarity Depth should come from interaction, not bookkeeping. Prefer: - state visible on board; - few exceptions; - local rule explanation; - concise move legality; - consistent geometry. Avoid: - rules that require remembering many historical exceptions; - hidden counters unless displayed; - many piece types with arbitrary abilities; - special cases that exist only to patch balance. --- # Part III — Anti-patterns ## 22. Reject or redesign candidates showing these patterns ### A. Non-termination Cycles or endless reversible play. ### B. Trivial forced win A short opening sequence wins regardless of response. ### C. Forced draw basin Most competent play rapidly converges to a draw. ### D. Meaningless branching Many legal moves, very few reasonable moves. ### E. Forced-move tunnel Long sequences where only one move avoids immediate loss. ### F. Excessive volatility Good play has little persistence; evaluation swings constantly. ### G. Excessive lock-in An early small advantage becomes unrecoverable. ### H. Solitary optimization Players barely affect one another. ### I. Dominant heuristic One simple policy wins almost everywhere. Examples: - always take center; - always capture; - always move forward; - always play largest group. ### J. Dominant opening One first move or small opening family is overwhelmingly superior. ### K. Cleanup tail Outcome is clear long before formal termination. ### L. Decorative mechanics Removing a rule does not meaningfully change decisions. ### M. Exception accumulation Balance is maintained only by adding many arbitrary special cases. --- # Part IV — Balance ## 23. First-player advantage Perfect-information deterministic games frequently develop seat bias. Measure separately: ```text P1 win rate P2 win rate draw rate conditional P1 win rate excluding draws seat advantage ``` Suggested seat-advantage metric: ```text seat_advantage = abs(P1_win_rate - P2_win_rate) ``` Do not define one universal pass threshold for every genre. Store target thresholds in a **profile**. Example profiles: ```text research: seat_advantage_warning: 0.20 competitive: seat_advantage_warning: 0.10 casual_short: seat_advantage_warning: 0.15 ``` These are project defaults, not mathematical truths. --- ## 24. Structural balancing tools Preferred order: 1. adjust board geometry; 2. adjust goal threshold; 3. adjust starting position; 4. add opening restriction; 5. add swap/pie rule; 6. add compensation; 7. only then add special-case rules. The pie/swap principle is especially useful: > Player 1 chooses the initial position; Player 2 may choose which side to play. This forces the opening choice toward fairness. --- # Part V — Candidate-generation system ## 25. Represent rules as composable ludemes/mechanics A candidate should have a machine-readable mechanic signature. Example: ```yaml mechanic_signature: topology: hex site_type: cell primary_action: place secondary_action: block interaction: adjacency objective: connection termination: goal_or_board_full symmetry: symmetric ``` This follows the same broad philosophy used by Ludii: games are represented as structured combinations of rule/equipment concepts ("ludemes"), making mutation and comparison tractable. --- ## 26. Generate by controlled mutation, not unconstrained randomness Preferred workflow: ```text seed game | mutate one axis | run viability tests | keep survivors | mutate again ``` Useful mutation operators: ### Numeric - board size ±1; - line length ±1; - movement range ±1; - starting piece count ±1. ### Topological - square ↔ hex; - cell ↔ vertex; - add/remove blocked region; - graph connectivity alteration. ### Action - step ↔ slide; - capture ↔ convert; - push distance; - mandatory ↔ optional capture. ### Objective - alignment ↔ connection; - capture ↔ blockade; - normal ↔ misère. ### Balance - add swap rule; - asymmetric starting piece; - second-player compensation. ### Termination - repetition rule; - move cap; - no-progress limit. One mutation should produce an attributable metric change. --- ## 27. Maintain game families Do not treat every variant as unrelated. Example: ```text family: bridge-race v0 place + reach v1 + blocking v2 hex topology v3 push instead of block v4 swap opening ``` Record lineage: ```yaml parent: bridge-race-v2 mutation: type: replace_interaction from: block to: push ``` This makes automated search and human reasoning much easier. --- ## 28. Novelty should be measured separately from quality A game can be: - good but derivative; - novel but bad; - novel and good. Do not combine these too early. Possible novelty features: - ludeme/mechanic vector distance; - normalized rule-tree distance; - board topology difference; - action-set difference; - goal difference; - opening-state difference; - playtrace similarity. Later, maintain a corpus of accepted games and reject candidates that are too close unless intentionally creating a variant. --- # Part VI — Automated evaluation ## 29. Three-stage evaluation model ### Stage A — Correctness and viability Question: > Does the game function as a game? ### Stage B — Strategic quality Question: > Does stronger decision-making matter? ### Stage C — Human interest Question: > Is thinking about this game enjoyable? Never let a high Stage C guess compensate for a broken Stage A. --- ## 30. Stage A: mandatory correctness tests ### Determinism For any legal `(state, move)`: ```text applyMove(state, move) == applyMove(state, move) ``` including serialized replay. ### Legal move integrity Every move returned by `legalMoves` must be accepted by `applyMove`. Invalid moves must never mutate state. ### Outcome integrity A terminal state must have a consistent outcome. ### Player-turn integrity Turn progression must follow the documented rule. ### State invariants Examples: - piece count conservation; - no two exclusive pieces occupy one site; - owners are valid; - board coordinates valid; - reserve cannot be negative. ### Replay integrity Move history must reproduce the same terminal state. ### Symmetry test If rules claim symmetry, transformed positions should preserve equivalent legality/outcome where applicable. --- ## 31. Stage A: viability metrics Record: ```text completion_rate draw_rate mean_turns median_turns p10_turns p90_turns max_turns repetition_rate no_legal_move_rate illegal_state_rate P1_win_rate P2_win_rate ``` `completion_rate` should be effectively 100% under the configured playout limit unless the limit itself is deliberately part of the rules. Random playout is useful here because it cheaply discovers broken state transitions and cycles. Random playout is **not** enough to estimate strategic quality. --- ## 32. Stage B: agent ladder At minimum compare several policies: ```text Random Greedy/simple heuristic Search-small Search-medium Search-large ``` Possible implementations: - minimax; - alpha-beta; - MCTS; - retrograde solving for small games. The important property is increasing decision quality or compute budget. --- ## 33. Skill gradient A strategic game should usually reward better play. Example metric: ```text skill_gradient = win_rate(SearchLarge vs SearchMedium) + win_rate(SearchMedium vs SearchSmall) + win_rate(SearchSmall vs Random) ``` Interpretation: - near zero: strategy may not matter; - extremely steep at tiny search depth: game may be trivially tactical; - gradual improvement: promising. Do not use this metric alone. --- ## 34. Effective choice count For sampled states: ```text best = max(value(move)) effective_moves = count(move where value(move) >= best - tolerance) ``` Track: ```text avg_legal_moves avg_effective_moves forced_move_rate one_good_move_rate ``` A game with consistently high forced-move rate may feel scripted. --- ## 35. Opening diversity Collect the first `N` moves from strong self-play. Measure: - unique opening sequences; - first-move frequency; - sequence entropy; - cluster count; - win rate by opening cluster. Warning: ```text one opening > 80% of strong-agent games ``` This is not automatically bad, but it deserves inspection. --- ## 36. Outcome uncertainty Estimate winner probability over time using a strong evaluator or rollouts. Track how early predictions become stable. Possible summary: ```text uncertainty_curve[t] = 1 - abs(P(win P1 at t) - P(win P2 at t)) ``` The exact estimator may vary. We want meaningful uncertainty to survive into the game without becoming pure evaluation noise. --- ## 37. Lead changes and permanence Track evaluation from both players' perspectives. Useful metrics: - number of sign changes in evaluation; - magnitude of evaluation swings; - immediate recovery after opponent's strong move; - persistence length of a significant advantage. Interpretation: - too many lead changes -> noisy/low permanence; - no lead changes -> may be snowbally; - some recovery + persistent consequences -> promising. --- ## 38. Killer / high-impact moves A candidate should sometimes contain moves that materially alter the position. For each state: ```text move_impact = evaluation(after best move) - evaluation(before move) ``` Track distribution rather than maximizing it. Too few: - flat game. Too many: - game may be dominated by tactical blunders. --- ## 39. Decisive tail Approximate the turn where the game becomes strongly predicted. Example: ```text decisive if |estimated_value| >= threshold and remains above threshold for K plies ``` Then: ```text decisive_tail = terminal_turn - decisive_turn ``` Large values indicate cleanup. --- ## 40. Reduced-board solving Whenever state space permits, solve smaller variants exactly. Use: - minimax; - retrograde analysis; - transposition table; - symmetry reduction; - canonical state hashing. Record: ```text solved_value_from_initial distance_to_win number_of_optimal_first_moves state_count terminal_count draw_count ``` Important: A mathematically solved game is not automatically a bad game. The question is whether the solution is **humanly accessible and strategically rich**. --- # Part VII — Human evaluation ## 41. Automated metrics are filters, not the definition of fun LUDI/Ludii research demonstrates that self-play metrics can correlate with human preferences, but game quality is not reducible to one universal equation. Therefore automated evaluation should answer: > Which candidates deserve human time? not: > Which candidate is objectively fun? --- ## 42. Human playtest questions After a game, ask players: ### Comprehension - Could you predict why a move was legal? - Was the win condition always clear? ### Agency - Did your choices feel consequential? - Were there turns where no choice felt meaningful? ### Depth - Did you discover a better way to think during the match? - Would a rematch change your plan? ### Interaction - Did you need to react to the opponent? - Could you pursue your own plan without looking at them? ### Tension - When did you think the game was decided? - Was the ending too long? ### Emergence - Did recurring tactical patterns appear? - Would you give any of them a name? ### Replay - Do you want to play again immediately? - What would you try differently? --- ## 43. Strong qualitative signal A particularly good sign is: > "I lost because I now understand something I should have done differently." This suggests: - causality is legible; - skill matters; - the player learned; - replay motivation exists. --- # Part VIII — Acceptance gates ## 44. Do not use one universal hard threshold Create a target profile. Example: ```yaml profile: casual_short target_turns: median_min: 12 median_max: 50 draw_rate: warning: 0.15 seat_advantage: warning: 0.15 forced_move_rate: warning: 0.40 completion_rate: minimum: 0.995 ``` Another game family may intentionally target 100+ turns or a high draw rate. --- ## 45. Default gate order ### Gate 0 — schema Pass if: - spec is complete; - objective and termination are explicit. ### Gate 1 — correctness Pass if: - no known invariant violations; - deterministic replay passes; - legal move tests pass. ### Gate 2 — viability Pass if: - playouts reliably terminate; - no obvious pathological duration; - no catastrophic seat bias; - draw behavior is intentional. ### Gate 3 — strategic signal Pass if: - stronger agents outperform weaker ones; - game is not mostly forced; - no trivial dominant strategy detected; - opening is not obviously degenerate. ### Gate 4 — quality signal Pass if: - uncertainty lasts meaningfully; - consequences persist; - decisive tail is reasonable; - multiple plans/openings exist. ### Gate 5 — human playtest Pass if: - rules are explainable; - choices feel consequential; - players identify learnable mistakes; - replay interest exists. --- # Part IX — Design workflow ## 46. One-sentence thesis first Before rules, write: ```text Players are trying to __________ while preventing the opponent from __________. ``` or: ```text The interesting decision is choosing between __________ and __________. ``` If this sentence is unclear, the game probably lacks a design center. --- ## 47. Minimal first prototype Start with: - smallest board that can express the mechanic; - one piece type if possible; - one action; - one interaction; - one victory condition. Then play/solve. Do not start with: - 8 piece types; - special powers; - exceptions; - resource economies; - multiple victory conditions. Depth should be earned by interaction first. --- ## 48. Add complexity only to fix a diagnosed problem Bad process: ```text game feels boring -> add more rules ``` Better: ```text diagnose: - choices too reversible - center too dominant - game too long - no interaction - forced openings then: - add/change the smallest rule that addresses that property ``` Every new rule should have a stated job. --- ## 49. Rule deletion test For each non-core rule: > If this rule is removed, what important decision disappears? If the answer is unclear, remove the rule and retest. --- ## 50. Variant experiment discipline For every variant record: ```text hypothesis single conceptual change before metrics after metrics human observation decision: keep / revert / branch ``` This prevents random wandering. --- # Part X — Suggested repository model ## 51. Repository structure ```text / ├─ AGENTS.md ├─ docs/ │ ├─ game-design-guidelines.md │ ├─ game-spec-template.yaml │ └─ evaluation-protocol.md ├─ engine/ │ ├─ core/ │ ├─ search/ │ ├─ simulation/ │ └─ metrics/ ├─ games/ │ └─ / │ ├─ game.yaml │ ├─ rules.* │ ├─ README.md │ ├─ tests/ │ └─ reports/ ├─ scripts/ │ ├─ simulate.* │ ├─ solve.* │ ├─ evaluate.* │ └─ mutate.* └─ results/ └─ leaderboard.* ``` --- ## 52. Rules engine must be UI-independent Do not embed rule logic in: - click handlers; - rendering code; - animation code; - CSS state; - network handlers. UI should ask the engine for legal state transitions. This makes: - AI self-play; - exhaustive solving; - regression testing; - game mutation; - server validation possible without rewriting rules. --- ## 53. State serialization Every game state should be serializable. Recommended properties: - stable; - deterministic; - versioned; - hashable; - compact enough for transposition tables. Suggested schema: ```text { game_id, rules_version, turn, current_player, board, reserves, counters, history_digest } ``` Store full history only when rules require it. --- ## 54. Reproducible reports Every evaluation report should include: ```text game version commit hash config agent versions search budgets number of games seat-swapping policy metrics timestamp ``` Even deterministic games can produce different aggregate reports if search agents use randomized exploration, so record seeds where relevant to the evaluator. --- # Part XI — Research-backed principles ## 55. Ludii / ludemic representation Ludii represents games as structured trees of reusable rule/equipment units called **ludemes**. Its high-level game description separates: - players; - equipment; - rules; - start; - play; - end. This is an excellent conceptual model for this project even if Ludii itself is not used as the runtime. Practical takeaway: > represent rule systems as composable data, not only bespoke imperative code. --- ## 56. Automated game generation Research systems such as LUDI and more recent work such as GAVEL show a useful architecture: ```text representation -> generate/mutate -> execute -> self-play -> measure -> select -> mutate again ``` The difficult step is usually not generating candidate rules. The difficult step is **evaluating candidate quality cheaply and reliably**. Therefore engineering effort should prioritize: - stable generic engine interfaces; - simulation speed; - metric collection; - report comparison; - rule lineage. --- ## 57. Metrics should remain interpretable Do not build a black-box "fun score" too early. A candidate with score `0.82` is hard to improve. A candidate with: ```text seat_bias: high forced_move_rate: low uncertainty: good decisive_tail: poor opening_diversity: good ``` gives a clear design direction. Use aggregate ranking only after retaining component metrics. --- # Part XII — Practical starter rules for Codex ## 58. When asked to invent a new game Codex should: 1. generate 3–5 mechanic concepts; 2. express each as a one-sentence thesis; 3. list mechanic signature; 4. reject obvious clones/degenerate ideas; 5. choose the simplest promising concept; 6. produce `game.yaml`; 7. implement pure rules; 8. add invariant tests; 9. run random playout viability; 10. run a small agent ladder; 11. report weaknesses; 12. propose **one** mutation at a time. Do not implement five full games before testing any of them. --- ## 59. When asked to improve an existing game Codex should first diagnose which property is weak: ```text termination balance duration meaningful choice interaction depth uncertainty permanence decisiveness opening diversity clarity ``` Then propose the smallest rule change likely to affect that property. --- ## 60. When asked to mass-generate candidates Use a pipeline: ```text seed families ↓ controlled mutations ↓ schema/rule lint ↓ random playout ↓ viability gate ↓ stronger self-play ↓ strategic metrics ↓ novelty filter ↓ ranked shortlist ↓ human playtest ``` Store rejected candidates and reasons. Rejection data is useful for later generators. --- # Appendix A — Candidate mechanic matrix A generator can sample from this matrix under compatibility constraints. ```yaml topology: - line - ring - square - hex - triangle - graph site_type: - cell - vertex - edge action: - place - step - slide - jump - push - pull - block - flip - convert - stack - split - connect interaction: - occupation - replacement_capture - jump_capture - custodial_capture - enclosure - displacement - conversion - blocking - route_cutting objective: - alignment - connection - loop - territory - capture - target_capture - elimination - blockade - race - majority - pattern - misere termination: - objective_reached - board_full - no_legal_moves - no_pieces - fixed_resource_exhausted - repetition - no_progress_limit - move_limit balance: - symmetric - swap_rule - opening_restriction - asymmetric_setup - compensation ``` Compatibility rules should be encoded separately rather than assuming every Cartesian-product combination is valid. --- # Appendix B — Research references These are starting points, not the only authorities. - Ludii Portal — https://ludii.games/ - Ludii User Guide — https://ludii.games/downloads/LudiiUserGuide.pdf - Ludii Language Reference — https://ludii.games/downloads/LudiiLanguageReference.pdf - Soemers, Piette, Stephenson, Browne, *The Ludii Game Description Language is Universal* - Browne & Maire, *Evolutionary Game Design* - Browne, *Evolutionary Game Design* / LUDI work - Todd et al., *GAVEL: Generating Games Via Evolution and Language Models* — https://arxiv.org/abs/2407.09388 --- # Appendix C — Guiding sentence When uncertain about a design decision, prefer the option that moves the game toward: > **few rules, clear state, meaningful interaction, persistent consequences, multiple viable plans, and an outcome that remains uncertain because the future is deep—not because information is hidden.**