Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Replay System


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
10 replies to this topic

#1 raptor70   Members   -  Reputation: 122

Like
0Likes
Like

Posted 14 March 2007 - 03:53 AM

Hi all, Does someone know a good article or website about ReplaySystem ? I found one on Gamasutra but are there other ? For me, a replay system must be able to register a game part and replay it... Thanks in advance Regards

Sponsor:

#2 0BZEN   Crossbones+   -  Reputation: 2029

Like
0Likes
Like

Posted 14 March 2007 - 05:25 AM

There are two sorts of replay systems That I know of.

1) If you have a deterministic game, all you need to store and replay are inputs (user inputs, frame timesteps, random number seeds, ...).

2) Serialisation / Deserialisation of the game state. Have your objects record and replay their states. In fact, you don;t record the states, but the state changes (many objects won't change).

#1 Is very lightweight, IF IT WORKS! The trick is to have a fully deterministic game, and that in itself can be a problem. Second, if there is a discrepancy, it is very hard to track down what made the game and it's recorded part deviate. And once they deviate by the slightest bit, that's it, game over. Anything as trivial as doing one collision check out of order is enough to send the replay sideways. Detecting deviation for debugging requires you to build hash values of object states (whatever that is, like a ray-traces, messages, ...)

Also, you cannot rewind, step into the game, without having to rollback the simulation to the very start, and replay up to the point of interest. Also, you need to decouple the update, and the rendering, if you do not have a fixed frame timestep, and you want stuff like slow motion.

#2 Requires more code. You need to implement serialisation methods to your objects. Then being able to record changes in game states (if you want to have a small replay buffer). It's not dissimilar in many respects to the Quake3 Networking Model. Instead of sending the game state to a client, you just write it to a buffer, and for replaying, grab the game states from the buffer, do interpolation, effects...

#3 rasher_b2   Members   -  Reputation: 128

Like
0Likes
Like

Posted 14 March 2007 - 01:59 PM

I have implemented the replay system that oliii described in 1.
Once you have a deterministic game then it's simply a matter of logging the user's inputs and replaying them back during the correct game update. It was surprisingly easy to implement but as was mentioned, the hard part is in making sure that your game is completely deterministic.

I decided to make mine deterministic because it's easier to debug and you don't have any crazy thing that can rarely happen for no reason at all.

#4 OrangyTang   Members   -  Reputation: 1294

Like
0Likes
Like

Posted 14 March 2007 - 02:08 PM

'1' is also a little fragile - if you make a recording with v1.0 of your game then the odds are it won't playback the same under v1.1 of your game. Now if you're just using it for an attract screen then you can rerecord without much hassle, but if your players are expecting to keep their replays between versions then it's probably not the best approach.

It is very, very light on memory though - typically you only have to record a handful of inputs every frame, so you can have quite long recordings without taking up much memory at all.

#5 raptor70   Members   -  Reputation: 122

Like
0Likes
Like

Posted 14 March 2007 - 10:15 PM

Thanks all...

The objective of this system is to test, all the night, the game during development and verify that there are not difference between the versions...
Does your purpose system adapt ?



#6 0BZEN   Crossbones+   -  Reputation: 2029

Like
0Likes
Like

Posted 14 March 2007 - 11:21 PM

Depends on what you need to reproduce, but 1) will replay 'exactly' as you recorded, or either it will bomb straight away. The second is more like an approximation of what's going on, and the A.I. and other components are disable (it's a 'pure client', like when you replay a Quake3 demo or observe a Guild Wars battle). If that's all you need, and you already have serialisation (load / save), then it's worth considering.

As said, 1) is very fragile. When your game code changes (anything from A.I., to collision, tiny optimisations even), the inputs will most likely no longer be valid. This is not quite so true for 2), although a change in the data format will invalidate the replay as well.

Both require a lot of work tbh. 1) is to make sure it's 100% deterministic, write debug tools to check on that (record/test hash values made of game data) and everytime you tweak the code, you have to keep it mind if the determinism will stick, 2) is writing all the serialisation and delta-compression methods, which is no small task.

Lots of things can get in the way of determinism, especially if you have a multithreaded system, then I'd be very careful. Obviously the threads will have to be sequenced properly, and that may or may not be part of your engine.

If you are pretty confident that your game can be fully deterministic, 1) is definitely the easiest. It's painstaking work (debugging notably), but it's still way more lightweight than 2) which will be a monster.

#7 0BZEN   Crossbones+   -  Reputation: 2029

Like
0Likes
Like

Posted 14 March 2007 - 11:26 PM

BTW, if replays are not 100% required and part of the deliverables, then gladly walk away. They are a pain, trust me on that (I've worked on / with a few).

#8 Tachikoma   Members   -  Reputation: 552

Like
0Likes
Like

Posted 15 March 2007 - 12:22 AM

Here's a couple of Gamasutra articles worth checking out:
Instant Replay : Building a Game Engine with Reproducible Behavior
Developing Your Own Replay System

(sign-up is free)
Latest project: Sideways Racing on the iPad

#9 raptor70   Members   -  Reputation: 122

Like
0Likes
Like

Posted 15 March 2007 - 12:42 AM

Thanks but I already found it... ;)

#10 0BZEN   Crossbones+   -  Reputation: 2029

Like
0Likes
Like

Posted 15 March 2007 - 12:47 AM

Those articles are pretty much bang on.

#11 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 15 March 2007 - 05:58 AM

I made a real simple system (it was for a 2D Mobile game) which worked extremely well and only took me a few hours to integrate. This was for a sports game, so for each player on the field they needed an X, Z animation and direction they are facing (among other things, but these were the core stats the needed to be replayed). The player class was already set up like this, so there was no refactoring needed or any headaches when implementing this system.

I had an array (note the int is actually Fixed point) in the Player class,
int m_iReplayPos[NumberOfFrames][2]; where NumberOfFrames = the number of frames to save, and pos0 = X, and pos1 = Z;

In addition, I stored their animation data like this
byte m_ReplayAnims[NumberOfFrames][2]; where NumberOfFrames = the number of frames to save, and pos0 = Direction they're facing (North, south, etc), and pos1 = their animation.

For each frame that was rendered (remember this is a cell phone game so fps = 10->15) i stored the position of each player and their animation + direction (I had a function that when it rendered them, used the animation and direction to display the correct frame).

I did the same thing for the ball and camera, and just iterate through this array when replaying, disabling ALL AI and anything else that would divert from this set course. As i said, it had to be simple for a cell phone game, (which was already pretty simple), but it integrated nicely into our game. In about 2 hours, I had the replay working no problems using about 10k for 15 seconds or so of replay.

Hope this helps!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS