RuleSweeper: Procedurally Generating
Gameplay Mechanics in Minesweeper

Ryan Fleishman · Teddy Clark · Shresth Kapoor · Jan Borowski · Tim Merino · Julian Togelius
New York University · IEEE CoG 2026

Abstract — Procedural content generation in games has traditionally focused on producing new levels within a fixed set of game mechanics, but there is much less work around generating the mechanics themselves. Mechanic generation introduces a central challenge absent from standard PCG: the evaluation environment becomes dynamic, so fixed game-playing agents may fail as the rules evolve. We present an adaptation of the MORTAR pipeline that addresses this problem by both generating mechanics and adapting a solver agent for the puzzle game Minesweeper. Our system mutates mechanic components within a structured game configuration using a large language model, evaluates each candidate through play with both fixed and LLM-adapted agents, and lets the search process continue into mechanic spaces that standard evaluators cannot reliably handle. The resulting pipeline produces playable, mechanically distinct puzzle variants, while the LLM-boosted solver achieves consistent gains over a fixed symbolic baseline across the generated mechanic archive.

What the paper does

Most procedural generation makes new levels for a fixed rule set. RuleSweeper instead generates new rules. We adapt MORTAR to a fixed Minesweeper engine whose every mechanic — board size, mine count, health, clue encoding, adjacency (neighborhood), reveal behavior, mine behavior, and win condition — lives behind a single structured GameConfig object. An LLM mutates that configuration, and for deeper changes it authors brand-new Python subclasses for one of five mechanic families (mine behavior, reveal strategy, clue/info strategy, neighborhood, and win condition).

MechanicArchiveSelect Parentmechanic / configLLM MutationInstantiateMinesweeper variantparameter changesnew mechanic codeAgent EvaluationRandom · PAFG · PAFG-LLMFitness / Selectioncompare agent performance
Fig. 1 — Mechanic-evolution pipeline for Minesweeper-MORTAR.

Each candidate is instantiated, played, scored, and — if it separates skilled from random play — folded back into the archive to seed future mutations.

The core challenge: a moving evaluation target

When you mutate mechanics, the environment used to judge a game keeps changing. A solver tuned to standard Minesweeper stops being a reliable yardstick once clue meaning, adjacency, or the win condition drift away from canonical. Perfect-information search like MCTS breaks down because Minesweeper is only partially observable and the forward model keeps shifting.

The method: a solver in the loop

Each candidate mechanic is scored by a panel of agents playing many seeded games:

A mechanic is interesting when a skilled agent extracts substantially more progress than random play. We measure each agent's progress fraction Pa — the average safe cells it reveals out of the S = r·c − m safe cells on the board — and define the selection signal, skill spread, as the best skilled agent's progress minus the random agent's:

Pa=average safe cells revealed by aS
skill_spread=maxa ∈ A \ {random}Pa − Prandom

Candidates are admitted to a persistent archive only when skill spread ≥ 0.10, and future mutations are sampled from that archive with a MAP-Elites-style procedure.

Results

Over a 100-iteration run on Claude Sonnet, 51 mechanics were admitted to the archive. The LLM-adapted solver (pafg-llm) beat the fixed symbolic PAFG baseline on higher progress for 36 of 51 mechanics (70.6%) and on win rate for 40 of 51 (78.4%), with a mean win-rate gain of +0.41. The largest improvements came exactly where a fixed solver's assumptions break — mechanics that obfuscate clue meaning or change adjacency.

AgentWinsProgressTurns
Random032.6%5.8
PAFG8091.9%104.4
PAFG-LLM8697.7%99.1

Table I from the paper — agent performance on canonical 16×16 Minesweeper, averaged over 100 games on the same seed.

Play the evolved mechanics

Five mechanics from the archive, each a different configuration of the same engine. The first two are the highest-lift examples highlighted in the paper; the rest are high-skill-spread variants that reinterpret how clues, reveals, and mines behave. All run entirely in your browser.

Skill-spread 0.71

5×5 Radius + Drifting Mines

Clues count mines over a 5×5 region while mines wander each turn.

Skill-spread 0.72

Telegraphed Mines

A rotating subset of mines flashes a warning each turn.

Skill-spread 0.56

Ranked Neighborhood Info

Clues show comparative rank, not absolute mine counts.

Skill-spread 0.72

Checkerboard Reveal

Cascades skip every other cell, leaving a hidden lattice.

Skill-spread 0.61

Ripple Reveal

Reveals expand in rings that halt at the first numbers.


Built on the rulesweeper research engine. Every mechanic here is a configuration of that engine.