Just sort of a general question - in a modern 3D game with so much freedom of movement etc how would you go about storing the movements and events to playback action replays? There must be so much information to keep track of that it seems like the data structures would be huge?

Why would they?

You need only store player inputs (at most, say, 10 floats per physics frame) and any seeds for any random number generation you're doing...

I suppose you might want to store the full game state as a keyframe each second or so, as insurance against going off track, but that shouldn't add a great deal of extra data.

http://www.gamasutra.com/features/200107...son_01.htm

I could see this being a headache if you are using one of the big physics packages. They never seem to behave the same even with identical input and starting conditions.

-Jon

Aarku is right. At least with ODE, you'll never get the same playback twice. There are *endless* discussions of exactly this matter on the ODE mailing lists.

If I were doing this, I'd simply have a std::vector of positions and transformation matrices for each actor running at, say, ten updates per second. It'd require a lot of memory, but you could have a thread in the background serialize it as the main thread adds more.

Games like Quake (the first two at least) store key frames for every object at 10-20FPS. Basically it's the same data that is sent out for a multiplayer game, and the engine interpolates those frames when playing back demos. This is generally a "safe" way to go about it, but a deterministic approach has benefits beyond demo playback. Reproducing and tracking down obscure bugs is a whole lot easier if you can playback exact user inputs for example.