Conceptually, how does replay work in a game?

Question

I think your initial thought was correct. To create a replay, you store all input received from the user (along with the frame number at which it was received) along with the initial seeds of any random number generators. To replay the game, you reset your PRNGs using the saved seeds and feed the game engine the same sequence of input (synchronized to the frame numbers). Since many games will update the game state based on the amount of time that passes between frames, you may also need to store the length of each frame.

Starcraft and Starcraft: Brood War had a replay feature. After a match was completed, you could choose to save the replay to view later. While replaying, you could scroll around the map and click on units and buildings, but not change their behaviors.

I remember once watching a replay of a match that had been played in the original game, but the replay was being viewed in Brood War. For those unfamiliar, Brood War contains all of the original units and buildings, as well as a variety of new ones. In the original game, the player had defeated the computer by creating units that the computer could not easily counter. When I played the replay in Brood War, the computer had access to different units, which it created and used to defeat the player. So the exact same replay file resulted in a different winner depending on which version of Starcraft was playing the file.

I always found the concept fascinating. It would seem that the replay feature worked by recording all of the inputs of the player, and assumed that the computer would respond to those stimuli in the exact same way each time. When the player inputs were fed into the original Starcraft replayer, the game played out exactly as it did in the original match. When the same exact input was fed into the Brood War replayer, the computer reacted differently, created stronger units, and won the game.

Something to keep in mind if you're writing a replay engine.

There are two major methods:

1. Storing events (such as player/ai actions) -- just as you say.
2. Storing state (full game state, f.e. locations of objects, in consecutive moments).

It depends on what you want to do. Sometimes storing events is better, because this takes usually much less memory. On the other side if you want to provide replays which can be played at different speeds and from different starting points, it is better to store states. When storing states you can also decide whether store them after every event or f.e. only 12 or 25 times per second -- this might reduce size of your replay and make it easier to rewind/fast forward them.

Note that "state" does not mean graphical state. More something like unit positions, state of resources and so on. Things like graphics, particle systems and so on is usually deterministic and can be stored as "animation X, time Y:Z".

Sometimes replays are used as anticheating scheme. Then storing events is probably the best here.

Technically you should write your engine to be deterministic, that is no randomness. Assuming a character in the game is aiming at the arm of an opponent, and fires a weapon, then the same amount of damage should be applied to the opponent in all cases.

Assuming a bomb detonates at location X, the particles produced by that explosion should always result in the same visual result. If you need randomness, create a set of random numbers, select a seed value when the game is played, and save that seed value in the replay.

In general having randomness in a game is a bad idea. Even for things like multiplayer, you can't have half your players able to see around an explosion while the others can't simply because they didn't get the right random value.

Make everything deterministic, and you should be fine.

Given the initial state and a series of actions with timestamps, simply go through the sequence as the recorded actions are supposed to happen have a replay.

In order to get random events to re-occur exactly the same, use seeded pseudo-random numbers and save the seed in the replay file.

So long as you use the same algorithm to generate the random numbers from the seed, you can recreate all the events just as they occurred in the live game without needing full snapshots of the game state.

This will require replays to be watched sequentially, but that's pretty normal for game replays (see Starcraft 2). If you want to allow random-access to the timeline, you can take full state snapshots at set intervals (say every minute), to jumping around the timeline at a set granularity.