How the atlas is made, and why you can check it

Every game, mechanic, technique, bet, and source is one plain-text record. The paper, the book, the videos, and this site are all built from those records, so they cannot drift apart: change a record and every page that uses it changes with it.

Each fact cites where it came from, with a short quote from the source. A record is marked sourced when its facts have sources, and verified when someone other than its author has checked them.

When a sentence in the paper or the book interprets the data, a check sits beside it. If new data makes the sentence false, the build stops until someone rewrites it, so the text stays true as the catalog grows.

People and AI agents add games, sources, and checks through pull requests, under written rules. Every change is logged as a run, and the contributors are credited in the paper.

everything below in one archive (assembled by the Pages workflow)

one flat table per entity type, edges.csv, game_mechanic_matrix.csv

full records with computed fields under _derived

nodes, edges, Cytoscape, GraphML

every statistic, and every analysis table as csv

one markdown page per record and vocabulary, with backlinks

the paper as markdown with its bibliography

per-record and dataset sha256, schema and vocab hashes

Who performed a research run.

How player intent reaches the simulation. A game may use several.

Order of magnitude of individually simulated agents in typical play. Aggregate populations shown as a number but simulated as stocks count as `aggregate`.

Confidence in a specific claim.

Effect on reproducibility, replays, lockstep multiplayer, and save integrity when used at runtime.

Every typed relation in the graph. Each edge is stored exactly once, on the `owner` side named here. Inverses are computed by the build and never stored. Symmetric edges are stored on the entity whose id sorts first.

How a technique changes a mechanic (attribute of the technique→mechanic `affects` edge).

What happens when the system goes wrong.

Dominant feedback loop polarity the mechanic creates in play.

How closely the model tracks real-world causal structure. Independent of graphics.

Expected time until meaningful use in shipped simulation games, as judged at the entity's last review date.

Formal mathematical model a mechanic instantiates, explicitly or implicitly. Used to connect mechanics to research literature.

Adoption maturity of a mechanic across shipped games.

Primary functional family of a mechanic. Exactly one per mechanic. Assign by the state the mechanic owns, not by the genre it appears in.

Role a mechanic plays in a specific game (attribute of the game→mechanic `uses` edge).

Depth of player modification supported or widely practiced. `scripting` and `total-conversion` mean the game exposes a modding surface (official, or a de facto loader most modders use), so those games must tag the `modding-api` mechanic; `content` games may tag it when the content arrives through official data definitions (E033).

Supported social play modes.

Where story comes from.

Kind of opportunity.

Primary camera or presentation.

Platform families a game shipped on at any point.

How the player touches this mechanic.

The fiction-level role the player occupies relative to the simulation.

How an opportunity's falsifiable prediction resolved. Set in `falsifiable_signal.resolution` by an independent verification run (E038).

Production context at release.

Primary risks of using a technique in simulation games.

Where in the lifecycle the technique runs.

Real-world domain the simulation models. One to three per game.

Spatial or organizational scale of the primary simulated unit of play.

Type of cited source.

Epistemic status of an entity. Ordered from weakest to strongest support. Status is a claim about evidence, never about importance.

Design lineage a game belongs to. One primary per game, optional secondaries. Lineage, not marketing label.

Computational representation the mechanic is usually implemented on. A mechanic may have several.

Research area of a technique or breakthrough.

Deployment maturity of a technique in games specifically (not in general AI).

Dominant relation between simulation time and player time. `real-time-pausable` games must tag the `variable-speed` mechanic and only `real-time-pausable` and `run-on-demand` games may (E033).

How play is bounded and evaluated.