How Audamir Is Put Together: Layers, Registration, One Move and Seats

Audamir started as one game with dice and territories. Today it has four games in two realms: dice and territories, with the campaign built on them, in Kastgard, and Colony with Lines in Rokgard; besides these there are two more realms in which there is no game yet. Each building has its own article: on the contract between a realm and a game, see From one game, more games; on moving Kastgard into its own folder, A move that must change nothing; on the building kit for boards, Two Games on One Board; and on texts and file names, Texts as trees (forthcoming article no. 38). This article is a map of the whole: how the pieces hold together today, where they meet and, above all, what holds them, so that a change which breaks the rules trips the check and not the player.

It answers a question that can be asked of any foreign project: how is such a game put together, so that modes and worlds can be added without rewriting, and how is that guarded (and not only drawn)? The pictures are not illustrations. They are drawn from measuring the game's tree (version 0.122.0, state of 6 November 2026) and from code that was read; where a picture is only a scheme, the caption under it says so. The basis was the architecture scheme of 29 October. It is a week older than the game, so every claim below is checked against today's code; where the scheme differs from today, the text says so.

This is my decision of 27 and 28 October 2026 on the direction of the rules. For this article today's code was read, the tools of the game were run, and it was tried what breaks them.

Three layers and one rule of direction

Four words recur below. A package is a folder of code with a list of its files (today nine packages and 338 files in js/). A realm is what the player sees: a card on the home screen, a hub with tiles, its own level and its own coins. A game is a set of rules with its own board, AI and record (in the code, a "ruleset"): stacks, campaign, colony, chains. The core (core) is what everyone uses: the random generator, the grid, the profile, the realm manager and the app's shell.

The rule of direction fits into one sentence: a realm uses its games, a game uses the core, and the core uses nobody. A game does not use its own realm, and realms do not use each other. The one exceptional relation is a game that builds on another game of its realm (campaign builds on stacks).

In Kastgard there are two games (stacks has 81 files, campaign 41), and in Rokgard two (colony with 19 and chains with 20; in the game they are called Colony and Lines). Vitgard and Telgard have 12 files each, three of code and nine of texts. They have no game, so the player does not see them: the home screen and the hubs are drawn only for realms that have at least one game (DESIGN §104.3).

The second thing in the picture is red, and the rule "the core does not know the game" does not hold entirely today. The tool tools/packages.js counts an edge when a file uses a global value that a file of another package defines. It looks for names in the code without comments and texts, names in the module list, and files named through require or importScripts. There are 1,370 edges, and 95 of them go against the direction, in 21 files: 59 from the core into stacks, 24 into campaign, 8 into the other packages and 4 from stacks into campaign. The reason lies in what the core is today. It is not only a library (35 files in js/core/) but also the app's shell (44 files in js/ui/): js/ui/app.js alone has 3,124 lines and 40 of those edges, and all of js/ui/ has 64. In js/data/ there are 9 more edges and in the library itself 18, in six files. A typical case is modetable.js: the table of modes loads before the realm manager, so it has to know which mode tables exist.

So the guard of the direction is not one hard "nothing" but two rules. Seven of the nine packages (both Rokgard games, its realm, Vitgard, Telgard, the realm Kastgard and campaign) are clean: any edge against the direction makes the check fail. Two (core and stacks) have a ratchet: the table in the file tools/packages-table.json writes, for each file, how many edges against the direction it may have. More is not allowed; fewer can be written (--lower-ratchet), and then the number does not rise again. Both rules were tried on a copy of the game's tree (git archive; the game itself was not changed). A line that reaches into Rules from stacks was added to game.js in Colony:

$ node tools/packages.js --check
direction: 1371 edges between the files of js/,
  96 break the rule (…)
  FAIL rokgard/colony -> kastgard/stacks:
    js/realms/rokgard/games/colony/core/game.js
    -> js/realms/kastgard/games/stacks/core/rules.js
    (Rules)
rokgard/colony: does NOT pass (…)
packages:check found a problem in 1 place.
(exit code 1; the lines are broken and shortened)

A name from the dice engine was added into a core file that already has one edge (js/core/phase.js). A clean package would fail at once; here the ratchet failed:

ratchet: 1 problem
  - ratchet: js/core/phase.js has 2 edges that
    break the direction, the table allows 1
    (…/stacks/core/ai.js, …/stacks/core/engine.js)
packages:check found a problem in 1 place.
(exit code 1; the lines are broken and shortened)

Why this is not mere decoration is shown by the next picture: what happened to the ratchet while the code grew.

The first entry was 120 edges (29 October). While the number of files grew from 187 to 338, the edges fell to 105 (31 October, when the campaign left the app's shell), to 94 (1 November, when the statistics moved from the core into the package of Kastgard), and on 4 November rose by one, when the challenge of the page was merged (js/ui/app.js 39 → 40). The increase is written in the table, so it is in the history. The rule can be relaxed, but only visibly.

Registration at start: clean data and one manager

When the page loads, each package writes clean data and functions; nothing is run yet. This is the manifest of the realm (its name, games, modes, tiles, level and coin), the game adapter (one frozen object that points to the code of the game: how it starts, what its cycle is, its record, AI and the facts of a finished game), a section (a game that builds on another) and the content that the game adds to shared lists: minigames, puzzles, lessons and tips. The picture shows who writes what; it is a search for the calls Realms.register( and others in the files of the packages.

A real example is Rokgard. Its manifest names the games the realm plays, the adapter of each game registers itself at the end of its file ruleset.js, and a mode is one entry of the table in modes.js. The excerpts are shortened and broken:

// js/realms/rokgard/data/realm.js (shortened)
const manifest = {
  id: 'rokgard', name: 'Rokgard',
  rulesets: ['colony', 'chains'],
  // …
};
Realms.register(manifest, api);

// js/realms/rokgard/games/colony/core/ruleset.js
return Rulesets.register(adapter);

// js/realms/rokgard/data/modes.js: Colony (shortened)
{
  id: 'colony', ruleset: 'colony', tile: 'colony',
  slot: 'colony', counts: ['history', 'realms'],
  end: { branch: 'colony', card: 'colony' },
  again: 'colony-again', back: 'colony-setup',
  restart: { how: 'confirm', start: 'same-setup' },
  hud: { tips: false, narrator: false, quips: false },
},

The realm manager (js/core/realms.js, 998 lines) then reads the assembly (Build.realms; the assembly may, for example, leave out the campaign section), checks the manifests and what the realms attach to one another (requires, extends), sorts them by their dependencies and calls start(ctx). A realm sees only its ctx (its own part of the profile, the generator, the texts, the sound), never another realm. If an exception happens in one realm or its time runs out, only that realm fails and the others keep running. And, above all, it knows no game: a test reads its code without comments and fails any change that would name a realm, a game or a module of a game in it.

The screens are then drawn from the registers: the home screen makes a card from each realm that has a game, the hub draws its tiles from the table of its modes, the list of games in progress is the list of mode slots (Principalities^[1], Tribes, free play, the daily challenge and others), and the windows of statistics, rules or settings are assembled from what the realm registers (pages).

The promise "a new mode needs no line in the wrapper" holds only halfway. A mode is a line of the table (slot, end card, the "again" and "back" buttons, what the HUD may show), and the screens read the table, so a mode that plays the same game as the others is only data. But the line of the mode Colony names handler functions (colony-again, colony-setup), and those are defined by the wrapper (for example 'chains-again': () => ChainsView.again() in js/ui/app.js). A new game always touches the wrapper. The table in DESIGN §104.5 of 31 October lists 20 registration places, and 13 of them are in files that every game edits (for example index.html, sw.js, the realm's line in modetable.js, lines in js/ui/app.js). Even a rough count shows it today: Lines stand in index.html on 13 lines (the screen and ten scripts), in sw.js on 5, in tools/compat.html on 4 and in style.css on 8. When Lines were built it was 91 lines in 14 files of the wrapper (DESIGN §80.6). Registration therefore shrank them, but did not remove them.

One move from a tap to the picture

The way of one move in the dice game, from one tap on a square. On the left the input goes down, on the right the picture goes up.

The input goes down. A touch or a click is caught by BoardInput (140 lines, js/ui/board-input.js). It tells a tap from a drag (up to six pixels it is a tap), from a pinch with two fingers and from a wheel, and sends the event tap with the number of the square. It does not know which game is running: it sends the event to the controller of the game, which the wrapper gives it. In the dice game that controller is Interaction.tap (js/ui/interaction.js). It knows that first an attacker is chosen and then a target, and that on touch the move is confirmed by a second tap if the setting asks for it. Then it calls Flow.humanAttack(from, to). Flow checks the move with the rules (the square must belong to seat 0 and the attack must be allowed), writes it into the record and performs it: the roll of the dice is computed from the state of the game, and Engine.resolveAttack makes a new state from it. Colony and Lines have their own controller (ColonyView, ChainsView) and their own game cycle, which answers to the same names, so the shared parts of the screen (the status line, the buttons) do not know which of them is running.

The picture goes up. When an attack ends, Flow calls the hooks of the wrapper (onAttackEnd, onState) and the wrapper redraws. The view of the board is made by StacksBoard.view(game, ui) (122 lines, js/realms/kastgard/games/stacks/ui/board.js): a description of one moment of the board, that is what stands on which square (the owner, the stack of dice, the terrain), which chances are shown on the edges, and which squares will still take a die. It is pure and only reads; a test runs it over a frozen copy of the game in every state of the collection of scenes that are drawn, and checks that the game did not change. The renderer js/ui/board.js (577 lines) draws that description. It calls no rules and reads no game. Colony and Lines have their own description of the board; the renderer is shared.

A state is a function of three things. A game is the setting, the number of the game (the seed) and the decisions. That is why the record of format 2 (A game record that can be replayed (forthcoming article no. 51)) needs to store nothing but the decisions of each seat, and Replay.run plays it again from them: the map is made from the seed, and Flow plays with the decisions from the record. From the game comes a stream of events (start, an attack with a path from one square to another, round, over). The replay player reads them through BoardEvents (338 lines, js/core/board-events.js: the verbs act and set, that is who did what and how the content of the squares changed). The picture of the game, the music and the analysis read them straight from the Replay stream. None of them changes the game; the narrator only observes as well (The first three minutes and the first weeks).

The end of a game is so far split into two ways. The game adapter can issue facts(game, ctx): the result, the length, the seat of the human, the level of the AI and the score. recordBoard in js/ui/app.js makes from them a line of the history, experience, coins and achievements of the realm, but only for Colony and Lines. The dice game has its own path in showEnd. Its facts exists, and a test compares it with the old path (on twelve golden records and 32 games from 16 setups, even the profile byte for byte, DESIGN §53.3 of 27 October), but nothing reads it.

Seats: who answers "what is your move?"

Each seat at the table answers the cycle of the game with the same question: what is your move? The answer differs only by who gives it.

A human answers with a tap, through the door Flow.humanAttack (and its siblings: moving dice, distributing dice, the end of the turn). The game cycle waits for that. AI in the Kastgard game answers with a function. Flow has a brain for the seats that are not a human, and that is a contract with two functions, attack(game, player, k, rng) and place(…). The ordinary brain Bots.brain calls AI.choose(game, player, …) in the main thread of the page; the level (1 to 3) and the personality of the seat it takes from the state of the game. AI in Colony and in Lines answers with the function choose(game, player, level). The view sends it to the worker (worker/bot.js) as a snapshot of the state and gets the move back, because a search at level 3 takes up to a second (in Lines on a large board), and the worker keeps the page alive; if the worker fails, the simplest legal move is played.

Two other "brains" are not the AI of a game, but the same question. When a record is replayed, Flow gets a script that reads the decisions from the record, and no AI is asked. Let the AI finish lets the AI play through the same door as a human (Flow.autoHuman), so the game is the same game with the same dice. The modes therefore change who sits where, and not the rules.

To be honest about it, a seat today is more a direction than a finished abstraction. The cycle of the game has one brain for all seats that are not a human, not a separate controller for each seat, and the human is always seat 0 (humanAttack checks whether the owner of the square is 0). The mode Watch the game must therefore switch off four places where the code counts seat 0 as the human (the header of watch.js). A real second human seat would not do without touching the cycle of the game.

Remote seats, the arena and playing with friends are a plan. ROADMAP chapter 4 (rooms with a code, AI for the missing players) says "nothing is built", docs/ARENA.md is a concept of 23 October that is "not approved and not started", and in js/ there is no network code (a search for WebSocket, RTCPeerConnection and EventSource found nothing there; the findings are only in the tools of the game, for example the checks in the browser). What is built is what such a seat would need: a record with the decisions of each seat, and a replay that verifies a game of a stranger without AI. In my view that is the base, not the network, and the state of the plans is not a promise.

What holds it together

The pictures would be only drawing if nobody guarded them. In this project the guards are the tests and tools that fail a change which breaks a rule. The checks run on a copy of the game's tree:

Two answers in the table have an important property: they say how to fix it. A file with an unfit name gets the sentence "rename it by its purpose, without the name of the package (the roles of Colony in core/ are game, ai, flow, setup, ruleset, events)". A test in the root of tests/ gets "put it into the folder of the package whose behaviour it proves, or into tests/tools/ for a tool". In my view this is why such a guard is not switched off at the first delay: a rule that only fails the build and does not say what to do gets bypassed.

The purity test of board-events.js shows a third kind of guard. It is not about the direction of the edges but about the character of a file. The file board-events.js must be a pure function, so its code (without comments and texts) must not contain document, window, localStorage, Date, Math.random, fetch or require(, and it must not name a game or its move (dice, colony, attack and others). The purity of the core without the DOM is not only a wish: the same files run in the game in the browser, in tests without a browser and in a worker.

Tests lie where the code is: the test of the file js/<folder>/x.js is in the mirror tests/<folder of the package>/<folder>/x.test.js. The tool tests-layout.js reports 352 test files (250 tests of packages and 102 tests of tools). The test of a clean package may name only the files of the core and of its own package, with one written exception: the test of Colony needs the real dice game, to prove that both games refuse the snapshot of the other. There are 4,609 tests in all; the full verify.js on a clean tree passed (4,608 passed, 1 skipped, 1,890 seconds), which is described in the article on the stamp (forthcoming article no. 37).

What the building changed from the plan, and what is debt

Building departed from the design, and those departures are the instructive part. Four were found during the work. The first: the core is not clean, it has 95 edges upward (see above). The second: Kastgard physically moved into js/realms/kastgard/ on 31 October (028), but the realm's id in the code stayed stacks, because an id does not change when a name changes (so says the header of the manifest). It was renamed only on 6 November 2026, to kastgard, and the header has since one written exception. Only what the player had saved under the old id was rewritten: the prefix of the achievements (stacks_… to kastgard_…) and the layout of the home screen, once, at the start of the game; the time and the order of the achievements stayed. The id of the game, its rules and the package kastgard/stacks, nor the text keys of the game, changed. It was proved on the data of the old code: 51 profiles, 1,193 keys, 357 transitions and 13 layouts came out the same after the rewrite, apart from the renamed id. The other way round does not hold: the old code loads the new data, but it does not know the new ids, so it would unlock achievements again and pay out Golden Dice. After publication, one therefore does not return to the old code. The third: names and status changed. The realm of board games was called Sporgard, then Taflgard, and from 31 October Rokgard; the campaign was first a realm, then a section, and from 31 October a game that builds on another game, although in the code it still attaches with a call to Realms.registerSection (028, Two renamings in one day (forthcoming article no. 44)). The fourth: one common core of texts for everyone was split into trees in the packages, so that a new realm need not write into foreign files (038).

The fifth was found only while reading the code for this article. The contract says that the realm manager can ask a realm for hub, saves, daily and weekly. A search in js/ showed that those hooks are called only by tests: the tiles, the games in progress and the daily challenge are read from the table of modes and from the wrapper. The contract is in the code, tested, and waiting for a caller.

Today's state of the parts of the design, in one table (game 0.122.0, 6 Nov 2026):

The debt has five named pieces: 95 edges against the direction (of them 40 in app.js), facts for the dice game, hooks without a caller, shared places when a new game is made, and the search kit for the AI of boards. All are in the documents of the game; none is a promise that it will be done.

What I take from it

• A rule without a ratchet is a wish. "The core does not know the game" is a nice sentence, but its value comes only with a table that says that today 95 edges hold and there will be no more. The number can be lowered, and an increase is visible in the history.
• A scheme ages faster than the code. The design of 29 October had stale states after a week (step B3 "not merged", events "planned", the profile per realm "running"), two false claims (that the core does not know the game, and that the screens read the unfinished games and the challenges from the realm manager) and one overstated claim (that each seat has a controller of its own kind). That is why the pictures are drawn from the tool and not from memory, and why they carry a date.
• Registration shrinks the shared places, it does not remove them. Of the 20 registration places, 13 are in files that every game edits. The truth is more useful than the sentence "without touching the wrapper".
• A seat is a direction, not a finished thing. The cycle has one brain and a human on seat 0. A network would change it the way the mode Watch the game changed it.
• A guard should say how to fix it. A message that does not state the procedure is bypassed later; the ones in the table do state it.
• What is a plan should be dashed. In the pictures and in the text, the plan and the state are kept apart: a difference that misleads the player, the reader and the developer alike the most.

Sources and notes

• State and data: the game Audamir 0.122.0 (6 Nov 2026); the game was only read. The design of 29 Oct 2026 is in the documents of the game (docs/mockups/architecture.html).
• Packages, edges and lines: node tools/packages.js --check (338 files, 1,370 edges, 95 against the direction in 21 files), tools/packages-table.json and the history of the ratchet in its commits; the tests by the testDirs table.
• Registration, move and seats: a search for the calls register in the files of the packages, js/ui/board-input.js, js/core/board-events.js, flow.js and bots.js; DESIGN §53.3, §80.6, §104.3 and §104.5.