Update Rates
by DIAG · in Torque Game Engine · 12/16/2003 (3:25 am) · 3 replies
Hello,
I have been reading through the torque documentation and i see that the moves that are sent to the server are 32 milliseconds snap shots of the users input. Surely these updates cannot be sent every 32 milliseconds, which could be near framerate.
Does anyone know anything about the rate at which updates are sent. If they are less than frame rate, how does the engine decide which moves to send?
Thanks for your help
I have been reading through the torque documentation and i see that the moves that are sent to the server are 32 milliseconds snap shots of the users input. Surely these updates cannot be sent every 32 milliseconds, which could be near framerate.
Does anyone know anything about the rate at which updates are sent. If they are less than frame rate, how does the engine decide which moves to send?
Thanks for your help
#2
Thanks for your help. That explained alot to me! Can anyone point me in the direction of some documentation explaining how client side prediction occurs in torque. i have really tried looking for some, and have come up with some, but would like a few more. as far as i can see, if the client is missing an update about a ghost object, it just reapplies the last received move to that object again. is that just it, or am i missing something?
thanks again guys
12/16/2003 (7:26 am)
Hey,Thanks for your help. That explained alot to me! Can anyone point me in the direction of some documentation explaining how client side prediction occurs in torque. i have really tried looking for some, and have come up with some, but would like a few more. as far as i can see, if the client is missing an update about a ghost object, it just reapplies the last received move to that object again. is that just it, or am i missing something?
thanks again guys
#3
The overview should explain all this. Is it not?
12/16/2003 (7:51 am)
Client side prediction is done by calling processTick on the client side... :)The overview should explain all this. Is it not?
Employee Melv May
I think perhaps you should look at some reference material on this subject. To explain a little; the server does not drive the clients framerate and driving a typical game simulation at high framerates is not required. What actually happens is that the server simulates the simulation in 32ms intervals. At the same time, possibly on the other side of the world on a connected PC, the client renders this world as fast as it can e.g. framerates.
Each object on the server can determine whether it needs to update its counterparts (e.g. ghosts on the clients) and does so using the network transport. If this was all there was, then all that would happen would be the clients seeing simulated 32ms jumps when they were updated from the server via the network. This does indeed happen but to counter this, the clients do prediction, typically based upon time-integrated velocities. If the client is currently at position [X,Y] with a volocity of [VX,VY,VZ] then it can render the object in framerate time intervals along that vector until the server updates the new position and velocity.
This would seem like you'd get jumpy movement and in-fact you do if there is sufficient latency in the network connection to the server but typically the movement is seemless. There are all sorts of different ways the client can predict actions; an important one that gives the impression of quick responsivness is the ability to rotate the view immediately without permission from the server.
As I stated in the beginning though; this topic can get very complex and I'm far from an expert in all the areas of it but there's plenty of information on client prediction etc around the net.
This is the Networking Overview for Torque which should help a little.
- Melv.
- Melv.