Games from Within

If you haven’t read it already on Game Developer Magazine, don’t miss the Dirty Coding Tricks feature article on Gamasutra. I contributed two “dirty tricks” used in some of my past projects. Identity Crisis deals with the horrors of a CRC clash on a resource right before submitting the gold master. And The Programming Antihero shows [...]

I really enjoy a good cup of tea. On the surface, making tea is really easy: take some tea leaves, pour some hot water over them, and wait a few minutes. In practice, the difference between a bitter, undrinkable brew, and a perfect cup of tea is all in the details; the type and amount of tea, the temperature of the water, and the steeping, time all make a huge difference. A playback system for a game is very much the same. As we saw last month, the basic idea is really simple: Record all game inputs, make the game deterministic, and you get the same playback every time. Unfortunately things aren't quite that simple in real life. Just as with tea making, the secret to a perfect playback system is all in the details.

How would you like to be able to reproduce every crash report that QA adds to the bug database quickly and reliably? How useful would it be to be able to put a breakpoint the frame before a crash bug happens? You can do all that and more if your game is deterministic and you feed it the same inputs as an earlier run. Sounds easy? It is, if you implement it early on and you keep it that way during development.

I've gotten a lot of questions about how big our codebase is, how fast does it build, how many tests we have... Fear not, Gentle Reader, all your pressing questions will be answered here.