What can be said about one game: a record, an analysis and a piece of music

The original Dice Wars had a History button that showed after a game how it had developed (according to reviews of the time). In Audamir three things came out of that button that can be written in one sentence: a game can be replayed, a game can be taken apart and a game can be played as a piece of music. The first two exist, the third is so far an idea with a precise plan for finding out whether it is worth it.

All three have one basis, which was spoken about in the article on testing: all the randomness of the game is derived from the state, so the same game always comes out the same.

The record: a game on one line

A game can be described by four things: the settings, the seed, the "salt" of the rolls and the decisions of the human. Everything else (the rolls, the moves of the opponents, the random reinforcements) can be computed from them. A typical game from the measurements (300 random settings, not only Principalities^[1]) has 140 decisions, 1.3 kB as JSON and 1.7 kB as a link (the largest was 5.5 kB). A decision is one entry with numbers: a12-13 is an attack from tile 12 to 13, e the end of the turn, r1 an answer to the question about a reroll.

This is what a real record of one short game looks like, coloured by parts:

From this follow things that the player will see as buttons:

• Replay in the player: Play and Pause, a step forward and back, a speed of 0.5× to 8×, a slider for the round. Playing a game back takes about 12 ms.
• Sharing by a link #R=… or by a file .dwr.json. Nothing is uploaded anywhere, the link carries the whole record.
• Copy result: one line and a link, as in Wordle. For example (an example adapted from the documentation) Audamir · daily challenge 2026-10-19 · win in 12 rounds · 1,420 points · luck +2.1.
• A bug report carries the game in progress as a Record: line, so the bug can be reproduced.
• The last 20 games are kept on the player's device.

Two traps that the record revealed

A double press of "End turn". If the second press were recorded as a second decision, the replay would end another turn. So the second press is not counted.

The player looks at a roll, then leaves. A game saved in the middle of an attack carries a "pending attack", which after a restore is repeated with the same roll, so that the player cannot choose another attack after seeing the result. The record has to cope with this: the decisions from the unfinished attack are taken out of it on restore and asked for again.

A contract with the past, the second time

As with the generator of tiles, a contract arises with the record: if the rules or the AI change, old records cannot be replayed the same way. That is why each one carries the version number of the rules (RULES_VERSION), and a record of another version is marked as outdated and is not played. The rule for the developer is on the list: with every change that can change a game, raise the version number. And because that can be forgotten, there are golden records behind it: a test plays back saved games, and if the result changed without the version number being raised, it fails and says what to do.

One serious bug was found in the review. A saved game on "End turn" carried the end-of-turn token while its snapshot still corresponded to the human's turn. After "Continue" the turn was played again, a second token was added and the replay broke. The fix is in the order: the token is written only after saving.

The analysis: where a game was decided

When a game can be replayed, it can be computed from. The Analysis button (at the end of a game, in the card of records and in the player) answers two questions: where the game was decided and whether it was luck or decision.

The main quantity is the chance to win by round. It is computed with the Monte Carlo method: from the saved position of every round the rest of the game is played many times, and the chance is the share of games that the player's team wins. Users of chess servers know similar charts from game reviews.

The exact definition is important. For the player a stand-in AI (proxy) of level 2 plays, the opponents play at the level of the game. So the number means: your chance if this AI played for you from here on. It is not a statement about what a better or a worse player would do.

Luck plus decision

A turning-point attack is split into two parts. For an attack with chance p three positions are evaluated: before the attack (V0), after a win (Vw) and after a loss (Vl). And then:

change    = Vreal − V0
expected  = p · Vw + (1 − p) · Vl
luck      = Vreal − expected      (what the dice added to what the odds promised)
decision  = expected − V0         (what value the attack had by the odds)
change    = luck + decision

It is the same idea that everyone who computes an expected value knows: an attack with a 40% chance can be a good decision and still be lost. The analysis can say so: for every turning point it shows luck separately and decision separately.

This is what it looks like on one real game:

Noise that tells stories

The analysis went wrong on one thing, and thanks to it it now has its rule. In a real game it found a "turning point" with a change of +8 points that was only noise from the random simulations. That is why the rule is that a turning point must be significant: the change of the chance must be at least twice its standard error, which is computed paired from the simulations with common rolls ("common random numbers"). The split into luck and decision is stated in words only when it is at least 3 points and 1.5 times its own error.

Can it be trusted?

Looking at a chart of chances and believing it is cheap. That is why it was calibrated: its predictions were compared with the real results in 210 games.

• A Brier score of 0.0452 (0 is perfect, 0.25 is constant guessing of 50%).
• No bias: the average predicted chance (51%) equals the real share of wins (51%).
• The chance in the first round differs from the share of wins of the same AI on other maps by +0.9 ± 1.5%.
• An independent sample gave 0.0431. The group of predictions of 80 to 90%, which looked bad in the first sample (95% at a prediction of 85%), was a result of chance: in the second sample 80% came true.

The computation runs in a Worker for 0.6 to 1.4 s. On a simulated slow processor (a phone) it was 3.3 to 6.1 s. The same record always gives the same chart: the plan of the computation is a function of the record, not of the clock.

The analysis is finished, verified and since 20 October merged into the main branches of the game (dev and main). The open questions got answers and they are worked in: the proxy level 2 stays, the narrator (the Avatar^[2]) offers the analysis after a game that was not won, and the analysis is everywhere a record of the game exists.

A piece of music from one game

The third thing is still only an idea, and that is exactly why you can see in it how ideas are handled in this project. The vision is this: every action in the game makes a sound, and the sounds are put together into a piece that follows how the game went. Several styles (techno, rock, ambient), it can be switched off, during the game a short recording of the previous round plays, and after the game the piece can be played or saved. A link to a record is at the same time a piece of music: nothing is saved, the piece is a function of the game.

In the plan of extensions (the ROADMAP) a fairly unusual document comes out of that idea:

• Music, not noise. The events are quantised to a rhythmic grid. One key and scale per game from the seed. One round is one bar. Every player has a voice (the colour of the player determines the timbre of the tone). The pitch of an attack follows from its chance: a probable hit sounds consonant, a surprise sharp. Wins resolve into chord tones, losses fall, the elimination of a player is a cadence.
• Density. A game has 400 to 600 attacks. The composer thins them out: the player's own events first, then the big turns, at most about 16 events per bar.
• Honest limits. Techno, chiptune and ambient can be synthesised well from oscillators, rock acceptably. "Classical" without sound samples will sound like a music box and a pad, an orchestra is not promised.
• A loop that keeps growing turns into noise after about ten rounds, so during the game at most a one-bar overview of the previous round plays.

And then the rule that turns an idea into a project: a prototype without an interface. The plan counts on a tool tools/score.js (it does not exist yet) that would play a few games, write MIDI files in three styles, and the author would listen to them in any player. Then it is decided whether to go on. No interface until the author has listened to the prototype. The quality of the sound decides everything.

It is the same principle as with the Boss duel: try the smallest thing that kills the idea if it is bad.

What I take from it

• Determinism is the best investment. From one decision (randomness from the state) came the record, the replay, sharing, bug reports, testing and the analysis.
• Contracts with the past must be written into a test. A version number without a test is a wish.
• Measure even what looks like a measurement. A chart with two decimal places is not proof. The calibration of the predictions is.
• Noise tells stories. Without a rule of significance a simulation shows you "turns" that are only chance.
• Ideas need an entry condition. For music it is "first it has to be possible to listen to it".

Sources and notes

• The record: docs/DESIGN.md §28 (the format, the verification, the review), the tool node tools/replay.js --games 300 --check.
• The analysis: docs/DESIGN.md §34 and docs/TUNING.md §26 (the state of 20 Oct 2026; merged into dev and main the same day); the calibration numbers from the documentation and from the development notes (a Brier score of 0.0452 and 0.0431, 210 games, times of 0.6 to 1.4 s and 3.3 to 6.1 s).
• The piece of music: docs/ROADMAP.md, chapter 15 (the proposal and the prototype, none of it is built yet).
• The History button in the original game: according to reviews of the time (JayIsGames, Gigazine), cited in the plan of extensions.
• Pictures (indicative, from today's state of the game, not of 20 Oct; game 0.119.0, dev, commit 25bc3d57, 6 November 2026): both games were played by the tool of the game with a stand-in AI in the place of the player (playRecorded from tools/realms/kastgard/games/stacks/replay.js), not by a human. The record in the first picture is a real record of format 2 (a small map, square tiles, one opponent, seed LLF4A5, 623 B), one of the shortest of 240 tried (chosen among the won games that do not start with the end of a turn); it is played back (Replay.run) to the checkpoints and the result that it carries, and the three maps are drawn by Scenario.svg as it is played back. The size of the screenshot is the file assets/shots/sk/kastgard-map.webp of this site (90,286 B); a typical game in format 2 (3.2 kB) is from docs/RECORD-V2.md §0. The chart of the chance is from another game (game number BAE8MR, the same kind of settings, 22 rounds, 2,249 B of record), chosen from about 200 games that were played and analysed as one with a clear turning point in which there is both luck and decision; the numbers were returned by the command node tools/realms/kastgard/games/stacks/analysis.js --record BAE8MR.json --json (1,797 simulations, the same on repetition). The turning point is an attack in round 7 with a 72% chance (58% → 81%, luck +7.9 and decision +15.5 points).