Doomsday Clock: territory rot, so a doomed side actually dies

[Zixer1]

Problem

The Doomsday Clock can't end a game. The drain stops at the troop floor, so a doomed side is crippled but never eliminated, and nothing ever removes territory. R4 of the last Major ended on the clock with 16 players alive, three of them holding 4, 22 and 64 tiles.

Change

Territory rot. A doomed side loses land until it holds none. Paced to a deadline (rotDeathSeconds from the skull appearing), each second taking ceil(tilesLeft / secondsLeft) — self-correcting, so the finish time is the same for a sliver and an empire. Rot spreads from interior seeds rather than picking scattered tiles, and takes any structure with the ground. Nothing is credited: no conqueror is passed, so no kill and no captured gold.

Decaying troop floor. The floor starts high and decays to drainFloorPercent, giving one window with a usable army to climb back above the bar. A permanently high floor would make a doomed side unconquerable (maxTroops is sublinear, ~100k at a single tile).

Wave schedule re-cut from 85 tournament games: seven small steps to 35% (2/4/7/11/17/25/35) instead of six accelerating ones to 55%. The runner-up's share at game end has never exceeded 21.6%, so any bar above ~16% catches the same players — a higher ceiling only climbed past the leader's own share (median 41%) and handed the game to the crown exemption. Small steps matter because half the players alive at the end hold under 0.4% of the map, so a big jump debuffed most of the field at once.

Timings

from skull		skull
0s	warn countdown	blinking white
30s	troops draining	steady white
120s	territory rotting	steady red, "Decaying"
180s	eliminated	—

Verified in-sim at 150 / 1,200 / 2,000 tiles: dead at 179s with zero tiles in every case.

Notes

• Opt-in per lobby — doomsdayClock.enabled still defaults to false. rotDeathSeconds: 0 disables rot alone.
• Deterministic: integer-only, rot's choices via PseudoRandom seeded per (tick, player).
• The red skull is a shader tint of the existing asset, no new image. isDecaying comes from the sim rather than being re-derived client-side, because the phase test is a knife-edge equality that flickers when recomputed.
• Spreading is O(quota) per second, not a per-tick territory scan — 10k ticks of a 3,000-tile player in 48ms.
• tests/GameUpdateUtils.test.ts now asserts every scalar PlayerUpdate field survives diffPlayerUpdate, which transmits only changed fields and is easy to half-wire.

2642 tests pass (291 server), tsc/oxlint/eslint clean.

Caveat: on a 25-minute fast round the 35% bar lands at the buzzer, so a player caught in the last two minutes won't finish dying before the cap. Fix is pulling the schedule earlier, not shortening the 180s.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

The Doomsday Clock now uses seven waves ending at 35%, a decaying troop floor, and deterministic territory rot. Players expose decay state through updates. Client rendering shows a dedicated Decaying status and encodes it as a steady red skull indicator.

Changes

Doomsday Clock decay

Layer / File(s)	Summary
Clock schedule, floor, and territory rot src/core/game/DoomsdayClock.ts, src/core/configuration/Config.ts, src/core/execution/DoomsdayClockExecution.ts, tests/DoomsdayClockExecution.test.ts	The clock uses seven waves ending at 35%. The troop floor decays over time. Territory rot removes tiles through deterministic speckling and frontier spreading, removes structures, and clears state during recovery.
Authoritative decay state propagation src/core/game/Game.ts, src/core/game/GameUpdates.ts, src/core/game/GameUpdateUtils.ts, src/core/game/PlayerImpl.ts, tests/GameUpdateUtils.test.ts, tests/util/viewStubs.ts	Players record recent rot events and expose isDecaying(). The state is serialized, diffed, applied, and preserved across partial updates.
Decaying status rendering src/client/render/types/Renderer.ts, src/client/view/PlayerView.ts, src/client/render/frame/derive/PlayerStatus.ts, src/client/render/gl/passes/name-pass/*, src/client/components/DoomsdayClockPanel.ts, resources/lang/en.json, tests/client/render/*	The client derives the decaying status, displays the Decaying phase, uses the shared troop-floor calculation, and packs decaying status as 3.0 with precedence over draining and warning states.

Estimated code review effort: 5 (Critical) | ~120 minutes

Sequence Diagram(s)

sequenceDiagram
  participant DoomsdayClockExecution
  participant PlayerImpl
  participant GameUpdateUtils
  participant PlayerView
  participant PlayerStatus
  participant NamePass
  DoomsdayClockExecution->>PlayerImpl: Mark player after territory rot
  PlayerImpl->>GameUpdateUtils: Include isDecaying in PlayerUpdate
  GameUpdateUtils->>PlayerView: Apply decay state
  PlayerView->>PlayerStatus: Expose isDecaying()
  PlayerStatus->>NamePass: Emit doomsdayClockDecaying
  NamePass->>NamePass: Encode status as 3.0

Loading

Possibly related PRs

• openfrontio/OpenFrontIO#4469: The Doomsday Clock status pipeline is extended with decay state.
• openfrontio/OpenFrontIO#4499: Both changes modify Doomsday Clock execution and decay configuration.
• openfrontio/OpenFrontIO#4587: This change extends related Doomsday Clock troop-floor behavior.

Suggested reviewers: evanpelle

Poem

The clock waves end at thirty-five,
The fading floor keeps troops alive.
Rot spreads tiles by measured thread,
Red skulls mark the players led.
Updates carry decay through,
Recovery clears the state anew.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 52.94% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: adding territory rot so doomed players can be eliminated.
Description check	✅ Passed	The description directly explains the territory rot, troop-floor decay, wave schedule, client changes, and validation results.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

tests/DoomsdayClockExecution.test.ts (1)

41-41: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Stale comment: the veryfast preset now tops out at 35%, not 30%.

The test at line 634 asserts doomsdayClockRequiredTiles("veryfast", land, 900) is 3500, which is 35%. Update the inline note so it matches the shipped schedule.

📝 Proposed fix

-    speed: "veryfast", // waves rise to 30% by 15:00
+    speed: "veryfast", // waves rise to 35% by 15:00

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/DoomsdayClockExecution.test.ts` at line 41, Update the inline comment
next to the veryfast speed setting in the DoomsdayClock test to state that waves
rise to 35% by 15:00, matching the existing 3500 assertion and shipped schedule.

🧹 Nitpick comments (1)

src/core/execution/DoomsdayClockExecution.ts (1)

300-311: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low value

Optional: skip the second speckle() scan on the first rot second.

On the first rot second front is empty, so spread() returns 0 and the fallback at line 311 always runs. speckle() scans every tile of the player, so that second is guaranteed to do two full O(tiles) passes. The cost is bounded and happens once per doom spell, so this is only a tidiness point.

If you want to avoid the repeat scan, let the first speckle() call take the full budget when the front is empty.

♻️ Proposed refactor

-    budget -= this.speckle(
-      mg,
-      player,
-      random,
-      Math.min(specks, budget),
-      front,
-      built,
-    );
+    // With no front to grow, the whole budget has to be speckled anyway, so
+    // take it in one scan instead of two.
+    const seedCount = front.length === 0 ? budget : Math.min(specks, budget);
+    budget -= this.speckle(mg, player, random, seedCount, front, built);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/core/execution/DoomsdayClockExecution.ts` around lines 300 - 311, Update
the budget allocation around the first speckle/spread sequence in the execution
method so an empty front passes the full remaining budget to the initial speckle
call, avoiding the guaranteed fallback scan on the first rot second. Preserve
the existing spread and fallback behavior for non-empty fronts.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@tests/DoomsdayClockExecution.test.ts`:
- Line 41: Update the inline comment next to the veryfast speed setting in the
DoomsdayClock test to state that waves rise to 35% by 15:00, matching the
existing 3500 assertion and shipped schedule.

---

Nitpick comments:
In `@src/core/execution/DoomsdayClockExecution.ts`:
- Around line 300-311: Update the budget allocation around the first
speckle/spread sequence in the execution method so an empty front passes the
full remaining budget to the initial speckle call, avoiding the guaranteed
fallback scan on the first rot second. Preserve the existing spread and fallback
behavior for non-empty fronts.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 873cedd8-6dbd-4996-9285-bab63122784e

📥 Commits

Reviewing files that changed from the base of the PR and between d77e4a0 and 37380a1.

⛔ Files ignored due to path filters (2)

• src/client/render/gl/shaders/name/status-icon.frag.glsl is excluded by !**/*.glsl
• src/client/render/gl/shaders/name/status-icon.vert.glsl is excluded by !**/*.glsl

📒 Files selected for processing (19)

• resources/lang/en.json
• src/client/components/DoomsdayClockPanel.ts
• src/client/render/frame/derive/PlayerStatus.ts
• src/client/render/gl/passes/name-pass/Types.ts
• src/client/render/gl/passes/name-pass/index.ts
• src/client/render/types/Renderer.ts
• src/client/view/PlayerView.ts
• src/core/configuration/Config.ts
• src/core/execution/DoomsdayClockExecution.ts
• src/core/game/DoomsdayClock.ts
• src/core/game/Game.ts
• src/core/game/GameUpdateUtils.ts
• src/core/game/GameUpdates.ts
• src/core/game/PlayerImpl.ts
• tests/DoomsdayClockExecution.test.ts
• tests/GameUpdateUtils.test.ts
• tests/client/render/frame/derive/nuke-telegraphs.test.ts
• tests/client/render/frame/derive/player-status.test.ts
• tests/util/viewStubs.ts

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (2)

tests/DoomsdayClockExecution.test.ts (2)

1007-1013: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add a case for rotGrainSeconds: 0.

rot() computes the speck count with (state.held * cfg.rotSpecklePercent) / 100 / cfg.rotGrainSeconds. With rotGrainSeconds: 0 that division yields Infinity, and the budget becomes the whole territory. Today the grainy guard (mg.ticks() - state.since < cfg.rotGrainSeconds * 10) is false at the first rot second, so the division never runs. That safety depends on the guard, not on the arithmetic.

Add a test that sets rotGrainSeconds: 0 and asserts the territory is not removed in one second. This locks the guard against a future edit.

💚 Proposed test

it("does not wipe everything at once when the grainy phase is disabled", () => {
  const g = rotGame({ rotGrainSeconds: 0 });
  rotFor(g, 1);
  // No grainy phase, so the even quota alone applies: a small first bite.
  expect(g.doomed.numTilesOwned()).toBeGreaterThan(90);
  expect(g.doomed.relinquished.length).toBeGreaterThan(0);
});

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/DoomsdayClockExecution.test.ts` around lines 1007 - 1013, Add a test
alongside the existing rotDeathSeconds coverage that creates a game with
rotGrainSeconds set to 0, advances it by one second via rotFor, and verifies the
territory is not wiped out while some tiles are relinquished. Name the test to
reflect that disabling the grainy phase still applies only the small initial
quota.

---

616-627: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Derive the wave levels from DoomsdayClock so the test catches schedule changes.

The current levels array is hard-coded and asserts against itself, so changing the schedule in src/core/game/DoomsdayClock.ts can pass this test. Read the intended level milestones from the shared schedule instead, for example by sampling doomsdayClockRequiredTiles at the normal ramp/pause caps.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/DoomsdayClockExecution.test.ts` around lines 616 - 627, Update the test
around the “steps gently and never jumps more than 10 points at once” case to
derive levels from DoomsdayClock’s shared schedule instead of hard-coded values.
Sample doomsdayClockRequiredTiles at the normal ramp/pause caps, then retain the
existing step-size and dense-bottom assertions so schedule changes are detected.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/DoomsdayClockExecution.test.ts`:
- Around line 1259-1264: In the test setup around inner and the three
small.buildUnit calls, assert that inner contains at least 9 tiles before
indexing it. Keep the existing city placement and length assertion unchanged, so
insufficient interior capacity fails at the explicit precondition rather than
passing undefined to buildUnit.
- Around line 483-486: Update the stale wave-percentage comment in teamGame to
say 25% instead of 26%, and revise the rotGame giveTiles comment to describe the
250 bar instead of 260. Change only these comment values so they match the
current schedule and bar size.

---

Nitpick comments:
In `@tests/DoomsdayClockExecution.test.ts`:
- Around line 1007-1013: Add a test alongside the existing rotDeathSeconds
coverage that creates a game with rotGrainSeconds set to 0, advances it by one
second via rotFor, and verifies the territory is not wiped out while some tiles
are relinquished. Name the test to reflect that disabling the grainy phase still
applies only the small initial quota.
- Around line 616-627: Update the test around the “steps gently and never jumps
more than 10 points at once” case to derive levels from DoomsdayClock’s shared
schedule instead of hard-coded values. Sample doomsdayClockRequiredTiles at the
normal ramp/pause caps, then retain the existing step-size and dense-bottom
assertions so schedule changes are detected.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: df90860d-e1a3-40d7-805a-78cc257b2d2d

📥 Commits

Reviewing files that changed from the base of the PR and between d77e4a0 and ed9d701.

⛔ Files ignored due to path filters (2)

• src/client/render/gl/shaders/name/status-icon.frag.glsl is excluded by !**/*.glsl
• src/client/render/gl/shaders/name/status-icon.vert.glsl is excluded by !**/*.glsl

📒 Files selected for processing (19)

• resources/lang/en.json
• src/client/components/DoomsdayClockPanel.ts
• src/client/render/frame/derive/PlayerStatus.ts
• src/client/render/gl/passes/name-pass/Types.ts
• src/client/render/gl/passes/name-pass/index.ts
• src/client/render/types/Renderer.ts
• src/client/view/PlayerView.ts
• src/core/configuration/Config.ts
• src/core/execution/DoomsdayClockExecution.ts
• src/core/game/DoomsdayClock.ts
• src/core/game/Game.ts
• src/core/game/GameUpdateUtils.ts
• src/core/game/GameUpdates.ts
• src/core/game/PlayerImpl.ts
• tests/DoomsdayClockExecution.test.ts
• tests/GameUpdateUtils.test.ts
• tests/client/render/frame/derive/nuke-telegraphs.test.ts
• tests/client/render/frame/derive/player-status.test.ts
• tests/util/viewStubs.ts

🚧 Files skipped from review as they are similar to previous changes (17)

• src/client/render/gl/passes/name-pass/Types.ts
• src/client/render/types/Renderer.ts
• src/core/game/Game.ts
• src/core/game/GameUpdates.ts
• resources/lang/en.json
• src/client/view/PlayerView.ts
• src/client/components/DoomsdayClockPanel.ts
• src/client/render/frame/derive/PlayerStatus.ts
• tests/GameUpdateUtils.test.ts
• tests/util/viewStubs.ts
• tests/client/render/frame/derive/player-status.test.ts
• src/core/game/GameUpdateUtils.ts
• tests/client/render/frame/derive/nuke-telegraphs.test.ts
• src/client/render/gl/passes/name-pass/index.ts
• src/core/game/PlayerImpl.ts
• src/core/game/DoomsdayClock.ts
• src/core/configuration/Config.ts

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/core/execution/DoomsdayClockExecution.ts`:
- Around line 32-54: Update PseudoRandom with an integer-only bounded-selection
API and use it in DoomsdayClockExecution for rot tile selection instead of
nextInt’s fractional path. Replace the quota and speckle calculations in the rot
logic with integer ceiling-division arithmetic, removing division-based
floating-point operations and Math.ceil while preserving deterministic seeded
behavior.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9ce1fca3-88b9-40ee-b631-8e650210ce01

📥 Commits

Reviewing files that changed from the base of the PR and between d77e4a0 and 8011979.

⛔ Files ignored due to path filters (2)

• src/client/render/gl/shaders/name/status-icon.frag.glsl is excluded by !**/*.glsl
• src/client/render/gl/shaders/name/status-icon.vert.glsl is excluded by !**/*.glsl

📒 Files selected for processing (19)

• resources/lang/en.json
• src/client/components/DoomsdayClockPanel.ts
• src/client/render/frame/derive/PlayerStatus.ts
• src/client/render/gl/passes/name-pass/Types.ts
• src/client/render/gl/passes/name-pass/index.ts
• src/client/render/types/Renderer.ts
• src/client/view/PlayerView.ts
• src/core/configuration/Config.ts
• src/core/execution/DoomsdayClockExecution.ts
• src/core/game/DoomsdayClock.ts
• src/core/game/Game.ts
• src/core/game/GameUpdateUtils.ts
• src/core/game/GameUpdates.ts
• src/core/game/PlayerImpl.ts
• tests/DoomsdayClockExecution.test.ts
• tests/GameUpdateUtils.test.ts
• tests/client/render/frame/derive/nuke-telegraphs.test.ts
• tests/client/render/frame/derive/player-status.test.ts
• tests/util/viewStubs.ts

🚧 Files skipped from review as they are similar to previous changes (18)

• src/client/render/types/Renderer.ts
• src/core/game/GameUpdateUtils.ts
• tests/GameUpdateUtils.test.ts
• src/core/game/GameUpdates.ts
• src/client/render/frame/derive/PlayerStatus.ts
• src/core/game/Game.ts
• src/client/components/DoomsdayClockPanel.ts
• tests/client/render/frame/derive/nuke-telegraphs.test.ts
• tests/util/viewStubs.ts
• src/core/configuration/Config.ts
• resources/lang/en.json
• src/core/game/PlayerImpl.ts
• src/core/game/DoomsdayClock.ts
• src/client/render/gl/passes/name-pass/Types.ts
• tests/client/render/frame/derive/player-status.test.ts
• src/client/view/PlayerView.ts
• tests/DoomsdayClockExecution.test.ts
• src/client/render/gl/passes/name-pass/index.ts

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

[Zixer1]

Continued in #4893.

Same commits, same head SHA 1be7633, nothing rebased. The branch was living on the main repo, which auto-deploys every branch to staging, so it has moved to the fork (Zixer1:feat/doomsday-territory-rot) and the branch here is being deleted. GitHub does not allow changing a PR's head repository, hence the new number.

Review history stays here for reference.