2
\$\begingroup\$

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?

Improve this question
\$\endgroup\$
1
  • \$\begingroup\$ 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. \$\endgroup\$
    – zoran404
    Aug 5, 2015 at 21:42

1 Answer 1

Reset to default
1
\$\begingroup\$

You are finding the cross hair to set the origin and orientation of the rocket. Then let the server track the rocket from there and inform the clients if anything affects the trajectory from what the clients logic can accurately estimate. Then inform the clients if/when it explodes.

This might not mean that clients see it from exactly where it is, but ultimately the effect should be unnoticable. Especially if the launcher makes a cloud of smoke before the server tells the client, milliseconds later, where it has officially acknowledged the rocket to be.

In otherwords, don't retroact rockets. Spawn it and forget it. Just like you won't go back in time to undo a death that occurred 5ms before the victim touches a health pack.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ 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? \$\endgroup\$
    – Ali Ok
    Aug 5, 2015 at 20:09
  • \$\begingroup\$ Only to determine where to spawn the rocket. \$\endgroup\$
    – RobStone
    Aug 5, 2015 at 20:12
  • 1
    \$\begingroup\$ You can't solve this one another way. Otherwise you will have players seeing rockets spawn 1.5 seconds from where the player is. Or worse, getting killed by a rocket which they never saw, 1.5 seconds before they know they're dead when they could have easily dodged it. It's better to expect that players will adapt to rocket latency and hide small errors in plumes of smoke. 1.5 second latency in a shooter is already unacceptable anyway. \$\endgroup\$
    – RobStone
    Aug 5, 2015 at 20:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .