The score that did not know how long a game lasts

On 26 October 2026 a record of one game from free play was made (a .awr.json file; the format of the record is described in the article on the record and the analysis), and with it a note of mine: the game was very long and demanding, and yet other games on free maps, where I place the dice by hand, I win on a medium map in roughly ten moves. The calibration and the points should be improved.

The record can be replayed on today's code, so there is no need to trust a feeling: the game had 199 rounds, 633 attacks of the player, 108 points and no bonus. A game that is won in 6 to 10 rounds, on the other hand, gets the full bonus for a quick win: 97 × 1.25 = 121 points. If the length of the game is converted by the time model of the tool tools/xp.js (3 + 0.5 × rounds, in minutes), it comes out at about 16 times more points per hour for the easy game. The score of the game evidently could not say that two games do not cost the same amount of time.

This article is a record of how it was checked, what was found (and it was not what was expected) and what changed in the score. It is the same kind of work as in the articles on the first move and on the calibration: a feeling does not decide, the AI plays.

First: it was not bad luck

The first question is always the cheapest one: was it not chance? The AI of level 3 wins exactly this setting (a large square map, archipelago, half of the tiles as reinforcements, at most 36 dice per tile, defender bonus 2, starting last, fog, three mixed opponents) with a median of 183 rounds; the 90th percentile is 322 rounds. So the game from the record is typical, not exceptionally bad.

Long games are not made by one setting but by the product of three. According to the measurement of 26 Oct 2026 the game is lengthened by:

The last row is the interesting one. With move half it could be expected to lengthen the game, and the measurement did not confirm it. The score gave it 0 points against 2 points of the original rule, which is only an oddity, not a bug.

The real finding: "I place them" can be exploited

The second part of the note was about manual placement of the dice. The rule "I place them" means that the player distributes the new dice at the end of the turn on their own, not automatically. The calibration (see article 08) gave this rule +2 points, that is, it considered it slightly harder. At first sight that was nonsense.

The reason is what the AI of the human seat does. The artificial intelligence distributes the new dice one at a time on the tile where the chance of a gain rises the most. A human does something else: pours all the dice into the largest stack on the front and then breaks through with it. The measurements were played by two AI opponents against each other in equal conditions, and so the calibration never saw this difference: the AI of the human seat placed the dice the same way as the opponents, so the rule had nothing to add.

An AI that stacks was therefore added (AI.placeStacked: the stack with the most dice among the tiles on the front, in a tie the one that neighbours the weakest enemy; the same plan is used by the stacker in the AI of the minigames, according to DESIGN §12). Results of 26 Oct 2026:

And in the setting from the record: the stacking AI wins 90% of the games in 28 rounds, random placement 16% in 248 rounds.

Equally important is what was not measured here. The opponents in the game still place the dice like an AI, and not like a human. The rule is thus strong also because the opponents have no counter-move against it. That is a weak side of the rule and it returns in the part about the open questions.

What was decided and built

Five commits of 26 Oct 2026 (and the version 0.50.11 after the merge) change these things:

1. The AI of the human seat can build stacks. The option humanPlace: 'stack' in Engine.playGame turns it on, but only in the calibration and in the check of the model (tools/score-model.js). The game itself and all the other tools do not change, so node tools/baseline.js stayed the same and calibrate.js --verify reported "identical" (according to the working notes, see the sources).
2. Manual placement has negative points. The value placement: manual in js/core/score-data.js is −41 (measured against the reference value random). The AI wins around 98% and the rate is bounded, so the real difference is larger. The sum of the points of a setting never falls below 0; the list of options shows "−41 pts" beside the choice and the rules window explains why.
3. The length of the game is measured. The same games that measure the chance to win also record the median of the final round of the games that the AI did not lose (l50). At the same time the cap of rounds in the measurement was raised from 120 to 400, because long settings had been cut off until then. Every value of a setting therefore has, besides points, a length term (the logarithm of the ratio of the expected rounds), and the terms are added.
4. The effort factor. The score of free play and of the daily challenge is multiplied by the number (expected rounds of the setting / rounds of the default setting with the same opponents) ^ 0.6, bounded to 0.25 to 4. The calculation of the score shows the row "Length of the setup (about N rounds) ×f" and the list of options has a chip with the same number. The speed bonus is shifted by the same ratio, because its original norm knew only the size of the map and the opponents.
5. The leaderboard is recalculated once. A record without the flag of the new formula gets, when it is loaded, new points of the setting and the length (the rest of the original sum, that is the hints, the win on points and the quick win, stays in the ratio of the original sum to the original base). Principalities^[1] and the daily challenge keep their numbers. Experience and Golden Dice that were already paid out are neither taken back nor credited again.

What the score pays after the change:

Why the exponent 0.6 and why Principalities are a special case

One can object: if a game takes twice as long, it should pay twice as much. With the exponent 1 an hour of play would always pay the same. A score proportional to the length would, however, also reward a setting that is long only because it is tiresome, and it could be "farmed": a setting that never ends (reinforce fixed has the term +2.48, the AI stops at the cap) would pay without limits. Hence 0.6. A game twice as long pays ×1.52 (it takes ×1.8 more minutes) and the upper cap 4 is reached at a ratio of lengths of about 10. The value 0.6 was not measured, it is a decision. It can be tuned in mods in score-data.js and checked with node tools/xp.js --check.

Principalities have no factor. Their score stays exactly the same (the call Score.finalize(game, { mode: 'classic' }); a test compares all numbers of players) and so do the Golden Dice, on which the economy of the game was measured. The formula touches only free play and the daily challenge. For the same reason the norm of the quick win is no longer fitted in the full measurement.

How good the model is

The effort factor stands on the length model: the expected rounds of a setting are exp(lenBase + Σ terms). The terms were measured one setting at a time against the basic one, so the model is exact for the basic setting and worse for every further setting changed at once. It is checked by node tools/score-model.js --configs 120 --games 300: 120 random settings, where every scored setting keeps its default value with a probability of 60%, both AI opponents 300 games each.

Points add up worse than lengths (it has always been so). The chance is bounded to 2 and 98%, so a setting that the AI wins almost always has less than the sum of its parts. The largest deviations of length: the archipelago is overestimated by 49% in a mixture of settings, the alliance of two by 38%, the defender bonus 4 and the handicap −2 are underestimated by about 40%. The check --check fails when the slope or the correlation fall below the limits; it catches a worsening of the model, it does not say that it is exact.

A full measurement of the calibration is heavy: 180 measurements of 2,400 games each take about 45 minutes on 16 threads (a figure from the working notes of this change, not from a document of the game; the documents give only the number of games).

Pitfalls

Three things are worth remembering, because they will come back with the next change of the score:

• The migration tools compare a profile with the data of the old code. Free play and the daily challenge are now scored by the new formula, so the Golden Dice, the experience and the best score differ from the old code and are not meant to be the same. The change of 26 Oct 2026 (game version 0.50.8) therefore removed the score fields of the games from the comparison, except for Principalities; for the other fields of the profile the comparison still holds. The related approach to the tests is in the article on testing.
• Achievements by the best score. The chain "Score" collects totals.bestScore and its thresholds are 100, 150, 180 and 210 (js/data/achievement-chains.js). The factor can raise the score of a single win up to fourfold, so a long setting could reach the thresholds with one win. That follows from the code; it was not tried in the game and it is an open point.
• Even a good change alters numbers that someone has already received. That is why the experience and the Golden Dice already paid out are not recalculated. What changes in the leaderboard is the score; what the player took out of the game stays.

What is open

• The opponents do not stack. The rule that has −41 points is the rule against which the opponents do nothing. An opponent who pours the dice into a stack the way a human does would make "I place them" a real choice. It is a change of the artificial intelligence, so a new version of the rules, a new base of the measurement and a full measurement. Recorded in the plan (ROADMAP).
• The length model has ±45% for settings with many changes. The way to a better one is a fit of the terms on random settings (ridge regression towards the terms measured one at a time) and terms for pairs (archipelago × size, placement × reinforcements). The factor is bounded to 4, so the error costs at most one multiple.
• The time model for manual placement (0.75 minutes per round, because every die is a click) is an estimate, not a measurement.
• Deliberately unchanged: the points of the other settings (they moved by 1 to 2 points where the cap of 400 rounds showed a longer game), the thresholds of the rating 70, 115 and 145 and the version of the rules (RULES_VERSION stays 2, because no rule changed and a record is replayed as before).
• I have not yet confirmed in the game that the new numbers match my feeling of the long games. The measurements prove that the model fits the AI opponents, not that it fits people.

What I take from this

• The record of one game found what 2,400 games per value did not find. The measurements were thorough, but the AI played the way nobody should play who wants to win by a shortcut. A human is the only one here who stacks. A value measured only by the AI should be compared with the play of a human at least once, and the best way to do it is from a record.
• A score without time is a score without a unit. Difficulty (what the chance to win is) and effort (how many rounds and minutes) are two quantities, and as long as they were joined into one, one of them could be bypassed.
• Negative points are more honest than zero. A rule that makes the game simpler should be visible in the list of options as a simplification. "−41" tells the player more than "0" and more than a missing option.
• Decisions and measurements belong in different columns. The exponent 0.6 will never be measured; it can only be justified and tuned. When they are written side by side, nobody thinks there is more behind it than there is.

Sources and notes

• Documents of the game: docs/DESIGN.md §51 (the occasion and the decisions; my note is retold in the article, not quoted) and docs/TUNING.md §3.9 (the measurements, tables, formula and model), both of 26 Oct 2026.
• Values in the code: js/core/score-data.js (−41, the length term manual −1.73, effortAlpha, effortMin and effortMax in mods).
• Changes: from the git log of the game (then auda-wars).

What could not be verified: the new numbers were not played in the game with a player, and score-model.js and calibrate.js were not run while writing (the numbers are from the documents and from score-data.js). The result of calibrate.js --verify, baseline.js and the figure of 45 minutes of measuring are from the working notes, not from the documents of the game. "16 times more per hour" is from DESIGN §51.1, not from an independent measurement, and the time model of manual placement (0.75 minutes per round, §51.3) is an estimate. That a long setting reaches the thresholds of the Score chain with one win is derived from the code and was not tried in the game.