So what you have is a compromise between delay between clients and having a smooth gameplay experience. I urge everyone to watch that video even if you never played Overwatch since it does point at a lot of common techniques used in games to give you the illusion of a smooth gameplay that is fundamentally limited by the laws of physics.
So in massive games what you need to have is a complex combination of several techniques (the balance of which is something the developers have to nail) and, perhaps, try to have a dynamically-scaling per-client interpolation (objects far away update less often, objects close to you update more frequently).
For all the shit people give Roberts, I think he’s done a good job at hiring and managing his company besides employing his wife as a manager. Even with the alter, it seems like he’s made up for it with his other business and development decisions.
As far as that library, huh that reminds me of another space game’s network code. Vendetta or something?
Usually TCP is used as it virtually guarantees delivery, but there’s much more delay and overhead. I’ve seen UDP mentioned a lot but I’m not aware of it being used outside of that one indie and not very successful Tachyon: The Fringe like game.
Personally, I never really liked the tick based networking like in Overwatch.
Dota2 also uses ticks, and you have these REALLY weird interactions with two things happening on the same tick.
Even with ticks, you can avoid that kind of by taking the order things came in minus the delta, but ehhh.
I don’t really understand why event driven networking can’t work, or a hybrid.
I also don’t like “favor the shooter” as much. I favor UT netcode that’s more about quick reactions to dodge things. I think it makes sense on hitscan, at least.
It is designed around the networking requirements of competitive realtime multiplayer games such as first person shooters and action games. As such it provides the absolute fastest, most time critical networking layer over UDP, with a client/server architecture supporting up to 64 players per-dedicated server instance.
That really doesn’t have anything to do with what UDP networking library you use, or if you use a custom connection implementation.
No UDP framework is going to be the limiting factor in supporting hundreds of players per server. The overhead of sending/receiving messages isn’t THAT high.
Their custom system is more what’s on top of the networking to sim the world and manage what is sent to clients in an efficient manner. That’s where the real work load is.
It would be cool to say that the slugs/bullets/whatever travels until it hits something (insert ME reference here), but the odds of hitting something that you can damage when you miss is so small it’s insignificant. Wasted resources. Unless you’re aiming like a boss, but that will be frustrating when your station is constantly sniped out of oblivion.
If one was to make them persist until impact then you have to start taking about the bullets/whatever being effected by gravity.
Also planets not rotating or orbiting and stations not orbiting makes them easy targets whereas realistically they’d be harder to hit from long range.
System resource limitations. Space is big and empty, and a round that doesn’t hit anything will likely never hit anything in a reasonable time. This requires your poor computer to keep tracking every round that was fired and do physics/trajectory calculations for their next position. Eventually it would bog your system down, no matter how beefy it is.
It still amazes me how massive the whole objective could be. You could have people every were! Planetary and
orbiting bases that could have MMO defending on ground level and air support! Or space support, It would be incredible to have long range or heat seeking missiles from base/ground level and evading enemy air/space craft trying to not get blown away. But all that to would probably be a nightmare for Flavien to incorporate, much less the servers. May be giving him a headache as he’s reading this. lol …sorry Flavien.