Goal
Add networking/multiplayer building blocks to the engine. There is currently no networking code anywhere in src — games needing multiplayer have to build this entirely themselves outside the engine.
Scope (suggested)
- A transport abstraction (WebSocket at minimum; WebRTC data channels for peer-to-peer scenarios is a reasonable stretch goal).
- State synchronization strategy for the ECS: likely a snapshot/delta-compression approach over
EcsWorld component data, given the engine's sparse-set ECS design (src/ecs).
- Client-side prediction / server reconciliation and interpolation are the hard, engine-specific parts worth designing carefully rather than bolting on generically — consider scoping an initial release to authoritative-server state sync without prediction, and layering prediction in later.
- Clear separation so single-player games pay zero cost for this module (matches the engine's existing modular subpath-export pattern, e.g.
@forge-game-engine/forge/networking).
Why this is a milestone, not a single issue
Networking touches ECS serialization, the game loop/timing model, and introduces a large new design space (authoritative vs. peer-to-peer, reconciliation strategy). This needs an initial design/RFC before implementation and will span multiple PRs.
Acceptance criteria (top-level)
Goal
Add networking/multiplayer building blocks to the engine. There is currently no networking code anywhere in
src— games needing multiplayer have to build this entirely themselves outside the engine.Scope (suggested)
EcsWorldcomponent data, given the engine's sparse-set ECS design (src/ecs).@forge-game-engine/forge/networking).Why this is a milestone, not a single issue
Networking touches ECS serialization, the game loop/timing model, and introduces a large new design space (authoritative vs. peer-to-peer, reconciliation strategy). This needs an initial design/RFC before implementation and will span multiple PRs.
Acceptance criteria (top-level)
documentation-site/docs/docs