Add world delta streaming and viewer smoothing

NEXT-STEPS.md

@@ -65,66 +65,81 @@ That turns the simulation into a real strategy loop.
 2. Make pirate target selection explicitly prefer economic targets.
 3. Surface faction stocks, throughput, and build priorities in the HUD/debug views.
 4. Expand the order/behavior set with higher-value RTS actions like `hold-here`, `attack`, and `defend-area`.
-5. Break [src/game/GameApp.ts](/home/jbourdon/repos/space-game/src/game/GameApp.ts) into smaller planning / faction / combat / logistics modules.
+5. Break backend simulation responsibilities into smaller planning / faction / combat / logistics modules.
 
-## Migration To .NET
+## Network / Multiplayer
 
-If the long-term goal is multiplayer, scale, persistence, or server authority, a .NET migration is a sensible next architectural track.
+The repository now has a split architecture:
 
-Recommended direction:
+- [apps/backend](/home/jbourdon/repos/space-game/apps/backend)
+  - authoritative .NET simulation
+- [apps/viewer](/home/jbourdon/repos/space-game/apps/viewer)
+  - rendering and observer UI
+- `GET /api/world`
+  - initial snapshot
+- `GET /api/world/stream`
+  - incremental SSE delta stream
 
-- keep the current Vite / Three.js client for rendering and input
-- move simulation authority into a .NET backend
-- treat the browser client as a renderer + command UI
+The next networking step is not “move the simulation into .NET.” That is already done for the active runtime.
 
-Suggested migration phases:
+The next steps are about scaling the transport and authority model cleanly.
 
-1. Define a shared simulation contract.
-   - ship state snapshots
-   - orders
-   - behaviors
-   - assignments
-   - combat / economy events
+Recommended work:
 
-2. Extract the pure simulation model from the Three.js runtime.
-   - separate rendering state from simulation state
-   - remove direct scene dependencies from game logic
+- add client-to-server command submission
+  - direct orders
+  - automation changes
+  - selection / observer commands only where useful
+- add persistence
+  - saves
+  - world seeds
+  - reconnect support
+- add player ownership / permissions
+  - command authority
+  - eventually fog of war / restricted information
+- harden replication contracts
+  - explicit entity lifecycle events
+  - versioning
+  - reconnect / catch-up semantics
 
-3. Rebuild the simulation core in .NET.
-   - `Order`
-   - `DefaultBehavior`
-   - `Assignment`
-   - `ControllerTask`
-   - faction economy
-   - combat resolution
+## Interest Management
 
-4. Add server-driven ticking.
-   - authoritative world step on the server
-   - deterministic or near-deterministic update model
-   - event stream / snapshot replication to clients
+The current stream is world-wide.
 
-5. Add persistence and multiplayer infrastructure.
-   - saves
-   - world seeds
-   - reconnect support
-   - eventually player ownership / fog / permissions
+That means every observer receives deltas for the full simulation, even when only looking at one part of space.
 
-Suggested .NET stack:
+Recommended work:
 
-- ASP.NET Core for API / realtime transport
-- SignalR or custom websocket layer for simulation updates
-- PostgreSQL for persistence
-- background hosted service for world ticks
+- add observer/view-scoped subscriptions
+  - visible systems
+  - nearby ships / stations / nodes
+  - faction-scoped or player-scoped channels later
+- support subscribe / unsubscribe as camera focus changes
+- send only relevant deltas per observer
+- keep coarse strategic updates available for off-screen context
+  - system ownership
+  - major combat
+  - economy summaries
 
-Suggested immediate prep before migration:
+This is the key step that makes many simultaneous observers practical without broadcasting the entire world to everyone.
 
-- isolate simulation data structures from rendering objects
-- isolate faction AI from UI code
-- isolate travel / docking / mining / combat systems into separate modules
-- make event emission explicit and serializable
+## Replication Quality
 
-The key rule for the migration is:
+The backend already sends:
 
-- do not port Three.js-shaped code into .NET
-- first separate the simulation from rendering in TypeScript
-- then move the pure simulation into .NET cleanly
+- initial snapshot
+- incremental deltas
+- event records
+
+Recommended work:
+
+- add stronger event typing
+  - spawn
+  - destroy
+  - dock
+  - undock
+  - cargo transfer
+  - combat hit / kill
+- improve interpolation and extrapolation policies per entity type
+- add resync handling when a client falls too far behind
+- consider switching from SSE to websocket transport if bidirectional command traffic becomes heavy