10-bets 4,565 words about 20 min

Chapter 10. Bets

Science output has halved, and the production graph says so without saying why. You open it and find the drop in electronic circuits, so you build four more circuit assemblers and connect them. Output stays where it was. The new assemblers sit with empty input slots. Twenty minutes later you trace the problem upstream by hand: the copper cable assemblers are starved, because the copper smelters share a belt with iron, and the iron side fills the lanes first. The new circuit assemblers had been waiting on cable the whole time.

The dataset's record for production chains lists this among the mechanic's failure modes: starvation far upstream is hard to diagnose without flow statistics, so players blame the wrong building. It also lists the reason the chase never ends: the slowest stage sets throughput, so the bottleneck moves each time you fix one. Factorio gives you better instruments than most games, per-item production and consumption graphs and a panel for the power network, and when power runs short the game shares it evenly, so every machine on the grid slows at once and the symptom shows up everywhere except at its cause.

A tool that answered the question directly would not need a new kind of AI. Perturb the factory: add a little capacity to each machine, belt, and buffer in turn, and measure how much the selected output rises. The machine whose extra capacity raises output most is the binding constraint. A short generated sentence can then name it, with a link that jumps the camera to the spot: "circuits are limited by copper cable, which is starved because the smelter column shares a belt with iron." That is the design sketch of one opportunity in the dataset, the bottleneck explainer. Production chains are among the most widely used mechanics in the catalog, and no technique in the dataset is linked to them.

The bottleneck explainer is one of the dataset's bets: specific designs that combine mechanics the catalog already has with techniques the dataset records, each with an experiment that would test it and a dated prediction that can come out wrong.

What a bet contains

The dataset holds 42 opportunities. Each one is a record with the same fields, and the fields make it testable.

The record names the mechanics it reworks and the techniques it applies, so the bet sits on the same graph as everything else in the book. It names precedent games that partly demonstrate it; for the bottleneck explainer they are Factorio, Satisfactory, Anno 1800, and Oxygen Not Included, the games whose players already hunt bottlenecks by hand. It states a thesis, a design sketch, and the risks the authors of the record saw.

The validation experiment says what a small team would build to test the idea and what result would count as success. For the bottleneck explainer: implement sensitivity analysis over a factory prototype's production graph, inject a bottleneck, and see whether players fix it faster with the bottleneck view than without; success is fixes 50 percent faster, with no drop in satisfaction among experienced players when the view is optional. The falsifiable signal predicts something about the world by a date: a factory or city-building game will ship a feature that names the binding constraint in the player's network by testing the simulation, not by displaying static ratios, by 30 June 2028, in a title with at least 1,000 Steam user reviews, with patch notes or a developer blog saying the feature re-runs or perturbs the network. Chapter 12 follows those predictions.

Each record is scored from 1 to 5 on three anchored scales: impact, feasibility, and novelty. Priority is their weighted geometric mean, with impact weighted at 0.45, feasibility at 0.35, and novelty at 0.20. A geometric mean punishes a low score on any axis, so a brilliant idea nobody can build and a buildable idea nobody needs both sink. The bottleneck explainer scores 3 for impact, 5 for feasibility, and 3 for novelty, for a priority of 3.587.

Figure: Where the bets sit on impact and feasibility. Each opportunity placed by its impact and feasibility scores, with its novelty score before its name. Blue names are the eight highest priorities, the weighted geometric mean of the three scores. Scores come from one rater's reading of anchor text. Interactive version: https://sim.yohei.me/#fig-opportunity-priorities

Opportunities by composite priority (weighted geometric mean of impact, feasibility, novelty; weights in vocab/rubrics.yaml).

The scores are one rater's reading of anchor text, like every rubric score in the dataset, so the table ranks arguments by how they were scored and predicts nothing about sales. It does show the shape of the set. 18 opportunities are buildable now, 19 in one to two years, and 5 in three to five.

The top of the list

The highest-ranked opportunity is Why-query over the simulation log. Its thesis starts from the constraint chapter 5 described: players abandon systems they cannot diagnose, so designers cap how much the systems touch each other. Overlays and causal tooltips explain current values: this district's land value is low because of the factory next door. They do not explain histories. "Why did the hospital close?" is a question about a chain of events over months of game time, and no tooltip answers it.

The proposal is to record the simulation's events with their causes, then let a language model retrieve the chain behind any outcome and narrate it, with every sentence linked to a logged event the player can jump to on the timeline. A right-click "why?" on any building, person, or indicator returns three to six sentences and a small causal graph. An answer that cannot be grounded in the log says so. The constraint on the output format does the safety work: the model may only make claims it can point at.

Many simulation games already keep an event log for replays and debugging, and the proposal turns that log into something players see. Dwarf Fortress, Victoria 3, RimWorld, and Cities: Skylines II are listed as precedents because each exposes some causal state already. The record also lists what could go wrong: fluent answers that are not grounded teach players wrong models of the system; shipped event logs often lack cause links, and adding them is real engineering; and an explanation layer can make optimal play too easy. The experiment is designed around the first risk. Give two groups the same failing save, give one group the why-query, and measure time to a correct diagnosis and the share of answer sentences whose cited events actually support them, judged by people. Success is diagnosis 40 percent faster with at least 95 percent of sentences supported.

Second on the list is a branch preview of policy futures. Forecasts in shipped games are thin: a countdown, a weather icon, a predicted change in approval. The proposal forks the live game state in the background before a decision, 32 to 256 copies with different random seeds, fast-forwards each one an in-game year on spare cores or through a learned surrogate, and shows the player fan charts of the key indicators and replays of the two futures that differ most. Using the preview costs an in-game resource so that it stays a decision. A deterministic simulation can fork from any tick, which means the preview runs the game's real rules instead of a hand-built predictor. The validation target is concrete: 64 branches previewed in under five seconds on a mid-range PC, and a measurable drop in decision regret without lower engagement.

Third, tied with two others, is the event-sourced simulation runtime: an engine layer that records every state change, including those a model decides, as an append-only log with inputs, outputs, and causes. It is infrastructure that many of the other bets depend on. The why-query reads its log. The branch preview forks from it. A replay or a multiplayer client reads logged model outputs instead of calling the model again.

A colonist with a memory

Another bet tied at third returns to the cook from chapter 1. In RimWorld, as in The Sims, almost every decision an agent makes is routine: eat, sleep, haul, cook. Rule-based utility scoring handles those cheaply and legibly. The memorable moments are rare: a death in the family, a public insult, a mental break, a first meeting. The salience-gated agent proposal keeps the utility loop for every tick and calls a language model only when an event crosses a salience score.

The call is narrow. The colonist's traits, recent memories, and the event go in. What comes out must parse against a schema: a thought with a mood value and a duration, an optional change to a relationship, an optional one-line spoken reaction, an optional new goal. The player sees the result as an ordinary thought in the needs tab, the same list that explained the cook's breakdown, except that the line could now name her son and mention the argument they had the week before he died. Nothing in the game's rules changes. The memory system gains entries that no writer had to author.

The experiment caps the model at one call per colonist per in-game hour and compares a pure-utility colony of 20 with a salience-gated one in blind playtests. It measures believability and attachment on a seven-point scale, tokens per player-hour, and state contradictions per hour, such as a colonist mourning someone who is alive. Success needs all of them: a gain of at least one point, fewer than 2,000 tokens per player-hour, and fewer than one contradiction an hour. The record dates the opportunity's feasibility to 2025, when small local models made per-colonist calls affordable, and constrained decoding is what lets the result be written back into game state safely.

Language modding, tied at third, applies the same discipline to the players who extend games. Modding keeps simulation games alive for decades, and writing a mod takes programming skill and knowledge of the engine. The proposal is an in-game workshop where a player describes a change in a sentence ("wolves avoid fire", "trains prefer cheaper routes"), a model proposes a diff to data and scripts against the documented modding API, and agents run a headless test scenario to check for crashes and for the intended effect before the mod can be shared. The description, the code, and the test results travel together. The experiment takes a hundred real requests from a modding community and counts how many compile, pass the scenario, and are judged by the person who asked to do what they asked; success is 60 percent.

The pattern behind the list

None of the leading bets asks a learned model to become the simulation. The authoritative state stays symbolic, typed, and deterministic, and models sit around it: they read it and explain it, as in the why-query and the bottleneck explainer; they propose changes that a validator accepts or rejects, as in language modding and salience-gated agents; or they decorate it, writing the line a colonist says without deciding whether she lives.

The dataset's synthesis names five principles the opportunities share:

• Keep the simulation symbolic and let models read, explain, decorate, and propose through validated interfaces.
• Spend inference on salience. Most ticks need no model; calls at moments that matter, cached and logged, buy believability at bounded cost.
• Explain before you generate. Comprehension limits how much coupling players can use (chapter 5), and few techniques target explanation (chapter 8).
• Generate offline and verify with agents. Content, recipes, scenarios, mods, and balance can be produced at design time and checked by automated play before any player sees them.
• Log every model call as an event, which restores replay, multiplayer sync, and bug reports, and gives explanation and forecasting their raw material.

Chapter 7 found that what has shipped mostly stays at the edge of simulation state, and chapter 8 found that the economic core of the genre has almost no technique pointed at it. Bets that keep the core symbolic can ship on techniques that already work. Bets that replace the core with learned prediction inherit the failure modes chapter 11 describes.

Storytellers and events

Two bets tied just below the leaders work on the narrative mechanics that chapter 6 found most limited by authoring cost.

The drama-aware storyteller starts from what RimWorld's storytellers leave out. They pick incidents mostly by threat budget and timing, so they produce tension without arcs: nothing in them registers that two colonists are estranged siblings, or that the doctor is the colony's only hope. The proposal keeps the deck of incidents authored and bound by the rules, and adds a narrative score to each candidate: which characters it involves, whether it resolves or escalates an open thread, whether it pays off something set up earlier. A model that reads relationship and memory state computes the score, and the incident it picks is still one a designer wrote. The chosen incident goes into the chronicle with its narrative reason attached. The experiment asks players to recount a run a week after playing it; success is more named characters and more causal links recalled with the narrative storyteller than without it. Its precedents are RimWorld, Crusader Kings III, Frostpunk, and This War of Mine.

Content-elastic events go after the writing budget directly. Designers write 200 event templates, each with preconditions, effects, and notes on tone. A generator fills a template with characters, places, and history from the player's save, decodes the result into the event schema, and passes every variant through a validator that rejects any event whose effects break the game's invariants. Generated events carry a tag, so players can filter them out. The test is a blind comparison: take 50 authored events from an existing design, generate 500 variants, and have raters score both. Success is generated events rated within half a point of the authored ones, with 99 percent passing validation. Its precedents are Crusader Kings III, Stardew Valley, Animal Crossing: New Horizons, Reigns, and Frostpunk.

Orders and managers

The control layer of chapter 2 has two bets of its own. Intent-level orders start from the micromanagement wall of colony and management sims: the work-priority grid, the stockpile filters, and the schedules grow until play becomes clerical work. Players think in intents, such as keeping the clinic staffed through winter or stopping hauling during raids. The proposal is an orders panel that accepts a sentence and turns it into a standing rule, shown as a card with the exact priority changes, conditions, and expiry it compiled into. The player can edit the result in the usual interface, and conflicts between rules are flagged with an explanation. Because each order compiles into grids the player already reads, it stays inspectable. The experiment collects 200 intents players have written on colony-sim forums, compiles them into a prototype's controls, and has players judge whether each rule does what they meant. Success is 80 percent judged faithful and 30 percent fewer management clicks per in-game day.

Explained delegation works at the other end of the same problem. Games already delegate, through Stellaris sectors, Football Manager staff, and automated trade routes, but the record calls those managers weak and opaque, so players either micromanage or put up with bad decisions. The bet trains a manager on the player's own past choices and has it propose each action with a reason that cites the game's indicators and those choices. The player approves, vetoes, or adjusts standing preferences, and a weekly report says what changed. The experiment trains the manager on a player's first 10 hours in a strategy prototype, then measures how often it agrees with that player in situations it has not seen, along with the player's trust; success is 75 percent agreement and more trust than the prototype's ordinary AI manager earns.

Laws written by players

Natural-language legislation applies the same compiler to governance. Policy in simulation games has been a menu, a fixed list of toggles chosen by designers. The bet compiles a free-text proposal into a typed policy object over the simulation's actual parameters. A player drafts a law such as banning coal plants within two kilometres of housing and subsidising heat pumps by 30 percent, and the compiler returns a policy card that lists the parameters it mapped to and anything it could not map. Interest groups such as miners, residents, and industrialists then post positions computed from the projected change in their welfare and voiced by a model, while votes and compliance are computed from the simulation's state. The record traces the idea to A Tale in the Desert and Eco, where players were the legislators and people did the parsing. The experiment builds a compiler over a city model with 40 parameters, collects 300 laws written by players, and has two people judge each mapping; success is 85 percent mapped faithfully or with the gaps clearly flagged, and playtesters preferring to write laws over choosing from menus.

Further down

Some bets fill the vacant lots of chapter 9. Building placement that triggers story events ranks seventh. Factories whose workers age, form families, and are replaced, and research driven by named scientists in place of a tech tree, sit lower; each pairs two common mechanics that almost never meet.

The placement bet adds 50 placement-triggered event templates to a small city-builder prototype and asks whether players describe their towns in narrative terms more often than a control group, with no drop in building time. The workforce bet makes every machine on a small automation map need a skilled operator drawn from a simulated population that ages and goes to school, and it compares session length and self-reported attachment with a machines-only version, without lower ratings for the throughput puzzle. Its design sketch adds the rest: workers have children who attend schools the player builds, and succession planning for the workforce replaces the usual tech-tree endgame. The scientists bet swaps a strategy prototype's research meter for ten named scientists. Each project needs a lead and collaborators, whose compatibility and rivalry change its speed and the chance of a side discovery, and scientists publish, poach each other, and defect, so what gets discovered depends on who works together. It succeeds if players recall more research stories without rating their build plans any lower.

Others are business models or infrastructure more than features. Local-first AI simulation games ship small language models inside the game so that AI features run offline with no inference bill per player-hour, which fits the one-time purchase most simulation games are sold on and the very long sessions people play them for. Its record cites inZOI's on-device characters as a precedent.

The three long shots score 5 for novelty and 2 for feasibility, the bottom of the scale, with a three-to-five-year horizon. A language-agent society terrarium makes watching a society of language-model agents the game: the player picks a map and founding traits, seeds 50 to 500 agents, intervenes rarely with a drought or a prophet, and reads the chronicle. Symbolic simulation with neural rendering keeps a city builder's state as a tile grid and lets a generative model draw it, so a player could restyle a city as watercolor without new art while saves, replays, and inspection tools read the grid. Automated mechanic discovery searches the space of rule programs with model-guided evolution and agent playtests, using this book's taxonomy as the reference for what already exists. Its prediction, that a commercial game will credit one of its shipped mechanics to an automated rule-discovery system, runs to 31 December 2030, the latest date in the set.

Search and emulators

Two bets apply search and learned emulators whose output can be reproduced from a seed or a log. Parallel autobalancing runs a headless build of the simulation on a GPU cluster. A quality-diversity search keeps an archive of strategies spread across behaviour descriptors such as expansion speed, military share, and dependence on trade, and a tuner adjusts the game's parameters to keep win rates and resource curves inside bands the designers set; the report flags each exploit with a replay. The proposed test is historical: run a MAP-Elites search over strategies in an open-source economy game for one GPU-day, then compare what it finds with the game's patch notes. Success is rediscovering at least half of the economic exploits the developers later patched.

The learned weather layer starts from how games handle weather now, as a chain of states with fixed transition odds or a replay of real forecasts. The bet proposes distilling one of chapter 8's learned forecasters into a small emulator per biome that rolls daily temperature, precipitation, and wind forward from a seed and a climate scenario. Crops, fire, and hydrology read those fields, so a player who picks a historical climate or a warming scenario sees droughts and storms arrive at realistic frequencies. The experiment's targets are under 100 MB for a region, under a millisecond per in-game day, and drought frequency and storm clustering within 20 percent of reanalysis data.

Bets outside games

The dataset types 3 bets as transfers outside games. The benchmark bet starts from what AI agents now need: environments that test planning over thousands of steps, the management of resources, and recovery from errors that compound, with outcomes measured as throughput, survival, or profit. Minecraft became a research environment through projects such as MineDojo and Voyager. The proposal is for a studio to ship a headless build with a typed interface for observations and actions, standard scenarios, and leaderboards, so researchers measure long-horizon performance and players watch agent runs. The experiment wraps an open-source colony or factory sim, defines five scenarios, and evaluates three frontier agents; it succeeds if the scores separate the agents and do not saturate within one model generation.

The calibrated serious-sim bet notes that Plague Inc. and Rebel Inc. are used in classrooms and briefings despite their stylized models. It proposes a calibrated scenario mode whose parameters are drawn from distributions fitted to historical outbreaks, with outcomes shown as credible intervals and a fit report that says what data the model matches and where it is unreliable. The experiment fits a game-grade contagion network to a public historical outbreak and asks for 90 percent interval coverage on held-out weeks.

The planning-sandbox bet starts from planners who already use city builders to communicate, in games whose models are not calibrated to real cities and whose residents are absent. A neighbourhood is loaded from open data; participants zone, budget, and route transit; overlays show the calibrated effects; and simulated residents from different groups react, each tied to the data behind it. The experiment runs three participatory sessions and compares what participants understand about the tradeoffs, before and after, with a slide presentation; it also asks that participants rate the tool as fair. Its prediction turns on a city government using the tool in an official consultation.

Who should build what

A small studio has the ones with feasibility of 4 or 5 and a horizon of now: a legibility layer over an existing simulation, schema-constrained events, salience-gated agents on a local model, offline balancing. Each can ship as a feature of a conventional design. An engine or middleware company has the infrastructure: event-sourced runtimes that log model calls, constrained interfaces from language to game actions, headless simulation for testing agents, and libraries of calibrated surrogates for weather and materials. A research group has the open problems: rendering symbolic state with guarantees that the picture matches it, learned material models that conserve mass and energy, automated discovery of mechanics, and ways to measure whether an explanation is faithful. A studio with a headless build can supply the benchmark's environments; the other two bets outside games need partners outside the industry.

Exercise: write a bet

Take a design idea you have been carrying around and write it as an opportunity record.

1. Name the mechanics it reworks, using the catalog's names, and the technique it depends on. If no technique in the dataset fits, name the published result you would cite.
2. Name two or three games that partly demonstrate it today.
3. Write the validation experiment: what you would build in a month, who would play it, what you would measure, and the number that would count as success.
4. Write a prediction with a date and criteria a stranger could check from public evidence: which kind of game, how many Steam reviews or which platforms, and what a store page or patch note would have to say. Then write down what you would conclude if the date passed with nothing shipped.

Most ideas get harder to state at step 3. The bottleneck explainer's record handles it with a number a playtest can miss: fixes 50 percent faster. The predictions attached to all 42 bets start coming due on 31 December 2027, and chapter 12 shows what checking one involves.

Dataset dfde7895aa6d.

mechanics in this chapter

12 linked or named

Building placementContagionDelegation to AI managersForecastingHydrologyInterest groupsLand valueModding APIProduction chainsTech treeTrade routesWeather