Mortar: Evolving Mechanics for Automatic Game Design

TL;DR

Mortar tackles automatic game design by evolving game mechanics rather than assets, using a MAP-Elites quality-diversity archive guided by an LLM to generate code-level variations. Mechanics are evaluated through end-to-end game construction via Monte Carlo Tree Search, with skill-based evaluation across five agents quantified by Kendall's $\tau$, and a Shapley-inspired CITS score to attribute impact to individual mechanics. The approach demonstrates increasing diversity and playability of generated games, with higher skill gradients and clear attribution of mechanic value, while ablations confirm the necessity of tree-search-based composition and LLM mutations. The work advances ideation tools for designers and opens avenues for richer visuals, larger design spaces, and designer-in-the-loop control, albeit with computational demands.

Abstract

We present Mortar, a system for autonomously evolving game mechanics for automatic game design. Game mechanics define the rules and interactions that govern gameplay, and designing them manually is a time-consuming and expert-driven process. Mortar combines a quality-diversity algorithm with a large language model to explore a diverse set of mechanics, which are evaluated by synthesising complete games that incorporate both evolved mechanics and those drawn from an archive. The mechanics are evaluated by composing complete games through a tree search procedure, where the resulting games are evaluated by their ability to preserve a skill-based ordering over players -- that is, whether stronger players consistently outperform weaker ones. We assess the mechanics based on their contribution towards the skill-based ordering score in the game. We demonstrate that Mortar produces games that appear diverse and playable, and mechanics that contribute more towards the skill-based ordering score in the game. We perform ablation studies to assess the role of each system component and a user study to evaluate the games based on human feedback.

Figures (5)

• Figure 1: A flow diagram of Mortar
• Figure 2: Coverage of game mechanic archive over a run.
• Figure 3: Performance metrics over evolutionary generations.
• Figure 4: AllyCraft gameplay sequence: (Top left) Initial state showing black-marked enemies to defeat and items to collect for rewards. (Top centre) Player spawns and controls allies as additional units. (Top right) Allies collect items while enemies advance each turn. (Bottom left) One ally is defeated by an enemy while simultaneously eliminating an opposing unit. (Bottom centre) Player and remaining ally attempt coordinated attack but are overwhelmed by enemies, resulting in a loss.
• Figure 5: TreasureHunt gameplay sequence: (Left) Initial game state showing treasure objective in a capture-the-flag style layout. (Centre) Player spawns at the top-left corner (blue marker) while enemies begins pursuit. (Right) Final state showing close competition between player and red-marked enemy, with victory determined by action processing order. The game features an evolved A* pathfinding algorithm for enemy movement (code in Appendix \ref{['appendixB']}).