Hacker News Reader

Comment by modeless | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com