For my day job I’ve always been a programmer. Well, not so much actual programming in the last few years, but my heart is there, and I still oversee some of the debugging effort. What has this taught me about the editing process?
So I’ve been doing another reading/editing pass on Starguild, concentrating on the most recently changed areas. It was during this process that the connection between fixing text and fixing programs came to me.
I think the number one cause of software bugs is fixing other software bugs. Ok, it tends not to be so bad in these days where we have written a suite of unit tests to cover our back (you have unit tests, right?) but we used to recognise a whole category of “regression bugs”, where legitimate new changes accidentally introduced errors in other parts of the code which were not being touched.
You can see where I’m going with this, can’t you? After some more testing I revised the ‘chase’ rules to work better. At the time I thought that I had covered everything, and rippled the changes through to everywhere affected, but… Three days later I’m reading my latest copy on the train and realised that I had introduced a couple of inconsistencies, and also needed to modify some text around a skill.
Happily Goodreader is not only an excellent tool for reading PDFs, it is also great for marking up with comments and edits for later fixing (www.goodreader.com) so I got the problems fixed that evening.
I’ve come to realise that the number one cause of editing bugs in a game is actually the revision process – the law of unintended consequences tends to introduce “regression bugs” into your text.
So whenever making changes, use whatever friendly reviewers you have to check the whole thing again. And if you are the only reviewer you have, leave it a couple of days and then look at the whole thing in slightly reformatted or reflowed text to help you see it with fresh eyes.
If only I could have a unit test suite for my game rules!