* * *
I decided to jot down a few things I've noticed in a lot of the amateur games I've tested or tried out. I've tried these games for reasons I can't entirely fathom; admittedly, it's easier and leaves fewer disfiguring scars than self-flagellation. It is not necessarily any less painful though.
This is not intended to be a "You know you're dealing with an amateur IF author when..." list. It is intended to be useful to new writers, to know some of the things that scream "WARNING: Amateur author ahead, proceed with Caution." I have also, in a couple of spots, mentioned ways to avoid the behaviour in question or even how to specifically avoid it in your game code. I've mentioned Inform only because it's the IF-programming language I'm familiar with. I don't claim any special knowledge of amateur mistakes.
Also note that I have used the generally accepted practice (at least by me) of using the words "he" "him" and "his" in a gender-neutral fashion. I'm fully capable of wasting enough space as it is without the added weight of fussing about typing 'his or her' every time.
1. POINT PROFUSION (or SCORING SURFEIT)For some reason, amateur authors like to have games with absolutely massive numbers of points. I'm not sure whether this is because it makes the game look bigger or better or what. It strikes me as very adolescent: "My game is so awesome!!! It has ten times as many points as Zork II."
Rather than have a game with 100 points maximum, the amateur will have the number of points be, say, 10000, and every time the player does anything he receives 100 or 500 or 1000 points.
SOLUTION: If you never award < 100 points for any action, follow this algorithm:
- take your maximum score and divide it by 100.
- take your awarded points, and divide them all by 100
2. SYNONYM SICKNESSa) Lack of synonyms for objects mentioned as being present
b) Objects mentioned but given different 'name' properties, eg. "You can see a toolbox here", but 'tool' and 'toolbox' don't work to refer to it, only 'box'.
MINIMUM: the name used to describe the object to the player MUST work to refer to it (e.g. the toolbox above)
BETTER: all the words used to describe the object, including adjectives, should work, e.g. 'shiny red toolbox' should generate matches for 'shiny', 'red', 'tool', 'box', 'toolbox'
BEST: you should also match reasonable synonyms that you DON'T mention in the text (e.g. 'chest' 'tools'). Use a thesaurus and check for synonyms. Of course, don't overdo it if you have multiple items that are similar, e.g. a leaflet, a pamphlet, a letter and a notebook. Overloading all of these when you have several of these items can lead to parser difficulties.
> take book
Which book do you mean, the spiral notebook, the small pamphlet, or the encyclopedia?
In this case, disallowing 'book' from the notebook and the pamphlet is better.
ABOVE AND BEYOND: If you're really feeling generous, you'll make sure that words that are complicated to type in your game (e.g. Montagnolo) have commonly misspelled variants in their list of matches and maybe some short forms as well.
3. TEXTUAL TRUNCTIONS (a.k.a. hard carriage returns in displayed text)This room is pretty
big, you cant see
any exits to north
or south but there
might be a door
east or west.
I think this error stems from working with IF-languages that don't automatically word-wrap for you. I've seen this in a lot of ports to Inform. It may also stem from a desire to avoid having lines in the source code file that run off the editor screen.
Beginners: if you want to wrap your printed text so that it appears nicely in your editor, just hit enter in the string. Inform interprets this whitespace as simply a space. Works beautifully. Let the player's interpreter worry about word-wrap—it knows how wide his window is. You don't.
4. EXCITING EXCLAMATIONS!!!You are in the bank.
There is a crazed person
here running toward you!!!
> x person
You can't see that here.
> x crazed
You can't see that here.
Oh no!!! The crazed person just
shoved it's ax in your head
now you're dead!!!!
The profusion of exclamation points in amateur writing (both IF and non-IF) is always astounding. It may stem from a desire to turn bland unoriginal text into more exciting EXCLAMATION-POINTED text. Any writing can be made more exciting with exclamation marks, can't it? (Some would argue that's reason enough to sprinkle them all over this document).
Exclamation marks tend to be overused. Use them sparingly, and don't use more than one at a time. Please!!!
Note that there should be exclamation marks sprinkled all over your Inform source code file. If they're not inside printed text, they're COMMENTS and comments are good.
5. ABERRANT ARTICLES (or Definite Article Errors)Torcher Chamber
You can see a Lord Blackadder here.
I don't really understand how these sorts of errors can exist. Presumably the author runs through his game while developing it. If I notice this as a jarring error, why doesn't he?
(Another problem apart from the definite article error is the lack of an initial description. Even if the article is correct, the message "You can see Lord Blackadder here." smacks of laziness. See below.)
6. ORAL OFFENSES (or Abuse of the Player)This is something that seems so adolescent and immature, and yet you see it from authors who, by several other measures, appear to be adults. An overwhelming tendency to insult the player when he does something that the author doesn't want to permit.
Why do authors do this? What goes on in their head that tells them these abusive responses will be appreciated?
Most players can tolerate mild sarcastic comments, especially if they do provide useful feedback (or are amusing):
> fire arrow
It would be difficult to do that without a bow.
But downright abuse should be out:
> cut thread
You cut the thread.
<lots of other things done in between, puzzles figured out>
7. ENCUMBERING EXPOSITION
8. SHOCKING SPELLING AND GRISLY GRAMMAR
Not everybody shares this opinion, but I believe that implementing anything other than the default response for 'examine
me' smacks of a lazy or amateur IF-writer, as well as a poorly-developed
PC for the story.
9. PLAYER PERUSAL
Think about who your PC is. Is he male or female? Tall or short? Ugly or attractive? How is he dressed? How is the response you print from 'examine me' affected by the PC's opinion of himself?
Another question to consider—how does the appearance of the player change during the course of the story? Do events happen that should cause the response to 'examine me' to change?
One additional point: much as it's bad form to insult the player, it's very cliché to have all the NPCs in the game treat the PC like dirt, or refer to him as ugly, smelly, dirty, whatever. Unrealistic too. In the real world, there are lots of helpful people, so if the PC is in a generally nonhostile environment, your NPCs should at least be civil towards him.
10. LACONIC LOCATIONSMany games seem to operate from the idea that giving a location a name is sufficient for fully describing it. It's not.
Yes, if you say "You're in a bank." most players will be able to imagine what a bank looks like. But the point is: we want to know what this bank looks like, how you the author have envisaged it.
Also frustrating are room descriptions that all begin with "You are in..." and the idea of variety is to start a room with the description "You are standing in...".
One of the worst I've seen recently (paraphrased to protect the guilty):
You look around. The only way out of here appears to be North as there is a wall to the south. East and West do jack-all for you.
You check your surroundings. You can go east or west. Southward appears to be blocked.
Didn't you read my instructions? You CAN'T go south.
The key problem with the last one is the use of "appears to be blocked" which implied to me that there was a barrier there that could be circumvented. Not the case. You just couldn't go south. No mention of what the apparent blockage was, of course.
Be imaginative when describing your locations. If you have trouble knowing how to describe things, observe the world around you. Look at pictures that resemble the locations in your games. Try to describe them to someone else, or have someone else describe them to you, and see how much of a picture you receive based on just the description.
Bear in mind though that location descriptions do not need to be long. Vivid and memorable is good, but functional is important too.
Beyond Zork is an excellent example of terse location descriptions, though of course, it benefits in that the automap mostly removes the need to clutter the description with exits.
11. ACTION ADVANCEMENT (via Location Descriptions)This is another one I've seen quite a bit. Here's a quick example to explain. We've got your average run-of-the-mill IF game. We're standing beside a car. There's only one way to get through the second-story window above, and that's by standing on the hood of the car when it explodes. So the amateur writes the "Second Floor" location of the house like so:
The car has exploded, and you are in the second story of the house where you were blown by the exploding car.
An easy rule would be: NEVER put plot action into the room descriptions. It doesn't matter if the given plot action is the ONLY way the player could EVER get into the location; do you want the player to see it every time they say 'LOOK' ?
What if, 37 room locations later, you decide that you do want the player to be allowed back into that location? So you put a link from the hallway back into the second story room. Guess what? If you don't remember that location which you wrote two months ago has a plot-centric description, you'll be in trouble.
For the more sophisticated, you can put some level of plot action into your room descriptions through the judicious use of logic.
For example, in Inform, you can use the "visited" attribute to figure out if this is the first time a room has been entered, e.g.:
Room Guild_Hall_Foyer "Guild Hall Foyer"
with description [;
print "The opulent splendour of the guild
hall foyer is almost overwhelming. Huge
marble columns rise up to hold the vaulted
ceiling in place, and the marble walls
and floor seem to glow and shimmer with a
queer internal light.^";
if (location hasnt visited)
"^A bored-looking guard glances at you
as you enter. ~Welcome to the Vechlee
Guild Hall,~ he booms in stentorian
"^The guard nods at you. ~Welcome back.~";
12. INSIPID INITIALSI don't mind seeing "You can see a <whatever>
13. MANGLED MIMESIS
14. ACTION ABORTION
NPCs that do nothing unless the magic words are said to them
15. CLOSEMOUTHED CHARACTERS
You are in the queens torcher
chamber. Baldrick is running
around and screaming let me
out let me out!!! he's in prison
for meeting the queen the
other day then he didnt bow to
her. So she told him to and
he did but not low enough!!!
You can see a Lord Blackadder here.
> ask blackadder about baldrick
There is no reply.
> ask blackadder about queen
There is no reply.
> blackadder, tell me about baldrick
There is no reply.
> talk to blackadder
That Baldrick is going crazy!!! We
have to find a way to get out of here
and YOU have to do it."
At the minimum, give your NPCs a default response to Ask and Tell. Personally, I don't like the "I don't know anything about that." type of response. That clearly says to me, as a player, "Here's a hole in the game." I prefer something like "You're busy worrying about that when we've got to escape this prison cell?" Something that works in the context of the game, and the context of the NPC, and why they're there with the player.
Try to predict the reasonable topics of conversation that the player might initiate with the NPC, and program responses in for them. Think about the objects the player is likely to have when they meet the NPC, and have the NPC respond meaningfully to the more important ones. And create a nice default response for being shown the rest of them:
"So you've got a fox who's so cunning he's just been appointed Professor Cunning at Oxford University