That was an interesting read.
The last bit about client/server prediction put multiplayer games into perspective for me. The client (AKA player) computer has to hold multiple past game states in memory and be able to replay back to the current game state in the event of lag. So the client computer has to be able to simulate the game itself significantly faster than the normal play speed. And since most multiplayer games support late joining, or at the very least are capable of correcting a client in the case of a severe desync, the server needs to be able to send the entire game state over the internet. On top of that, what can be actually contained in a packet is more limited than I realized. I didn't understand that user's routers could be a bottleneck where if you send too many packets in a short frame of time it chokes up and starts buffering.
Everything just... makes so much sense now. Multiplayer games have been built around the limitation of network architecture, rather than the network architecture being built around the game. Because neither game developers nor game players truly control the hardware that makes up the internet. Game state is too complicated to be simulated quickly, client can't correct for lag. Client and server have to send too much info router chokes. Client computer can't process the game fast enough, it falls behind everyone else's game state and now you have to send them the whole state as if they were newly joining. The game must be built within certain very specific perimeters.
No wonder most successful competitive and multiplayer titles are so far behind the curve graphically! The devs already have so many concerns, the thought of CPU or GPU lag on top of that must be a nightmare. No wonder the FPS developers of the previous generation liked consoles so much. They can make assumptions about the client's hardware. And the way Microsoft and Sony handled online connectivity (the ONLY good thing I'll say on this topic) is that they encouraged players to use wired connections to the router rather than wireless. So now devs that want to make a game run fast like sonic, can still push the hardware to its limit (since they know what that hardware is) and the average internet connectivity is better. Trends have changed since then but that's its own bag of worms only loosely related to hardware (PC is now the path to the casual multiplayer crowd, believe it or not).
And if you look at which multiplayer games have survived, its almost always games that have ignored recent gaming improvements. Most of the huge MP successes have barely any non-player physics objects and most certainly do not use havoc, rather using their own physics calculations. It also explains why even tho modern FPSs always have at least one projectile that's simulated they choose to make almost all guns hitscan. Many games even have detailed sniper simulation with bullet drop but don't apply that to modern weapons. Its because hitscan shots don't need to be remembered, only the inputs that resulted in the shot. And also why most RTS style games (like MOBAs) implement basic attacks as homing skillshots (which are cosmetic and thus acceptable to be desynced as long as the time damage ticks remains consistent). So if you think about it, in the average multiplayer FPS, the game state is *ultra* simple. Its physically impossible for most players to have more than 5 projectiles out at once without cheating, and generally a projectile attack will resolve before you can start another one. Then most competitive games have no NPC players whatsoever. So all that you need to send to each client is the stats of each player's character. So that's... a position, a rotation, the current animation state and the frame, then a couple values like health/mana/cooldowns/ammo. And then all active projectiles, which is almost nothing. Oh my god, the game state in Overwatch is so simple, I just realized. All those crazy attacks and abilities on the heroes, yet the info the server needs to send to each client is so... simple.
I always felt like characters that could fire multiple simulated projectiles attacks in a burst (Lucio, Genji) had a fire speed just *slightly* slower than they should. The developers were limiting the complexity of the game state! In most cases, you aren't going to realistically have more than two Lucio or Genji bursts off before the shots stop landing. So that's no more than six projectiles at once. And if you think about it, that's... the highest clip size of any projectile attack character. The devs must have sat down early in development and settled on a limit of no more than six projectiles per player, probably due to some arbitrary technical requirement. Or maybe eight projectiles, yeah it must be eight. A nice clean power of two, just like computers want. Sym can practically have two plasma balls out and six turrets, junkrat can have 5 grenades, his trap, his mineand his tire at the same time. Hanzo can have one sonar arrow out, 6 scatter arrow projectiles, and one normal arrow. With his ult out he can go over eight, same for Symm and Pharah. Those were the only exceptions with ult, and Roadhog was the singular exception to the "rule of 8" that didn't have to use his ult.
And oh my god, the rule only changed once the balance team went off their meds. Roadhog was the only pre-release character who broke the rule without having to ult, since his shotgun is projectile based and fires more than 8 pellets. In fact it fires 25. That's bad, but the nature of Roadhog is that most Roadhogs will fire at short range so the shots vanish quickly, and due to reload speed they couldn't sustain 25 simulated objects continuously. Now they increased his fire rate. So Roadhog can have 50 shots out at once, and on top of that they buffed his clip size and fire rate so he can fire near-continously. An entire team of heroes that adhere to the rule of 8 could only put out 48 objects, now one player can put out 50! That's not even getting into Orisa. Orisa can build only two things, but there's a little more data that her shield and totem need than the average bullet (if nothing else, they both have health values). That pales incomparison to her gun however. Giant clip, fast fire rate, long range, slow moving projectiles. Literally every thing that they could have done to keep the packet size impact of Orisa's gun down, they failed to do.
That being said, these changes don't necessarily matter for most players. Most players in Overwatch set their graphics high enough they can handle normal gameplay they lag when the particle vomit is on the screen from a teamfight. That's not internet lag, that's graphics lag. That can make online lag compensation harder (especially if your computer overheats to the point where it can't process the game fast enough to keep up with the server), but its not the same thing as online lag. The upshot is that on release, with the exception of Roadhogs,
essentially nothing you did in-game could increase the internet lag for yourself or other players. Since the developers clearly sat down beforehand and reserved space in each packet. You know, this packet is the level packet. This range of bytes is the game clock, this range of bytes is the objective progress, this range of bytes represents bool values indicating if an environmental object is destroyed provided we only have 64 destructible objects. And that's the thing, as long as the amount of info you have to send each time is static, gameplay will have no effect on the amount of packets the server has to send each tick. And Overwatch was clearly designed around this. No special modes or maps require a particularly higher amount of extra data. The game assumes no more than 6 players on each side to the point of being hardcoded. And if you actually break what values are needed to represent the current state of a hero, its the same between all heroes. So as long as you leave some reserved space in your packets for heroes with extra features, you're good. Even if new buffs and debuffs are added to the game it should not increase the number of packets. All you need to express buffs and debuffs are eleven different duration values, one for each player except the client. You don't actually need to know what the debuff is. Since you can't apply buffs to your enemies or debuffs to your allies, as long as every new hero has at most one buff and one debuff, you should be fine. Ticking healing and damage are the same principle, you just need to know how many ticks are left and when the next one is; from that you can show the effects of the healing/damage without knowing what a tick actually looks and sounds like. But again the new the path the development team has taken immediately screwed the pooch. Ana has no less than 5 status effects, 3 of which are debuffs. And they keep doing this like that.
I don't know, mainly I'm just frustrated because its clearly that the low level programmers who worked on the project pre-release did a really good job and now their elegant work is being sort of stripped away from the game. If those employees are still tasked to Overwatch I highly doubt they're being consulted as much as they should be when it comes to connectivity issues.
Mainly this just makes me impressed with the Planetside 2 team. I now understand the enormity of the task they set themselves to.
Author
Topic: if self.isCoder(): post() #Programming Thread (Read 890087 times)