Conceptually, how does replay work in a game?

Question

I was kind of curious as to how replay might be implemented in a game.

Initially, I thought that there would be just a command list of every player/ai action that was t

Answer 1

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.

Answer 2

I would believe that at certain increments the game would take a snapshot of the state of everything (EVERYTHING). Then when the replay is happening simple usage of linear-interpolation can be used to fill in the "holes". At least that is how i think it would be done.

You are correct that recording the inputs would be unreliable/not guarantee the same output. The game definitely has to keep track of the state of all the objects (or at least the important ones)

Answer 3

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.

Answer 4

Perhaps you could Simply save a stack of commands being sent by each player. So instead of saving that a bomb detonates at a certain point and time, or that a certain car is destroyed, you simply save the key presses sent by each player. Then, in the replay, you simply simulate the game as it would have happened with those presses. I feel like that has the potential to take up less space, but I've never worked on a replay system like that.

Interesting question, though. I'd be interested in how it's done in professional games.

Answer 5

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.

Answer 6

Throw my two pence in.

Depends on what you want, replay may be accomplished via

1. Recording video buffer and replaying later,
2. Capturing object state every frame and replaying later,

Most of the time, people want an interactive replay, so 2. is the way to go. Then depending on your constraints there are a number of ways to optimize this process

• ensure system is a deterministic simulation *, such that every input generates a consistent and expected output
• if randomicity is required, ensure random numbers may be reproduced exactly at a later time [look at seeding with Pseudo Random Number Generators PRNG, or use canned random sets]
• divide game elements into "mechanic" and "aesthetic" elements. mechanic elements affect outcome [eg column falling over and blocking path], aesthetic elements are for show and do not influence any decision making process in the system [eg visual particle effects like sparks].

It really is a fascinating topic. I remember that one launch title for original Xbox Wreckless had a good playback feature. Unfortunately, on more than one occasion the replay would screw up ;)

oh yeah, how could anyone forget Blinx Time Sweeper! great interactive replay that was incorporated into actual game mechanic!

---

*= seems there are some comments regarding time stepping. i am using "simulation" here to capture this feature. at the core, your engine needs to be able to produce discrete frames of time. even if a replay frame takes longer or shorter to process than the original, the system must perceive that the same time delta has passed. this means recording the frame time-step with each recorded input, and supplying this delta to your engine clock.