A Plan Written Down Before The Code

The Document

docs/research/multiplayer-server-architecture-v2.md and docs/research/tick-system-deep-dive.md, describing a three-layer design:

Simulation  ->  Network  ->  Game

With a multi-rate tick system supporting FPS at 125Hz and RTS at 30Hz, and TypeScript branded types for unit safety:

VelocityPerSecond
DisplacementPerTick

Branded types for this project are a big deal. They exist because the same number means two different things depending on which tick you are standing in, and v0.9.5 later records exactly that confusion as a root cause.

The CLI-First Rule

Testability via CLI for every subsystem, and performance budgeting aimed at mobile and browser targets. Two test scripts:

test-spawn.ts            headless spawn validation
compare-local-vs-server.ts   physics comparison tool

Key Findings

Quoted as written:

• ▸Server physics works correctly in headless isolation.
• ▸Client/server integration has spawn synchronization issues.
• ▸Velocity scaling and unit confusion identified as root causes.

Also in this release: enhanced logging in HeadlessBSPCollisionWorld.stepSlideMove(), and a fix to ground detection so it checks movement against collision response rather than trusting the surface normal.

This is the release where the project worked out that its physics were correct and its clocks were not, three months before v0.9.0 proved it at 125Hz and v0.9.16 fixed a scheduler that had been running at half speed.

Known Issues: none stated — the findings are recorded under Key Findings, not as caveats, because at this point nothing is claimed to work.