rts - What data to exchange in multiplayer real time games?

I am a hobbyist programmer and right now I am curious about what data is exchanged in a multiplayer session in real time games like starcraft 2. I did a bunch of searches. I found gafferongames.com offering a very good overview of the issues to consider.

Glenn in his article and comments gives a very strong case for using UDP over TCP, but SC2 obviously uses TCP. To qoute Gleen,

The problem with using TCP for games is that unlike web browsers, or email or most other applications, multiplayer games have a real time requirement on packet delivery. For many parts of your game, for example player input and character positions, it really doesn’t matter what happened a second ago, you only care about the most recent data.

So from his statement, I am guessing that his approach is to send the the full game state of every unit on each frame. If the server does not receive a player input on the current frame, then it's just back luck on that player. For God of War: Acension, in which he is lead network dev, this should work quite well I guess.

For SC2, due to it's replay capability, my gut feeling tells me that the underlying engine is a deterministic fixed timestep "user input playback machine", where the only data exchanged is player inputs. Hence Glenn's statement mybe completely irrelevant for SC2. Player input is important, and input sequence is even more important. I don't think it's feasible for SC2 sending game state of 200 units and more at 30 - 60 FPS.

Question: I could be wrong, but I have attempted to identify 2 possible types of data. What are other techniques? Will be good to qoute the game if you will.

EDIT: found this link about starcraft networking model

Answer

Glenn in his article and comments gives a very strong case for using UDP over TCP, but SC2 obviously uses TCP.

Glenn mostly talks about physics-driven games, ie. first person shooters and driving games. These have different requirements to real time strategy games where precise unit positions at every logic step are important. So the communications strategies are necessarily different.

"Real-time" means different things in different contexts. Games are not 'hard' real time in that if a message is late, the whole thing breaks. (At least, there is no good reason for a game to be so demanding, as a software-only system should be able to recover from processing delays, unlike a nuclear power station or a piece of medical equipment for example.) Games are really 'soft' or 'firm' real time. (Definitions at Wikipedia as usual.) The type of game makes a difference as to how quickly you need the information, whether you can lose information and get away with it, etc. Suffice to say that TCP is good enough for many games, but for other games, UDP is preferable.

I am guessing that his approach is to send the the full game state of every unit on each frame.

He would send enough information to reconstruct the relevant game state of any unit that has changed.

1. You don't need to send any information about something that has not changed.


2. You don't need to send the full state if you can send enough information for the recipient to construct the new state from the old state. (eg. Just send a delta value relative to an old state. Or just send the parts of the state that have changed and not the rest.)


3. If two games run exactly the same algorithm and have exactly the same data then you can just send inputs and the recipient resimulates the effects locally to derive the new state.

Most games don't fulfil the criteria for 3, so they use 1 and 2 instead. Many RTS games however can, and do, make use of 3.

Also, it doesn't necessarily have to be "every frame". The concept of a frame is also nebulous. Is it a frame of rendering? Is it a batch of logic? Is it a frame of network data being sent? Do the three always align one-to-one or do you get variable graphics rate with fixed logic rates? Some games, especially real time strategy games like Starcraft 2, or games with replay ability (as you touch upon) like to keep everything in perfect lockstep by having regular network updates (which may or may not match 'frames' in other senses) but this is not a requirement for all games. Many games just send out updates on a semi-regular basis, depending on how far behind they're willing to let the clients run.

Player input is important, and input sequence is even more important. I don't think it's feasible for SC2 sending game state of 200 units and more at 30 - 60 FPS.

Many games won't necessarily treat a rendering frame as a logical frame. They might have 60FPS in graphics but only have 10 logic updates a second, and send 1 network update for each one. But even 30 network updates per second is reasonable if you use the 'send input' method, certainly.

I have attempted to identify 2 possible types of data. What are other techniques? Will be good to qoute the game if you will.

It's not so much that there are distinct techniques, but several different constraints on the systems, and the importance of each constraint will vary from game to game. So you just have to pick a system that works for you.

• Few units, moving quickly and erratically via user input, latency is sensitive, exact synchronisation across systems not important - broadcast positions via an unreliable protocol (eg. UDP) to get maximum speed, and missed messages won't matter as a new one will come in soon. Simulate physics locally to improve rendering quality but correct the positions when new information arrives. Good for shooters and driving games.


• Many units, but most are irrelevant, and they move slowly - only send updates for units near the recipient, send them as changes rather than full states, send them relatively infrequently, and send over a reliable protocol (eg. TCP) to avoid having to worry about how to handle missed updates. Good for MMOs.


• Many units, moved by the AI based on prior user input, exact synchronisation across systems very important - send time stamped user input over a reliable protocol and resimulate locally to have the game algorithms keep state synchronised. Good for RTSes and turn-based games.