Adventure Gambook Play-Testing

You may have noticed the progress bar at the top right which mentions a gamebook (if it's not there, the book is done so go ahead and buy it).

As of now my co-author (FNH) and I have both done all the entries, traps, encounters, puzzles and so forth and are doing proof-reading for quality and consistency of text across entries. After which comes play-testing.

Those of you who are writing, or considering writing, a gamebook may be intrigued to know that actual play-testing is being kept to a minimum.

Why and how?

The "why" is easy. Testing takes time and playing through a gamebook trying all combinations enough times to be happy with the outcome take a long time indeed. Anything that can reduce that is welcome.

Hence the "how".

The intention is to release in multiple formats, both electronic and paper. To do this, the traditional way of writing is not ideal as the final master manuscript would then need converting and massaging to suit each other format. If things change before publication then it needs doing again.

To get around this, we keep a master file (shared editing via Google Docs) which consists of entry titles, content, links, challenges and stats changes. This is in a standard format from which, using a C# tool I've developed, we can create a number of other formats (including RTF, HTML and EPUB) automatically and consistently, in seconds, on demand.

Given that this all exists to support the writing it took only a few more steps to add in automated play-testing. The tool will now run through the gamebook a chosen number of times, with average player stats, making choices, performing challenges, engaging in combat, collecting and using items, receiving damage and so forth. Choices are random, but bad ones are remembered for the player being simulated and are then avoided on the next run through. When/if the computer player completes the game a new computer player starts learning from scratch.

The end result?

A large number of test runs on demand. Only minor intelligence is displayed, with a minimal amount of learning, but it is good for a representative overview.

From that run we get details of how many attempts a minimally intelligent computer player takes to finish the book, how often each entry is visited, where players usually die (whether outright or through cumulative damage), which entries are most travelled by players who complete the game, and more. We get completely laid out graphs of these so we can see it all at a glance. We also get an automatically generated bestiary with creature stats.

Half a million runs through the book in around 4 minutes, summarised into entry map images.

We still need manual play-testing to confirm/clarify, especially as a human plays differently to a computer, but we know in advance which entries cannot be reached, which loop back inconsistently, which branches are most frequently visited (which is where most images should go) and more.

I'm saying all this to make a point.

Play-testing is onerous and time-consuming. Multiple format presentation is too. If you can code, or know a coder, make it easy on yourself and create a tool with a standard input. Or search for one that's already out there. Even if it only does basic consistency checks and no more that's a great deal of testing done away with.

Automate. You get ease and consistency as a result.