Network Serialization/Synchronization on the Roadmap?

[Riizade]

Is there a plan to include a canonical Bevy solution for networking in online multiplayer games?

I'm consistently impressed by Bevy's abstractions and ergonomics and I'm very, very interested in what the team will come up with for networking.

My understanding is that in order to implement rollback-style netcode the engine needs a way to serialize the data which represents a minimal representation of game state from which all other state can be generated. There doesn't seem to be a concept in Bevy yet of separating out state that can be reproduced from other state (e.g., it is likely unneeded to pass Sprite components over the wire since their attributes are likely generated via some fixed mechanism that does not differ across clients, such as which enemy type is being represented).

With the (to my understanding) upcoming Scene rework, are Scenes a good fit for this kind of "representing canonical state" problem? I think I read that Scenes are appropriate for the save/load use case, which should resemble loading state from the network quite closely, albeit with less timing and size constraints.

I'd also be happy to be pointed to previous discussion on this topic, I couldn't find anything with a brief search, but it's entirely possible I missed something.

[CleanCut]

Networking is not one of the current focus areas (see the What's Next section of this blog post).

I haven't seen any other issues/discussions on networking, so it looks like this discussion is the de-facto place to discuss it. 😄

[Riizade]

In that case, I guess I'll throw out some ideas for what I might like to see and how I've been thinking about this problem. Keep in mind I'm not an expert, I have never implemented game networking before, so I might be way off the mark with current approaches to this problem space.

There are a few different network modes that could be implemented:

1. Lockstep - clients pass specific update commands to the server (could be as low-level as just raw input alongside timestamps, or could be a bit higher-level, like passing "game action" messages). The server processes the update commands, calculates the new state, and sends Changed<T> components/entities back to the client. The client then updates these entities.

2. Server-authoritative with client-side prediction - the same as above, but some systems run locally and the client updates state as it believes appropriate, but stores which changes were "client-updated", and the next time it receives a state update from the server, discards its client updates in favor of the server ones.

3. Client-authoritative - the client calculates its own state, then sends it to the server. The server collects states from clients and merges them, then sends state that each client doesn't already know about to the clients that need them. The client-authoritative nature of this setup makes cheating easy, so developers should keep that in mind.

Additionally, there are a few ways Bevy could abstract away most of the hard parts of networking. The biggest abstraction challenge in my mind is how to declare which parts of game state need to be synced across the network, and which don't. Things like menu state and UI elements don't need to be in-sync across clients, but player characters and NPCs and things do. Here are a few off-the-cuff ideas.

1. Networked component. Adding this component to an entity would cause its state to be sent across the wire, in effect marking it as something that needs to be in-sync across clients.

2. An explicit NetworkState resource type that developers extend by writing systems that write to this resource. At the networking stage of ECS execution, the NetworkState is finalized/serialized and sent across the wire. This resource could look a lot like the Scene format.

A couple of miscellaneous thoughts:

1. I don't know what the current state of game networking looks like, but I'd imagine that packets look a lot like UDP (fire and forget). In this case, we want to serialize extra state to ensure that a dropped packet doesn't cause clients to get out of sync. For sending state (e.g., from an authoritative server to clients), it might make sense to send Changed<T> type state updates on every server tick, and then on some interval, it sends a full state dump. This ensures that if an incremental update is lost, the client is only out of sync for a maximum amount of time as the interval of full state dumps. This process could be amortized by sending subsets of full-state information on every tick alongside the changed elements, rather than sending a full dump on an interval.

2. As above, for clients sending very little information to the server (e.g., sending only button/key inputs), an input buffer could be maintained for the last N server tick intervals, and every time input is sent from the client, it sends the full buffer. This ensures that a dropped packet doesn't lose input information (or rather, only delays it until the next packet is received by the server).

3. Need some way to decide which system stages are subject to state rollback and which are not. When a packet is received, it'd have a timestamp on it, and the client/server should store networked information for N frame intervals, and if a packet is received with a timestamp within those frame intervals, the client/server can roll back to that state, then replay its own state alongside the new information it received to recalculate the current state. The Networking stage itself should clearly not be replayed, however, and we'd also want to avoid e.g., drawing to the screen since we only care about presenting the latest frame in this case. So some stages need to not be subject to the rollback mechanism.

That's all I've got for now. I have no idea if this will be helpful, but I'm thinking about this stuff for my own game, so this is basically my state dump.

[Riizade]

Want to additionally just point out this awesome talk from GDC: Overwatch Gameplay Architecture and Netcode

Overwatch uses ECS and the talk touches on some of the ways they synchronize game state between clients.

And this one I haven't watched: 8 Frames in 16ms: Rollback Networking in Mortal Kombat and Injustice 2

[minecrawler]

Just want to throw in a possible collab with the Amethyst team. Since the Amethyst engine also uses an ECS (SPECS / Legion), it might be worth syncing with them and see what kind of things they already worked out and how well they fit with Bevy's strategy.

CC @fhaynes

[fhaynes]

These two links might be useful: Multiplayer Games and Auto-sharding Worlds

The first one is a fairly comprehensive look at the various types of multiplayer games and some of the technology required for each. The second is an unfinished doc that I had started on how to implement auto-sharding worlds.

I've done quite a bit of game network coding, and there's a few others in Amethyst who have as well. Laminar was designed to allow for most common multiplayer game needs. If you can be more specific about what type of multiplayer functionality you'd like to start with, I'm happy to do design reviews, answer random questions, etc.