Reading through the networking product page, Netcode for GameObjects is being marketed towards Casual Co-op while Netcode for Entities is being marketed towards competitive. Why is that?
My game idea does not necessarily benefit much from the ECS paradigm, but it is a small-scale competitive game (client-server, server authoritative), and would require excellent netcode performance.
It will have a total of 8 players and a few other networked objects like projectiles (let’s say 10 at most).
So, am I fine with going with Netcode for GameObjects? What is it about Netcode for Entities that make it more suitable for competitive games?
I can still choose to go with ECS, but would like more info before making that decision. Thanks!
Netcode for Entities implements prediction, relevancy and other features you might care about in a multiplayer-oriented game. Netcode for GameObjects is more like a toolkit for slapping multiplayer on top of a singleplayer game and calling it a day.
Note that behind the scenes a Netcode “unification” is in progress though I wouldn’t expect this to surface before next year. The intention is for NGO to sit atop of NfE to some degree, although details are unclear it was promised that several NfE-only features will then be available for NGO.
NGO is primarily restrained by not having client-side prediction, minimal anticipation features, and the most important for competitive play: no server-side rollback.
Rollback means that if a client fires a weapon in tick 100 but the server only receives that information at tick 110, applying the shot at this point in time will cause unexpected hits or misses from the client’s perspectives. With rollback, the server can “go back in time” to tick 100 and simulate the outcome of the weapon fire, then fast forward the next ten ticks to see what other states may have changed (ie a client got a headshot and died, thus this client’s weapon fires must be “rolled back” aka discarded). The resulting changes are then synchronized to all clients.
This is the primary reason why NGO isn’t for competitive ACTION games where these things matter. For a competitive slow-paced or turn-based game you can still very well use NGO.
The other major difference is that NGO will be taxed (CPU and bandwidth) with just a few dozens network synchronized objects. NfE is far more efficient in this regard. With NGO you can, depending on the game and your skill and time investment, support maybe a few 100 simultaneously moving and frequently synchronized objects with network state. Whereas with NfE you can easily have thousands.
As to player count it’s less of an issue because competitive action games hardly sport more than 64 players in a single match, and most of such large-scale action game sessions are rather deserted anyway, or prone to highly fluctuating player counts if it has hop-on/hop-off mechanics (deathmatch). The main issue with action games at this scale is design - the environment needs to be fun to play with all player counts and the bigger the gap between 2 and X the less fun that sort of game tends to be unless you force games not to start without at least 20 players and add AI bots to fill in slots so players actually get to shoot something etc …
No framework is like that!
Networking cannot be slapped on top of a singleplayer game. If the game is even slightly more complex than something like Pacman the effort to integrate networking after the fact amounts to a full rewrite of all gameplay systems. Especially so if the developers never even considered to later add networked multiplayer or simply have no prior networked multiplayer game dev experience.
So from that, I can say that NGO is not currently suitable for my game.
In that case, I would need to either go with NFE or a third-party solution. This leads me to my next question.
Does adopting NFE mean that I must also adopt ECS across the entire tech stack, specifically the Entities Graphics package? Or is it possible to partially adopt NFE?
Hmmm you may want to ask this in a new topic with proper tags. Theoretically you can simulate all game state with Entities and sync this back to GameObject instances which do the rendering.
But I’m not familiar with this approach so I don’t know if there are any roadblocks. It’s possible that the Entities package mandates Entities Graphics as a dependency but last time I checked it was optional.
You might need to fall back to GameObjects for certain edge cases where an ECS-native solution isn’t available (cameras, terrains, etc), but if you’re going to use NFE it’s probably best to implement gameplay using ECS, since all of your game state already lives there.
You can ignore Entities Graphics and implement your own rendering - with GameObjects or from scratch - but I’d avoid doing that unless you’re trying to solve a specific problem. Entities Graphics is a decent foundation. You’ll probably need to rely on a third party library for character animation, though.
