I also vaguely remembered such a resource. Thanks a lot for pointing us to it!
Here are a few more resources about writing room (and other) descriptions …
This article by Stephen Granade is very practical:
Quotes from IF reviews about good and bad descriptions (plus a few more links):
Related threads from the rec.arts.int-fiction newsgroup:
Graham mentions the book Writing BASIC Adventure Programs for the TRS-80 … I just found out that it can be downloaded here:
Grahams piece made me wonder about writing “You are in…” or “You can see…” in the description. Does it serve some purpose, giving the player a bit more presence in the world, or is it just tedious and redundant?
It’s a crutch, I grant you that - a fallback for when you can’t think of anything more exciting. It’s the most obvious way to present a world to a player in the second person. Room descriptions often gain by avoiding it - but failing to avoid it is not shameful.
My advice: make it like an ice cream sundae and put the cherries on top. That is to say, lead with the most salient details. Stuff like temperature and wind can be put in a one-time only message, perhaps staggered to appear after being in the location a while.
(first sentence) (middle sentences) (last sentence)
If all of these are present in a room, then the player’s awareness (from things they are most aware of to things they are least aware of) will be something like:
- object listing
- room name
- exit listing
- first sentence
- last sentence
- middle sentences
(This will vary by person, of course. But in general.)
I build room descriptions based on a combination of this information and a personal design sense about where I want the player’s attention to go. Examples:
If I want an object (or exit) to be extremely visible, then I separate it from the room description. If I want it to be more environmental, then I embed it inside the room description.
If I want players to read the room description carefully (over the course of the full game), then I keep exits listed in the room description only. If the room description doesn’t matter as much, then I separate exit listings from the rest of the room description.
If the PC’s attention would go immediately to a specific object, then I place it either in the object listing or the first sentence.
…and so forth.
XYZZYmag had Michael Berlyn write on this very subject: xyzzynews.com/xyzzy.17d.html
I’ve got some thoughts on this, but I’m struggling to find a way of expressing them without referring to that which must not be referred to in the IFcomp.
Room descriptions are your main opportunity to establish a consistent ‘voice’ through your work. They can be verbose, descriptive, bare, specific, vague, static, dynamic. They are more than a mechanic in that, as well as delivering the required information for the palyer to interact with the world, they both ground it and inform the player’s experience of that world. They establish atmosphere, and set expectations for the text.
They are also your control mechanism for world objects. An object is scenery. It is built into the room description. It is mentioned obliquely. It is separated out. It has the player’s attention drawn to it or it is part of a run-one sentence. It is buried in a list of things. It’s a noun the player can explore, or one you forget to implement. A room description is the starting point for revealing the world.
A room description might be dynamic - it changes in response to a players actions, and, as such, it becomes a part of the narrative drive.
Room descriptions can do alot.
Later edit : Oooh…I’ve just remembered, we were discussing a similar sort of thing relatively recently here: The compass, location descriptions and mimesis
One of the first things I did with the game I’m working on was to say, “At last I can junk the whole cumbersome north-south-east-west description paradigm that sounds so awkward to a player who is new to the genre.”
So I implemented a map that used only “left, right, forward, back, up, and down” as legitimate directions. (No diagonal connections allowed). I keep track of a player’s orientation in a room, so that if he enters the kitchen and the hall is behind him and the dining room is ahead of him, when he enters the dining room and then comes back to the kitchen, he will see that the hall is now in front of him and the dining room is behind him. I even implemented >Turn Right, >Turn Left, and >Turn around, so that a player can change his orientation in a room without leaving it.
Very proud of myself, I was.
Until the first testers go ahold of the game and universally panned it as confusing.
Unwilling to (totally) give up, I (for now) have left the original “left, right” style directions as the default in the game, and told the player that he can type “>Compass on” to revert to the traditional “east, west” style of directions. So far, although the testing pool is small and is made up only of seasoned adventurers, everyone has switched over to Compass directions the moment they had the chance.
There have been a few tests done with relative movement as opposed to absolute movement, but as you saw for yourself, it’s not trivial to implement - and it’s not trivial to play, either. In a text-based game, changing orientation is an unnecessary complication on top of a game that already demands quite a bit of attention from you. It probably works well as a gimmick, in a short game or a short section of a game, but I certainly wouldn’t want to play a whole game that way.
Then again, if you can find someone who is new to the genre to take a look, you’ll get a fresh pair of eyes. You’ll also have to get someone who is new to the genre to understand the concept of interpreters, though, and how to interact with the parser. After all that, cardinal directions may actually be easier to understand!
Sounds very interesting! Do you have this online somewhere?
Spoff, you may want to give Rats in Control a whirl:
No one ever really wants relative directions in actual play.
Over the years, whenever I’ve seen someone who is unfamiliar with IF complain about the counter-intuitiveness of compass directions, what they invariably would rather see is pathfinding – that is, they want to type GO TO THE BRIDGE, and then just automatically go to the bridge from wherever they happen to be.
Which is actually done in a few games. Good to know!
Blue Lacuna isn’t talked about much these days, but it tried very, very hard to offer the best of both worlds. I don’t think it got enough praise for that. Then again, neither did it get panned as a failed experiment, which is what happens more often than not!
Check out the “Regional Travel” and “Permission to Visit” extensions.
There’s also Distant Movement and its ilk, for moving directly to certain rooms. (I’m of course going to mention my own first but they all have different interfaces and feature sets, depending on your preference.)
“Go to [room name]” (with “go through [door name]” for unvisited rooms) is absolutely the gold standard, in my opinion, especially if you allow pathfinding to rooms that are more than one move away. You can still have the compass directions to help folks understand the layout, but unless navigational difficulty is supposed to be part of the story, why not just let people do the thing they want to do without having to recall the abstract instructions for how?
Some other implementations of that interface are how Emily Short implemented it in Bronze and the extra-fancy stuff she did in Counterfeit Monkey (Book 4, Part 3), although both do contain some spoilers for the games.
I don’t know if I like the idea of the player being able to ‘teleport’ directly to the kitchen. Sounds more like an efficient program than a game. I think the spatial navigation in itself lends some solidity to the narratives physical world.
Overworld-navigation in the form of a train, car or teleport is fine, though.
I remember a mechanism from a Short game where the player did not teleport directly to the kitchen. I think it was Bronze. You got a list of all the rooms you went through.
It got to be a bit of a mouthful, but it did prevent that “teleport” effect. Also, some text along the lines of “You leave [location] and soon arrive at…” is usually sufficient.
Finally, the mechanism I think is being talked about really isn’t teleporting, it’s pathfinding. So that if there are obstacles, the player will be halted at that obstacle.
Counterfeit Monkey also had text about how you got from place A to place B. It’s so much nicer than having to type “w.s.sw.u.n.e.n” when you want to get a place seven rooms away (I’m thinking of Metamorphoses, I guess, where I kept hopping back and forth between the puzzle rooms and the rooms with the tools in them, and I eventually started chaining together the navigation commands. Excelsior was another game with a lot of travel between widely separated places and it didn’t even let you chain commands together, though it also had a good excuse for not allowing fast travel.)