Sign in to follow this  
sofakng

What can't I understand the basics of real-time game networking?

Recommended Posts

I'm trying to create a multiplayer Scorched Earth/Worms game and am having a hard time understanding the networking concepts or keeping everything in-sync (eg. to make sure projectiles follow the same trajectory and have the same collision points, etc). Some people have said "if you use the same numbers the simulation should be the same on every machine", but I've also been told that due to floating-point calculations that results are almost NEVER the same and thus the need for real-time networking. Because of this, I've decided to try to implement a real-time networking protocol for my game but I'm havinga hard time understanding the overall process. I understand that in most real-time network protocols, the server sends out updated movement information (eg. the object's current position and velocity) every XX milliseconds and the client interpolates object position between network updates. (does that sound right?) So here is my question... (in the form of a sequence diagram) 1) Server sends updated object position to clients. (we'll call this time 0 [t0]). 2) Client receives update at time 1 (t1). 3) Client compares object's current position to the received update. If the updated position is different than move to the "correct" (eg. updated) position (via dead reckoning?). What I can't seem to understand is suppose that the object is at (10, 10) on the server (eg. this is the "real" position). Now let's say the object moves to (15, 15) over the course of 5 seconds. The first time the server does tell the clients that the object is at (10, 10) and moving at (1, 1) per second. After 2 seconds (server-time), the server sends an update to the clients and says the object should now be at (12, 12) with a velocity of (1, 1). Now I also understand that the server is operating in "present time" and the client's are in "past time" but I still don't understand what happens when an update is sent from server --> client. How does the client know when the update was sent? For example, let's suppose the client has extrapolated it's position to be (12, 12) but then receives an OLD update that says it's position should be (11, 11)? I'm sorry for the long post but I'm really trying hard to understand this. If anybody could help me out I would very greatly appriciate it. Thanks, John

Share this post


Link to post
Share on other sites
Generally the client has a history buffer, ie a buffer which holds the position, time and input that caused a change. The server sends a update(which includes the time) the client looks into the history buffer and checks whether the position is within a range to the servers said position. If the client is not within this range change the position, to the servers position or an adjustment size so that the client does not jump, then recalculate movements which have happened since(which are stored in the buffer).

The simple answer for old updates is just to ignore them. If a message has been received that is newer than the old message then the new message will contain the correct information without needing the other message. If on the other hand the old message is important than you need a reliable type of message.

Share this post


Link to post
Share on other sites
Quote:
...but I've also been told that due to floating-point calculations that results are almost NEVER the same...


I'm no whiz, but this doesn't make sense to me. I would think that precision errors while crunching identical numbers on two processors of the same fundamental architecture would lead to the same "bad" results. I.e., the precision is the problem not disparity of results. I'm sure a bigger geek than I can correct me if I'm wrong... :)

Anyways, the usual context for floating-point precision problems is your matrix and vector calculations. Issues typically only show up after a rather large number of operations; but people find it's practical to use normalizations each frame.

Quote:
...let's suppose the client has extrapolated it's position to be (12, 12) but then receives an OLD update that says it's position should be (11, 11)?


Server update msg > interpolation/dead reckoning

Server updates are authoritative, so ignore your interpolation upon receipt of one and use the received information to update your objects. Different packets have different requirements, for movement you might want to go with an unreliable orderless transmission. This way your "old" {11,11} packet gets dumped in the void and, failing delivery, doesn't return to haunt you. But I'm sure a networking guru can enlighten us. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by CmpDev
Generally the client has a history buffer, ie a buffer which holds the position, time and input that caused a change.

Are you talking about the normal update packets received from the server are the ones being stored in the history buffer? I'm confused when you say "inputs that caused a change"

Quote:
The server sends a update(which includes the time)...

So I need to synchronize the time between the server and client? ...or how does this work?

Quote:
Original post by spartanx
Anyways, the usual context for floating-point precision problems is your matrix and vector calculations. Issues typically only show up after a rather large number of operations; but people find it's practical to use normalizations each frame.

I'm not too familar with matrix operations and normalization (I'm only doing 2D programming and not 3D), but all I know is that most people say "float-point" math is unreliable and "fixed-point" is reliable. (...and I guess that most 2D engines use "floating-point" for movement, collision detection, etc... [??])

Share this post


Link to post
Share on other sites
Quote:

Are you talking about the normal update packets received from the server are the ones being stored in the history buffer? I'm confused when you say "inputs that caused a change"


An object traveling at a velocity will continue on its path until a force acts upon it, if this force is not know to the server then there is a change which it needs to know about. This could be a player pressing forwards, backwards etc. a collision with a surface is something which the server knows about.

Quote:
The server sends a update(which includes the time)...
So I need to synchronize the time between the server and client? ...or how does this work?

This is the source of many papers. A very simple example is to send a number of messages with timestamps and record the rtt, average the rtt and set the client time relevent to this.

Share this post


Link to post
Share on other sites
Fixed point math is reliable because it's just integers and those are guaranteed to act the same on every machine. Games like Doom used fixed point and just sent user input (key presses) across the network.

The way this basically works is that you use very small integer units... Say each "distance unit" in your game is 1/65536 of a meter instead of using 1.0f for a meter. So an object moving at 5m/s when the framerate is 60 frames/s will move 5461 units (5461/65536m) per frame. This gives you enough accuracy to do smooth movement in any direction at any speed while all the calculations are done with integers. As you can see, in this case you're always using 16 bits for the fractional portion of the coordinates, leaving you with 16 bits for the integer portion on a 32-bit system (so the range of values is from -32768 to 32767) which will limit the size of your game world. This is called "16.16 fixed point" because the "decimal point" is fixed with 16 bits of precision on both sides.

It's a big hassle to do anything like real physics in fixed point so it's not popular... Something like Scorched Earth should be OK though. I wouldn't be surprised if the original used fixed point, as it was at a time when floating point math was done by a co-prosessor not everyone had.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this