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
NVidia PhysX (a physics simulation engine that is often used in games) is capable of recording the full state of the physical scene over time. This incorporates any driving inputs from the game engine, which means you don't need to track random number seeds as others have suggested. If you take this scene dump, you can replay it in an outside tool (provided by NVidia), which is very handy for tracking down problems with your physical models. However, you could also use the same physics stream to drive your graphics engine, which would then allow you to have normal camera control, since only the physics driving the graphics have been recorded. In many games, this includes the particle effects (PhysX includes some very sophisticated particle systems.) As for sound, I'm guessing that's recorded verbatim (as a sound stream), but I'm not sure.
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.
Your original idea is right, and for the really complex effects, they aren't remembered exclusively. For example, the Warcraft 3 replay system doesn't store the state of animations, or particle effects in the case of random effects, etc. Besides, MOST things can be computationally computed from a starting point in a deterministic way, so for most systems that use random variables (a particle explosion that gives a random offset, for example), all you would need is the time of the effect, and the random seed. You could then re-generate the effect without really knowing what it will end up looking like.. knowing that it is going through a deterministic code path.
Thinking of it purely conceptually, to replay a timeline of events, all you need are the user actions. The program will react exactly the same way, except in the case of random variables. In this scenario, you could either ignore the randomness (does it REALLY matter if the effects look EXACTLY the same, or can they be randomly re-generated), or store the seed value and fake the randomness.
The problem of having a consistent replay is the same (well, easier) like have a consistent multiplayer game.
As others mentioned before, replays in RTS games are stored by recording all input (that has an effect. Scrolling has no effect.) Multiplayer transmits all input, too
Recording all input not just a guess - there is a library for reading Warcraft3 replays with reveals this.
input includes timestamps for this answer.
Dan Bryant
Further, recording random seeds would not be sufficient for rewind support, since random progression is not a reversible procedure without special support in all of the logic relying on the randomness. It's more flexible to record the results of the random operations as part of the event stream.
That's exactly What I thought at first when I was trying to figure out how did they make it so that the game replays always the same each time. With Doom I thought at how random the shoots went :D. Store any random number got used, I found out it could be a solution. That was before I came across a pdf paper about Crysis technology. Some textures noise there and grass or tree disposition, seemed to be using pseudorandomization with fixed reversible seed to make it so you didn't see altered disposition of noise, trees and grass anytime you look!
Avoiding at the same time, to store millions of trees and grass shafts position. Apparently pseudo random sequence can replay the same anytime, as the logic is fixed, to just make a fake statistically random sequence of numbers.
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.