Recording games...
BlitzMax Forums/BlitzMax Programming/Recording games...
| ||
| Well, didn't know where to put this, so I'll put it here. Does anyone have experience adding the ability to record and play back their games? I've been thinking about how to do it, and was wondering if anyone has solved these issues before. Some of the main issues I see: 1) Timing with Input When playing back the recording, how do you know when to poll the "recording" for input? 2) Timing with the game Games that use timers (for end of level, etc...) or are time based, how do you make sure the recording stays in sync with the game timers? 3) Randomness My games incorporate a lot of randomness in them, do I create a new seed each time they play a game and save that seed to the recording file? This seems the most logical to me. Anything else I should be concerned about? Is anyone working on a Module for this type of functionality or maybe a Module to save game play as an AVI (with Audio)? |
| ||
| If everything in your game is deterministic then its not that hard to do. |
| ||
| This is pretty easy ... just record all the input during record and then on play back you must read it all back and check for "virtual buttons" to see if they've been pressed during the normal game loop. To make it easy check for input in one place in your code. You can also save the random seed as you said. |
| ||
| How to 'record' a game (for a replay, presumably?) greatly depends on the type of game... If a game is fairly linear it is a lot easier than when a lot of different things go on at the same time, since in that case timing becomes crucial. you could either capture the input controls/times and go by replaying those, although that will probably cause timing problems if you have multiple independent objects interacting with each other: one error in timing will influence other objects as well, which lead to bigger and bigger changes over time. You can also record the actual *actions* rather than the controls: At time -x- object -a- begins moving to location -z- at a certain speed. At time x+3 object -b- begins moving to location -z- at a certain speed. At time x+17 the objects collided and performed action #15. If you script everything in a way like that, you can correct timing errors because you explicitely tell it to perform that action #15 at time x+17 rather than hoping that things will come together at the right time and will 'automatically' lead to that result... small timing differences would be corrected this way. As far as the actual implementation... Hard to say without knowing more: a one-person board game is obviously a LOT easier to record than a full-motion 3D immersive game with hundreds of independent units running around. |
| ||
| If you capture and read the input correctly in the same places you won't have issues. I've used this method in quite a few instances with no problems ... Aerial Antics and Leadfoot GT. Yes, you'll run into issues if you don't capture the input correctly and in the same place everytime but other than that it's not hard. |
| ||
| Just remember to save the random seed as suggested |
   |