Hey Everyone, I was wondering how games like Warcraft III and Neverwinter Nights decrease the amount of data sent to each client. I assume that a game company can only assume that people playing over the Internet have about 10KB/s upload speeds so how do these games update the locations of all of the players and all of the creatures. I first thought that by using tiles you can limit the amount of information that needs to be sent to update the coordinates of each player. I also know only the players that move need their coordinates updated. It is also possible to only update the players and creatures that each player can see. Are there any tricks or do game companies simply assume fast connections. Over a LAN most this is probably not an issue, but accross the Internet when 8 players are playing over battle.net and each player has 40 units moving to battle someone else I would think that would cause unacceptable lag. (If a map is 256x256 tiles then player coordinates can be represented by two bytes. 40*8*2=640bytes sent to each player to update all player coordinates). If anyone knows more about the networking of these games I would be very interested. In particular I have read that Neverwinter Nights II plans to support 64 players in a server like the original, but the graphics engine is not tile based. This leads me to believe that networking support never relied on players being at specific tiles.

i would think that the games send only useful information [that which is seen or near seen]. they also should perhaps when player of 1 sends unit to x,y position only position and unit id is sent to player of 2,3,4,etc. you may also consider other compression of data such as only send full unit positions every 2sec.

Quote:Original post by AllTheLuck
I assume that a game company can only assume that people playing over the Internet have about 10KB/s upload speeds so how do these games update the locations of all of the players and all of the creatures.

Simple, they don't. And 10KB/s upload is quite high.

If you are going to make a multiplayer game, you have to design to code to sync in a low bandwidth networked environment. Multiplayer games work by making smart code, not by trying to compress all the data produced by dumb code.

The two cases you brought up use two different models:

Warcraft 3 is an RTS. The strategy for an RTS multiplayer game is to create a peer-peer networking strategy - while the game may have a host (and in newer games the host may be required as a conduite for transfering data), there is really no central controller.

Instead all the games have an identical copy of the environment, and an identical sets of games rules. When you order a grunt to attack the enemies town hall, the command is sent to all machines. All machines execute the command at the same network frame, and since they are running at the same network framerate, the same thing happens and continues to happen until another order is issued (at the next network frame all machines will have placed the grunt 1 step closer to the town hall, even though no network communication was used).

The network frame is a fixed processing scale - all important decisions (units health is decreased by attack, building is completed, etc) are done at these frames, which are identical on all machines. The calculations done between frames (essentially intra-frames) should only affect the visual presentation on the local client, to provide a smooth game. For example if a units walking speed is 10 units per network frame, then each network frame it should calculate the units position based on the last network frame, while the intra frames can use standard variable framerate movement so that it looks smooth, but with the intra frame position being discarded each time a network frame is reached.

To do this, things like random number generators must be designed to be completely replicatable (if given the same input, they'll give exactly the same result every time, on every machine). Even so, it is still required to do synchronization checks to prevent the games from going off in different directions - for example different processors can do floating point calculations at slightly different precisions, resulting in tiny bits of drift, which can cause a unit to see another unit one network frame too soon, which sets of a chain of events that puts the different players out of sync with each other (they are no longer seeing the same game).

Synchronization checks can be done by creating state hashs - take all the information that affects the game (position of units, health, current orders, etc) and make them into one or more hashs. The hashes are stamped with the network frame number and compared. If the hashes don't match up, the game pauses (if done well, pauses should not be noticible to the player) and figures out what information doesn't match up - this can be done by combining the hashing with a binary search (split one group of objects being hashed into two groups of objects, each with their own hash. Once it is narrowed down to a specific object the data can be sync'ed).

To hide lag, the RTS doesn't execute commands as soon as you click. Instead, it sends the command stamped with a value of 1 or more network frames in the future. At the end of each network frame, the player tells all other players how many commands where sent (this isn't needed with TCP, only a "I'm done this frame" message, since communication is serial). At the start of each network frame, players check to see that they've recieved all orders that are scheduled to be executed on this frame. If they haven't been recieved, the game pauses until they are (this is why laggy RTS games stutter)


I'll post in a little while about other game network models (like Neverwinter nights)

Many other games use something similar to the RTS model, but substitute the lock step system (commands are sent ahead of time, and are executed at the same time on all clients) with a more aggressive real-time command system backed up by a central server providing synchronization.

This sacrifices the ability to handle a game world with hundreds of directly controllable entities for one with a faster "twitch" style of game play. To do this, a central server is responsible for maintaining the true game state, while each client runs their own approximation of the game state based on the information they've received from the server.

When a player does something (turns their head, shoots their gun, steps forward), they send that information to the server, but also do it immediately in their own copy of the game state. When the server gets the command it executes it (note that in both models the game should always check that the command is valid if possible), creating the true version of the game state. This information is then transformed with time information and forwarded to the other clients. The other clients receive it, and use the time information (when the server executed the command) to approximate how it should affect the client copy of the game state.

For example if I start moving forward on my local copy of the game state (at 0ms), the command is sent to the server, which takes 50ms. The server starts moving my character forward (in the "real" copy of the game state my player didn't start moving until 50ms) and sends the information to all other clients. The other clients (who we'll say are slower) receive it 60ms after it was sent from the server. Unlike the server, which executed the command when it was received, the clients make an approximation - they decided that the other players character started moving forward 60ms ago on the server, so that character is pushed ahead on the clients copy of the state (there are many articles on GameDev about how to hide this, for example), so that it is in the position it would be if it had started moving 60ms ago.

As all important decisions are made on the server using the server’s copy of the game world, player’s actions and their results don't always match the local copy. For example in a multiplayer FPS, you have to aim ahead of a moving target, depending on your lag, in order to hit it - even if it looks like a hit on your client, it's up to the server and its view of the world to decide if it was. The server is responsible for telling the player (and other clients) when important events happen, and clients usually won’t show those actions (even if their copy of the game says it should happen) until the server confirms it.

This kind of on the fly action means that individual player’s copy of the game state quickly drifts apart from what the server and other players see. This means clients must constantly be making small synchronization adjustments to remain close to the server. To avoid the game stopping every 2 seconds, the usual hash check system is loosened, so that corrections only happen if the client drifts too far off (the corrects are obviously only one way, the server correcting the client). The server also reduces the number of objects that must be synchronized by only considering things that will directly affect the client in the near future – for example a player on the other side of the map can’t be seen and won’t affect the game state of the client, so the server doesn’t both correcting the client on that players position.

Well, I also think 10KB/s is a good upload rate.

For example, If you have to send 4 bytes to update your position and you send it every time you move then you would send a maximum of (datasize * game_fps) assuming that the player can move every FPS.

The most common framerate limit is 30 FPS, so you would send per second, a maximum of 120 bytes. But there are also more information in the game than just the player position but let´s suppose that you would send a maximum of 300 bytes if other events happen.

So that´s 300 bytes per second you will need to send, right?
But you can send up to 10.000 bytes per second.

Of course, this is for a game with a server, so for the client I think 10KB/s is already very good.

I never found a game which I couldn´t run well with my 128kbps upload rate.

Am I correct?

But for peer-to-peer games, I´ve seen tricks used in Baldur´s Gate 2 for example, in which if you play by LAN and the two computers are next to each other, they don´t show the exact position of the players.