StateDelta / Warping
by William Todd Scott · in Torque Game Engine · 09/22/2006 (1:20 pm) · 3 replies
Hi all,
Can someone provide a high-level explanation of what the StateDelta structure (specifically the warpTicks, warpCount, etc.) accomplishes? I am trying to dig through the code in the vehicle class but am having some trouble getting my mind around what is going on, because I'm not sure what exactly it is trying to accomplish.
I believe it is providing some level of client-side prediction, but not really sure how it works with writePacketData/readPacketData and packUpdate/unpackUpdate.
I didn't see anything on TDN that went through the use of this structure.
Thanks
Todd
Can someone provide a high-level explanation of what the StateDelta structure (specifically the warpTicks, warpCount, etc.) accomplishes? I am trying to dig through the code in the vehicle class but am having some trouble getting my mind around what is going on, because I'm not sure what exactly it is trying to accomplish.
I believe it is providing some level of client-side prediction, but not really sure how it works with writePacketData/readPacketData and packUpdate/unpackUpdate.
I didn't see anything on TDN that went through the use of this structure.
Thanks
Todd
#2
Little known fact, but due to the nature of networking, the client and server are actually time machines!
As part of client side prediction (used on the control object only, to make sure that you get instantaneous response when you press a movement key), the client is actually allowed to apply a move inputted by the player directly to the client side simulation, before the move is sent to the server.
Now, for those that understand the networking theory and the concept of Torque's "authoritative server simulation/non-authoritative client simulation" structure, that seems to be a violation of the fact that Torque clients must follow the server's updates on their simulations...but it's actually not.
For most ghosted objects, the client simulation is always "in the past" in comparison to the server--it takes time for updates to be sent across the network, and time still passes on the server, so the client is normally behind the times, so to speak.
However, since we apply moves directly to the client's simulation for that client's control object, for this object only, the client is actually "in the future" when it comes to responding to that move. Once the move is applied, and the client's simulation is updated, the move is then packaged up and delivered to the server. The server then applies the move, and sends an authoritative update back to the client.
Now, this puts us in a sticky situation--the client has already applied the move, and more importantly, has also applied any additional moves that player have made during the network round trip--so what do we do?
Well, within the update from the server, we have a timestamp (along with other information, such as the position in the move window letting us know which move this update is concurrent with), so the client in effect "unwinds" it's simulation state back to the time when the move was first applied, and then accepts and corrects for the authoritative update from the server. It then "winds" back up to the time state that the human is at, but re-applying all of the moves that have occured since this move was sent. That way, to the player it appears that things are still current, yet the client side simulation has been re-synched with the server at the time the move was originally applied.
Torque Networking--learn it, love it, live it!
09/23/2006 (1:19 am)
Basically in a nutshell it allows the client and server to wind and unwind current control object game states so that they can correctly re-synch when updates and moves are delivered.Little known fact, but due to the nature of networking, the client and server are actually time machines!
As part of client side prediction (used on the control object only, to make sure that you get instantaneous response when you press a movement key), the client is actually allowed to apply a move inputted by the player directly to the client side simulation, before the move is sent to the server.
Now, for those that understand the networking theory and the concept of Torque's "authoritative server simulation/non-authoritative client simulation" structure, that seems to be a violation of the fact that Torque clients must follow the server's updates on their simulations...but it's actually not.
For most ghosted objects, the client simulation is always "in the past" in comparison to the server--it takes time for updates to be sent across the network, and time still passes on the server, so the client is normally behind the times, so to speak.
However, since we apply moves directly to the client's simulation for that client's control object, for this object only, the client is actually "in the future" when it comes to responding to that move. Once the move is applied, and the client's simulation is updated, the move is then packaged up and delivered to the server. The server then applies the move, and sends an authoritative update back to the client.
Now, this puts us in a sticky situation--the client has already applied the move, and more importantly, has also applied any additional moves that player have made during the network round trip--so what do we do?
Well, within the update from the server, we have a timestamp (along with other information, such as the position in the move window letting us know which move this update is concurrent with), so the client in effect "unwinds" it's simulation state back to the time when the move was first applied, and then accepts and corrects for the authoritative update from the server. It then "winds" back up to the time state that the human is at, but re-applying all of the moves that have occured since this move was sent. That way, to the player it appears that things are still current, yet the client side simulation has been re-synched with the server at the time the move was originally applied.
Torque Networking--learn it, love it, live it!
#3
That is a most awesome explanation.
I'm psyched to get back at the code, armed with this knowledge.
Thank you so much for taking the time to really lay this out.
Todd
09/23/2006 (8:36 am)
Hey Stephen,That is a most awesome explanation.
I'm psyched to get back at the code, armed with this knowledge.
Thank you so much for taking the time to really lay this out.
Todd
Torque Owner Demolishun
DemolishunConsulting Rocks!
Good luck