GENF20

evantgel — Sat, 21 Mar 2009 06:38:15 GMT

Thanks for article.MotoGP is my favorite.

re: MotoGP: replays

Ultrahead — Sat, 21 Mar 2009 07:11:53 GMT

"Solution: don’t have any bugs!"

Lol!

mistery

ApellA — Mon, 23 Mar 2009 12:35:01 GMT

Now I'm really curious of what that last sollution might be.

Keyframes are useful for debugging

gfoot — Tue, 07 Apr 2009 12:56:13 GMT

The keyframes were really useful for debugging the purely input-based part of the replay system. While you're playing back the replay without the user jumping back and forth, you can just ignore the keyframe data - the input recording should have already got the physics into the right state. But while you're there, in debug builds, you might as well check that the keyframe state matches the current physics state. If it doesn't, you can report numerically exactly which bits of state didn't

match, and these give valuable clues to which bit of the system is not being deterministic.

Due to the butterfly effect you often find that by the time you reach the next keyframe pretty much all of the state is wrong, but you can set the keyframe interval very low to catch the errors sooner (at the expense of only being able to store about ten seconds of replay data) and hopefully you then find that only one member is wrong (e.g. mWheelieAmount) and you then know exactly what's causing the inconsistency.

In fact I think we actually did restore keyframes when we reached them anyway, even though it shouldn't make a significant difference. I don't remember exactly, but I think this actually "fixed" some bugs. I guess there are a few possible explanations, but I never thought of one that actually made sense in the end.

If I was implementing this kind of system again, there's one particular thing I would have wanted to do - and that's segregate the physics state into constant data, primary inter-frame state, derived state, and possibly temporaries (which were only necessary to communicate between methods during the course of the frame). Then you can mostly ignore constant data (just make sure it gets set up consistently next time the game runs), store the inter-frame state in keyframes, and recompute derived state after restoring keyframes. Crucially you also get the obvious option to zero out the derived state before recomputing it, and to zero out the temporaries at the start of every frame.

All of a sudden you can be a lot more confident that the physics engine isn't storing data in places it shouldn't, that storing a keyframe is writing the right data, and that your bugs are going to be reproducible (rather than depending on the state you switched from and to when you restored the last keyframe). The hardest bugs to diagnose were the ones where you can to skip to a keyframe where the bike was flat on the ground from a state where the bike was doing a wheelie.