Future Features?

Unity Engine
,
1

Hello,

I wanted to know what future features were planned for ECS Netcode. Right now it seems to be setup as one-size-fits-all, but I wanted to know if the following were things that might be addressed in the future (or already loosely supported!):

  • Custom Serialization using bits so I can do custom quantization using octrees or other methods to efficiently send data
  • Variable tick rates and quantization resolutions for different importance levels, not just the global server settings
  • Custom packet type headers so I can better manage my own deltas and process chunks of similar data types versus a single entity at a time… also it might be nice to take even more shortcuts when it comes to reducing packet size
  • Being able to fine-tune delta-only ticks with periodic absolute values of position/etc to keep things efficient
  • Optimized handling of new clients joining by receiving the entire server state over RPC
  • Ability to cleanly do custom partitioning so that more than 1 server can simulate a single play space

Some of these I know I can do manually with the Transport already if I grinded on it, but the ECS package is probably more mature. All of these I believe would be necessary for allowing Unity to support large scale and groundbreaking multiplayer experiences.

Thank you!

2

Hey chasse!

Yes, you’re right, our implementation is very “opinionated” about how serialization is done.
I.e. Our architecture is fairly rigid in terms of GhostField snapshot replication, where the flow is:
Gather Ghost Chunks > Sort them > Iterate over entities in chunks until snapshot is full > Serialize all GhostFields using the strategy defined in the template.

I’d recommend reading this page: https://docs.unity3d.com/Packages/com.unity.netcode@1.0/manual/ghost-types-templates.html

As well as these three serialization pages: https://docs.unity3d.com/Packages/com.unity.netcode@1.0/manual/synchronization.html

Therefore, changing how an individual ValueType is replicated can be done via defining user templates, but we don’t provide much more snapshot serialization flexibility than that. However, that does not stop you from fetching the drivers and pipeline stages yourself, and building + sending packets manually. At that point, our Netcode for Entities package would be more of a bootstrapping tool for your own netcode implementation.

Sending entities at a lower tickrate via “Importance Scaling” (where our default implementation is Distance-based Importance Downscaling) is supported, but we use the approach of:

  • Define how big your packets should be, and at what frequently each packet is sent.
  • Netcode will attempt to fill the packet, using a chunk importance heuristic to sort ghost chunks.

Thus, if you’re used to setting a specific tickrate for a specfic ghost under a specific importance scaling, our approach is the inverse. We’ll send as much as we can until the user-defined packet size is full.

You can modify / replace / toggle our custom distance-based downscaling if you want finer control.

This would require fairly significant packet modification, if what you want cannot be achieved via the (aforementioned) custom serialization template.

Similarly, this is something we do automatically for you. You can see our delta-compression approaches in said templates. We have a few ideas to further improve this, but nothing we can talk about today.

We handle this simply by sending pertinent snapshots until the client has received all “relevant” ghosts. I.e. Eventual consistency handles this. You can do things like:

  • Define a subset of server ghosts which should be sent to this client (Relevancy). Example: Relevancy radius around the player of 500m.
  • Increase the importance of ghost chunks which the client has never received.
  • Query the percentage of ghosts that the client has received, of the aforementioned “relevancy set”.

Because we have state synchronization via snapshots, writing bespoke logic for new joiners is unnecessary. We would likely provide the sort of thing you provide for a GGPO architecture, however. Best example that comes to mind is Factorio.

The “multiple servers” architecture is not supported in Netcode for Entities, but it is on our radar in the long-term. Our current focus is optimizing single-server scalability, especially as “Vertical Scaling” can often solve these “persistent MMO” scale player counts (e.g. 500+ players in a single server).

In my personal view (i.e. not speaking as a Unity employee here), “multiple server” architectures:

  • Add a huge amount of complexity (and latency considerations), which classes them automatically as “extremely ambitious”. DOTS provides a lot of the necessary flexibility for this kind of architecture, but it’s a huge undertaking.
  • Are still poorly suited to handle a large quantity of players converging on a single area, resulting in unplayable levels of network degradation and rubber banding. So, at that point, why not just use tried and true region/realm instancing?
  • Are prohibitively expensive to operate, except for large AAA teams.
  • Don’t yet have a concrete use-case. I.e. I think the idea of a 1k player server sounds better in our heads than in practice, especially if the goal is meaningful interaction. I.e. The best multiplayer experiences I’ve ever had are when I know and understand the people around me. E.g. A small, intimate concert venue vs an arena. If you want an arena atmosphere in a video game, the “hard problem” isn’t the netcode IMHO, it’s the audio and voice chat.

LMK if this was helpful, cheers.

3 Likes
3

Btw this seems close to the Halo netcode (and by extension Tribes), so linking to this great GDC video might help people:

1 Like