This week I’ve had three intrepid beta-testers thrashing their way through my latest text adventure game, The Only Possible Prom Dress. The way this works is, I send them a version of the game and they start a playing session by typing SCRIPT. The game development/playback software then records, as a text file, exactly what happens during their session. They send me the text files, and I read through them to learn what’s not working.
It’s fun, but gruesome, and mainly just a whole lot of work. Naturally, at the start of the testing process I would like to think my game is close to finished — but from having gone through this process a few times in years past, I’m quite aware that that’s not going to be the case. There are sure to be many, many problems.
Sometimes the problems are easy to fix. A tester gives the game a reasonable command, and the game gives a response that doesn’t make sense. Or the tester tries to converse with a non-player character (an NPC), but the NPC doesn’t yet have any code to respond to that specific topic. So I write something.
Other issues can get more complex. The player may be able to do things that ought not to be possible, such as getting into locations that ought to be blocked off. Or it may be possible to get the game into a state that I simply hadn’t anticipated. In the latter category, I have two NPCs who can follow the player character around in the environment of the game. One of them is going to be helpful, and the other is an annoyance that you’ll have to deal with. It had simply never occurred to me that a player could have both of them following at once. Leading a parade, in effect. This creates a kind of clutter that I don’t need.
So I add a bit of code that will cause one of the NPCs to get bored and leave the parade after X turns — and in doing that I create a bug that makes the game unwinnable. I have a test run-through that will play straight through from the start to the happy ending, so when I run the test and things go horribly wrong, I have to figure out how to fix it.
Here’s another amusing issue. The library I’m using, adv3Lite by Eric Eve, is brilliant, but in at least one respect it’s a little too brilliant. Eric has implemented a complex system for allowing the player to converse with NPCs. This system allows and in fact expects the author to set up greeting and departure protocols. To initiate a conversation with an NPC, you need to issue some sort of say-hello command. That’s lovely, except when it’s not. If you happen to be writing a game where there’s a fireman, and the player guides her character into the room where the fireman is waiting and types TELL FIREMAN ABOUT FIRE, the game will respond, “You’re not talking to anyone.” You have to politely say hello to the fireman before you can tell him about the damn fire!
This is awful. I’m sure there’s a way to fix it, but in half an hour of trying this and that I still haven’t figured out how. So I’ve posted a message on the forum asking for suggestions. This generally works; there are a few people who know the adv3Lite library better than I do. So I’m keeping my fingers crossed.
The underlying issue here is verisimilitude. One wants the scenario of the game to seem real. When the software balks, it’s up to the author to figure out a way to bring it into line. And with a complex game, that’s not likely to be easy. There are some classic difficulties that authors run into. Elevators, for instance, and liquids, and ropes that are tied at one end and free at the other end. I have one of each in the game. Maybe I’ve got them coded adequately. Maybe.
This game is huge. In the first four days of testing, none of my three testers has even gotten past the second of the four opening challenges. Essentially, these four items are multi-part puzzles, and they have to be worked through in a set order. After that, the game opens up and there are lots of ways to proceed. Also lots of places, I’m sure, where the software is going to need massaging. Whether it will all be tested adequately remains to be seen. Tester burnout is a real possibility.
I think it’s a fun story, but I didn’t anticipate that it would be as tough for players as it’s starting to appear. One of my testers managed to get the octopus released from its tank in front of the pet shop, but she had no idea that she had just set up the solution to the first puzzle. She just wandered off and started looking at other stuff. I’ve implemented an extensive system of hints, of course, and my testers are avoiding them because they want to actually test stuff. But players of the finished game may also prefer to avoid diving into the hints, so I need to think about how best to sprinkle in-game clues in the player’s path.
It’s like building a castle one brick at a time.
Jim Aikin's Oblong Blob 