# Lag compensation in rocket game context

I have read a lot of papers recently to understand the lag compensation concept recently. They were all about the same context: shooter game where bullets move in infinite velocity.

The most important thing is checking what was in the crosshair when the client created the fire command. If another player was there at that time, then s/he's damaged. That is done by checking the world state at that time by finding a snapshot and executing commands until the fire command.

How about firing a rocket? That is slow (not to mention other differences: ignition time and area damage). That means, I cannot only check what was on the crosshair of the client at the command creation time.

If I go back and check the world state at that time (with same method above), it wouldn't be enough. I would still need to do the simulation for the next snapshots until the most recent one (server's present).

That would mean, if I have a time step of 15ms (tick rate = 66) and I want to discard a command if it is older than 1.5 seconds, I need to keep the most recent 100 (1500/15) snapshots of the world. And every time a delayed command comes, I have to re-simulate the world from that command's timestamp to present - including reprocessing the commands with timestamps after that one.

This sounds too much work on the CPU to me. Is this the same in the first scenario (infinite speed bullet)?

What about lag compensation for movement commands? Would that be different?

Or did I misunderstand something / many things?

• First of all you can not go back one and a half seconds if the time stamp says the command was sent one and a half seconds ago. This will allow for clients to cheat by sending false data. The "big" delay on the network happens when packets are lost and have to be resent (delay depends on ping), this can be prevented by constantly sending states of the game and commands. If you want to re-simulate the game for the delayed commands you should measure the ping and use that as the limit, but make sure to impose a maximum valid delay, as the clients can hack the game and fake a big delay. – zoran404 Aug 5 '15 at 21:42

• But this still means server has to simulate the world again since the command's timestamp ( = Current Server Time - Packet Latency - Client View Interpolation according to here), is that right? – Ali Ok Aug 5 '15 at 20:09