Network Synchronizing

Blitz3D Forums/Blitz3D Programming/Network Synchronizing

Poita(Posted 2006) [#1]
I'm making an RTS and I'm hoping to add Network play in addition to the normal game modes. I understand that with RTSs with possibly hundreds of units and hundreds of bullets that synchronizing the game on each computer is the best way to handle networking, only sending commands such as move clicks and build commands etc. I have a couple of queries:

1. Do all computers do calculations using the exact same method? ie. will one floating point calculation on one computer get the EXACT same answer as on another?

2. Is the random number list on all computers the same so that I can just send the seed to each client and they will generate the same random numbers as me (I can probably work round it if it isn't but it would be nice to know :D )

Thanks in advance!


jhocking(Posted 2006) [#2]
1. dunno

2. no


LAB[au](Posted 2006) [#3]
1. Yes hopefully...
2. Best method I found is to have a frame or time sync in between the computers and then send the seed of the random number generator, or reset to the "common"(transmitted) seed before each call to random function


KuRiX(Posted 2006) [#4]
1. I suggest to pass through the network the net clicks and options as you suggest, then the game must be synchronized along the network, and relay the positions and options in integer numbers, not float. So the units can move using floats but the position, internally, is a integer.

2. If you synchronize the seed and you do the same number of calls to random you will get the same results...


Shifty Geezer(Posted 2006) [#5]
1. DirectX changes it's rounding on the fly, so two computers running the same calculations won't necessarily end up at the same answers. You can't rely on this

2. The random number generator is a fixed function of the language you use. If you use the same seed then the answers will come out the same every time. So yes, you can rely on a blitz series of random numbers to come out the same. Though as Kurix says, you need ot call them the same amount of times. If one PC is running the main loop faster than the other (like 75 Hz instead of 60 Hz due to different monitor refresh and a VWait) then things'll get out of sync.

You may want to consider running the game proper on a server, and farm out the results of calculations (unit and bullet positions etc) to client machines, rather than calculate on all machines and try to keep them synchronised.


Poita(Posted 2006) [#6]
Thanks guys

I don't think that not synchronizing is even an option. If there are say 50 units on screen with maybe even 100 bullets then there is no way to keep it going smoothly if position data has to be sent out for each one of those objects. I believe synchronizing is how pretty much all RTSs are done anyway, I know for sure that Age of Empires was done this way.

KuRiX - "I suggest to pass through the network the net clicks and options as you suggest, then the game must be synchronized along the network, and relay the positions and options in integer numbers, not float. So the units can move using floats but the position, internally, is a integer."

I'm not sure I understand what you mean here. Are you saying that all the units/bullets etc move using floating point math but when I send click options that I send those as integers?

Shifty Geezer - "DirectX changes it's rounding on the fly, so two computers running the same calculations won't necessarily end up at the same answers. You can't rely on this"

So say if I had an object that was moving in a circle (or something involving high precision floating point values) using the exact same algorithm on two computers, would they not follow the same path?

If not then how do other RTSs implement network play?

Thanks agian


Shifty Geezer(Posted 2006) [#7]
They would follow the same visible path as the degree of variation is tiny, but these variations can result in accumulated differences. My knowledge on this comes from a game development forum where a experienced developer was explaining one reason why physics simulations don't give the same result each time they're run. If you have an ODE simulation like the recently posted 'man-on-a-seesaw' code in the JV-ODE thread, each time you run it the result is different, even though the starting parameters are the same and the solving algorithm is the same.

As for how to keep a network game in sync, I've never written one, so will be interested to hear the ideas of those who have!


LAB[au](Posted 2006) [#8]
I wrote one but based on server/clients. The server is the master of time, all others are following/waiting this timestamp to apply all the needed actions, no actions on the clients are available until the received timestamp is considered as "current".

This works as well because network events are performed as fast as possible while the gameplay in itself is limited to 30 fps. Whenever possible data is sended as "absolute" (like players positions), so that you minimize the effect of lost packets. When an object is in a "key" state (like going from active to idle) a network message is sent, giving all his absolute parameters(position, rotation,etcetera), this works good for particles and physics sync. But this was as well the most easy setup as this was on a LAN with UDP.

Then of course there is a lot of techniques for interpolating in between network messages including fancy "prediction" of players position for example, but this would be really usefull if network is slower than gameplay which was not my case.


Poita(Posted 2006) [#9]
I don't think that sending player positions of potentially hundreds of units is very effective.


Shifty Geezer(Posted 2006) [#10]
How much data do you need per unit? X and Y and Z positions and rotations? At 16 bit each, that'd be 12 bytes per unit. 100 units is 1,200 bytes, or less than a kb. 30 FPS would need < 36 Kb/s, which I guess is over the limits of most people's upload speed.

Have you thought of sending only a part of the scene? For each frame you could send the position and orientation type data of perhaps a quarter of the objects. The client can move these objects to absolute positions while moving the other objects based on it's own calculations.

eg. For 30 tanks, own frame 1 the client computer receives exact data on tanks 1-10 and places them accordingly, and positions Tanks 11-30 based on position+movements. Frame 2 updates the exact positions of tanks 11-20 while tanks 1-10 and 21-30 are calculated client side. Frame 3 updates tanks 21-30 based on the servers processing. And frame 4 cycles back to tanks 1-10.

Segmenting your updates this way would keep network traffic down to manageable amounts and keep the clients close to the servers output with no worse than a few frames variation which shouldn't be noticeable.


KuRiX(Posted 2006) [#11]
Let's look for an example: Starcraft of Blizzard

The game works perfectly on a 56kb modem with 8 players and hundred of units... why???

Because they only broadcast user input.

It has a synchronized time, so everyone is running the game at more/less the same time. For example:

Suppose:

- Two computers playing
- The game starts with timer = 0.
- The first player select one unit when timer = 3
- Then there is a message sent to the other players saying that, and the players that get the message synchronize the response when the timer is = 3.

What happens if a timer is greater in one computer? then the computer waits for other players.

If you allow the messages to arrive a little late, then the resynchronization is not noticeable for the user.

The system starcraft uses is really great, but no easily implementable. I don't know every algorith they use, but this is more/less the idea.


Poita(Posted 2006) [#12]
Shifty Geezer - I have considered that approach but I think it would be much more prone to errors than with synchronizing. I'd also have to send out bullet information, and in a heated battle with many units and many bullets would result in quite noticable lag due to latency.

KuRix - That is exactly what I am planning to do. I read this article at gamasutra http://www.gamasutra.com/features/20010322/terrano_01.htm, which is about the multiplayer design for age of empires 1 & 2. The system is pretty much perfect except for occasional out of sync errors, which I can tell you from experience are quite a pain.