I'm writing a simulation program. I need a way to record and then play back the entire simulation, at any given point. Kind of like how games like Age of Empires 2 does it, not as in actual video recording of the player's screen. My simulation consists of a really large grid of moving/changing objects. I've already had to dump the core of the program and I'm in the process of replacing it with a messaging system, so that any information that is WRITTEN to the simulation is done in a mesage format (eg. pObject->sendMessage_setDirection()) and information that is READ from the simulation is done regularly (eg. pObject->getDirection()).

This is turning out to be very hard to maintain. Every time I add a new object or a new kind of message for an existing object I have to add new code snippets all around. Mostly because messages have to travel from the top of the simulation through 2-3 layers down to the actual object, and every layer needs to know how to handle or route each and every message.

So I'm wondering if there's some clever way to go about this besides my approach. My program is relatively young so I can afford to make large changes at this point, specially if it'll make developing the rest of it easier. Recording pixel-by-pixel (video) isn't an option because the grids are supposed to be able to get really large (for example 64,000x64,000 tiles). I also thought about reading through the entire simulation after every tick (a "tick" is the smallest unit I need to record) and saving it to a file but again, it can be really large, so doing this every tick would make the whole thing very slow.

Thanks in advance.

In a game (or actually a simulation) I worked on, we abused the networking system for this. We made a special kind of 'client' that would not connect through the network, but ran on the server locally. It would store all the game state updates sent to the clients in a file. Periodically, the whole game state (say, your save game) would be stored as well, serving as a kind of keyframe.

Then, at a later time, that file could be used as a replay.

Is it ideal? No.

In a large game, you'd selectively send updates to clients. So if units are not near the player, you'd not (or more sparsely) send updates. Also, it requires you to have networking code in place, which not everybody does, of course.

But for us, it was the quickest way to get things working.

Oh, and a link I found interesting: http://gdcvault.com/play/1018138/Implementing-a-Rewindable-Instant-Replay

One way is to store user input and playback a recording of the input.

This requires that state is properly reset at the start of the playback. Random numbers must also be seeded the same so that AI makes the same decisions. Some thing that require randomness but aren't critical (e.g. particle systems etc.) can use a separate source of random numbers which you don't require to be repeated exactly.

It can be quite tricky to get that system right though, and if you make a change to logic you invalidate the replay data. Also you can't rewind except to the start unless you save checkpoints (i.e. all the data and state) at regular intervals.

Timing issues can mess it up too so you probably want to use a fixed timestep and playback at the same rate.

That's actually what I had done before. Problem is the simulation sometimes takes too long on a tick so live playback of all the computations can be slow, and it cannot be rewinded, which is necessary here.

some games have recorded things like demos and similar, mostly by recording internal events (generally those that represent what the user sees).

so, whenever something moves or happens in-game, it is recorded.

to playback the demo later, you replay the events, typically on a timer, so it is as-if these things were happening again, and all the events are seemingly recreated on-screen.

recording user input has also been done in various games, but tends to be a lot more problematic:

if there is any non-deterministic behavior in the system (such as timing behaviors due to variability in framerate, AI logic timers, etc...), or something subtly changes from one version to another, then these tend to be very prone to blow up and have everything go berserk, whereas recorded game events tend to be a lot more stable.

That's what I'm doing right now, event/command recording. Apparently that's the best way even though it's complex.

Thanks everyone!

You might want to check out http://www.gamasutra.com/view/news/197635/.