A game without dice in a game about dice: Colony

Audamir^[1] is a game about dice and a move in it means a roll. In the new mode Colony nothing is rolled at all. The player has pieces on the board and in a move copies one of them onto a neighbouring cell or jumps with it by two, and on landing turns all the opponent's pieces around it into their own. No chance, no dice, no reserve. Why a game about dice got a game like this and what it cost is the subject of this article.

The mode was made on 26 October 2026 during a single afternoon (the first commit at 16:42, the last of the first stage at 19:26) and a day later it needed a renaming across the whole code.

Where it comes from

The brief was "after Hexxagon and Ataxx". A few features of those games are well documented, though with surprising gaps.

According to Wikipedia the arcade Ataxx came out in 1990 (publisher Leland Corporation), is played on a square 7 × 7 board and is won by whoever has more pieces at the end. The idea was invented by Dave Crummack and Craig Galley as early as 1988 for the unreleased game Infection; Virgin Mastertronic licensed it to Leland and used it in its own game Spot: The Video Game as well. The move itself is the same as in the mode Colony: a piece is copied onto a neighbouring cell, jumps to a distance of two (the source cell is vacated) and after landing the enemy pieces next to the target turn into the player's own.

Hexxagōn, according to the same page, is a game for IBM PC compatible computers from 1993 (Argo Games, publisher Software Creations) and uses a hexagonal board; a version in Flash was made later. These data about Hexxagōn are only from Wikipedia and were not verified on a second source. The pages that the documentation of the game gives as the sources of the rules (they are not read again in this article; the rules at Yucata, the manual from the DOS era, Dampfkraft, the clone in MATLAB) agree on the moves and on the result, but nowhere do they give the number of cells, the position of the holes, the starting position or who moves first. The missing data were supplied by my snapshot of its start, because I know the original game.

Why without dice

The reason is practical. The game already has a screen with a board, a top bar, a hero and windows (see boxes) that the player knows. The new rules can be built on the same screen and the game gets a second kind of experience without a second program. Until 29 October 2026 the link with dice remained in the record too: in the record of the game one die was an empty cell and two dice a piece. Every cell had an owner and a number of dice, 1 or 2; a neutral cell always one, an owned one always two. So the board could be drawn by the same renderer as in the other modes and the engine did not need a state "empty". The test and the measuring tools checked it after every move in thousands of games. Since 29 October the rules of Colony do not write dice (see the section "What happened to Colony afterwards").

The first picture is the original display: every empty cell is one die and every piece two dice with the badge "2". The second is the same game today: the same seed, the same seven moves of the player and the same replies of the AI. Both screenshots are from the real game, the moves were clicked in a browser.

The move is single and compulsory. A target with two dice is never legal ("two cannot take two"), so pieces change owner only by flipping. A jump may cross holes, a step may not. Whoever has no move passes; the game ends when nobody can move or only one player is left with pieces, and whoever has more pieces wins. The rule fill (the free cells go to the player who can still move, as in Yucata) is available but off by default, because Ataxx passes.

Architecture: a core of its own, no changes to the rules of dice

The rules of the mode are a module of their own (ruleset-colony in today's naming; at the time it was made leap.js), pure code without the DOM and clocks. It is not made through the generator of the other modes, because that one built territories, terrain and dice from a seed and dozens of settings, of which nothing is used on a fixed board. The game Colony creates an object of the same shape (cells, players, round, log, result), but its own: game.colony in it marks the mode, as game.puzzle marks a puzzle.

Important decisions, each with its reason in the documentation:

• Distance is a property of the map, not of the rules. The function reach looks for the distance in a graph that includes the blocked cells too, and that is why a jump crosses a hole. Later vertical edges between two layers of the board can be added to the same graph (the sixth stage of the plan).
• Boards and starts are data. A board is a mask of characters, a start a list of cells per player.
• A game can be replayed from the record. The record has moves (copy, jump), passes, eliminations and the end; replay plays the moves and compares the record entry by entry, so a forged, missing or surplus entry is rejected.
• The results of the old modes did not change. The baselines (baseline) and the calibration (calibrate --verify) came out identical, no golden record was rewritten.

Everything that concerns dice is switched off in this mode: it has no save slot, record, analysis, picture, music, achievements or experience. So in the first stage the game is not saved and not counted. The reason is caution: a seventh kind of saved game would change the lock "one game in progress, one tab", the strip of unfinished games, the backup and the migration; it is a separate change with a check of its own. It was verified that an abandoned game leaves no key in the storage and that the other saved games and the profile stay byte for byte the same.

The AI: depth, where there is no chance

A game without chance and with complete information can be played by search, not by guessing. The AI for two players uses negamax with alpha-beta pruning, iterative deepening and a table of positions with a Zobrist hash. The evaluation is plain: the difference in the number of pieces. The depth is limited by a budget of nodes, not by time, so the same game repeats from a seed on every machine. Three levels:

The levels are far apart: level 1 scored 0 points against level 2 and against level 3 (0 of 100 games), level 2 scored 1.3% against level 3 (40 games). A player who does not want to lose therefore has somewhere to grow.

How does it compare with other computer opponents? The source code of the original Hexxagōn was not found; from its readme only the opponent CRANIAC in three levels is known, and nothing is written there about the algorithm. The clone by Erik Jonsson from 2001 (GPL) searches with negamax with alpha-beta and iterative deepening to a fixed depth (4 by default), evaluates only by the difference in the number of pieces and, according to the code that was read, does not play at random; the report on Ataxx by Curtis Bright from 2010 uses the same basis with a depth of 5 to 6. Our AI has the same basis and in addition a table of positions and a budget of nodes instead of a fixed depth; chance is only in level 1. This is a comparison of descriptions, not a measurement of strength.

The AI must not loop

The first run of 1,600 games of level 2 brought a bug that no test had foreseen: in 5 games on the board without holes two AI opponents repeated the same six jumps (each of them flips four pieces), the position came back every six half-moves, in one game twelve times. The game was ended only by the cap of 400 moves. It was decided (26 Oct 2026) that the rules do not change, but the AI avoids repetition: the best move that would bring the position for the third time it skips and plays another equally good one; if all of them repeat, it plays the best of the others at the cost of at most one piece. In 3,200 games of level 2 after the change not a single one reached the cap. A human may go on repeating, if they want.

A weak AI that must not be stupid

The second fix came from a player, not from a measurement. The first design of level 1 took only the largest immediate gain, did not see the opponent's reply and played moves after which the opponent took five pieces. It seemed too stupid to me. The fix (let it look at the reply) beat it in 96.4% of 400 games and was already too strong: of 5 games I won 1 and my remark was that this is strong even compared with the weak opponent of the original game.

So the goal was expressed as a number: a player who always takes the largest gain should win about 65–70% of games against the new AI. That corresponds to a distance of 350–390 Elo points from the previous level, so that one has to beat the new level in 90–92% of games. The estimate is rough, because it comes from five games of mine, and in the documentation it is marked so.

Level 1 has three numbers: noise (a random share of up to 3 pieces), slip (the share of moves without a look at the reply) and miss (the share of random moves). Measured with the tool tools/colony.js --weak --games 800:

More mixtures reached the goal, so the question of what kind of mistake a weak player makes decided. Noise plays a worse move everywhere, miss now and then plays nonsense, but **slip is the mistake of a beginner**: it jumps at the biggest prey and does not see what the opponent takes back. The rest of its play stays reasonable, so a player who sets a trap is rewarded. The new weak AI beats a random player in 100% of 800 games and a player "always the largest gain" beats it in 63% of games (the previous level won against it 91%). It also turned out what its mistakes look like: it jumps for two pieces and opens a hole where the opponent copies and takes seven; it jumps for four and leaves the opponent eleven.

An independent check

A second reader (a subagent of the assistant, 26 Oct 2026) was given the code and the rules, not the conclusions. It recomputed the search against a simple negamax on 3,910 small searches, compared make/unmake with the rules in every position of whole games, checked the distance against coordinates in a cube on both boards and on 200 random masks and tried races of the loop and the worker. The conclusion: no bug that would affect the boards and options delivered. It did find six edges, five of which were fixed with a test each: a pass before the first move was not announced, normalize took "constructor" for the name of a board, teams were not part of the setup (they would be lost in a snapshot and in a replay), replayFrom checked only the moves, the worker kept the queues of searches of an abandoned game. The sixth was the cycle described above.

One claim of the first draft had to be softened: that the table of positions never changes the value of a search with a fixed depth. It uses entries searched deeper than asked, so in a rare position the value may belong to a deeper search. In the measurement the root value agreed in 54 of 54 positions; the independent check found one different position in 3,910 searches.

Renaming the id: leap → colony

The working name was leap. The name "Colony" is my choice from 26 Oct 2026 (the icon 🧫, a Petri dish); my first proposals were Cloner, Clones and Replica, and "Space opera" is already the name of the eighth music style. The translations in nine languages are one constant and one key.

In the code leap stayed until 27 Oct 2026. Then it was renamed (9 files moved with git mv, 44 keys in the catalogues), because the first stage of saves and the registry of worlds would touch the same files. The rule from the previous renaming applied again: stored identifiers do not change without a migration. Only the tile on the home screen was stored (in profile.hero.revealed and in the order of the tiles). That is why the alias LegacyIds.TILES = { leap: 'colony' } was made, which both codes read, and the tool tools/colony-id-migration.js makes the data with the old code (git archive before the change), lets the new one load them and compares the home screen, the profile and the backup. Without the alias it fails in every scenario. The script also compared each of the 3,642 keys of the translation in nine languages: 44 were renamed, no value changed. The check also caught a mistake of the renaming itself: it also renamed the English name of the puzzle "Leap through the portal" (portal-leap), which has nothing to do with the mode; the independent check caught it and it was put back.

The original seeds (leap-…) were left on purpose, because a seed that is renamed is another game. Likewise the musical "leap" (a melodic skip) in the composer was not renamed.

What is open

According to the plan (ROADMAP chap. 25) the mode has six stages. By 27 October the first was done; the state of 31 October is in the last section. The rest:

Open questions from the documentation: the length of the game (half of the moves are jumps and a game on the board without holes often lasts over 150 moves), the proposed default values (without fill, the tile at the end, the setup only for the visit) and above all what the game should pay when it is finished: the AI levels are very far apart, so a win over level 1 must not pay like a win over level 3. Chapter 26 further decided that the second stage will not be built by a seventh hand-made slot but by a registry of worlds: Colony is a ruleset and belongs to the realm that the player will see under the name Rokgard^[2].

What I take from it

• A game without chance needs other questions. With dice it is about probabilities; here the fairness of the first move and of the seat, the length of the game, the reliability of the end and the distance of the levels were measured.
• An AI that plays best can make the game loop. An AI has no boredom. The bug was not found by a test but by a regular run of thousands of games and a look at the games that ended by the cap.
• A weak AI is a design of a mistake, not switching quality off. The same strength can be reached by noise, random moves or a "shallower depth"; a player, however, recognises which mistake is human.
• The goal for a calibration must be written as a number. "Too strong" was not enough; the estimate "a player who takes the largest gain should win 65–70%" helped, though from five games.
• A renaming is a migration. Whoever changes a name and has no data from the old code will see the errors only at the player.

What happened to Colony afterwards

From 26 October Colony changed from a guest to a game of the application. This section adds the state of 31 October 2026 (version 0.65.6); the versions and dates are from the git log of the game.

The realm and the name. My decision of 28 October: the board games have one realm and Colony is a game in it (version 0.51.4, DESIGN §61). The id of the game, of the mode and of the tile stayed colony.

A disc instead of stones. On 29 October Colony got a board view of its own (ColonyBoard.view, version 0.55.4, §71) and a piece is a disc in the colour of the player. The rules of Colony do not write dice and tools/colony.js --check verifies it. Redrawing is cheaper: a median of 1.3 ms down to 0.9 ms for the board hex58, measured in the panel of the browser before the change and after it; the corpus of 277 drawing scenes holds: 204 scenes of the game with dice did not change even once and 46 scenes of Colony were deliberately rewritten once, at the change to a disc. The mark of a player (circle, square, triangle and others) shows automatically from three players: the standard palette fails with deuteranopia from three players (red against green 7.9 in the CIEDE2000 measure), with two it is safe (red and blue 47 and more). Colony has two players so far, so nothing is shown by default. The stone and the die are drawn, but are not offered to the player: they wait for the wardrobe of the realm Rokgard, which is not designed (§71.8).

A game of the application. Version 0.58.0 of 30 October (§77) gave Colony a slot of its own colony: saving 300 ms after a move and on leaving, one game in progress and one tab, continuing even with the AI to move, the button Restart, a row of the history and a tab Colony in the statistics by the level of the opponent. A finished game paid nothing then.

Colony pays. Version 0.60.1 (§82) pays for a win half an XP for every move of the player, times 0.5, 1 or 2 by the level of the AI. A typical win gives 13, 30 and 58 XP (from 52, 59 and 58 rounds), a draw half, a loss nothing; without a bonus for the first win and without a daily limit. The doubling per level is the whole rule against farming the weakest AI. The XP go to the level of the realm Rokgard, not of Kastgard, and since version 0.62.3 (§85) the player gets one token for every XP, Golden tokens, the coin of the realm. The tokens cannot be spent yet, because the wardrobe (step R3e) is not built. The games played before were counted once by an estimate from the history. The question from the end of the article, what the game should pay, thus has an answer; whether it stays at 0.5 XP per move when Kastgard switches to payment by moves (ROADMAP chap. 27) will be decided only when Colony has been played.

The second game of the realm. Version 0.59.0 of 30 October (§80) added Lines (Čiary)^[3]: three in a row, five in a row and a gravity four against an AI with three levels, as a game of the application like Colony. I did not like the cross and the circle on a 3 × 3 board, so all three variants draw discs (30 Oct, §87). The rules and the saved game handle two to five players (0.63.7), but the interface for three and more is missing, and on 31 October a configurator for square boards was added (0.65.6). Lines is the subject of the articles Three in a row and When a row stops being played.

What Colony still lacks. The rules, the AI and the slot are there; the header of ruleset-colony.js says that the record, the tutorial and the solver are missing, and the adapter lists only can: ['slot', 'restart']. Of the plan in the table above the tutorial (R2b-1b), the record and player (R2b-2), analysis, picture and music (stage 3), more players and bigger maps (4), free style (5), two layers of the board (6) and the sound of moves are still waiting.

Sources and notes

• Ataxx and Hexxagōn: Wikipedia, Ataxx (read on 26 Oct 2026; the page itself warns that it lacks citations). The year 1993, the publisher and the Flash version are only from it.
• The rules: Yucata, RulesPal, Dampfkraft, MATLAB clone. The session of the first stage read them (DESIGN §50.2) and took from them only the agreement in the rules. The start of the original, the first player and the single map I have only from my own snapshot and answers of 26 Oct 2026 (§50.2, §50.9).
• Other computer opponents (searched on 7 Nov 2026): the readme of the original (original, without code), Hexxagon by Erik Jonsson (a clone, 2001, GPL 2 or later, a copy in the LLVM test suite) and the report of Curtis Bright on Ataxx (13 Dec 2010, licence not stated).
• The game: docs/DESIGN.md §50, §61, §71, §77, §82, docs/TUNING.md §36 and docs/ROADMAP.md; the versions are from the git log --first-parent (read on 31 Oct 2026). The numbers from the documents were not repeated (the measurements are under the original name tools/leap.js, the colour difference 7.9 and 47 is from the mockup in §71.4).

What could not be verified: the data about Hexxagōn outside Wikipedia (the source code of the original and its AI were not found even in the new search), the start of the original, the impression of real players of level 1 after the retuning (the calibration rests on the games of AI opponents and five games of mine), touch on a touch screen, build:check and smoke (Chromium did not work here) and the payment with the redrawing after 26 October (Colony was not played in a browser then; the pictures in the text are from 7 November). Also uncertain is whether the payment of 0.5 XP per move holds after payment by moves is introduced for Kastgard.