19-08-2026, 04:50 PM
Issue #5197 mentions adding the ability to pause, seek, move back and forth by individual frames and change
the speed of playback when watching replays. To this, Alayan responded "Pause, rewind and speed change are
all things I would like to have as well. This won't be in 1.5 and maybe not in 2.0, but it's definitely on the roadmap."
I have built the engine side of this and in accordance with the "Communicating with the team" section of the
contributing code guidelines I am making a forum post about it.
I have implemented this by means of a ReplayControl class that owns the replay clock. It can pause (setPlaying), move
the head of the playback to a desired time (seek) and change the rate of playback (setRate). The ability to move back and
forth by individual frames naturally falls out of this; you would just seek by a frame-sized delta (or move to an adjacent time
via m_all_times, both can work). This functionality is currently enabled via a --replay-control flag and without it it is inert.
This doesn't change the normal race clock: everything outside of watch replay mode remains untouched.
I have deliberately NOT added the UI. I've built the mechanism, however as it stands there is no user interface that allows
the user to control it. This is on purpose and has been done for two main reasons.
1. Building UI blind without knowing if it is wanted or how the structure should be set out puts my time and effort at risk of being wasted.
2. Where the UI lives, how it looks, where the buttons are, etc. are design decisions that are not my call to make.
This feature has a dependency on the fix outlined in pull request #5837 - without it, seeking backwards would cause the ghost
to freeze in place, which is far from ideal.
The diff can be found here: https://github.com/schrowd/stk-code/compare/fix-ghost-controller-seekable...feature-replay-control
(Note to reviewer: the three "removed" lines in world_status.cpp are still there, they're just indented one level deeper and so
GitHub shows them as red. None of the original behaviour has been changed or deleted. You can see that exact same code in
lines 479-481.)
To wrap this up, I'd like to ask a few questions:
the speed of playback when watching replays. To this, Alayan responded "Pause, rewind and speed change are
all things I would like to have as well. This won't be in 1.5 and maybe not in 2.0, but it's definitely on the roadmap."
I have built the engine side of this and in accordance with the "Communicating with the team" section of the
contributing code guidelines I am making a forum post about it.
I have implemented this by means of a ReplayControl class that owns the replay clock. It can pause (setPlaying), move
the head of the playback to a desired time (seek) and change the rate of playback (setRate). The ability to move back and
forth by individual frames naturally falls out of this; you would just seek by a frame-sized delta (or move to an adjacent time
via m_all_times, both can work). This functionality is currently enabled via a --replay-control flag and without it it is inert.
This doesn't change the normal race clock: everything outside of watch replay mode remains untouched.
I have deliberately NOT added the UI. I've built the mechanism, however as it stands there is no user interface that allows
the user to control it. This is on purpose and has been done for two main reasons.
1. Building UI blind without knowing if it is wanted or how the structure should be set out puts my time and effort at risk of being wasted.
2. Where the UI lives, how it looks, where the buttons are, etc. are design decisions that are not my call to make.
This feature has a dependency on the fix outlined in pull request #5837 - without it, seeking backwards would cause the ghost
to freeze in place, which is far from ideal.
The diff can be found here: https://github.com/schrowd/stk-code/compare/fix-ghost-controller-seekable...feature-replay-control
(Note to reviewer: the three "removed" lines in world_status.cpp are still there, they're just indented one level deeper and so
GitHub shows them as red. None of the original behaviour has been changed or deleted. You can see that exact same code in
lines 479-481.)
To wrap this up, I'd like to ask a few questions:
- Is this something you'd want in the main game?
- Should I build the UI or is that something you would be doing?
- Is driving the world clock the correct approach?
- Where should this live? It currently lives in src/replay: does it belong somewhere else?
- Whose job should it be to handle frame-stepping - ReplayControl's or the UI's?