Generally, you need some 'a-team' style clock synchronisation.
Can be as simple as using timestamps to measure roundtrip latency (and half it) and convert local time to to a global shared time (maintained by the server).
I don't have an algorithm at hand, but it should be easy to work out. Being aware of drift, and especially if you base your clocks on timesteps (imo you'll be better served with using the cpu tick counter for that).
I´ll use the stuff explained in
this topic. I hope that it will be sufficent.
You can do your game state updates as soon as the packets from the server arrive. The entity positions at render time are then calculated as the interpolation between two game states. Thus it is maybe also better to go back 2.5*Updateinterval, so you can still interpolate the positions when one packet is lost.
For the game state updates from the server you could also use quake3 style delta packets so you never miss any information and you only have a problem if two packets in a row are lost.
I´ll have a look into delta compression. Thanks for the tip
[quote name='Heg' timestamp='1348746338' post='4984320']
I didn´t, because the lag compensation is not implemented for explosions. In the current version you will die when the server detects you in a fire, even though you didn´t stand in the fire on your local machine. That is horrible and will drive players insane, that is why I couldn´t make some real test runs.
I have to refine my entitiy interpolation and implement lag compensation for explosions first, then I can test how bomb planting feels. I´ve got my hopes up that it will feel okay as it is. We´ll see ;)
I do not really get that part. Lag compensation or not, you should always see exactly what happened on the server only with a delay. Lag compensation just makes it smoother. At least that is how I meant it. You just draw all entities at the same point in time and do not do any client prediction.
[/quote]
Oh, sorry about that. What I was trying to say is that trapping other players is a matter of gameplay, therefore I have to test it with real players. I tested the current state against my A.I. players, and the delay is noticeable. The thing that automatically happens is that I am anticipating the delay and because of that I am still able to trap the players. This happens, because I am the programmer and know that the delay is there. I have to see how it affects other people, whether it is annyoing or not and how often it occurs in a series of matches. Only after that I can decide if some sort of lag compensation is needed or not.
If you suggested that I shouldn´t interpolate or predict the players at all and just show them at there last recieved position, I tested that as well. That works horrible over an internet connection, because the delays are very noticeable.
