Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

up vote 3 down vote accepted

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.)
share|improve this answer
    
Good points, in particular the first one. I forgot about this use but it is quite helpful. –  Klaim Jul 17 '12 at 21:04
    
Bingo, especially on #1. If I had the time to create some input recording system, I would be able to log every single test, as well as catch some hard-to-reproduce bugs. Being able to load these "rare case" logs again makes it easier to spot the bug as you step through your code. –  ChrisC Jul 17 '12 at 22:23
add comment

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.

share|improve this answer
    
In the question I specify that the game model is fully deterministic. There is no physics and frame rate variation is only visible on client side, not in the game model that is totally dependent on the "tick". –  Klaim Jul 18 '12 at 7:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.