Is it possible to advance certain objects ahead by a certain dT, and not the entire physics system?
I ask this because i am working on implementing a client/server game using JiglibX and many popular algorithms for how to handle networked physics(such as in Unreal) include modifying each players position on the server based on the delta time since the last update from the client.
But i dont see how this is possible with Jiglibx, has anybody else tackled this problem? The only solution i can see is to use a fixed timestep on both the client and server, but this limits the frequency the Server can call Update() and bottlenecks the server to 60 updates a second….
This is the section from the Unreal network algorithm im looking to reproduce
The approach can best be described as a lock-step predictor/corrector algorithm. The client takes his input (joystick, mouse, keyboard) and physical forces (gravity, buoyancy, zone velocity) into account and describes his movement as a 3D acceleration vector. The client sends this acceleration along with various input related information and his current timestamp (the current value of Level.TimeSeconds on the client side) to the server in a replicated ServerMove function call:
Then the client calls his MoveAutonomous to perform this same identical movement locally, and he stores this movement in a linked list of remembered movements using the SavedMove class. As you can see, if the client never heard anything back from the server, the client would be able to move around with zero lag just as in a single-player game.
When the server receives a ServerMove function call (replicated across the network), the server carries out the exact same movement on the server immediately. [b]It deduces the movement's DeltaTime from the current ServerMove's TimeStamp and the previous one's.[/b] In this way, the server is carrying out the same basic movement logic as the client. However, the server might see things slightly different than the client. For example, if there's a monster running around, the client might have thought it was in a different position than the server (because the client is only in rough approximate sync with the server). Thus, the client and the server might disagree about how far the client actually moved as a result of the ServerMove call.