On a previous post, we’ve been discussing what makes a game feel like work to play, and what doesn’t — and a lot of the answers come back to matters of polish. Is the game bug-free, or close to it? Are puzzles well clued? Are there responses to lots of unexpected commands? Are boring, repetitive actions omitted? Is the space easy enough to understand that the player doesn’t need to map? Does the game help track important clues for the player, so he doesn’t have to take notes?
People keep recommending beta-testing as a way to find and correct such flaws. This is good advice, but it misses a point I think is just as essential:
Play it yourself.
Play your game while you’re writing it. Play it a lot. Play it over and over. Every time you start work on your game again, begin your work session by replaying. You’re coming in fresh, since you haven’t just been writing code; you’re more likely to bring a player’s perceptions to your game, rather than an author’s. Try to forget about what you know you coded, and just play your own game as though it were by someone else.
Are there commands you get sick of typing out? Create shortcuts. A description that gets boring after a few plays? Rewrite it. Odd commands that come into your head to try just because you have already seen this scene a million times? Put them in.
This may seem artificial, but sometimes I even write up a list of design flaws I experienced, just as though I were creating a beta test report for someone else.
Of course, this is easier advice to give about a short game than about a long one. If your work is a ten-hour epic, you’re not going to be able to play the whole thing though and still have time to get any coding done in that session. Which is where my second piece of advice comes in: if you have a long game, create jump-in points so that you can start the game partway through and replay just the scene or section that you’re currently focused on.
This is reasonably do-able with Inform 7. One approach I’ve taken with my more narrative WIPs:
- structure the entire plot as a series of scenes
- make sure that each scene sets up the essentials I need to play through (moving characters into play, etc.)
- to test a new scene, comment out the real scene-starting condition and make that scene start when play begins. (And also comment out the scene that normally starts when play begins.)
A related piece of advice:
The prologue text you wrote when you started the game is almost certainly not the prologue text you want to ship with. I often encourage my students to write the main body of an essay first, and do the introduction and conclusion last. (If they feel uncomfortable starting with the body, they can write a filler introduction — but it should be replaced after they’ve written the main argument.) Roughly the same principle applies to IF: even the most specific idea tends to develop as you write your game, and you may find that the starting text no longer gives a good sense of the game’s theme or major goals — so fix it. Many players see the opening of a game as the author’s contract with the player: you’re supposed to communicate what the game is going to be like, so they can decide whether they want to go on or not. There are occasionally times when this contract can legitimately be broken, but most of the time players will be annoyed or disappointed if you do, even if they would otherwise have liked the work.
This is especially true if you wind up down-sizing your idea somehow. You set out to write an epic, get through the first three episodes out of a projected 27, realize that the whole thing is never going to get done and that you want some feedback on what you have done, and re-structure the piece into a comp-sized entry. Great — but it’s best to make sure that your introduction now fits the revised ambitions of the work.
These two qualities — a high degree of polish, and a clear vision that is evident from the very first move — go a long way towards inspiring player trust. And that trust is what gets people to settle in, relax, and enjoy.
Emily Short's Interactive Storytelling 
A postscript: the reason I found Chinese Room so compelling even despite its various bugs and gameplay annoyances was that it really nailed the “clear vision” part. The writing was confident; the point of the game was presented immediately and held steady throughout. So I trusted that if I could get past the places where I was stuck, what I found beyond would be worth finding.
You’re definitely on to something in bringing up this point. Many experienced game designers say you should try designing a game from the middle — do the middle first, then the end, then the beginning.
One issue authors seem to have is more practical: they have trouble finding beta-testers. When you post to the newsgroup asking for beta-testers, make your request as attractive as possible; even if you don’t want to disclose the plot of your game, you should at least give an aura of confidence in your writing.
If you’re a little more daring, you might try this:
Take a look at the list of beta testers on another game, especially a game that seems well tested. Write down who the testers are. Find another game and repeat. Put stars next to names where the author singles out a particular tester for praise. If a beta tester shows up in multiple games, also keep special note. Once you’ve got a list, look around for emails and make personal requests. It will help to explain how you found them: “I noticed you got compliments on your beta testing abilities” or “I noticed you tested games A and B and C and they were all good” or “I got a recommendation from your friend Mr. X”. Don’t be offended if they say no; they might be starting on their doctorate or they might have moved to a new country or maybe they’re just semi-retired. However, you should be able to find at least once tester this way. Then, ask that tester if they could recommend anyone else.
Yeah, that’s a fair point. Asking people directly is important. I pretty much never do an open call for beta-testers, and I very rarely respond to one. (The only recent exception I can think of was for Eric Eve’s “Blighted Isle,” and I answered that because I knew from the story description and Eric’s previous work that it was a game I was going to want to try, and I thought I was more likely to find time for it if I signed up as a tester.)
People are, in my experience, much more likely to agree if you ask them specifically. The worst that can happen is that they say no.
Does anyone still use the IF Beta Site?
Does anyone still use the IF Beta Site?
Yes! I’m not maintaining quite to the standards I would like to (sometimes games go up late, or testers get notified late) but it’s still up and it does manage to still pair up testers with games.
Another suggestion I’d make to authors: Beta-test other people’s games.
I recently beta-tested a game for the first time, and it gave me a different perspective on pacing, puzzle-design, etc. It’s different from from the view I’ve had while writing a game ,and also different from the view I’ve had as a simple player. I can’t exactly put my finger on it right now (that may be due to 13 hours of driving and an 8 hour workshop this weekend), but I think it’s sort of approaching the work from an author’s perspective but without knowing the content.