My old web-page at MTS has come down and as this is linked in a few places on-line, I thought I'd archive it here. Google never deletes anything, right? This is not perfect as the only place I could find it archived was the original Usenet post, when it was called "Amateur Author Annoyances." I've gone through the suggestions after the post and tried to re-incorporate suggestions I likely incorporated at that time but it's likely not exactly the same as it was.
* * *
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 SICKNESS
a) 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'.
SOLUTION:
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.
INFORM SOLUTION:
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).
SOLUTION:
Exclamation marks tend to be overused. Use them sparingly, and don't
use more than one at a time. Please!!!
INFORM NOTE:
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>
> cut thread
You already did that!!! PAY ATTENTION!!!
SOLUTION:
The people playing the game are your CUSTOMERS. Admittedly, you're not
getting paid for this IF work most of the time, but you want it
well-received and well-reviewed. Don't insult your target audience.
In the example above, if you're going to respond with more than a "But
you've already cut the thread." message, at least be clever and original
about it, rather than simply heaping abuse on the player:
> cut thread
You cut the thread.
> cut thread
You painstakingly retie the piece of thread back to the spool, and cut
it again, gaining yourself vast amounts of satisfaction.
(note: the above makes no claim to be either clever or original, but may
serve to indicate the idea).
7. ENCUMBERING EXPOSITION
I've seen many games with massive exposition in the introductory text
explaining everything that has happened in the player character's (PC's)
life to bring him to the point he is currently at as the story opens.
This is a tricky one, and is less indicative of an amateur IF author
than it is just of an amateur author in general. It's very hard to get
right--striking the balance between giving the player the information he
needs in order to understand who he is and play the game with some sense
of that, but also avoiding having things sound like "the story so far...".
There are two extremes. You can relate everything that has happened to
bring the PC to this point, or you can relate nothing at all. There are
some very excellent games in the latter category, but there are not very
many good games in the former.
Remember, as the author of the piece, it's important that you know and
understand exactly how the PC got to where he is. What you need to
decide is how much of that the player needs to know.
Try to avoid the need to relate everything that has happened to the
player until now.
This is bad:
(based on an exposition-heavy game I have seen, but translated to
Planetfall universe for example purposes):
Your big moment has finally come. After much struggle and study, you
managed to win a scholarship to Stellar Patrol University. You have
graduated and attained the rank of Ensign Seventh Class, and after all
your hard work and study, you have been assigned to the Stellar Patrol
Ship Feinstein for its voyage to a far-away planet that was recently
discovered by Stellar Patrol patrols. But there was a massive accident,
and the ship is going down. Your job is to escape from the ship before
it explodes.
Deck Nine
This is a featureless corridor similar to every other corridor on the
ship. It curves away to starboard, and a gangway leads up. To port is
the entrance to one of the ship's primary escape pods. The pod bulkhead
is open.
>
Compare that to the actual way in which Planetfall opens, which I think
is a pretty good example of a game with light exposition, which handles
it pretty well. Way back when, I was able to start playing Planetfall
the day I got it, without having glanced at the documentation and
feelies, and know exactly who I was, my position on the ship,
everything. And all this in a relatively short opening paragraph:
Another routine day of drudgery aboard the Stellar Patrol Ship
Feinstein. This morning's assignment for a certain lowly Ensign Seventh
Class: scrubbing the filthy metal deck at the port end of Level Nine.
With your Patrol-issue self-contained multi-purpose all-weather
scrub-brush you shine the floor with a diligence born of the knowledge
that at any moment dreaded Ensign First Class Blather, the bane of your
shipboard existence, could appear.
Deck Nine
This is a featureless corridor similar to every other corridor on the
ship. It curves away to starboard, and a gangway leads up. To port is
the entrance to one of the ship's primary escape pods. The pod bulkhead
is closed.
>
And then the game makes you wait around, scrub the floor, bump into
Blather, the Blow'k-bibben-Gordo ambassador, until eventually, the
massive explosion rocks the ship, and you know the imperative is on you
to escape.
What does the Planetfall opening tell you? It tells you everything you
need to know in order to play and enjoy the game, and, significantly
VERY LITTLE MORE. The information about Blather could arguably not be
needed, but it's pulled in again at the end of the game to tie
everything together neatly--those two parts of the story bookend the
game beautifully.
A useful exercise is to take every sentence in your opening and figure
out what it tells the player about the game, and his role in it.
Evaluate each sentence's effectiveness and decide whether it
communicates meaningful information to the player.
Evaluate your opening against the four W's (Who, What, Where and Why.
There's also When, but the immediacy of IF makes it less of an issue for
most works). How well are they answered by the time you get to the end
of the opening? As an example, let's try that with Planetfall and see
how it stacks up.
1) Who? You are a lowly Ensign Seventh Class.
2) What? You have been assigned to scrub the deck.
3) Where? You're aboard the Feinstein, a Stellar Patrol ship.
4) Why? You're scrubbing the floor because you're following orders.
All the questions are answered, and with a brief paragraph, the player
knows a lot about who he is and what his immediate goals are.
It's a good idea to check the opening text of many different IF games,
of many varied styles, and see how effectively they communicate the
opening situation to you, without overloading you with weighty exposition.
Trinity is another very good example of a concise opening that conveys a
lot of information.
All this is not to say that initial exposition is bad—but if you need a generous infodump at the beginning of your game in order for the players to play it effectively, you may want to rethink how the game starts. Or if the information can be parceled out in an interactive fashion, that's even better.
The main thing to avoid here is the life story of the character dumped out in a blur of poorly worded "Then...", "then...", "and then..." type sentences. The title of this section is Encumbering Exposition and exposition can be fine if done effectively so it doesn't encumber the story.
8. SHOCKING SPELLING AND GRISLY GRAMMAR
A basic command of English (or whatever language you're writing in) is
essential. The IF community is full of well-read players and authors.
If your game suffers from poor language and grammar, it will definitely
not rise to the top of the pile. There is so much IF that's very
well-written that if your game isn't, I don't think it's overreacting to
say it's doomed to insignificance. The odd typo is tolerated but
consistent poor grammar, spelling and diction will annoy most of your
players. As for the rest of your players, they will be members of the
militant wing of the (to spoof Planetfall) "Speller Patrol" and will
immolate you in the fires of scorn and derision.
Leniency (or burn cream) is given to those whose first language is not
the language in which they're writing, but in general:
if you lack confidence in your command of the chosen language, ask
people to review it for writing style, spelling, grammar, etc.
Running your game through a spellchecker is difficult, because it's
source code, right? Well, turn on the scripting facility of your
interpreter, run through your game, performing all the actions to win
the game, and trying to examine all the objects. Then take the
transcript generated, and run it through your spellchecker. This will
ensure at least that anyone who runs through most of the standard things
in your game won't encounter any glaring errors.
Remember though that spellcheckers never catch homonym misuse, e.g. it
won't flag:
You can see that their is a piece of paper here.
Grammar checkers might catch that, but they make enough other mistakes
that they should probably be avoided. Though there are a few works of
IF I've seen which are so bad already that running through the grammar
checker would definitely have been an improvement.
On another grammar-related note, specific to a lot of Inform games: if
you're going to use the -ize endings of words like "realize", then
please define DIALECT_US in your code, so that we don't have
incongruities like:
You struggle to read the piece of paper, but you don't recognize the
language used.
> study paper
That's not a verb I recognise.
9. PLAYER PERUSAL
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.
SOLUTION:
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 LOCATIONS
Many 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.
Another one:
You check your surroundings. You can go east or west. Southward appears
to be blocked.
> north
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.
SOLUTION:
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:
Second Floor
The car has exploded, and you are
in the second story of the house
where you were blown by the
exploding car.
>
SOLUTION:
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
tones.";
"^The guard nods at you. ~Welcome back.~";
];
12. INSIPID INITIALS
I don't mind seeing "You can see a <whatever>
here" a few times in a
game.
I also don't mind seeing that for things that the player has
dropped in a room. It's nicer if everything has a describe routine, but
that's a lot of work.
As well, if you have a describe routine for
everything, and a player drops everything he has in a room, it makes for
a very lengthy pile of text when he types 'LOOK'.
What I do mind seeing is objects that are still in their initial
location being described as merely:
"You can see a <whatever>
here."
It's not really reasonable that all these things are just lying around
to begin with, but throwing that aside, let's see some originality in
describing them. Have them sitting on the table, discarded on the
floor, lined up in a row, anything.
It should also be self-evident that you should not mention items that players can pick up in the room description (unless of course you're also testing to see if they're still there and avoiding that printing if so).
Along with this idea, let's introduce some sense into the locations
where you find things. Far too many games seem to get all the puzzles
created and then the objects needed to solve those puzzles strewn about
the map at random. Why is there a wrench in the kitchen? Why is there
a flask of acid in the bedroom? Invent reasons for why things are where
they are. Put a leaky faucet in the kitchen, explaining the wrench. Or
put things in places that make sense. A wrench in the toolshop, acid in
the laboratory.
The cardinal sin in initial descriptions is doing this for NPCs. How
boring is it if everytime Jack is in the room and you issue a Look, you get:
"You can see Jack here."
It doesn't take much to change the game to make it look like so much
more than just the standard library with some rooms tacked on. Even a
simple:
Jack is lounging against the sofa here, looking bored.
does wonders for adding realism to the game.
Preferred is doing a
switched random(x) statement of some kind, so Jack does slightly
different things every time the player issues Look.
13. MANGLED MIMESIS
Lots of games break their mimesis
through deliberate and forced injection of the author's voice. One
example I saw recently makes tantalising references to:
... but what exactly is it for?
Only the game author knows!!!
upon examining an object.
Or, worse yet, upon trying to attack an NPC:
If you keep trying to do stupid
things like this, I will find you
and kill you personally.
This was not said by the NPC, but by the game itself.
For me, nothing pulls me right out of the environment of a game worse
than this.
There are also incongruities of technology and culture, say where a
dungeon contains a copy of a modern magazine, or a modern naval vessel
has, for some inexplicable reason, a 150' tall wooden mast.
There may be artistic reasons for doing this sort of thing, say in a
game involving time travel or some sort of really warped technological
world, or a certain freedom in a laissez-faire world of fantasy like the Zork or Enchanter series.
However, if you're trying to write a game with a consistent
setting, make sure you understand the level of technology appropriate to
the setting.
14. ACTION ABORTION
Trapping actions in order to disallow them and provide the "correct"
syntax. This one really annoys me. When I type a sequence of commands
in an IF-game, I can understand if they don't have the right effect.
But if I type:
You can see a rug here.
> sit on rug
Psst, try STAND ON RUG instead
or:
You can see a cannon here.
> put cannonball in cannon
Hey!!! Use LOAD CANNONBALL IN CANNON instead.
I get extremely irritated knowing that the author anticipated my typing
the "wrong" phrase, obviously knows what I wanted to do (because he
suggests the proper phrase), but doesn't bother to do the right thing
for me.
SOLUTION:
If you're going to bother to catch the alternate way of phrasing the
action, and tell me the correct one, why not just have the "incorrect"
one work, and keep quiet about it?
15. CLOSEMOUTHED CHARACTERS
NPCs that do nothing unless the magic words are said to them
e.g.:
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."
SOLUTION:
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," sighs Lord Blackadder. "Too bad it
doesn't help us get out of here. Actually, now that I think about it, it probably would."
* * *
References:
- thanks to the following for their suggestions to the first draft:
- Jim Aikin
- Cedric Knight
- Mike Roberts
- Andrew Plotkin
No comments:
Post a Comment