Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About DiB08

  • Rank
  1. 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).
  2. 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.
  3. Good question. There is a special mode where a player can act on what has already happened. For this to work, I will need to play back what has already happened and insert the player's new data as well. I would then want this new data available for future playback.
  4. Right now my thought was to make a header struct with the packet type, packet size, and timestamp. Then follow every header struct with the actual data. Save the data at arbitrary rates, and keep a table in memory of "key frame" locations in the file to assist with searching for a specific time and being able to play from there. The biggest overhead I can see would be inserting new data in the middle of the file, which would mean updating the "key frame" table. It just seems that this problem must have been tackled a thousand times a thousand ways and I'd hate to repeat a bad design!
  5. Yeah...trying to avoid "slow". I can't record input because of network players. I have an "obvious" solution, but I wanted to incorporate anyone's lessons learned or avoid some not-so-obvious pitfalls before I go too far down one path.
  6. I am looking to write a record/playback system for a game. I wanted to see if there were any good hints out there as to how to do it effectively. I need the system to be able to handle an arbitrary number of players, an arbitrary number of packet types, an arbitrary frame rate for each player, insertion of data, forward play, backward play, fast forward, rewind, etc. I plan to write everything out to a binary file, which is fine, but how best can I structure my data and file as to be able to move through it fast. I am not as concerned about disk space as I am performance and capability. Thoughts or lessons learned? Thanks.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!