Jump to content
  • Advertisement
Sign in to follow this  
kitman20022002

Unity Question about creating a replay system

This topic is 1092 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm tying to design a replay system in Unity5 that will playback the last n seconds of gameplay when I score a goal. I looked up the internet and found two solutions :

1.  Record all of the game events and game object states and play it back (seems most people recommend to use this) 

2. Simply take a screenshot every frame and play it back. 

 

My question is why people don't use the 2 method and instead they choose the 1 ? because the 1 method seems like a very heavy weight solution. thanks

Share this post


Link to post
Share on other sites
Advertisement

You might find these interesting:

 

Game Developer Dec 2012 p36 - recording unity - Building a replay system in Unity
 
Game Developer May 2008 p46 - IMPLEMENTING DETERMINISTIC PLAYBACK SYSTEMS
 
Game Developer Jun-Jul 2008 p47 - IMPLEMENTING DETERMINISTIC PLAYBACK SYSTEMS PART 2

Share this post


Link to post
Share on other sites



First, the size. A single screen capture image may be 1920x1080x24 = 58 MB uncompressed.

 

Wait, is my math off with this?

 

1920*1080 = 2.073.600 pixels

2.073.600 * 3 (per channel, one channel is one byte right?) = 6.220.800 byte

6.220.800 / 1024 = 6075 KB

6075 / 1024 = 5.93 MB

 

Thats still something but 58MB seemed a little much for a single screen picture, even uncompressed. 

Share this post


Link to post
Share on other sites

There is a third option, that only CaptainMurphy mentioned:

 

Write a deterministic system; and only save the input sources of undeterminism (e.g. initial conditions, RNG seeds, player input, network input).

Replaying is a matter of feeding the input from the saved values instead of the player's keyboard/network/etc.

 

If you start with this method from ground up, it's very easy to implement. Otherwise it's a PITA if the engine is halfway through (main trouble is guaranteeing determinism and ensuring all sources of undeterminism are isolated).

The best of this feature is that it's useful not just for replaying, but also for debugging. Got a crash? Catch the crash, save all the input and close the app. Now reply the saved session with a debugger hooked. Also if you have a race condition or an uninitialized variable, it will be spotted almost immediately. Very hard to miss.

 

The disadvantage is that if you update your application, the saved sessions become useless (since it needs to be played on exactly the version it was recorded with). For Unity's, you also have to add that updates to the C#'s .Net runtimes may affect the determinism (unless you embed Mono dlls with the app?), and due to the JIT nature of C#; it probably won't replay correctly on another machine.

Edited by Matias Goldberg

Share this post


Link to post
Share on other sites

 

First, the size. A single screen capture image may be 1920x1080x24 = 58 MB uncompressed.

 
Wait, is my math off with this?
 
1920*1080 = 2.073.600 pixels
2.073.600 * 3 (per channel, one channel is one byte right?) = 6.220.800 byte
6.220.800 / 1024 = 6075 KB
6075 / 1024 = 5.93 MB
 
Thats still something but 58MB seemed a little much for a single screen picture, even uncompressed.

 

You're correct. The numbers were wrong. However, the actual problem is that at 60 fps that amounts to 60 x 5.93MB = 355MB/s.
You would need an SSD to record it, since no current user-grade HDD can keep up with that write bandwidth.
You would have to compress it. H264 live encoding is possible, but you would have to use the zerolatency quality profile for fastest speed, and deal with H264 licencing and patents. (and also high CPU usage)

A more reasonable approach is using YCoCg at 30fps and later reconvert to your favourite compression scheme to lower CPU usage, and workaround the H264 licensing/patent issues.

Share this post


Link to post
Share on other sites
Oops, sorry about the math. I was thinking 24 bits per pixel, then calling them bytes. Still, at anywhere from 5 to 15 MB per frame and bunches of frames per second, the load can be extreme.

And as was pointed out, you can do much more with replay data.

Share this post


Link to post
Share on other sites

I created a replay system that, every update frame, simply recorded the locations of all the graphical objects in the game screen as well as when sounds were played and saved it to a file.  This is much simpler than recording inputs and trying to make it deterministic, and it's much smaller than taking a screenshot every frame.  You can still do the replays form different angles as Sean was mentioned as well.

 

It worked great for a game I made years ago, I don't know why it won't work for you.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!