Pith. sign in

REVIEW 5 major objections 5 minor 30 references

Automatic Game Design via Mechanic Generation

T0 review · 5 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A generate-and-test architecture can synthesize game mechanics that satisfy design constraints and verified playability.

desk verdict New planning-based mechanic representation with a clean generate-and-test loop; the evidence is thin and the 'ensure' claim overshoots, but the idea deserves a serious referee. read the letter →

arxiv 1908.01420 v1 pith:C4M7GMMV submitted 2019-08-04 cs.AI

Alexander Zook , Mark O. Riedl This is my paper · ORCID
classification cs.AI
keywords gamemechanicsproceduralcontentgenerationAIplanninganswersetprogrammingdesignmechanicplayabilityverificationdomain-independentrepresentation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper attacks one part of the question 'can an AI design a game?' by separating game design into mechanics and content, then automating the mechanics half. The authors claim that a wide class of avatar-centric rules—spells, jumps, double-jumps, ranged attacks—can be written as planning operators with preconditions and effects, extended with time indexing and relative coordinate frames. Under that representation, a constraint solver generates candidate mechanics that satisfy hard and soft design requirements, and a planner tests whether those mechanics let a player achieve goals without violating maintenance goals (such as staying alive) or engine constraints (such as gravity). They demonstrate this loop in an RPG, a platformer, and a combined platformer-RPG, plus extensions to multilevel progressions, multiagent goals, and control mapping. The paper's central claim, read sympathetically, is that mechanic generation is tractable as a generate-and-test planning problem rather than a matter of hand-authoring genre-specific rules.

What carries the argument

The load-bearing object is the avatar-centric mechanic as a planning operator with extensions: each precondition and effect is a triple $\langle frame, time, condition\rangle$, and the $Performed(i)$ predicate lets one mechanic reference another mechanic having occurred, enabling combos such as a double-jump after a jump. The companion machinery is an Answer Set Programming constraint solver that generates candidate mechanics and an ASP-based planner that verifies playability by constructing playtraces. This machinery converts game-design questions such as 'what spells should exist in this battle?' into a search over mechanic form followed by a proof that a valid playtrace exists.

What would settle it

Give the system a game whose decisive mechanic is inherently continuous or random, such as a jump height controlled by button-hold duration or a battle that depends on a die roll, and ask for generated mechanics that meet a winnability requirement; if no combination of integer-typed preconditions and effects can represent the mechanic, the system cannot produce a verified playable set, directly testing the domain-agnostic claim.

Watch

Extended reading notes

Core claim

The central discovery is a composable, cross-domain representation of game mechanics together with a generate-and-test method that uses it. A mechanic is a tuple $\langle i, P, E\rangle$ where $i$ is an identifier, $P$ is a set of preconditions, and $E$ is a set of effects; preconditions and effects are tagged by coordinate frame (absolute or relative to the avatar) and time index, and effects can invoke another mechanic through the $Performed(i)$ predicate. The constraint solver searches over these tuples to meet design requirements, while the planner proves playability by finding a plan that reaches the goal while respecting maintenance goals and engine constraints. The authors state the claim directly: the constraint solver and planner together can generate or adapt game mechanics in a relatively domain-agnostic fashion while ensuring the mechanics achieve desired play experiences.

Load-bearing premise

The method assumes that every relevant game mechanic can be captured as a deterministic, turn-based planning operator over integer-valued state, so real-time physics, continuous control, and stochastic events sit outside the claimed domain-agnostic scope.

Editorial extensions

If this is right

  • A designer can specify only goals, maintenance conditions, and engine rules, and the system fills in the spell set or movement moveset automatically, verifying each candidate set on concrete game instances.
  • The same representation supports cross-genre recombination: RPG and platformer mechanics can be concatenated into a combined game without rewriting the state model.
  • Existing mechanics can be adapted rather than regenerated: the solver can make minimal changes to a mechanic set to satisfy new playability or design requirements.
  • The generate-and-test loop extends to multilevel progressions, multiagent goals, and control mappings by adding requirements, so generated games can be structured to teach mechanics gradually.
  • If the central claim is correct, automatic game design can be decomposed into content generation plus mechanic synthesis, with playability guaranteed up to the fidelity of the planner's model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because game instances are planning problems, the same verification loop could be inverted to generate levels that are winnable under a fixed mechanic set, connecting mechanic generation to content generation.
  • The restriction to deterministic, turn-based, integer-valued state suggests a natural stress test the paper does not run: stochastic effects such as random damage or continuous controls such as variable jump height would require probabilistic or temporally dense machinery, so the domain-agnostic claim is probably bounded by that form.
  • Mechanic adaptation reads as a constraint-negotiation primitive: a human designer could add requirements one at a time and have the rule set update minimally, which points toward a mixed-initiative design interface built on this loop.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. Zook and Riedl propose an automated game-mechanics synthesis system. Mechanics are represented as planning operators whose preconditions and effects are extended with time indices, absolute/relative coordinate frames, and performed-event references to support recombination. An ASP constraint solver generates candidate mechanics satisfying design requirements on mechanic form; a planner then checks whether the mechanics admit a playtrace satisfying goals, maintenance goals, and engine constraints on supplied game instances. The paper demonstrates the approach on an RPG spell domain, a platformer, a combined platformer-RPG domain, and sketches extensions for multi-level progression, multiagent games, and control mapping. The core generate-and-test architecture is clear, but the reported evidence is anecdotal and the playability guarantee is weaker than the paper's language suggests.

Significance. If the claims were fully supported, the paper would be a useful contribution: it formalizes a composable representation that is independent of any particular genre, it separates design (form) constraints from playability (function) constraints, and it reuses standard planning and ASP machinery rather than building a bespoke generator. The authors also deserve credit for stating the current restrictions explicitly—deterministic turn-based domains and avatar-centric mechanics—and for acknowledging that expected-gameplay-outcome reasoning is future work. However, the manuscript does not provide a systematic evaluation: the generated examples are hand-picked, there is no baseline comparison, no runtime or success-rate data, and no user study. The central assertion that mechanics 'ensure desired play experiences' is not established by the implemented planner, which proves only the existence of one satisfying playtrace. These gaps make the paper a promising systems/position piece rather than a validated result.

major comments (5)
  1. [Playability Checking; Introduction; Conclusions] The strongest claim in the Introduction—that the mechanics 'ensure desired play experiences'—is not supported by the implemented playability check. The planner in the Playability Checking section proves only that there exists at least one plan achieving the designer-specified goals while maintaining the maintenance goals and respecting engine constraints. Existence of a plan is a much weaker property: a mechanic set can be playable in this sense yet have a single contrived winning trace, with most sequences of player choices ending in failure. The Conclusions concede that 'reasoning over the space of potential gameplay outcomes will be needed to control for expected gameplay outcomes,' which is exactly the missing property. The claim should be weakened to 'admits a playtrace meeting specified requirements on the supplied instances,' or the playability checker should be extended to reason about plan quality or outcome distributions.
  2. [Examples] The evaluation is anecdotal. The Examples section reports only a handful of mechanics, and the authors note that 'our examples were chosen to illustrate the most semantically sensible mechanics generated; by definition all mechanics achieve playability and design requirements.' This selection introduces a positive bias: we learn nothing about how often generation succeeds, what fraction of generated sets are usable, how results vary across instances or random seeds, or whether the constraint-solver-plus-planner loop outperforms simpler baselines such as random enumeration or hand-authored mechanic sets. Adding a systematic study—success rates, runtime, diversity of generated mechanics, and comparison with a baseline—would substantially strengthen the paper's central demonstration.
  3. [State Model; Mechanic Model] The cross-domain claim is supported only by three hand-specified domains that all fall within a narrow formal class. The State Model section states that the representation 'currently focuses on turn-based domains with deterministic actions,' and the Mechanic Model restricts parameters to integer ranges with simple update effects. Real-time physics, stochastic events, and continuous control are outside the formalism. This is an acceptable scope restriction if labeled as such, but the Abstract's 'cross-domain' and the Introduction's 'relatively domain-agnostic' wording overstate the demonstrated generality. I suggest either qualifying these claims or testing the representation on a genuinely different genre outside the current class.
  4. [Mechanic Generation; Mechanic Formalization] The playability guarantee is instance-specific, not domain-wide. The Mechanic Generation section defines playability checks over 'a provided set of game instances,' and the aspiration that the set might be 'all valid game instances in that space' is not realized in the implementation or evaluation. As a result, even the existential guarantee in my first comment holds only for the few hand-chosen levels and battles tested. The paper should state this limitation explicitly and, if the claim is meant to be stronger, verify playability over an exhaustive or representative set of instances.
  5. [Mechanic Adaptation; Richer AI Design] The sections on mechanic adaptation, multi-level progression, multiagent games, and control mapping are described only at a prose level. No generated mechanics, playtraces, or quantitative results are reported for these extensions, so the reader cannot verify that the proposed extensions work as claimed. If these capabilities are part of the paper's contribution, they need at least illustrative examples and, ideally, the same kind of evaluation as the core system; otherwise they should be explicitly marked as planned future work.
minor comments (5)
  1. [Related Work] There is a duplicated word: 'can can generate games' should read 'can generate games.'
  2. [Mechanic Design Formalization] The phrase 'a transition models (mechanics)' should be 'a transition model (mechanics).'
  3. [Mechanic Design Formalization] The definitions of hard and soft design requirements are given only in prose; a compact formal syntax or a table of encoding choices would make the approach easier to reproduce.
  4. [Platformer] Figure 1 is referenced in the Platformer section, but the figure is not visible in the submitted text; please ensure the figure is included and that the caption fully explains the arrows, the dotted gravity arrows, and the goal marker.
  5. [Mechanic Generation] The paper does not state whether the ASP encodings or the planner implementation are available; adding a reproducibility statement would help readers assess and build on the system.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the generate-and-test pipeline is self-contained and makes no fitted prediction.

full rationale

The paper's contribution is a generate-and-test pipeline: an ASP constraint solver synthesizes planning-operator mechanics subject to hard and soft design requirements, and an ASP planner verifies that, on given game instances, a plan exists satisfying goals, maintenance goals, and engine constraints. There are no fitted parameters, no quantities predicted from data, and no uniqueness claims resting on self-citation. The statement 'by definition all mechanics achieve playability and design requirements' is a description of the solver's acceptance criterion, not a derived prediction; the examples are demonstrations of expressiveness rather than empirical confirmations. The central weakness, that the planner proves only existence of one playtrace and the paper itself notes that 'reasoning over the space of potential gameplay outcomes will be needed to control for expected gameplay outcomes,' is a gap between the formal playability check and the advertised 'desired play experiences.' That is a correctness or scope concern, not circularity: no load-bearing step reduces to its own input by construction or by self-citation.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical entities, forces, or dimensions. Its inventions are representational: time-indexed preconditions/effects, absolute and relative coordinate frames, and the Performed(i) event. These are logical constructs, not falsifiable physical entities. The free parameter is the hand-chosen weighting of soft design requirements, which is not reported. The axioms listed are the domain assumptions that the central claim rests on.

free parameters (1)
  • Soft requirement weights and priorities
    The paper states soft requirements 'optimize over weighted and prioritized sums of terms' (Mechanic Generation section) but never gives the exact weights used to produce the shown mechanics. These choices affect which mechanics are selected and are hand-chosen by the authors.
assumptions (4)
  • domain assumption Game mechanics can be modeled as planning operators with preconditions and effects, plus time-indexing and coordinate frames.
    The entire framework in the Mechanic Model section depends on this expressivity claim; no proof is given that all avatar-centric mechanics fit this representation.
  • domain assumption Inertial state and circumscription: unchanged parameters persist; Performed(i) is an event not subject to inertia.
    Adopted from PDDL in the Mechanic Model section; required for the semantics of state updates and event references.
  • domain assumption Game domains are turn-based and deterministic.
    Explicitly restricted in the Mechanic Model section ('Currently we focus on turn-based domains with deterministic actions'); this limits the generality of the cross-domain claim.
  • domain assumption Playability is captured by goals, maintenance goals, and engine constraints in a planner.
    The paper equates the existence of a plan that meets these formal requirements with a playable game; no human-subject or external validation supports this equivalence.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Automatic Game Design via Mechanic Generation." pith.science (2026). https://pith.science/paper/C4M7GMMV

@misc{pith2026190801420,
  author       = {Pith},
  title        = {Pith review of: Automatic Game Design via Mechanic Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/C4M7GMMV}},
  note         = {Machine review of arXiv:1908.01420}
}
read the original abstract

Game designs often center on the game mechanics---rules governing the logical evolution of the game. We seek to develop an intelligent system that generates computer games. As first steps towards this goal we present a composable and cross-domain representation for game mechanics that draws from AI planning action representations. We use a constraint solver to generate mechanics subject to design requirements on the form of those mechanics---what they do in the game. A planner takes a set of generated mechanics and tests whether those mechanics meet playability requirements---controlling how mechanics function in a game to affect player behavior. We demonstrate our system by modeling and generating mechanics in a role-playing game, platformer game, and combined role-playing-platformer game.

Figures

Figures reproduced from arXiv: 1908.01420 by the authors.

Figure 1
Figure 1. Platformer level showing a playtrace using a gen [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 29 canonical work pages

  1. [1]

    write newline

    " write newline "" before.all 'output.state := FUNCTION fin.entry add.period write newline FUNCTION new.block output.state before.all = 'skip after.block 'output.state := if FUNCTION new.sentence output.state after.block = 'skip output.state before.all = 'skip after.sentence 'output.state := if if FUNCTION not #0 #1 if FUNCTION and 'skip pop #0 if FUNCTIO...

  2. [2]

    Andersen, E.; Gulwani, S.; and Popovi\'c, Z. 2013. A trace-based framework for analyzing and synthesizing educational progressions. In ACM SIGCHI Conference on Human Factors in Computing Systems

    work page 2013

  3. [3]

    Baral, C. 2003. Knowledge Representation, Reasoning and Declarative Problem Solving . Cambridge University Press

    work page 2003

  4. [4]

    M.; Liu, Y.-E.; and Popovi\'c, Z

    Butler, E.; Smith, A. M.; Liu, Y.-E.; and Popovi\'c, Z. 2013. A mixed-initiative tool for designing level progressions in games. In ACM Symposium on User Interface Software and Technology

    work page 2013

  5. [5]

    Cook, M.; Colton, S.; Raad, A.; and Gow, J. 2013. Mechanic M iner: Reflection-driven game mechanic discovery and level design. In EvoGAMES

    work page 2013

  6. [6]

    Dormans, J. 2009. Machinations: Elemental feedback structures for game design. In GAMEON-NA

    work page 2009

  7. [7]

    Dormans, J. 2010. Adventures in level design: Generating missions and spaces for action adventure games. In 1st Workshop on Procedural Content Generation in Games

    work page 2010

  8. [8]

    Dormans, J. 2012. Generating emergent physics for action-adventure games. In 3rd Workshop on Procedural Content Generation in Games

    work page 2012

Show all 30 references
  1. [9]

    E., and Nilsson, N

    Fikes, R. E., and Nilsson, N. J. 1972. STRIPS : A new approach to the application of theorem proving to problem solving. Artificial Intelligence 2:189--208

    1972

  2. [10]

    M.; Mahlmann, T.; Manrique, D.; and Togelius, J

    Font, J. M.; Mahlmann, T.; Manrique, D.; and Togelius, J. 2013. A card game description language. In Applications of Evolutionary Computation . Springer. 254--263

    2013

  3. [11]

    Fullerton, T.; Swain, C.; and Hoffman, S. 2008. Game Design Workshop: A Playcentric Approach to Creating Innovative Games . Morgan Kaufmann

    2008

  4. [12]

    Gebser, M.; Grote, T.; and Schaub, T. 2010. Coala: a compiler from action languages to ASP . In Logics in Artificial Intelligence . Springer. 360--364

    2010

  5. [13]

    Lavelle, S. 2013. Puzzle S cript. website

    2013

  6. [14]

    Love, N.; Hinrichs, T.; Haley, D.; Schkufza, E.; and Genesereth, M. 2008. General game playing: Game description language specification. Technical report, Stanford University

    2008

  7. [15]

    Mahlmann, T.; Togelius, J.; and Yannakakis, G. N. 2011. Towards procedural strategy game generation: Evolving complementary unit types. In Applications of Evolutionary Computation . Springer. 93--102

    2011

  8. [16]

    McDermott, D.; Ghallab, M.; Howe, A.; Knoblock, C.; Ram, A.; Veloso, M.; Weld, D.; and Wilkins, D. 1998. PDDL - the planning domain definition language. Technical report, Yale Center for Computational Vision and Control

    1998

  9. [17]

    J., and Mateas, M

    Nelson, M. J., and Mateas, M. 2008. Recombinable game mechanics for automated design support. In 4th AAAI Conference on Artificial Intelligence and Interactive Digital Entertainment

    2008

  10. [18]

    Osborn, J.; Grow, A.; and Mateas, M. 2013. Modular computational critics for games. In 9th AAAI Conference on Artificial Intelligence and Interactive Digital Entertainment

    2013

  11. [19]

    J., and Norvig, P

    Russell, S. J., and Norvig, P. 2009. Artificial Intelligence: A Modern Approach . Prentice Hall, 3rd edition

    2009

  12. [20]

    Salen, K., and Zimmerman, E. 2003. Rules of Play: Game Design Fundamentals . Cambridge Mass.: MIT Press

    2003

  13. [21]

    Schaul, T. 2013. A video game description language for model-based or interactive learning. In IEEE Conference on Computational Intelligence in Games

    2013

  14. [22]

    M., and Mateas, M

    Smith, A. M., and Mateas, M. 2010. Variations F orever: Flexibly generating rulesets from a sculptable design space of mini-games. In IEEE Conference on Computational Intelligence and Games

    2010

  15. [23]

    Smith, A., and Mateas, M. 2011. Answer set programming for procedural content generation: A design space approach. IEEE Transactions on Computational Intelligence and AI in Games 3(3):187--200

    2011

  16. [24]

    M.; Butler, E.; and Popovi\'c, Z

    Smith, A. M.; Butler, E.; and Popovi\'c, Z. 2013. Quantifying over play: Constraining undesirable solutions in puzzle design. In 8th International Conference on the Foundations of Digital Games

    2013

  17. [25]

    M.; Nelson, M

    Smith, A. M.; Nelson, M. J.; and Mateas, M. 2010. LUDOCORE : A logical game engine for modeling videogames. In IEEE Conference on Computational Intelligence and Games

    2010

  18. [26]

    Swink, S. 2009. Game Feel: A Game Designer's Guide to Virtual Sensation . Morgan Kaufmann

    2009

  19. [27]

    Thielscher, M. 2010. A general game description language for incomplete information games. In AAAI , volume 10, 994--999

    2010

  20. [28]

    Togelius, J., and Schmidhuber, J. 2008. An experiment in automatic game design. In IEEE Symposium on Computational Intelligence and Games

    2008

  21. [29]

    Togelius, J.; Yannakakis, G.; Stanley, K.; and Browne, C. 2011. Search-based procedural content generation: A taxonomy and survey. IEEE Transactions on Computational Intelligence and AI in Games 3(3):172--186

    2011

  22. [30]

    Treanor, M.; Schweizer, B.; Bogost, I.; and Mateas, M. 2012. The micro-rhetorics of G ame- O - M atic. In 7th International Conference on the Foundations of Digital Games

    2012

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.