4 ms·

What sort of multiplayer are you targeting? There's FPS-style (latency is important, lag compensation via extrapolation and interpolation, rewindable time for

What sort of multiplayer are you targeting? There's FPS-style (latency is important, lag compensation via extrapolation and interpolation, rewindable time for shooter-wins hit detection, UDP serialization with priority and delivery guarantees, sometimes client-side or peer to peer physics resolution, small player count), MMO-style (latency is less important, server-side everything, UDP or TCP, MUD-style messaging/RPCs, high player count, area of interest algorithms to optimize traffic), webgame-style (HTTP or VOIP-tech in browser, coarse grained calls, high latency is ok). There's also client/server, peer to peer, roll-your-own lobby vs. e.g. steamworks integrations, etc. Not much docs up yet on this topic and the demos are a little sparse.

FredrikNoren 4y ago
The current networking stack is pretty straightforward; it's built on top of QUIC so we do get reliable and unreliable UDP with multiple channels so the latency is really low, but we don't do anything fancy. We used to do rollback networking but removed it to simplify things; we realized it was overkill to have it on everything and it would make more sense to implement prediction on the entities that actually benefit from it (like player camera). We're currently working on deploying Ambient to the web too, where we'll probably use WebTransport, which is built on top of QUIC and should give us similar characteristics. For filtering which entities are stream; we haven't implemented that yet but we'd like to do it one day. For lobbies/matchmaking; yes we're planning to implement a service for that. Steamworks integration is a bit further down the line but would be nice one day too.