How do game recordings work?

[Dando]

In worms and other games we have a method of replaying the game using the engine so that we don't have to store massive amounts of data like movies.

My question is: How is it done?

Is it done by means of key loggers that log what keys were pressed at what frame/time and then just start the game again with the same variables and let it play out? Or is it done another way?

I hope to add the idea to my game, so that is why I am asking;) Also, does worms incorporate any completely random numbers? In My game there is, Randseed changes frpm game to game...I could account for this also by logging which was used i suppose.

[CyberShadow]

Is it done by means of key loggers that log what keys were pressed at what frame/time and then just start the game again with the same variables and let it play out?Yeah, something like that.Also, does worms incorporate any completely random numbers?W:A stores the initial random seed in the replay header, and then uses the usual RNG algorithm to generate the same random sequence as it plays back the game.

For more information, check out this article on the WKB: http://wiki.thecybershadow.net/Replay_file

[Dando]

cheers!
--------

[Lex]

Also, does worms incorporate any completely random numbers? In My game there is, Randseed changes frpm game to game...I could account for this also by logging which was used i suppose.Yes. There is a different random seed generated at the beginning of each game which is saved to the replay file for proper playback. Other than that, there is only pseudo-randomness. Therefore, each game with the exact same input can be played back in exactly the same way, providing it has the same random seed. Replay-playback depends on this. WA simply parses the input from a replay file the same way it would parse input in real-time.

This is essentially exactly what CyberShadow said. Ha. I'm silly and didn't read before I wrote.

[Dando]

Well I have run into my first problem;) It is easy to do ona game using frame based movement (because all frames are played out regardless, there is no skipping either). i.e. log at each frame. But with time based it is not:

Example: I press UP at 1.294 seconds (since I am using timegettime/1000).

thats ok, cool. Now when playback happens, because the difference between frames in time changes differently and is effected by skip...BANG the sprite does not go in exactly the same place and so the butterfly effect ruins the whole thing after about 10 seconds.

Frame based movement would work 100% but unfortunately it also means that a game will slow down on slow computers.

So anyone got any ideas;)

also because timegettime is not accurate and the way in which I am measuring it can never be dead on...it goes out. I am going about this wrong I know it

[franpa]

i and im sure most others would be all fo frame accurate rendering... as it will just make the game tons smoother...

[Dando]

thats not actually true franpa, the game is as smooth as the game can render. All good games for PC are time based movement. If you have a slow comp, frames are dropped, fast comp= 0. In framebased movement, if your PC is slow, the game runs slow because all frames are rendered whether PC can render them quickly or not...so slow often that it is not nice to play.

If you are programming for a console, thats fine, the hardware is constant. PC is not.

And I am pretty sure worms armageddon uses time based movement? If it doesn't, obviously it is very well designed if no frame drops occur across all pC's in frame based mode (but I can't see it)

[bloopy]

Now when playback happens, because the difference between frames in time changes differently and is effected by skip...BANG the sprite does not go in exactly the same place and so the butterfly effect ruins the whole thing after about 10 seconds.

What you are saying here is that the framerate is affecting the game logic. That is not time-based.

If you want time-based, you need to forget about the frames for a moment. Think about how often the game logic updates, for example 50 times a second like W:A. So every 20 milliseconds, you do some calculations based on the key presses/releases that happened within the last 20 milliseconds. With this it should be easy to playback and get the same results, as long as you have the same data about the input (Maybe you don't care that UP was pressed at 1.294 seconds. Maybe you only care that it was pressed between 1.28 and 1.30 seconds, but either way... it's up to you).

Then you need to work out how to do the frames on top of that. So if you draw a frame at 1.307 seconds, maybe you just draw whatever the state of the game was at 1.30 seconds, or maybe you have some functions that can tell you what difference that 7 milliseconds makes.

[Dando]

I will give this some more thought:) 1 way I could do it easily I suppose is to have playback run framebased, and have game play run timebased but log frame based.

I am not using conventional tools/compiler to make this game, because I don't have that much experience;) Anyway, I will see how it goes.

If it was turn based like WA it wouldn't be a problem...since I could tell it to wait until action is performed. Realtime movement is a bit harder

[franpa]

heh yea i was a little confused and what you say makes loads of sense now dando :) and i know what you mean... its just like frame skip or no frame skip in a emulator....

[Dando]

yeah I think that about sums it up;)

[bloopy]

I will give this some more thought:) 1 way I could do it easily I suppose is to have playback run framebased, and have game play run timebased but log frame based.
If you have game play run time-based, why not log time-based? It would make sense! :)

[Dando]

I do log time based but because of the way I have programmed and the tools I am using, it will not work;)

I will have to think it over and wor out how to implement it better. :p

[Dando]

Thinking is over and it is done;)

I just make it render every frame, for slower computers this will mean their playbacks will run slower than they played it, but hell I don't care it WORKS:p

Then actions are done by the frame, and because frames are now always played, the action is always taken. game runs at 62.5 FPS:

Frame 22: UP
Frame 33: DOWN

So there is no way it skips...it has to go though all frames and all actions.