Monday, November 06, 2017

First-timer Foibles

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