Conceptually, how does replay work in a game?

I swear SC1 had rewinding in its replays. Or at least jumping to the past. And from what I remember, SC1 replays recorded all user inputs, timing data, as well as w/e the unit AI (pathfinding and auto attack) did. This would cause some problems across patches which would make previous replays glitchy since something about the unit stats would change. For example, if a unit had 45 hp and then upgraded to 50hp in a patch and the replay had a unit kill the 45 hp unit and immediately leave, then in the patched replay, you would just have a 5hp wounded unit left standing there.

There were all sorts of tools for analyzing replays. They did contain ALL user inputs, so you could map a players APM second to second through the entire game, and you could also break out what percentage of their clicking was spam, and what were actual commands.

In my opinion, the main source of replay instability comes from the timing model. I just dealt with this yesterday, in fact: I have a puzzle game running the Box2D physics engine, and had to rework some of my architecture to make it run deterministically each time the player restarts, since the gameplay is predicated on testing a configuration, resetting, and adjusting it.

Representing time in a game requires some way of slicing a time delta into discrete slices that you can run processing on it; so in the end every timing model comes down to "use a time delta directly within your simulation code" or "chunk it into frames and store or drop the remainders." The latter option is almost a given if you want your results to be stable and deterministic, it's just a matter of _when_ you apply the frames.

In my case, before the refactor I had each segment of the simulation(AI, spawners, physics, etc.) running independent frame chunks from the same dT. The problem is that in a loop that looks like:

ai.update(dT); phys.update(dT); spawns.update(dT);

If dT is large enough, then AI will run multiple times before ever hitting physics, causing some bizarre behaviors that may or may not be acceptable(in my case, not).

My solution was to change it to:

while (dT>fixdT) { ai.update(fixdT); phys.update(fixdT); spawns.update(fixdT); dT-=fixdT; }

This way, no one piece of code can race ahead of the others, but the option is still there to let some things run only every n frames(including fractional amounts).

Another thing I had to do for stability was a full reset on everything. Pre-refactor, I let Box2D stay "warm" and just removed all bodies, but this turned out to affect determinism - and proved worse for start times than a cold restart, anyway.