Replay system: record inputs or events?

Question

I read this: How to design a replay system But it don't really answer my question.

My game is built with the client "view" of the game as a separate program from the server "model" and "controller". (a bit like a mmo, or any multiplayer game built this way). The server side is always the "truth" of the game, it only accept action requests as input from the clients and output events and "current state" messages.

The game model and rules are fully deterministic with a fixed "tick" update cycle, so on the server side I can record both the events sent to the client views, and the action requests. Both are associated to specific cycle number.

The question is: in this case, to setup a replay system, should I use the input, or user action requests (as suggested in there) or the events?

It looks to me that both would give exactly the same output. The only differences I can see are:

• Events gives the real output while action requests have to be processed to give events.
• Action requests might be far less data to record.

Are there other things to consider?

Answer 1

Given a deterministic system they are logically equivalent so your summary is pretty much correct. However there are 2 more things that would sway me towards recording input actions rather than output events:

1. If you save the actions, you can use them as test data later, as they exercise more of your code than just replaying events will. This can help with diagnosing crash bugs, finding behavioural regressions between builds, etc.
2. In future you might change the events that you send for a certain action, or you might send different events to different clients for some reason. In this case, the replay could become invalid or incomplete. The same problem could in theory apply to inputs, but usually the domain of inputs is more constrained than outputs and so is less likely to change and easier to accommodate with backwards compatibility when it does. (Inputs are limited to what the player and other input sources (eg. random number generator) can do, whereas the outputs include all the results of those inputs plus any other outputs generated by the game rules, such as presentation hints, periodic server-side events, etc.)

Answer 2

Either works, though there are a few things to consider.

First, remember that you need to record time information. For games with any kind of variable frame rate, this can be particularly tricky; you need to ensure your replay data can provide the exact same timing information that the game originally used for simulation.

You also need to account for tweaks to the game behavior. If you record input and then tweak any part of how input is handled, how physics resolves, etc, your recording becomes invalid. Even if you record game events, if any part of how those events get interpreted changes, you're stuck.

If you just want playbacks, a good approach is to record a specific list of positions and rotations for the player entity along with timing information. Disable as much of physics and other gameplay logic while running the playback as you can. How easy or feasible this is depends on how many other objects you need to sync up.