Worldrepresentation and Lag compensation

Troubleshooting spidermonkey
1

Hi I am new here, I started a little game project. I have still created a Server and a client which can successfully exchange messages. Currently the basic game-logic is still in the client. Now I am starting to move all the game-logic to the server and the client should only render the output, provide the movement input to the server and should also compensate the jitter / lag from client to server or the opposite direction.


  1. My first problem / thought is about the collision detection which is if I do it on the client side (like I do it now) no problem. If I move the collision detection to the server I not really sure how to do it. I load my terrain out of an high-map. So should I load the terrain out of the high map like before and generate the CollisionShape + RigidBodyControl and for the player the CapsuleCollisionShape + CharacterControl and add the player and terrain to the physic-space of the bulletAppState (and don’t add the things to the root node)? If I do it like this way, would I be able to detect collisions without graphical output on the server side? How should I do this?


  2. My second problem / thought is about the movement of objects and the player its self. I read the following articles:



    Source Multiplayer Networking - Valve Developer Community

    Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization - Valve Developer Community



    So the server does all the simulation work. The Server has the “game time” which is send to each client. each client corrects this time by the delay of his connection to the server. So the time is nearly synced (nearly because you wouldn’t be able to sync the time by 100%).

    With this game time you can handle actions in the past. The time is added by any updates of the server or by any command of the client. The client has to check if the time is still in sync after each update the server sends, if not the client has to correct it to become back in sync.



    The Server stores all the positions of a moving objects for some time (lets say 1sec). Now the server is able to add movement-commands or run hit-detection for shooting-actions for the correct time, because of the network-delay client commands will arrive delayed while the game simulation is still going on.

    So for this behaviour I have to store a array of positions for each of my moveable objects?



    The client it self couldn’t wait for the response of the server after each movement command, the game would look laggy. So the client dose a movement prediction. The client stores ale the commands in a list which have been sent to the server. The Client adds the command to the last position which is received by the server and this is the predicted new position. this position is used for the next rendering run and also saved in a list with the time stamp when the movement command was send. So after the next update of the server the client has to check the received movement positions of the server against the positions the predicted positions of the client at the specific time. If the predicted position + a little difference doesn’t match the client has to re calculate all the commands starting at the time where the miss-match was found.



    Have I understood it right? So The movement-command of the client would be an vector-direction and speed information? When the player stops moving the client sends a a direction for the view direction and 0 for the speed?



    Or how do you solve the movement problem in your games? Can you please explain it to me, the thinking about it drives me crazy :smiley:
2

Sounds about right I’d say. The very simple approach (without local smoothing or applying but with complete relaying over the server) is in MonkeyZone and I guess you might have looked at that as well. The valve docs go in depth about this but I think you have the basic problems and solutions figured out. And yes, its headache-causing stuff :wink:

3

The one part I didn’t see above is that the client is actually viewing the world at a delay. If you are sending world update messages 20 times a second then usually rendering will be “back in time” by 150 ms or so. This allows a few missed packets to go unnoticed.



You also aren’t really “correcting” the client time. The client time will be at a delay from the server equivalent to the latency. This is the “game time” as far as the client is concerned… and it will be 100 ms or so before it gets to render that data anyway since the visuals (as mentioned in the first paragraph) are rendered at gameTime + viewDelay.



The other stuff you talked about is for doing compensation on the server in the case that you have instant weapons like guns where the bullet effectively travels in an instant. You don’t want the player thinking they got a head shot only to find out that the other guy has already moved… so the server tries to back up time to when the client thought it shot. If you don’t have instant weapons then you don’t need to do this because the delay is already felt and known by the player and they can lead their targets appropriately. (As soon as the missile leaves the launcher and starts flying it is already just another game object to the player.)



It’s on the client that you need to keep an array of positions for the objects in view… since the rendering will be interpolating against the known 150 ms of history.

4

@normen thank you for the hint, I will have a look into MonkeyZone.



@pspeed ah ok I miss understood the client time thing, I think now it is clear to me. Currently I don’t have any weapons so I ignore the compensation on the server for hit-detection for now. But sunder or later I will have to look deeper into it.



So thank you for replay and I will try to fix my issues :slight_smile: