Basic Mechanics Checklist

"The details are not details — they make the product.
It is, in the end, these details that give the product its life."
- Charles Eames

Here is a checklist to get you started writing high-quality games. This is intended for relative novices and there's no rocket science here, so this list won't endow you with brilliance or creativity. It can, however, help you get your basic mechanics solid by finding and correcting errors which would make your game look sloppy and amateurish. Many of these guidelines are simply principles of writing good prose, which should be no surprise since the most visible part of Interactive Fiction is prose.

Without a written list like this it can be very easy to overlook these errors when writing. Such mistakes might be trivial in a short story, but they are likely to be much more distracting and even irritating in an IF game because your player will see them over and over again, so they're worth fixing. People are used to professional software and have come to demand perfection, so take the time to fix all the bugs and rough edges you can find. These items are listed in roughly increasing order of difficulty, but there is no special order in which you have to do them.

  1. Check all your capitalization to make sure it is correct and consistent. If you want to use capital letters to mean something special that's fine, but write down the exact rule you're using, e.g. "The name of each object with magical powers is Capitalized, and the name of each person with magical powers is written in ALL CAPS." If you don't bother to write the rule down, it's easy to accidentally change it midway through writing the game and that will confuse your players.
  2. Check all your punctuation for correctness. If you're not sure about something, look it up in an English style guide. (This will not only improve your games, it will also improve your other writing.)
  3. Double-check all of your spelling, if possible with an automated spelling checker. If you're writing with JIFFEE and you keep your external strings in their own block of code, you can just copy that block into a word processor and let it do the spell-checking for you. Just remember to copy your corrections back into your game! Also remember that spell-checkers rarely catch mistakes like confusing "their" and "there" and "they're," so a good dictionary can be your best friend.
  4. Look over your grammar to ensure it is technically correct, but also keep an eye out for style problems like run-on sentences.
  5. Make sure your game uses either first-person or second-person consistently, for example it should not say "You pick up the box" in one place and "I can see the bridge from here" in another. Pick one perspective and stick with it.
  6. Avoid slang, jargon, and abbreviations. There may be a few places where it is appropriate, but using too much of it will limit the size of your audience — not to mention being hard to translate into other languages. Remember that you're creating a piece of literature, not texting a MSG 2 UR BF TYVM. RLY.
  7. Have someone else who is fluent in the target language proofread your strings for capitalization, punctuation, spelling, and grammar, because you will inevitably miss a few mistakes in your own writing.
  8. Every physical object mentioned in any description should be known by the game, i.e. the player must be able to at least examine it. If you describe a room with a vaulted ceiling, and the player tries to "examine ceiling," you do not want your game to respond by saying "I see no ceiling here." Doing a full and complete job of this can be tedious, but you risk seriously annoying your players if you neglect it.
  9. Make sure that in each location, an attempt to move in any direction gets a sensible response. A default like "I see no way to go in that direction" may be fine inside a room, but if you're in the middle of an endless expanse of prairie you'd better supply something more reasonable. Be sure to consider all 12 "normal" directions at every location: n, ne, e, se, s, sw, w, nw, up, down, in, out. In the prairie example the 8 compass points are probably sufficient, but if you are in a barn where you can see a ladder then trying to move "up" should either succeed or produce an explanation of why that's not possible.
  10. Conversely, make sure the description of every location supplies adequate information about where the exits are. Don't force the player to mindlessly try all 12 directions to discover which ones work. (It's OK to have something like a hidden door, but only if you provide an appropriate clue; see below.) You should also tip off the player when an exit doesn't lead in the intuitive direction; for example if a player follows a road to the north but that road bends so it runs into the next location from the west, be sure to describe how the road curves to the right so the player won't be confused.
  11. Make sure your descriptions are consistent with the game's overall physical layout. For example if you can see a lake to the north, and you move north, you should reach the lake or at least get closer to it. Your player will get frustrated if moving toward a lake takes you to a train station where there is no mention of any lake. Draw a map to help you get this right.
  12. If the player has to do something special, make sure you've left clues where they can be found. The clues can be hidden, but they must be hidden "fairly," i.e. where the player can find them using common sense and without having to make any lucky guesses.
  13. For each word that the user might type in as part of a command (i.e. each noun, adjective, adverb, and verb that you define), include all the reasonable synonyms that you can think of. Players will think of lots of different ways to say things, and to the extent possible you want anything that makes sense to work. A good thesaurus can be your other best friend.
  14. Now have someone play your game (this is called "alpha testing"). Choose someone who will be brutally honest with you, i.e. somebody who won't hesitate to tell you that your shirt really does make you look fat so you'd better wear something else on that hot date you have tonight. Watch them play, and take notes. You will be amazed at what they find that you need to fix. If there were a lot of problems, you may want to repeat this step with a second (different) alpha tester after you fix what the first tester found.
  15. After you've finished making changes in response to feedback from your alpha testers, go back and run through this whole list again, because you've probably made a lot of changes since your first once-over and those changes all need to be checked too.
  16. Now recruit a couple of "beta testers". Since the game is probably more solid by now, these don't have to be close friends. People you meet on Internet IF discussion forums can be good candidates for this. The idea is the same: they will play your game, and tell you what they think is broken or could be improved. You don't have to take all their advice, but do at least listen to it.
This may seem like a rather long list of tasks which will be a lot of work to do well. It is, but if you are not conscientious about looking for these kinds of errors you will give the impression that you don't really care about your own game — and if you don't care about it, why should anybody else bother to play it?