Hacker News Reader

Comment by meheleventyone | Hacker News Reader

There's a third way here so rather than:

* Interpolate between the previous state and the new state by the remaining time which leaves the action delayed in the past.

* Simulate an extra variable delta tick with the extra issues you can get from going off cadence.

You can simulate a temporary tick a full fixed tick ahead and then interpolate between the current tick and the future tick. Typically the cost of ticking a new frame doesn't depend hugely on the length of time it's simulating so the cost is largely the same as the method presented. This has some advantages in terms of keeping the time delta consistent, meaning you don't need to worry about it throughout the simulation code.

View on HN

This runs the risk of showing events that don't occur, as you're rewinding and replaying part of a time step every frame. For example, the player might die in the temporary time step and you'd show the first frame of death animation but then a jump input comes in later that frame and when you redo the time step for real the player doesn't die.

Yes but rollback and replay still looks good in practice and is considered state of the art in latency dependent games (like fighting games).

For multiplayer, sure. The latency is large and variable, so you have to make compromises. But local inputs are low and fixed latency and ideally you don't need the same compromises.

The ideal solution from a latency perspective is non-fixed time steps, but there are a lot of downsides of course. The rewind/replay solution could be improved with some tweaks. You could set a flag in the temporary time step to disable all irreversible state changes like dying, so you would never see/hear a flicker of death.

Why do you think you would see a flicker of death?

For local inputs, the fixed timestep is always a frame or smaller, this is not an issue unless you're over a network

Edit: Oh i see, this is a problem with the commenters suggestion of predicting the future though

Yes if there was a change in input that would mean there was a significant difference but it'd both be fleeting and rare at most game framerates. If one frame you predicted death and the next it corrected it's unlikely much of anything will have started happening. In a rollback networking situation you can often go back several frames of incorrect prediction without it being particularly noticeable, so one frame is basically immaterial.

that's a cool idea! However it does mean I would still have to write the interpolation code which is not fun. But it's a good way to solve the latency issue for sure. Thanks for the idea, I'll add a note to mention it somewhere in the post.

Thanks, like most engineering things it's all about picking the set of tradeoffs that you can live with. :D

Reply on news.ycombinator.com