First up, the state of your game should be decoupled from your rendering.

The rendering loop should query the game state and display it on screen.

A separate loop (sometimes called a physics tick) is where you handle changes to the scene.

Many physics engines require consistent time steps between iterations, and other background tasks (like AI) shouldn't be impacted by how good the user's graphics card is.

Depending on what you're doing, this may require a little coordination (thread signalling) to ensure the game state isn't changing at the same time as the renderer is trying to display it.

You haven't specified what technology/engine/language you're using, nor the specific problem you're trying to solve, so let's pick an example and say there's a log rolling down a hill.

By default, the log will roll until it hits a door and breaks it.

It's possible for a player to shoot at the log and divert it.

You server has a physics tick every n milliseconds.

In that tick you calculate the movement of the log due to known forces.

If you receive a packet saying "the player fired at this spot at time X", you need to:

• "Rewind" the simulation to the first tick that would've been impacted by the event
• Add the physics effect from the shot to the simulation
• Run the simulation forward to the present time [possibly re-processing every intervening tick], being sure to handle all other player input you've received so far.
• Do it all quickly enough that it's not perceptible.

How exactly you do this is implementation- and use-case specific.

Some systems save state data for the last n ticks, so they can just discard everything since then and start from a known good state.

Others have a physics simulation that can be run in reverse deterministically, so they can run time backwards and forwards.

Yet others use clever algorithms to invalidate/recalculate only those physics objects potentially impacted by the event.

However you do it, when you've worked out the world state, you update it in memory and the render picks it up. The log will appear to teleport from where it was to where it should be.

First up, the state of your game should be decoupled from your rendering.

The rendering loop should query the game state and display it on screen.

A separate loop (sometimes called a physics tick) is where you handle changes to the scene.

Many physics engines require consistent time steps between iterations, and other background tasks (like AI) shouldn't be impacted by how good the user's graphics card is.

Depending on what you're doing, this may require a little coordination (thread signalling) to ensure the game state isn't changing at the same time as the renderer is trying to display it.

You haven't specified what technology/engine/language you're using, nor the specific problem you're trying to solve, so let's pick an example and say there's a log rolling down a hill.

By default, the log will roll until it hits a door and breaks it.

It's possible for a player to shoot at the log and divert it.

You server has a physics tick every n milliseconds.

In that tick you calculate the movement of the log due to known forces.

If you receive a packet saying "the player fired at this spot at time X", you need to:

• "Rewind" the simulation to the first tick that would've been impacted by the event
• Add the physics effect from the shot to the simulation
• Run the simulation forward to the present time [possibly re-processing every intervening tick], being sure to handle all other player input you've received so far.
• Do it all quickly enough that it's not perceptible.

How exactly you do this is implementation- and use-case specific.

Some systems save state data for the last n ticks, so they can just discard everything since then and start from a known good state (can be memory intensive and puts a hard limit on how late packets can arrive).

Others have a physics simulation that can be run in reverse deterministically, so they can run time backwards and forwards without the simulation becoming unstable.

Yet others use clever algorithms to invalidate/recalculate only those physics objects potentially impacted by the event, cascading the calculations as needed.

However you do it, when you've worked out the world state, you update it in memory and the render picks it up. The log will appear to teleport from where it was to where it should be.