Got some questions for those of you that handle recording player input and playing it back, be it either as a demo sequence, or a high score replay.
1) What additional data do you save other than the players input and the frame number / timestamp?
2) How do you handle desync'ing situations when played back on a client that runs at a different FPS?
Recording/Playback player input, how to handle desync?
Re: Recording/Playback player input, how to handle desync?
What do you mean by "different FPS"? If you want reliable input playback, you need a fixed simulation time step that doesn't depend on rendering time steps.
Re: Recording/Playback player input, how to handle desync?
1. You don't need to save the frame number or a timestamp, just make sure you start recording (if recording) and playing back (if playing back) in the same part of your code. If you have randomness you need to initialize and store the random seed in your replay and then load it from the replay when playing back.
2. Make sure everything uses a fixed time step, for example everything that moves in the game has its movement handled by you with simple code like "location += normal(direction)*speed" and doesn't rely on built-in functions that could sneak variable time step logic into your game. Stuff that is just eye candy can't desync the replay so built-in functions are fine for those.
2. Make sure everything uses a fixed time step, for example everything that moves in the game has its movement handled by you with simple code like "location += normal(direction)*speed" and doesn't rely on built-in functions that could sneak variable time step logic into your game. Stuff that is just eye candy can't desync the replay so built-in functions are fine for those.
Re: Recording/Playback player input, how to handle desync?
If you don't want 60 entries per second, you need a timestamp (or rather a framestamp).ciox wrote:just make sure you start recording (if recording) a
The eventual difficulty setting.Dave_K. wrote:What additional data do you save other than the players input and the frame number / timestamp?
And yes, a constant time frame step is a lot easier than trying to do variable FPS input playback. I haven't tried it myself, but it feels like it could be really hard to get it working properly.
Re: Recording/Playback player input, how to handle desync?
Thanks for the advice guys! I need to think about this some more, as currently my game (written in AS3/Flash) is based around a frame counter. I do have access to the frame delay upon exiting a frame, so maybe I should be using this to adjust the replay?
Re: Recording/Playback player input, how to handle desync?
Not at all. Adjust nothing to compensate for real-time delays; just render new frames.Dave_K. wrote:Thanks for the advice guys! I need to think about this some more, as currently my game (written in AS3/Flash) is based around a frame counter. I do have access to the frame delay upon exiting a frame, so maybe I should be using this to adjust the replay?
It might help to think of the game as a turn based one: every turn you collect the player's input for that turn (presumably by polling, only once per turn, which buttons are down) and then you update the game state.
Rendering frames to the screen and playing music and sound effects is a completely accessory and optional activity; when you reproduce a recorded game you can render something different from the first time (different screen size, more frames, increased quality, added or removed text, etc.) and change speed (particularly to compensate any involuntary slowdown).
Re: Recording/Playback player input, how to handle desync?
This makes a lot of sense. Thanks again for the help!