Jump to content
  • Advertisement
Sign in to follow this  
DiB08

Record and Playback System

This topic is 3806 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

Thanks for verifying that it's a PITA. The engine is non-deterministic and I foresee the huge requirements for storage. It sounds like brute force is the only way to go with some minor optimizations possible.

Share this post


Link to post
Share on other sites
Advertisement
A little question about recording inputs : how do you play backward ? Or how do you fastly reach a given position in the playback ?

For the moment, our system is non-deterministic, but it'll be, and then I'll have to redo the recorder system. And if I can only store inputs, that would reeeaaaally be great. But I don't know how to play backward, or radomly access the playback ...

If there's a way, good. Else, I think I'll use compression :)

One thing to note about that is the data you record is mostly continuous. I mean, 99% of the time, objects are quite close to their previous position, 1% left being teleportation, if any at all. And there are really efficient algorithms to compress / decompress those kind of data.

Share this post


Link to post
Share on other sites
Several points :

If I understand you correctly, you want that as a feature of the game, and not as a wonderful debug tool.
* In this case, you have to start recording at the start of the "map" ( whatever map really mean for your game ), and to insure that you restore a complete initial state.
* The same issue applies for your saved data at arbitrary rate for replaying from here.

I had some tries on this subject, but only for debug. Recording inputs and time delta at each trame was only the emerged part of the iceberg. Then you have to make sure file operations are taken into account, and the biggest issues were multithread ones : concurrent access to any shared variable must concur in the same order.
It then really depends on your architecture, but it can be really painful.

If you only use it for gameplay, you may not use a real replay. I think quite often car games replay are just recording/ resetting cars state ( pos, speed, acceleration, ... )

Share this post


Link to post
Share on other sites
There were two things I planned on doing to support access and storage.

1.) I was going to store locations of key frames (say, every 5 or 10 seconds) in memory. Then, when i need to jump to a location, I can quickly find the closest previous key frame and search from there.

2.) I planned on NOT recording player information at an incredibly high rate, but at a lower rate and then dead reckoning as I play back. Aside from dead reckoning, if we have all of the player's states, we may be able to do some really nice interpolation given how much information we end up storing (position, velocity, acceleration, orientation, and even orientation rates).

Share this post


Link to post
Share on other sites
As you are using a networked game and the server sends the message which are true and are in binary format already then why not simply record the binary packets received when a flag is set to record the data. Memory map virtual storage and write to this, there does not need to be a saving/loading interface just dump it to memory, why playing back make the file the server and replay the messages.
"1.) I was going to store locations of key frames (say, every 5 or 10 seconds) in memory. Then, when i need to jump to a location, I can quickly find the closest previous key frame and search from there."

So I take it that you do not want an actual replay just an approximation? For example a player is walking forward (key frame) walks in a circle for 9 seconds and then continues walking forward, at ten seconds you make a key frame yet you have lost the information about the actions in between. Imagine playing an online game where packets were sent every ten seconds!

"2.) I planned on NOT recording player information at an incredibly high rate, but at a lower rate and then dead reckoning as I play back. Aside from dead reckoning, if we have all of the player's states, we may be able to do some really nice interpolation given how much information we end up storing (position, velocity, acceleration, orientation, and even orientation rates)."

The server will send information in ticks and this is what I think (also Dave Weinstein GDC 2005 "A case for message passing architecture" ) you should record, the packets will normally already be optimised for transmission and therefore reduce the size of storage required.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!