World and Ticks

One persistent world

• Every player shares one permanent world on a two-dimensional square grid.
• There are no seasons, no match resets, and no NPCs, monsters, or server-controlled fleets.
• An account owns at most one living Core at a time.
• Units, and each generation of a Core, get non-enumerable UUIDs. An object keeps its ID for as long as it lives, and no ID is ever reused after death.
• Every Core publishes its owner's username. Enemy state still never carries account IDs, email addresses, or Unit owner usernames.

An account that activates while the world is mid-resolution does not get spliced into a half-built snapshot. Instead the server records a persistent activation_tick, and the player enters through deterministic respawn processing at that Tick like everyone else.

Deterministic chunk generation

Terrain comes in 32×32 chunks, generated from a permanent secret world seed and a versioned HMAC-SHA256 contract. Clients never see the seed.

That buys you a few guarantees worth relying on:

• The same world, generator version, balance, and coordinates always produce the same terrain.
• Neighboring chunks share deterministic boundary passages.
• Every passable pocket connects to the chunk backbone, though one-cell chokepoints are allowed and can matter strategically.
• [0, 0] and its route to the backbone are always EMPTY, so the Champion Beacon is never walled off.
• If the generator contract does not match, the service refuses to start. Changing generation semantics therefore means a new world database.

Obstacles and backbone passages are permanent terrain. Resource points are a separate, consumable layer with a fixed quota per chunk; their replenishment is also deterministic. See Map and vision for the quota and placement rules.

Tick lifecycle

Every logical Tick has a fixed command phase followed by a resolution phase whose length varies.

The window opens first, and only then does the server publish states one player at a time. What reaches you is therefore whatever is left of that global 15 seconds; receiving state does not start a private timer of your own. The protocol deliberately withholds opened_at and deadline_at.

Keep the two messages straight: tick only announces that a logical Tick exists, with commands still closed. state is the one and only signal to act.

Resolution order

This order is part of the protocol, not an implementation detail:

1. Lock the final valid Agent and Manual plans.
2. Resolve every SELF_DESTRUCT, remove those Units, and drop any Worker cargo on their final cells.
3. Resolve Unit movement, and Core migrations that reach their fourth Tick.
4. Validate new Core START_MOVE actions.
5. Resolve Champion Beacon pickup and drop actions.
6. Resolve Worker harvest and deposit actions.
7. Freeze one immutable combat snapshot and accumulate every legal attack.
8. Apply damage simultaneously, remove destroyed objects, and transfer eligible destroyed-Core inventory.
9. Resolve SELF_DESTRUCT for every Core that survived combat. Destroy its inventory and fleet, and drop Worker cargo and the Beacon at their actual positions.
10. Resolve surviving Unit HEAL actions in Unit UUID order.
11. Snapshot each player's living population, then resolve each remaining Core's HEAL, REPAIR_SHIELD, or dynamically priced SPAWN action.
12. Immediately attempt to respawn newly destroyed Cores. Retry next Tick only when no legal spawn exists.
13. After every fourth resolved Tick, replenish only the consumed resource slots in each affected chunk back to that chunk's fixed quota.
14. Atomically commit the world, resource layer, events, statistics, journal, and new clock.
15. Announce the next Tick and prepare fresh private states.

The server never skips a Tick to catch up with wall-clock time; downtime simply pauses the world. And two Ticks never resolve at the same time.

Resource replenishment belongs to the resolved Tick. A point consumed on a replenishment Tick is removed first; the later replenishment step then fills the chunk's missing slots. Existing unharvested points stay where they are, and unused capacity never accumulates above the quota.

Atomicity and replay

One Tick's result commits in a single PostgreSQL transaction, so there is no window in which a client can observe a half-resolved world. The engine is also forbidden from letting map iteration order, wall-clock time, process randomness, or unordered query results decide an outcome.

Given the same world state and the same locked plans, the rules produce the same result byte for byte.

Crash recovery

Failure point	Recovery
State preparation fails	Do not open the command window.
State publication fails	Abort the gate; reannounce the same Tick and reopen a full 15-second window after recovery.
Server crashes while OPEN	Keep persisted plans; on restart send the same tick, full state, latest receipts, and reopen a full window.
Server crashes after lock	Do not reopen; replay the persisted locked plans deterministically.
Server is offline	The world and all logical timers pause.

Existing-world transition

The consumable-resource release replaces the legacy resource layout in the existing world. It does not reset the world clock, players, Cores, Units, inventories, respawn status, or Champion Beacon state. Resource positions switch to the new per-chunk quota and replenishment contract as a map-layer migration.

Rules v0.5 retained Worker cargo piles and added population-based Core storage. Rules v0.6 set that capacity to max(10, population × 5). Rules v0.7 let Ranger shots pass through Units and Cores; only obstacles block them. Rules v0.8 adds exact 45-degree diagonal fire at range 1-3, with only intermediate shot cells checked for obstacles. Rules v0.9 transfers a combat-destroyed Core's inventory, up to capacity, to the highest-damage player whose Core survives that combat Tick. Rules v0.10 moves Core resource actions after combat and adds Unit and Core HP recovery. Rules v0.11 made unpaid maintenance damage excess Units instead of the Core. Rules v0.12 added unconditional, cooldown-free Core self-destruction after combat. Rules v0.13 added target-free Ranger cell shots and deterministic lowest-HP/UUID target selection. Rules v0.14 removes maintenance and replaces it with exact, population-based Unit prices. Existing v0.1 through v0.13 worlds upgrade at an OPEN or COMMITTED boundary without resetting game state. The current rules also remove the respawn cooldown: a destroyed Core gets a replacement attempt later in the same Tick. A server stopped in LOCKED or RESOLVING must finish that Tick under its old rules before upgrading.