Any time
Write
Queue atomic orders — as few as one, as many as the Shard allows. Reorder them, copy them, delete them, rewrite them. Say what should happen if one fails.
How it plays
One action per character, per Tick
That single constraint decides the shape of everything else — the clock, the queue, the acting order, the failure rules and the report. This page explains the whole machine, and marks which parts of it exist as code and which are still only written down.
Not built yet
Atomic Tick is not playable. There is no public server, no deployed API, no accounts, no sign-in and no demo. Everything described here is a designed rule; where a rule is also implemented in code, this page says so in the same sentence.
The parts that do exist — Tick scheduling, order queues, snapshots, deterministic resolution, movement, maps, combat, loot and Tick reports — are implemented in a private codebase and pass their tests in development. That is a long way from a game you can open.
The loop
Four beats, repeating, forever
Every Tick in every Shard follows the same four beats. Once you understand this cycle you understand the game; everything else is content built on top of it.
60 seconds before
Lock
The Shard freezes the entry at the head of every queue and takes a snapshot. Everything queued behind the head stays fully editable. Nobody gets a late edit.
On the boundary
Resolve
The server acts once for every eligible character, in an order set by initiative and a recorded draw. The same instant, for everyone in that Shard.
Immediately after
Read
A report says what locked, what became effective, which numbers applied, which draw was used, why the result happened, and what became of your queue.
The Tick
A Tick is a boundary on a clock, not a turn
The design documents define it in one sentence: a scheduled Shard-resolution event in which the server locks intent, determines acting order, resolves at most one effective action per character, applies declared passive phases, and records results.
- Cadence
- The fixed real-time interval between a Shard's scheduled Ticks. It is a property of that Shard, set before it opens, and it does not change because a player would prefer it faster.
- Alignment
- Boundaries are aligned to UTC, computed from the clock rather than from the last Tick plus an interval. Drift is therefore impossible: a 30-minute Shard resolves on the hour and the half hour, every hour, forever.
- Legal cadences
- Any interval that divides the day evenly — 5, 10, 15 or 30 minutes; 1, 2, 3, 4, 6, 8, 12 or 24 hours. A thirty-seven minute Shard is not offerable, because it cannot be anchored. Thirty minutes and one hour are the two profiles the design works through in detail.
- The lock lead
- One minute before the boundary by default. The interface counts down to the lock rather than to the boundary, because the lock is the deadline that matters to a player.
- Deadlines
- Every authoritative deadline is stored as a Tick number, never as a wall-clock time. Real times shown to you are derived from that, and are recomputed after any delay.
- Built or designed
- Built in code. UTC-aligned boundaries, the lock lead, the snapshot, precompute, resolve and commit all run in development, with tests. No server runs them for anybody but the developer.
Cadence is a property of the world, not a difficulty setting
A thirty-minute Shard and a twelve-hour Shard are not easy mode and hard mode. They are different worlds with different rhythms, different populations and different economies, and in the fiction they are different stabilised temporal rhythms left by the same event. A twelve-hour Shard resolves twice a day, suits people who check in at breakfast and at bedtime, and costs almost nothing to operate.
Nothing carries across. Characters, statistics, mastery, items, currency and property do not transfer between independently balanced Shards, so a fast Shard can never be farmed to dominate a slow one. That isolation is what allows cadence to vary at all.
A missed boundary is skipped, not owed
If a Shard is down when a boundary passes, that boundary does not queue up. The next Tick happens at the next aligned boundary and the Tick number advances by exactly one. Six missed boundaries produce one Tick, not six.
This is deliberate, and it is an absence rule as much as an operations rule. Six missed thirty-minute boundaries resolving in a burst a few seconds apart would take three hours of decisions away from every player at once. Instead the Shard remains at its last committed Tick and everybody gets a fresh window to observe and edit.
The queue
Your plan is the interface
There is no cooldown bar to watch and no window you have to be awake for. There is a list of things your character will do, in order, one per Tick — and it is yours to edit right up until the head of it locks.
- Write an entry, insert one, copy one, reorder them, or delete them. None of that costs anything and none of it is rationed.
- Every entry stays separately visible. A queue is never compressed into "travel to the village" — that is twelve Move entries and you can see all twelve.
- Give an entry a failure policy, so a blocked doorway does not discard the rest of your day.
- Set one standing behaviour for the Ticks after the queue empties, so an unattended character does something predictable rather than nothing.
Built in code. Queues, queue locking and the Tick snapshot are implemented and tested in development.
Queue
illustration
5 of 20
#1
Move east
T+1
#2
Collect
T+2
#3
Equip
T+3
#4
Move north-east
T+4
#5
Hold
T+5
standing behaviour: Hold
covers the next 2h 30m
The lock window
One minute before each boundary, the Shard freezes the entry at the head of every queue, records which revision of the queue it took, and snapshots the inputs it needs to sort the acting order. Between the lock and the boundary the server computes resolution scores and sorts actors. That precomputation never decides an outcome; it only decides sequence.
Locking early has a visible cost, and the design states it rather than hiding it: the last minute before a boundary is not editable. In exchange, nobody can watch the clock and slip an edit in at the last possible instant, and the server has time to do its arithmetic without rushing a shared world.
Only the head locks. Entry #2 onward stays editable throughout, including during the lock window.
Capacity is a horizon, not a budget
Queue capacity is how far ahead you may plan. It is never how much you may do. A character with fifty queued entries and a character with three both receive exactly one action at the next boundary. The candidate range is twenty to fifty entries per character, configured per Shard; on a 30-minute Shard twenty entries covers ten hours and fifty covers twenty-five. On an hourly Shard, double both.
This is the point most often mistaken for something familiar, so it is worth being blunt about the difference.
| Question | Atomic Tick queue | An energy bar | Action points |
|---|---|---|---|
| Can it be saved up? | No — an unused boundary is gone. Nothing accrues while you are away. | Yes — energy refills in the background and waits for you. | Yes — points bank until you choose to spend them. |
| Does a larger allowance mean more actions? | No — a longer queue plans further ahead at the same one action per Tick. | Yes — a bigger bar is straightforwardly more play. | Yes — more points is more done per turn. |
| Can it be spent in a burst? | No — entries resolve one per boundary and cannot be cashed in together. | Yes — that is usually the whole loop. | Yes — bursting is the tactical decision. |
| Can it be bought? | No — queue capacity is equal for everyone in a Shard and is never for sale. | Commonly, yes — refills are a standard purchase. | Commonly, yes — extra points are a standard purchase. |
| What does staying online all day earn? | Nothing extra. The same one action per character per Tick as somebody asleep. | More total actions, because the bar is drained more often. | More total actions, and usually better timing. |
Queue capacity changes how far ahead you may plan. It never increases throughput.
Resolution
What happens at the boundary
A Tick is one transaction. It commits entirely or not at all, and it always runs the same nine steps in the same order. There are exactly two extension points in that sequence — prepare and settle — and no rule may add a third.
- 1 — Claim
- One resolver claims the Shard for this boundary. Two resolvers can never work the same Shard at the same Tick.
- 2 — Allocate
- The Tick number is allocated. A database constraint enforces one completed Tick per Shard per Tick number, and one outcome per actor per Tick.
- 3 — Prepare
- The first extension point. Non-player actors append their intent here, through the same queue and the same resolver a player uses — there is no separate monster path.
- 4 — Lock
- The head of every queue freezes, along with its parameters, its failure policy, the standing behaviour, and every input to the resolution score.
- 5 — Draw
- Random values are derived, not streamed: each is a keyed hash over Shard, Tick, actor, purpose and sequence, using a server-held secret. A retry cannot reroll a bad outcome.
- 6 — Score and sort
- Resolution scores are computed and sorted once. The resulting order does not change for the remainder of the Tick, and no implementation is permitted to re-sort mid-Tick.
- 7 — Resolve
- Each actor in turn: validate, then resolve at most one effective action against the world as it stands at that actor's own point in the order.
- 8 — Settle
- The second and last extension point. Statuses expire, defeated actors are marked, spawns refill, regeneration applies. These are published Shard rules, not actions.
- 9 — Commit
- State, the append-only ledger and every report are written in one transaction.
Initiative decides who acts first, and it is recalculated every Tick
The candidate model adds base initiative, an equipment modifier, an action-speed modifier, a current-status modifier and a seeded random draw. Highest acts first. The exact ranges are not settled yet, and this site will not print numbers the design has not agreed.
What is settled is the fairness rule underneath it. Acting order is computed fresh at every boundary, so a permanent character identity never creates a permanent priority. Ties break on a deterministic value derived from the Shard, the Tick, the actor and a server-held secret — never on account age, never on who registered first, and never on who paid.
What is frozen, and what is read live
This split is the reason a scheduled game can still surprise you. Your intent is fixed a minute early; the world it meets is not.
FROZEN AT LOCK
Your intent
- The selected queue entry and its parameters
- The failure policy attached to it
- Your standing behaviour
- Every input to your resolution score
READ LIVE AT YOUR TURN
The world
- Position, terrain, health, resources and statuses
- Whether the target still exists and is still eligible
- Inventory, equipment and ownership
When two characters want the same thing
Nothing is reserved in advance. If two characters both queued Collect on the same stack, both orders lock, both are valid at lock, and the acting order decides. The earlier actor collects it. When the later actor's turn arrives, the stack is no longer there, so their order is rejected before any attempt begins — a pre-invalid rejection rather than a failed attempt.
The distinction matters, because a rejection means no attempt legally started, and a standing behaviour is allowed to supply the effective action instead. A failed attempt is different: once an attempt has legally begun, the Tick is spent whatever the outcome, and no substitution may fire.
Contested movement works differently again, because a character occupying a square does not block it. Nobody can trap you in a doorway by standing in it, and two characters may finish a Tick on the same square. Combat is not a contest for space; it is a contest for attention, and outside expressly marked arenas and competitive zones, ordinary overworld characters cannot attack each other at all.
Failure
A bad Tick costs a Tick, and nothing more
Play-by-mail had one genuinely bad property: an early mistake could ruin a two-week paid turn, and you would not find out for a fortnight. Explicit failure handling is how this design keeps the commitment and drops the punishment.
- Success
- The action resolved as intended. The entry is consumed and the next entry becomes eligible at the following Tick.
- Executed failure
- The attempt legally began and did not achieve its aim — a missed attack is the ordinary case. The Tick is spent. A genuine executed failure may still grant limited practice, because trying and failing is how people learn.
- Pre-invalid rejection
- The order could not legally begin at your resolution point: the target is gone, the square is blocked, the item is no longer yours. Validation itself is not an action, so a standing behaviour may supply the effective action instead. No practice is granted.
- Inability to act
- The character could not act at all — Downed, or otherwise ineligible. The report says which, and why.
Failure policy: continue or pause
You choose what a failure does to the rest of the plan, per order or per character. Both options are deliberately simple, because a policy you cannot predict is worse than no policy at all.
CONTINUE
Consume it and carry on
The failed entry is consumed and the next entry becomes eligible at the following Tick. Right for a long walk, where one blocked step should not abandon the journey.
PAUSE
Freeze and wait for me
The failure is recorded and everything behind it freezes until you resume. Right for anything where the remaining orders only make sense if this one worked — which is most of them.
Which of the two is the default is not settled yet, and it may end up being a per-Shard setting.
A failure never causes another queued instruction to execute immediately.
That is the whole anti-cascade rule, and it is a binding law rather than a preference. Whether an order succeeds or is consumed by failing, the next entry becomes eligible at the following Tick. There is no catch-up, no double action, and no way for a bad Tick to become a bad hour.
The order vocabulary
Every order the game knows about
This is the complete list, split honestly. Six player orders are implemented and covered by tests in a private codebase. Everything else is written design with no code behind it, and is marked that way on every entry.
Built in code — the six player orders
-
Built in code
Move
Advance one adjacent square. Eight directions, one Tick each. A diagonal step is only legal when both of the orthogonal squares it passes between are passable, so you cannot squeeze through a wall joint that is not really there.
-
Built in code
Hold
Hold position and take no active action. Always legal, and the terminator of the standing-behaviour chain: whatever else fails to apply, Hold applies.
-
Built in code
Attack
Attack one target within reach — a named target, or the nearest eligible one. Attack never moves you. A miss is an executed failure, not a rejection, so the Tick is spent.
-
Built in code
Engage
Close on the nearest hostile and attack it when in reach. At resolution it does one of those two things — it moves one square or it attacks. Never both in one Tick, because that would be two actions wearing one name.
-
Built in code
Collect
Pick up one item or one legal stack from the square you are standing on. Reach is zero: there is no collecting at a distance, and no "loot everything nearby".
-
Built in code
Equip
Equip a carried item, or unequip an equipped one — the same order toggles both ways. Anything displaced from the slot returns to the pack. Changing a whole loadout is not one action; it is one action per item.
Built in code — but not player orders
-
Built in code
Return Strikes
A bounded automatic reply to incoming damage, from a per-Tick pool of two to five charges. It costs a charge and ammunition, needs the attacker inside your weapon's range, carries an accuracy penalty, cannot chain, never touches your queue and never changes the acting order. It exists so that standing among twenty hostiles is dangerous rather than merely quiet. It is not something you trigger, which is exactly why it does not break the one-action rule: a reaction is not player-directed, and it remains one decision per actor per Tick.
-
Built in code
Non-player order policies
Creatures and other non-player actors queue ordinary orders through the same queue and the same resolver as characters do. One identity model, one order path, one set of rules — which is also why a creature cannot cheat the acting order.
Designed, not built — next in sequence
-
Designed, not built
Train
Grant one unit of valid practice to one Skill or track. Blocked on two things that do not exist yet: per-actor Skill rank storage, and Skill proficiency affecting resolver outcomes. The progression loop is fully documented and cannot run.
-
Designed, not built
Guard
Apply one defined defensive stance. Automatic Return Strikes exist in code; player-directed defensive intent does not.
-
Designed, not built
Rest
One recovery unit under current conditions.
-
Designed, not built
Revive
One revival attempt on a Downed target, costing the helper their whole action for that Tick. Actors can already become Downed in code; nothing can pick them up yet.
-
Designed, not built
Drop
Create one ground entitlement from one item stack.
-
Designed, not built
Use item
Consume or activate one item, once.
Designed, not built — the wider catalogue
Grouped for reading, but the grouping is presentational: each of these is one order, bounded to one thing, and none of them has code behind it.
-
Designed, not built
Magic
Cast spell — resolve one known spell once and pay its declared resources. The whole Magic module is additionally blocked on an unresolved decision about how spells map onto Skills.
-
Designed, not built
Traversal
Enter and Exit one defined doorway, vehicle, structure or layer transition. Climb, Swim and Crawl — cross one specially defined edge, or add one unit of progress toward crossing it.
-
Designed, not built
Combat, in more detail
Targeted attack against one observed body zone or component. Use combat Ability — one defined Ability, which may have multi-target consequences. Heal — one healing attempt, where contribution counts only effective restoration. Cleanse, repair armour and recharge shield — restore or remove one defined state or resource package.
-
Designed, not built
Perception and access
Search or Observe — one perception attempt. Open and Close — change one legal access state. Pick, Hack, Override and Tinker — one bypass attempt or one unit of progress. Unlock, Unseal and Force entry — one bounded attempt with a learned Ability, changing the lock state only. Activate — trigger one defined device, shrine, control or mechanism.
-
Designed, not built
Objects and inventory
Give — transfer one stack to a recipient's public code, under range and capacity rules. Unequip — return one equipped item to inventory. Pack and unpack companion inventory — one stack to or from one subordinate. Collect highest-priority match is a candidate only, and it deterministically collects at most one eligible item; it never means collect every match.
-
Designed, not built
Work and production
Study or Research — one unit of progress or one discovery attempt. Gather — one gathering attempt. Craft — complete one bounded recipe or add one unit of progress. Repair — one bounded repair or one contribution to it. Build — one bounded work unit on an approved property, facility or public project. Use noncombat Ability — one exploration, social, technical, magical, recovery, production or information Ability.
-
Designed, not built
Speech and identity
Speak or Negotiate — one conversation or negotiation step. Change Class at an approved preparation location, which never includes equipping an entire loadout. Change Job or prepare certification — one active change.
-
Designed, not built
Groups, institutions and subordinates
Contribute to ritual — one bounded unit of progress or one named stage; never complete every stage. Summon or call subordinate — create or call one explicit subordinate actor, which gets its own separately recorded action, never advances your queue, and never acts on the Tick it was created. Command subordinate — update one subordinate's bounded command profile. Register with or use an NPC Guild — one membership, advancement, certification, training-access or service interaction. Propose or accept Clan Alliance — one auditable diplomacy record, which merges no treasuries, property, storage, leadership or action opportunities.
-
Designed, not built
Objectives, markets and property
Accept quest, contract, commission, duty or assignment — establish one objective, which performs none of the requested work. Market list, buy, bid and cancel — one escrow-backed market operation each. Claim, rent or relinquish property — one authoritative ownership or rental change.
-
Not started
Still open
Conditional Wait — remain waiting until a visible condition or a timeout — is a candidate that has not been accepted. Party, trade and Clan administration are designed, but which of them should consume a Tick has not been decided. Where the design has not decided, this site does not pretend it has.
The boundary
Orders that will never exist
A vocabulary is defined as much by what it refuses as by what it contains. These are written down as disallowed, so that a future feature cannot smuggle four actions into one instruction and call it convenience.
Never one order
- Travel to a distant destination as one character order.
- Follow and attack as one ordinary action.
- Clear room.
- Loot everything, without a bounded stack rule.
- Complete quest.
- Gather until inventory full, as one queue entry.
- Train whichever skill is best.
- Automatically heal and then attack.
- Choose any profitable market activity.
- Switch class and equip a complete loadout as one action.
- Command every minion at once, without an expressly bounded group-command rule.
- Build an entire estate add-on as one action.
What you write instead
- One Move per square, every one of them visible in the queue, every one of them a boundary you could have spent differently.
- Engage, which either closes one square or attacks — and tells you which it did.
- One attack per Tick, and a report explaining each one.
- Collect, once, from the square you are standing on.
- An objective accepted in one action, then done in the actions it actually takes.
- One named Skill trained, chosen by you, with the practice awarded shown.
- One market operation at a time, each backed by escrow and each recorded.
- One equip per item, so a loadout change is a plan rather than a button.
The studio's own review question for any new mechanic is blunt: how many player-directed actions can this cause in one Tick, can the player see every queued action it creates, does it reward constant availability, and is it understandable on a mobile screen? A mechanic that fails those does not get built, however good the idea was.
Tick report
illustration
one character, one Tick
- Locked intent
- Move east
- Became effective
- Move east
- Acting position
- 3 of 11 among eligible actors
- Resolution score
- 12 = base 8 + equipment 3 + draw 1
- Random draw
- d20 → 14 ref 3f2a…9c · move/contest
- Result
- Success — moved to (20, 9), a doorway square
- Resources
- no change · health 34/34 · stamina 18/20
- Queue
- #1 consumed · 4 remaining · next lock 60s before the following boundary
Reports
Every result can be explained, down to the draw
A scheduled game asks you to accept outcomes you did not watch happen. That only works if the server can show its work — so it does, for every Tick, for every character, without you having to ask for it.
- Which intent was locked, and which action actually became effective.
- Where you fell in the acting order, and what put you there.
- Which random draw was used, and the reference that identifies it.
- Why the result happened, in plain language rather than a status code.
- What changed: position, health, resources — and the queue itself.
Because randomness is derived rather than streamed, a draw can be quoted back to you exactly, and it cannot be quietly re-rolled by retrying anything.
Built in code. Tick reports and an append-only Tick ledger are implemented and tested in development.
Results must be explainable. It is a binding law, not a nicety — a feature that cannot be explained does not get built.
Everything a report can contain
Not every section appears every Tick; a character who moved through an empty field gets a short report. This is the full field catalogue the design specifies, so you can see the shape of what the server is required to be able to say.
- Tick header
- Shard name and identity · Tick number · scheduled time and actual completion time · ruleset version · any delay or maintenance note · character or roster summary.
- Character resolution
- Character name and public code · starting square and state · the selected queue entry · which queue revision was locked · failure policy · standing behaviour · initiative components and the final resolution score where visible · acting position among visible relevant actors · validation result · effective action · target or direction · success, executed failure, pre-invalid rejection or inability to act · a plain-language reason · resources consumed · damage, healing, prevention, statuses, movement or interaction result · ending square, health and important resources · whether the queue entry was consumed or preserved · whether the queue continued or paused · the next eligible entry and its predicted time.
- Encounter
- Encounter identity and visible participants · visible action results in chronological order · enemy state changes · character defeat and revival · effective damage · effective healing · prevention and control · objective contribution · how the encounter concluded · experience and reward entitlement.
- Loot
- Items generated that are visible to you · the ownership rule applied · the protection deadline · the public deadline · the expiration deadline · the result of collection or transfer.
- Training
- Which track was trained · the requirements used · practice gained · current progress and progress to the next rank · any facility, mentor, item or status modifier.
- Law and reputation
- Jurisdiction · any observed offence or lawful contribution · the witness, sensor or evidence source visible to you · Faction reputation change · suspicion, citation, fine, warrant, detention or service state · the route to appeal, restitution or expiry.
- Subordinate actors
- Subordinate identity and controller · the stance evaluated · the target eligibility rule · selected action and initiative · outcome and failure reason · contribution credited to the controller · capacity, duration, upkeep, health or separation change.
- Markets, contracts, Clans, Guilds and property
- The listing, auction, contract, Clan, Guild, project, shop, property or rental identity · item and currency escrow changes · fees, rent, tax, proceeds, collateral, payout and refund · public identities that privacy rules permit · permission, ownership or access change · crafting or construction progress · expiry, renewal, delivery or recovery deadline.
What a report leaves out, and why that is also a rule
Reports exclude hidden actors, undiscovered item details, secret rolls, and anything your character was not entitled to perceive. The authoritative ledger holds more than any player report shows, and support tooling reaches the complete record only under audited authorisation. Explainability is not the same thing as omniscience, and treating them as the same would hand every player a sensor suite.
One further requirement sits on all of it: a complete plain-text representation accompanies the visual report. That is there for screen readers, for support, for export, and for a bad connection on a train — four problems solved by the same decision.
Absence
Designed so you can leave
The game should not demand constant presence. Six mechanisms are designed so that sleep, work, travel and ordinary life cost you a plan rather than a character — and one hard limit exists so that they never add up to a character that plays itself. Four of the six are built, one is designed only, and one is built as far as the Downed state and no further. Each card says which.
01
The queue
Twenty to fifty entries, configured per Shard. On a 30-minute Shard that is ten to twenty-five hours of covered boundaries; on an hourly Shard, twenty to fifty.
02
Failure policy
Continue or pause, chosen in advance. Nothing silently discards the rest of your plan while you are asleep.
03
Standing behaviour
One behaviour, used only when the queue is empty, paused, or unable to supply an action that can begin. Never after an attempt has legally begun, never recursive, and it falls back to Hold. Candidates: Hold, Guard, attack the nearest eligible hostile, train a selected track, Rest, Hide, observe or scan, use a selected survival item — of which four are accepted in code today and the rest are candidates in the design.
04
Notifications
Queue low or empty, paused by failure, Downed, revived, loot approaching public state, Shard maintenance — with per-character filtering, quiet hours, batching and channel choice. Designed, not built.
05
Recoverable defeat
At zero health a character is Downed: the queue pauses, allies get a limited window to Revive at the cost of their own action, and an unrevived character returns to a sanctuary under a temporary or curable consequence. Neither route restarts old movement or combat orders. Permanent death exists only in expressly marked Hardcore Shards, disclosed before you enter one. Being Downed exists in code. Revive, Rest and sanctuary recovery are designed, not built — nothing can pick a Downed actor up yet.
06
Protected loot
Loot begins under a visible protection rule, becomes public at a known deadline and expires at a known deadline — with both shown in real time and in remaining Ticks, so being asleep is a known quantity rather than a gamble.
The limit: absence protection is not autonomous play
Standing behaviour is deliberately small. The test the design applies is that one standing behaviour should be simple enough that a player can predict it. These are named in the design as behaviours that will not be offered:
- Automatically travel toward a distant goal.
- Automatically select the most profitable action.
- Automatically switch between combat, training and gathering.
- Automatically manage inventory or sell loot.
- Run a player-authored script with unrestricted conditions.
Every one of those creates autonomous play rather than a simple absence contingency. The queue is meant to carry your decisions through the night, not to make new ones on your behalf.
You are not disadvantaged because another player can remain online all day.
Worked example
Three Ticks, worked through
One character on a 30-minute Shard, across ninety minutes. Every order used here is one of the six that exist in code, and every rule applied is one stated above.
Read this as a walkthrough, not a recording
No Shard is running and no character exists. The panels below are drawn by hand to show what the designed rules produce, and the Tick numbers are written as n, n+1 and n+2 rather than invented figures, because there is no history to quote.
Tick n — the ordinary case
The character is inside a walled settlement. A stack of loot sits one square east, dropped by a creature two Ticks ago; its protection deadline has passed, so it is public and anybody may take it. The plan is: step onto it, collect it, equip what is in it, then move on. Five entries, two and a half hours of cover.
At 60 seconds before the boundary, entry #1 locks. At the boundary the character resolves third of eleven eligible actors and moves one square east.
Queue at lock
5 of 20
#1Move eastT+1
#2CollectT+2
#3EquipT+3
#4Move north-eastT+4
#5HoldT+5
standing behaviour: Hold
covers 2h 30m
Report
Tick n
- Locked intent
- Move east
- Became effective
- Move east
- Acting position
- 3 of 11
- Validation
- Passed — destination passable
- Result
- Success — moved one square east, onto the stack
- Resources
- stamina −1 · health unchanged
- Queue
- #1 consumed · 4 remaining · #2 eligible next Tick
Tick n+1 — somebody else got there first
Another character also queued Collect on that stack, and their resolution score put them second in the acting order. By the time our character's turn arrives at position seven, the stack is gone. Collect cannot legally begin, so this is a pre-invalid rejection rather than a failed attempt — which means the standing behaviour is permitted to supply the effective action, and it supplies Hold.
Entry #2 carried the failure policy pause, so the queue freezes with everything behind it preserved. Critically, entry #3 does not run early to make up for the wasted Tick. Nothing is owed and nothing accelerates.
Queue at lock
4 of 20
#2CollectT+1
#3EquipT+2
#4Move north-eastT+3
#5HoldT+4
standing behaviour: Hold
covers 2h 00m
Report
Tick n+1
- Locked intent
- Collect — one stack from this square
- Acting position
- 7 of 11
- Validation
- Rejected — no eligible stack on this square
- Reason
- collected at acting position 2 this Tick · stack was public, protection expired at Tick n−1
- Became effective
- Hold — standing behaviour
- Practice
- none — a rejected attempt teaches nothing
- Queue
- paused #2 preserved · 4 remaining · nothing advanced
- Notification
- queue paused by failure
Tick n+2 — the plan resumes
The player reads the report at some point in the next half hour, deletes the dead Collect and the now-pointless Equip, resumes the queue, and leaves Move north-east as the head. All of that is free and none of it is rationed. It also changes nothing about the next boundary: the resumed head becomes eligible at the following Tick, exactly as it would have if nothing had gone wrong.
Three Ticks, ninety minutes, three actions — one of which produced nothing but a Hold. That is the honest cost of a contested stack, and it is also the point: the loss was one boundary, it was explained, and it did not cascade.
Queue at lock
2 of 20
#1Move north-eastT+1
#2HoldT+2
resumed · 2 entries deleted
covers 1h 00m
Report
Tick n+2
- Locked intent
- Move north-east
- Became effective
- Move north-east
- Acting position
- 5 of 11 — order recomputed this Tick
- Validation
- Passed — both shared orthogonal squares passable
- Result
- Success — moved diagonally onto open ground
- Queue
- #1 consumed · 1 remaining · queue low warning sent
Where this is
Of the machinery in that walkthrough, the Tick clock, the queue, the lock, the snapshot, deterministic resolution, movement with the diagonal rule, combat, loot protection, Collect, Equip, standing behaviour and the report structure are all built in code and pass their tests in development. Revive, notifications, the failure-policy interface and the browser client that would show you any of it are not. The honest status page lists the whole thing, item by item.