study: single-threaded command-queue tick (thin World, no lock)

marco commented

2026-07-19 00:53:43 +02:00

Owner

World is now a pure lock+delegate facade (#49), but its surface is still broad — ~30 methods across every domain — because the single _gate lock forces it to be the gateway for every operation. It reads like a god-class even though each method is thin.

The deeper fix: connection handlers enqueue intents (as TryEnqueueMove already does); a single-threaded tick applies them via the systems. World becomes state + tick orchestration — no lock, no broad mutating facade.

Why it is worth studying now: the spell system (its first real client) wants exactly this — server-paced word emission is enqueue-intent + process-at-tick. Doing it before/with the spell system avoids building the spell system against the current lock model and refactoring later.

Trade-offs to work through:

Synchronous results today (equip true/false, pickup result, command SystemMessage) become asynchronous — returned via the tick result / a message. Rework the handler flow.
~1 tick (≤100ms) latency on intents — fine for a tick-based game.
The whole concurrency story (the P0 races we fixed) disappears — single thread.
Big refactor of the networking↔world boundary.

Definition of Done (for the study)

A written analysis: how each current synchronous World call maps to an intent + async feedback, and what the handler flow becomes.
A recommendation (do it before the spell system, or keep the lock model) with the reasoning.
If go: a phased plan that keeps the suite green at each step.

World is now a pure lock+delegate facade (#49), but its **surface is still broad** — ~30 methods across every domain — because the single `_gate` lock forces it to be the gateway for every operation. It reads like a god-class even though each method is thin. **The deeper fix**: connection handlers **enqueue intents** (as `TryEnqueueMove` already does); a **single-threaded tick** applies them via the systems. World becomes **state + tick orchestration** — no lock, no broad mutating facade. **Why it is worth studying now**: the **spell system** (its first real client) wants exactly this — server-paced word emission *is* enqueue-intent + process-at-tick. Doing it before/with the spell system avoids building the spell system against the current lock model and refactoring later. **Trade-offs to work through**: - Synchronous results today (equip true/false, pickup result, command `SystemMessage`) become **asynchronous** — returned via the tick result / a message. Rework the handler flow. - ~1 tick (≤100ms) latency on intents — fine for a tick-based game. - The whole concurrency story (the P0 races we fixed) **disappears** — single thread. - Big refactor of the networking↔world boundary. ## Definition of Done (for the study) - [ ] A written analysis: how each current synchronous World call maps to an intent + async feedback, and what the handler flow becomes. - [ ] A recommendation (do it before the spell system, or keep the lock model) with the reasoning. - [ ] If go: a phased plan that keeps the suite green at each step.

marco referenced this issue

2026-07-19 01:05:41 +02:00

docs: single-threaded simulation study (#54) + ModernUO as reference #55

marco commented

2026-07-19 01:05:42 +02:00

Author

Owner

Study written: docs/command-queue-study.md (PR above). Decision: adopt B (single-threaded simulation, ModernUO-style). Validated against ModernUO (single game thread, no world lock, packets processed on the game thread → immediate feedback). Migration via a single-threaded executor, phased so the suite stays green each step (Phase 1: executor foundation → route World access → move reads off connection threads → remove the lock). Combat under B: pipeline stays in a system, per-type OnHit reaction hooks on the entity.

Study written: `docs/command-queue-study.md` (PR above). **Decision: adopt B (single-threaded simulation, ModernUO-style).** Validated against ModernUO (single game thread, no world lock, packets processed on the game thread → immediate feedback). Migration via a single-threaded executor, phased so the suite stays green each step (Phase 1: executor foundation → route World access → move reads off connection threads → remove the lock). Combat under B: pipeline stays in a system, per-type `OnHit` reaction hooks on the entity.

marco referenced this issue from a commit

2026-07-19 01:05:42 +02:00

docs: single-threaded simulation study (#54) + ModernUO as architectural reference

marco referenced this issue

2026-07-19 01:11:04 +02:00

feat(gameserver): single-threaded world simulation, no lock (#54) #56

marco referenced this issue from a commit

2026-07-19 01:11:06 +02:00

feat(gameserver): single-threaded Simulation executor (command-queue Phase 1, #54)

marco referenced this issue from a commit

2026-07-19 01:13:07 +02:00

docs: single-threaded simulation study (#54) + ModernUO as reference (#55)

marco referenced this issue from a commit

2026-07-19 01:29:00 +02:00

feat(gameserver): single-threaded world simulation, no lock (#54)

marco referenced this issue from a commit

2026-07-19 01:33:27 +02:00

feat(gameserver): single-threaded world simulation, no lock (#54) (#56)

marco commented

2026-07-19 01:34:00 +02:00

Author

Owner

Implemented and merged in #56 (main 28df348): single-threaded Simulation executor, tick moved onto the sim thread (WorldTick/SimulationHost), every World access routed through InvokeAsync, and World._gate removed. World now holds no lock. Study conclusions realized.

Implemented and merged in #56 (main `28df348`): single-threaded `Simulation` executor, tick moved onto the sim thread (`WorldTick`/`SimulationHost`), every `World` access routed through `InvokeAsync`, and `World._gate` removed. World now holds no lock. Study conclusions realized.

marco closed this issue

2026-07-19 01:34:00 +02:00

marco referenced this issue

2026-07-19 05:31:39 +02:00

Epic: spell system — server-paced power-word duel (vertical slices) #36

marco referenced this issue

2026-07-19 13:19:15 +02:00

refactor(gameserver): move placement + corpse-decay logic out of World (HARD GATE) #94

marco referenced this issue from a commit

2026-07-19 13:19:16 +02:00

refactor(gameserver): move placement + corpse-decay logic out of World (HARD GATE)

marco referenced this issue from a commit