1
\$\begingroup\$

I have a multiplayer cooperative game (PVE) in where there can be up to 200 enemies at a time (somewhere around that) and I was wondering how devs generally synchronize these? I already have packets being sent every 0.2 seconds or so to players telling other player's position, health points and things like that, and I have no idea how much of the network I can actually use (in a P2P UDP connection).

I really don't wanna leave the clients to sync the enemies positions themselves, as myself as a player have played games like these and its so annoying to have you shooting an enemy in one corner of the map and your friend shooting the same enemy on the other corner. But I have no idea if sending every 0.3 seconds or so updates from 200 enemies and their position is reasonable.

TL;DR: How would devs synchronize a high number of entities for multiple players and what is the limitation of a UDP connection? Is there a number of packets per second that you would work towards?

\$\endgroup\$
1
\$\begingroup\$

Your problem reminds me of this article about AoE: https://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php

The articles solution for AoE's large number of units on screen is for every client to simulate the game on their own. The clients only process the commands other players send out but otherwise the entire simulation is client side.

In your game for example, every player could send an event when they use a weapon, an ability, or fire a projectile. Every client simulates the effects of that action and simulates the change to the enemies or environment. That would reduce your networking traffic pretty heavily I'd imagine.

Since your game is PvE and P2P I feel like you could get away with a simulation trick like this rather than full replicating every enemy character in your game.

There are some caveats to consider. Most publicly available large scale game engines don't guarantee that a physics simulation will be identical on two machines. A late join player would require a special case for one of the players sending the entire state of the game to them and probably freezing any command execution during that time. Any packet loss could be catastrophic to the simulation so you have to guarantee that every command has been received and processed.

\$\endgroup\$
  • \$\begingroup\$ Thank you for your answer. Very interesting article, but it left me with one more question. What is the 200 msec "fluctuation" that's mentioned in the article? Or, in other words, what would be the consequence of actually using the full synchronization of 200 enemies over the network? A FPS lag spike, an overload on the network? I ask because, as with most fast paced multiplayer games, a player interpolation is needed, making it so that other players are actually "rendered on the past", which could result in problems with enemy pathfinding and causing desync, I imagine? \$\endgroup\$ – justanotherdev Aug 30 '18 at 1:16
  • \$\begingroup\$ Sorry for the late reply. The fluctuation they refer to is how far off the simulation could get when fully replicating all of the units and how each player's machine would simulate at different speeds depending on what they were doing or looking at. And you could definitely see both an FPS and network lag spike when replicating 200 enemies' data at once. Because the processing time to process/interpolate new enemy information as well as the high data cost of transferring that much data at once. \$\endgroup\$ – Connor Hollis Aug 31 '18 at 21:09
  • \$\begingroup\$ As far as player interpolation you can still fully replicate the players, but if you can fake the enemy path finding to correct based on players positions but still stay in-sync with every other player you'd be fine with doing simulation locking and not full replication. \$\endgroup\$ – Connor Hollis Aug 31 '18 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.