Something that is very cumbersome (and boring) to do for every developer out there is the software testing. To combat that, you usually develop a number of methods that helps you track down bugs, for example automatic bug-reports and unit-testing.

One of the more interesting ones is automated testing. For games, this usually means that you have a system that simulates the player and automatically generates input for it. For my latest project Hyena. I’ve had the rare opportunity to play around with an application where the controls are so basic that it was actually possible to write a system that played the whole game for me.

For Hyena this was obviously extremely simple, since controls only require you to choose from of a number of predefined choices. The game-book I used for testing was Flight From The Dark, which has 350 pages and each page has on average about 1.6 choices, so fully testing the game was definitely possible. Some preliminary runs did prove very helpful. First of all, it pointed up some show-stopper bugs in sections like this where you ended up with all choices disabled due to a problem in the LUA-script. The other kind bug it pointed out appeared when I looked at the pages that never was displayed, and could trace that to another LUA-script bug.

Also, doing simple analyses of such runs are also trivial and can be a great tool for game-design. You might remember hearing of such analysis from the development of the original Half-Life. Basically, they built a system that tracked stuff like the health of the player throughout the levels, and having this activated during focus-testing allowed them balance the game better. We (Starbreeze) asked Valve about that a few years ago while working on Riddick, and while they still were very enthusiastic about the idea, they also told us that it never got to the point where it was really useful. My guess is that the big problem for most games is that you still need to rely on real players for the data to be useful.

Then again, that’s not equally true for Hyena and game-books in general, since there isn’t that much of a difference between a simulate player and a real one. The only limitation my simulated player has is that it never goes to the action chart and actively uses items (healing potions for example). Of course, it also happily chooses a really stupid-sounding choice as often as a sane one. Still, the analysis gives a lot of information about how well the game-book is structured. Take a look:

http://www.collectingsmiles.com/hyena/analysis/fftd_analyze.jpg

This is a flowchart generated from a simulated run of 40139 playthroughs (yes, it took a few hours) and shows for example that:
• The game is  completed in 7.5% of the cases
• The Gourgaz kills you in 57% of the cases
• The most dangerous enemy are The Doomwolves, who kills you in 74% of the cases

It also displays a couple of “flaws”:
• There is this really big path that takes off from near-death experience in this section that is shown in less than 0.1% of the cases.
• A couple of sections are never displayed, either because of the problem above, or because of this one, where a fight extremely seldom lasts 4 rounds.

I intend to expose this analysis functionality in Hyena, so this tool will hopefully be available to anyone who wants to write his own game-book.