Networks and bullets? Where and when?
by Mark Storer · in Torque Game Engine · 09/09/2005 (10:36 am) · 4 replies
Okay, lets say we've got some player moving around, and they fire a bullet.
Where does that bullet come from, and when? Where the server thought the player was at the time the fire event was recieved (most secure, least like what the player wanted)? at the time it was generated on the client machine? Where the client thought the player was at the time they fired? Where the client thought the player was at the time the server hears about it?
It seems there's this two-by-two grid of possibilities. On the one axis you've got "client pos, server pos", on the other "client time, server time".
Hmm. I suppose you could even take some weighted average between the positions, but high lag could cause WILDLY different results.
See, if you throw a 100ms ping (a "good" connection), and you're looking at a tick or two between when an event is generated on the client, and when it is received on the server, and a bit longer before other clients see the projectile. Further, a higher ping means a higher difference between what the server and clients think the world is like.
Yow. How do you networking types handle this mess? And (more importantly) how does Torque handle it?
Where does that bullet come from, and when? Where the server thought the player was at the time the fire event was recieved (most secure, least like what the player wanted)? at the time it was generated on the client machine? Where the client thought the player was at the time they fired? Where the client thought the player was at the time the server hears about it?
It seems there's this two-by-two grid of possibilities. On the one axis you've got "client pos, server pos", on the other "client time, server time".
Hmm. I suppose you could even take some weighted average between the positions, but high lag could cause WILDLY different results.
See, if you throw a 100ms ping (a "good" connection), and you're looking at a tick or two between when an event is generated on the client, and when it is received on the server, and a bit longer before other clients see the projectile. Further, a higher ping means a higher difference between what the server and clients think the world is like.
Yow. How do you networking types handle this mess? And (more importantly) how does Torque handle it?
About the author
#2
Torque uses a variety of features to both interpolate and extrapolate to make sure clients get the "best picture" of what is going on, as well as a couple of different strategies for making sure the right information gets networked to the right clients as soon as possible.
FYI, there is a pretty in depth article I'm writing about the topic in the alpha TDN...once TDN is released I'll come back with a starter link!
09/09/2005 (12:13 pm)
Projectiles in stock TGE are actually server side objects that are networked to the client. All authoritative positioning (including collision) is handled on the server, and ghosted to the clients that have the projectiles in scope.Torque uses a variety of features to both interpolate and extrapolate to make sure clients get the "best picture" of what is going on, as well as a couple of different strategies for making sure the right information gets networked to the right clients as soon as possible.
FYI, there is a pretty in depth article I'm writing about the topic in the alpha TDN...once TDN is released I'll come back with a starter link!
#3
09/09/2005 (12:21 pm)
Man, you GG guys are so mean, throwing out a mention of TDN all the time... I'm almost out of saliva! :P
#4
Dead Reckoning is the process basically used to predict on the client side the path of an object until an update from the server changes that prediction model. So, if a bullet is fired on a certain vector, that vector is used for calculations until the server comes back and updates it.
Why would the projectile path differ from the client to the server? Network latency and processing time are the biggest answers. However, processing time for the most part is minimal so it's really network latency. If a player is standing still, most likely there won't be a problem. However, if a player is moving, it's most likely that what you see on your screen and what the server is calculating are two different things. As a result, you'll find that players constantly will complain that they missed when on their screen they actually shot the player. That is because the latency between them and the server is high enough to make a difference. In the time it took for the message "Shoot" to get from the client to the server, the player has moved a few units on the server. As a result, the player is not truly firing from the spot they thought they were. Since latency has become so low these days (ie less then 200ms on average), most game engines make it up by giving a small deadspace that counts as a hit. That is why it is possible for a player to seemingly miss someone on their screen and still kill them.
How would this work? Let's take a very simple example. Let's say a player can only face in four directions, North, South, East and West. The client and the server both agree that the player is facing North. Our player sees an enemy about to cross their path and shoots the weapon. However, you have to understand exactly what the player is seeing. Instead of transferring actual location data between clients, the server is sending vector data. As a result, the client game is displaying the enemy in the location that it thinks the player is based on the enemies last vector heading. However, the enemy could change moves at any millisecond and this model would soon become innacurate. Our player, however, is tricked into believing that they should shoot now in order to hit the enemy. The enemy on the other hand, tells the server that it is now strafing away from the player's heading. As a result, the player could not possibly hit the enemy according to data on the server. However, because the message has to go from the enemy, to the server, and to our player, the latency causes our player's client to still predict the enemy's motion into our player's crosshairs based on the vector data it has. The player shoots, seemingly hits but instead misses and notices the enemy quickly dodge to the side.
This is an extreme case but hopefully gives you a handle on how dead reckoning works. While it may seem flawed, please understand that it works very fast in implementation so the example above is not exactly the majority case.
09/14/2005 (10:12 pm)
Although you can't call my an expert on the subject, a generic answer to this would be to say that most engines use some form of Dead Reckoning.Dead Reckoning is the process basically used to predict on the client side the path of an object until an update from the server changes that prediction model. So, if a bullet is fired on a certain vector, that vector is used for calculations until the server comes back and updates it.
Why would the projectile path differ from the client to the server? Network latency and processing time are the biggest answers. However, processing time for the most part is minimal so it's really network latency. If a player is standing still, most likely there won't be a problem. However, if a player is moving, it's most likely that what you see on your screen and what the server is calculating are two different things. As a result, you'll find that players constantly will complain that they missed when on their screen they actually shot the player. That is because the latency between them and the server is high enough to make a difference. In the time it took for the message "Shoot" to get from the client to the server, the player has moved a few units on the server. As a result, the player is not truly firing from the spot they thought they were. Since latency has become so low these days (ie less then 200ms on average), most game engines make it up by giving a small deadspace that counts as a hit. That is why it is possible for a player to seemingly miss someone on their screen and still kill them.
How would this work? Let's take a very simple example. Let's say a player can only face in four directions, North, South, East and West. The client and the server both agree that the player is facing North. Our player sees an enemy about to cross their path and shoots the weapon. However, you have to understand exactly what the player is seeing. Instead of transferring actual location data between clients, the server is sending vector data. As a result, the client game is displaying the enemy in the location that it thinks the player is based on the enemies last vector heading. However, the enemy could change moves at any millisecond and this model would soon become innacurate. Our player, however, is tricked into believing that they should shoot now in order to hit the enemy. The enemy on the other hand, tells the server that it is now strafing away from the player's heading. As a result, the player could not possibly hit the enemy according to data on the server. However, because the message has to go from the enemy, to the server, and to our player, the latency causes our player's client to still predict the enemy's motion into our player's crosshairs based on the vector data it has. The player shoots, seemingly hits but instead misses and notices the enemy quickly dodge to the side.
This is an extreme case but hopefully gives you a handle on how dead reckoning works. While it may seem flawed, please understand that it works very fast in implementation so the example above is not exactly the majority case.
Associate Sam Bacsa
Heh, sorry, just had to insert some humor into a topic I wish I could answer, but alas my Torque networking knowledge is limited at the moment.