Set up basic deterministic lockstep

server/README.md

@@ -1,8 +1,8 @@
 # Headless GameServer
 
 This target runs the authoritative `InternalGameServer` without SDL, OpenGL,
-audio, Lua, or rendering dependencies. On Windows it exposes the state through
-a Boost.Beast WebSocket listener.
+audio, Lua, or rendering dependencies. On Windows it exposes a deterministic
+lockstep session through a Boost.Beast WebSocket listener.
 
 ## Build
 
@@ -39,7 +39,7 @@ For a multi-configuration Windows build, the executable is normally
 For smoke tests, `--ticks N` limits execution and `--no-sleep` skips the
 real-time delay.
 
-Start the first multiplayer transport iteration:
+Start the multiplayer lockstep server:
 
 ```powershell
 .\server\build\Release\GameServer.exe --campaign battle_zone_multiplayer --location uni_exterior
@@ -48,8 +48,11 @@ Start the first multiplayer transport iteration:
 The listener defaults to `ws://0.0.0.0:8080`. Launch the Windows graphical game
 afterward and select `battle_zone_multiplayer`; that campaign connects to
 `ws://127.0.0.1:8080`. Other campaigns continue to use the in-process server.
-The server broadcasts an initial full state and then one every five seconds.
-Client commands are intentionally discarded in this iteration.
+
+The server sends one state snapshot when a player connects, then broadcasts one
+numbered command bundle every 100 ms. Bundles may be empty. Destination input is
+scheduled two ticks (200 ms) in the future. Tick IDs, rather than server or
+client wall-clock values, define simulation time.
 
 If `--location` is omitted, the campaign's configured start location is used.
 `--campaigns PATH` selects a different campaign registry. Content paths are
@@ -64,17 +67,24 @@ Available startup options:
 --campaigns PATH
 --address IP
 --port N
---tick-ms N
+--tick-ms 100
 --ticks N
 --no-sleep
 ```
 
-The graphical client executes Lua/dialogue behavior after building its runtime
+Network mode requires a 100 ms tick; another `--tick-ms` value is rejected.
+The selected campaign's `networkPlayerSlots` lists pre-existing character IDs
+assigned to connections in order. `networkCompatibility` is a release token
+that must be changed whenever deterministic content changes; clients reject a
+different token. The bundled multiplayer Battle Zone has two slots (`player`
+and `player2`) and rejects additional clients. Disconnecting
+releases the slot. The bot's random autonomous controller is disabled in
+multiplayer.
+
+The graphical client executes presentation behavior after building its runtime
 `Location`; the headless content pass loads authoritative navigation, NPC,
-interactive-object, trigger, teleport, taxi, and animation metadata only.
-The standalone WebSocket lifecycle creates the existing shared `"player"` so
-the graphical client can render its local character. It does not create the
-battle-zone test bot.
+interactive-object, trigger, teleport, taxi, and animation metadata. Lua and
+dialogue-driven shared multiplayer behavior is not yet supported.
 
 ## Tests
 
@@ -82,5 +92,13 @@ CTest covers:
 
 - repeated `LocationGameState::setup()` preserving mutable runtime state;
 - ticking a prepared location with zero players;
+- deterministic fixed-100 ms replay behavior;
+- protocol-v2 parsing, validation, target normalization, state hashing, and
+  two-tick command ordering;
+- a WebSocket initial-state/slot/destination/tick integration test;
 - idle server startup;
 - headless loading of `battle_zone_multiplayer/uni_exterior`.
+
+The lockstep implementation currently targets identical executable and content
+builds. Diagnostic state hashes detect divergence, but there is no automatic
+checkpoint resynchronization or reconnect input history yet.