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
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.
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?
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.
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
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.
Look over your grammar to ensure it is technically correct,
but also keep an eye out for style problems like run-on sentences.
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.
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.
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.
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.
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.
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.
Make sure your descriptions are consistent with the game's overall
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.
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.
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.
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.
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.
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.
JIFFEE and JIFFEEgames.com copyright © 2007-2010 by Michael S. Kenniston. All rights reserved. This page was last updated on 2010-01-01.