Recording Games
Author
After seeing Starcraft 2, and starcraft 1 both have a screen recorder function. I was wondering how to implement that too. Does anyone have any idea how to do that? I was thinking using the print screen function, for ever frame print and copy to the custom video file and save it for later. But have not tried it yet...
When I have done this in the past I have grabbed the frame buffer each frame and output each frame to an image file. I then use these separate images and use [enter your video editor of choice] to create a video.
This has advantages and disadvantages, such as:
- It is very slow and you take a noticeable frame rate hit.
- If you interpolate between frames correctly you will get a
nice sequence of images no matter how long it takes to generate them.
When you put them into a video editor you will get a smooth
X fps for the video.
There are also libs to create a video sequence (rather than a sequence of images like I do). I don't know how these compare performance-wise but I think the bottleneck is reading the framebuffer. I use opengl and glreadpixels, its quite possible there are much more efficient ways of doing this.
This has advantages and disadvantages, such as:
- It is very slow and you take a noticeable frame rate hit.
- If you interpolate between frames correctly you will get a
nice sequence of images no matter how long it takes to generate them.
When you put them into a video editor you will get a smooth
X fps for the video.
There are also libs to create a video sequence (rather than a sequence of images like I do). I don't know how these compare performance-wise but I think the bottleneck is reading the framebuffer. I use opengl and glreadpixels, its quite possible there are much more efficient ways of doing this.
Starcraft (And starcraft 2) do this by recording the player's input and a few things about the game state each frame. The replay functionality is then just an input replayer, which is rather trivial to implement. Saving and reloading every frame into a framebuffer is far too expensive to do right now.
Yeah replay files simply record every external command made, plus the random seed used for the game, and can then replay the entire game by duplicating all the commands you made and having the random number generator generate the same random numbers causing it to have the same internal effects that it did during actual play. Given that the same code is running and the internal and external influences are the same, the game deterministically plays out exactly as it did originally.
You can tell this is how it works both by the recorded file size and the fact that you can click on things and scroll around etc while the game is playing.
The problem with this approach is that one little bug will cause the replay to deviate from what actually happened during the game, and everything can get totally out of whack.
I saw this once replaying a starcraft game of an old version. I had triupmhantly won the game, but in the replay I lost about mid-game. All it took was for say one bunker that had nearly got blown up during actual game play to take slightly more damage than it was supposed to, and blow up, then the units in there got killed, and then they weren't there to fend off the next attack, and then that bit of my base got wiped out, etc... dominoes!
When programmed correctly though, it works beautifully!
You can tell this is how it works both by the recorded file size and the fact that you can click on things and scroll around etc while the game is playing.
The problem with this approach is that one little bug will cause the replay to deviate from what actually happened during the game, and everything can get totally out of whack.
I saw this once replaying a starcraft game of an old version. I had triupmhantly won the game, but in the replay I lost about mid-game. All it took was for say one bunker that had nearly got blown up during actual game play to take slightly more damage than it was supposed to, and blow up, then the units in there got killed, and then they weren't there to fend off the next attack, and then that bit of my base got wiped out, etc... dominoes!
When programmed correctly though, it works beautifully!
It's probably how the multiplayer code works also because in a RTS you can't often replicate the properties of each unit on each client in realtime. They are probably just replicating the inputs, seeds, delta time etc. on each client. So once you got it working for the multiplayer, it's trivial to do replays.
I did this in my side-scroller (you replay the last level while the credits are scrolling). the way i did it was simply recorded where all the objects were on the screen at a specific interval (say, every 60 milliseconds). I would store them in a file, (using a simple format to store which image was where each frame).
It's simple, but be careful how you store the information. Don't use large structures, or the file can become quite large!
As other said, using the players input isn't the most stable because variables in the OS can change the smallest thing, and cause a problem with synch.
It's simple, but be careful how you store the information. Don't use large structures, or the file can become quite large!
As other said, using the players input isn't the most stable because variables in the OS can change the smallest thing, and cause a problem with synch.
You are setting the seed value yourself. Most people use the systemtime as initial value. So you only have to save it when you pass it to the generator.
A delta time is the time difference between two states. Mostly between the
steps of calculation that drive your game forward.
You could do a mix of the "input replication" and the "lets save everything" choices. Most of the time you replicate the actions by the given inputs but
every once in a while you should save everything to force a synch.
If you do it right you will get medium sized files with low risk of
"butterfly-effects" like described by iMalc.
The hard thing is to figure out when to put a key-frame where everything is
saved.
A delta time is the time difference between two states. Mostly between the
steps of calculation that drive your game forward.
You could do a mix of the "input replication" and the "lets save everything" choices. Most of the time you replicate the actions by the given inputs but
every once in a while you should save everything to force a synch.
If you do it right you will get medium sized files with low risk of
"butterfly-effects" like described by iMalc.
The hard thing is to figure out when to put a key-frame where everything is
saved.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
