the well described room: how to build a room with the #854 parent

Acknowledgements

This tutorial describes a generic that is available on RiverMOO, which is located at rivermoo.com port 8888. The specific syntax of some of the verbs is specific to the object #854 at RiverMOO, but the general concepts will apply to the generic seated secure room with integrated details which is available at most MOOs. You'll have to @examine the room and read the help for it to adapt some of the instructions to a different generic on another MOO. Seats, details and integration are pretty common MOO-technology, but the actual syntax of verbs to create them varies slightly from MOO to MOO.
The room generic #854 was programmed by Defender on RiverMOO and is a child of the basic $room object. The exit generic #855 and door exit generic #1855 were programmed by Jedi-Knight on RiverMOO and both are children of the root object.
The author of this tutorial is Lelandra on RiverMOO, EdenMOO and ElderMOO.

bar

Introduction

In this tutorial, we'll build a typical hotel room, as that is something we're all probably familiar with. I should hope that by the time we're through, you can build an area with a little more imagination, whether it be a glittering crystal cave, a treehouse, a burbling brook, or quarters on a space station. Our example room need not contain any additional objects simply to provide atmosphere - merely by taking good advantage of messages, details, and seats you can create a room with a surprising amount of interactive potential.

bar

Digging the Room and Setting its Parent

The first step is to make an empty room out in limbo. You need to think of a name that describes what the room is, ideally one that is both tantalizing and unique. Our demonstration room isn't very tantalizing - we'll just call it "Rutherford Inn Economy Suite". We're putting quotes around the room name because it contains space characters.

@dig "Rutherford Inn Economy Suite"

When you type in the above command, a generic empty room will be created, and you'll be told the OBJECT NUMBER for the new room. It's a good idea to write it down so you can go visit it later. However, if you forget the object number you can just audit yourself and you'll see it listed in the things you own:

@audit me

The next thing you should do is teleport your character to the new room. This will allow you to use the word "here" rather than needing to type in the object number in the commands to the MOO. If you want to detail your room remotely (from inside a different room), everytime you see the word "here" put in the object number instead. We'll assume that the MOO assigned the object number 9999 to the new room; you should fill in the number of the room actually assigned instead:

@go #9999

MOOs are object oriented. This means that everything is an object - your character is an object, this room is an object. All objects are created from parent objects and inherit characteristics from the parent objects. When you @dig, a generic room is created - this has very few automatic characteristics, and you'll want to make your room the child of a parent object with more automatic characteristics. This is done with the @chparent command. Generic room #854 provides many of the commands we'll be using to detail our room, so to follow along you need to have #854 or one of its children as the parent object.

@chparent here to #854

If you decide you always want to have #854 as the parent of the rooms you dig, set your build-option to use it. Once you've set the build-option, every room you dig will automatically have #854 as a parent, and you won't need to issue the command @chparent here to #854.

@build-option dig_room=#854

As long as you are setting @build-options, you can go ahead and set the option for the accompanying exit for this room. We'll make use of this later on in the tutorial.

@build-option dig_exit=#855

bar

Describing the Room

Now let's put in the description that anyone who enters the room sees automatically. This is the most important and most difficult part of building your room. If the description is boring, people probably won't stay long enough to look at the details, sit in the seats or play with the verbs. Yet it should only be about a paragraph in length (6-8 lines or so). You really need to tease your readers into wanting to look around at things more closely - don't give away the entire description at once.

Try to make every word in the description work to both describe what the thing IS and allude to its personality. Think about the personality you are trying to convey - is it ominous? nostalgic? luxurious? playful? Spend some time with a thesaurus to collect the nouns and verbs that convey that kind of personality. Try to find evocative nouns and verbs rather than piling on adjectives and adverbs. This is a far more effective technique than using statements that bludgeon the reader with instructions telling them how they feel in the room, such as 'You feel very uneasy here.' I never feel uneasy in the room when it contains such a phrase - though I do feel disappointed in the writer.

A good description is lyrical. It uses interesting words, avoids cliches, and despises categorical statements. A good description will describe a forest by describing the trees reaching heavenward, the wildflowers perfuming the air and carpeting the understory, the babbling brook splashing over stones and gleaming like crystal instead of stating 'You see a forest'.

A good description provides something for more than one sense rather than just describing how something looks. How does it smell? Can you hear any interesting background noises? What is the quality of the light? Is it cold or hot, dry or clammy? Make use of colors, but use their full power. "Blue" is boring: is it pale blue like a prairie sky on a winter day, or maybe an electric blue like that at the base of a candle flame. Colors indicate fashion and can suggest a lot about the personality of a place - think about the difference between your reaction to the pairings of avocado green and orange or mauve and gray or turquoise and carnation.

Separate the mechanics of the room from the description of the room. If you've programmed some interactive verbs that you want to tell players about, set the help_msg for the room with instructions for their use. Or modify the verb :enterfunc to tell the player just when they come in. Or make a detail, such as a plaque, that has the necessary information.

Correct your spelling and grammar. Spelling errors are terribly discordant. An extra five minutes with a dictionary looking up the spelling of unfamiliar words will prevent the discordant shock of seeing a description of 'tappestries' in a room that would otherwise succeed in transporting the reader into your own personal vision of a place. The same is true of grammatical errors. Every MOO I've visited is full of rooms that misuse its/it's and there/their/they're. Remember: the only time there is an apostrophe between 'it' and 's' is when 'it's' is short for 'it is'. When you are using 'it' in the possessive sense, there is no apostrophe: 'its'. Furthermore, 'their' is always spelled with 'e' before 'i', and is only used when you are talking about something that 'they' possess. 'There' is a word referring to a location, and 'they're' is short for 'they are'.

Rutherford Inn is a downtown hotel that is starting to fall on hard times. The ownership still cares about providing a high quality stay, but hasn't had the funds to redecorate the rooms lately. It is also reasonably apparent that the ownership's aesthetic sense was never really the epitome of refinement...

@describe here as "A faint scent of Pine Sol burns at your nostrils, while your eyes are accosted by the burnt orange draperies depicting peacocks strutting among eastern temples. Small pools of light from imitation stained glass sconces play across the surface of a Moorish facade bureau brooding across from the double bed. A threadbare coverlet in loud apricot and spruce green stripes gladdens the room.

That's really enough to let your reader's imagination take it from there. They've probably seen similar examples of 70's fake ethnic decor and their mind's eye can better supply the combined horror and comfort of the visage than any excess of prose you supply. Don't worry - you'll have plenty of opportunity to describe what else is in the room when you add details, thus rewarding the attentive explorer with more tiny bursts of description.

You'll notice I didn't describe the room as "a hotel room in horrible 70's fake ethnic decor" - I let the color scheme, the suggestions of age, the imitation sconces supply the category of what we were looking at. The management's attentiveness to cleanliness was suggested by the Pine Sol which you can still smell (and subliminally echoed by the "spruce" green - spruce is a synonym for "neat", as well as being a kind of evergreen). Horror and comfort were alluded to with 'accosted', 'brooding', and 'gladdens'. You'll note that nowhere did I waste space by using a form of the verb 'to be'. Every verb in the description carries its weight.

Now that we've got the wording down, let's make sure the formatting is set to make this as readable as we possibly can. Two things should be addressed: spacing and word-wrap. Readability will be improved if there is spacing before and after the paragraph of description. The space between the title and the description could take the form of a blank line, use of hyphen characters to underline the title, or 80 characters of various ASCII characters, combined decoratively (such as %%%%%%%%% or ^*^*^*^*^*). Since not everyone has the same line length on the MOO, it will look better if you don't force line breaks, but join all the lines in a paragraph into one line. We'll pretend that the description got typed in as 5 separate lines. We'll add the spacing lines by inserting a blank line at the beginning and end of the description (before line 1 and after line 6), then join lines 2,3,4,5,6 into one line.

@edit here.description
ins 1
"
ins 7
"
join 2-6
save
quit

bar

Adding Details to the Room

Make a little map of your room on paper. Figure out what's in the room and how everything relates to everything else. In our room, we'll assume that the entrance from the hall is at one end, and that's where the person stands when they first enter the room. The smell of Pine Sol is coming from the bath, which is to our reader's right. The drapes that caught our eye must be right across the room, so that's where the window is. Hotel rooms generally have a table and two chairs in front of the window. We could see the bureau when we started to turn to figure out where the smell was coming from. Usually there's a TV sitting on the bureau. That means that the headboard of the bed must be on the opposite wall. Above is simply the ceiling, and below is the floor. That's enough to go on, so we'll add our first details.

@detail bureau,dresser is "You see a television perched atop a massive dark veneer bureau.

@detail is what the person in the room will see if they LOOK BUREAU. Note that I have given the detail two names, with no spaces between the names. This will increase the chances that players hit on the name you chose to use for the detail when they are looking at details. Also, any time you use compass directions, you should alias both versions of the direction name (e.g. "north,n").

Remember that bathroom? Unless you wish to burn quota actually building the bathroom as a separate room, you can simply suggest its presence with details. If you aren't planning to actually spend time in a room, and it's not the sort of room other players would want to spend time in, use a detail instead of building the room.

@detail bathroom,bath,pine sol is "Through the open door you can see a sparkling expanse of harvest gold tile. Towels are stacked on a glass shelf above the stool. A small basket of soaps and shampoos has been left by the sink.

We'll not belabor the point here, but the same efforts are put into filling in the rest of the details. If it was important enough to mention in the description, you should make a detail for it. For up and down, include likely synonyms:

@detail up,u,ceiling is "You see white acoustic tile that has grown yellow over time.

@detail down,d,floor,rug,carpet is "You see a brown textured shag carpet that is compacted by years of heavy use.

Now that you've finished describing the main details, you can describe some of the things found in the room. Make a list of some of the more prominent objects that you might not have mentioned in the main description. You of course have the bed, the chairs, the table, the nightstand. Perhaps there's a telephone that the reader will only find out about if they look at the nightstand. You might have something else to describe about the bureau or the television. Maybe there's a horrible starving-artist painting on the east wall.

Save your quota by creating details instead of creating objects that don't actually DO anything. If you only want to have an item in the room, but it won't have any verbs on it, use a detail instead.

@detail television,tv is "You see an old behemoth of a set from the days prior to remote control.

For all the other detail commands for room parent #854 you should not type in the list of all of the aliases. In the example of the bureau, it has the aliases bureau and dresser. Let's take a look at the other detail commands.

If you want to add more text to a detail, use the command @moredetail. Whatever you type will be appended to the existing detail.

@moredetail bureau is "The surface is spotted by a few ancient cigarette burns.

You can not only look at a detail, you can smell it, touch it, listen to it, display a message to the room when someone looks at it (the olook_msg), or include a phrase about it in the description of the room (the look_msg). Let's fully detail the television to show how this is done:

@detail/smell television is "The television smells musty.
@detail/touch television is "An arc of static electricity shocks you.
@detail/listen television is "The sound is fuzzy and tinny... which seems appropriate given the old Johnny Carson rerun that's playing.
@detail/look_msg television is "The television blaring on the bureau dispels the quiet. @detail/olook_msg television is "%N studies the television intently.

The %N in the olook message will be replaced with the player's name who looks at the detail. Therefore, if Sluggo types 'look tv', he will see 'You see an old behemoth of a set from the days prior to remote control.' Everyone else in the room with Sluggo will see 'Sluggo studies the television intently.'

If you decide you want to get rid of a detail, use the command @rmdetail.

@rmdetail television

To see a list of all the details defined on the room, use the command @details. There are no permissions on running this command. You can use @details in any room that has #854 as a parent, no matter who owns the room.

@details

bar

Integration and Other Room Options

To make your fellow players look at details to find the interesting objects you've planted in your room, define look_msgs on the objects and turn on detail integration. Let's say you have a Gideon Bible object that has several interesting verbs built onto it.

@create $thing called bible,Gideon Bible

If you drop the bible, and look, you'll see the message "You see bible here." appended to the end of the room's description. That's pretty boring, so let's improve it by setting the look_msg.

@property bible.look_msg "A tattered Gideon Bible sits forlornly on the nightstand.

Now set the room option for integration on.

@room-option +integrate

Now when you look at the room, you'll see the message "A tattered Gideon Bible sits forlornly on the nightstand." instead of "You see bible here." at the end of the room's description.

The following information will help you with a few tweaks you can perform on integration. If you want the text in the look_msg to be added to the last line of the room's description instead of at the very bottom of the description, turn on the i_lastline option:

@room-option +i_lastline

You can turn any room option off by using a minus sign instead of a plus sign:

@room-option -i_lastline

If you'd rather have the look_msg information appear with the list of people sitting down, rather than having it in the room description, use the i_sitters room option:

@room-option +i_sitters

If both i_lastline and i_sitters are turned on, the integration text will be added to the last line of the list of sitters rather than appended to the very bottom.

If you want to prevent including the look_msg of player objects (who have look_msg defined), use the i_noplayers room option:

@room-option +i_noplayers

You can also customize the amount of space appearing between the description itself and the look_msg. By default it's three spaces. You can change it:

@int_sep here is " "

Finally, if you want to limit the number of players who can crowd into the room at one time, you can set the room's capacity. To set the capacity to four players (disconnected players not yet removed by the housekeeper are included in the count):

@capacity 4

To reset the room's capacity back to unlimited:

@capacity unlimited

bar

Seats

I like to make sure I've provided a seat for anything I mention in my room's description that people would sit on, sit in, lean on, or lay down on in real life. In this case I'd add seats for the chairs, bed, and leaning against the bureau. Use your imagination. Seats give you a programming-free way to add interactivity to a room. Every room can benefit from having seats defined, especially if the messages are set creatively.

To describe a seat, simply use the @addseat command. It will prompt you through adding all of the messages displayed.

@addseat chair

The script will ask you for the capacity (the number of players who can use the seat at the same time. You could say 'none' for unlimited capacity)

2

Next it will ask you for the sit message, the message shown to players when they sit down in the seat. You can reset it later with the command @sit chair is "whatever".

You sit down in one of the chairs. The acrylic upholstery feels scratchy against your skin.

It will ask you for the osit message next. This is the message shown to everyone else in the room when the player sits down in the chair. You can use pronoun substitution for this message.

%N sits down in one of the chairs, recoiling slightly from the touch of its upholstery.

Then it will ask for the stand message, the message shown to players when they stand up.

You get up from the chair. It's a bit of a struggle as the springs are going.

Then it asks for the ostand message which is shown to everyone else when a player stands up.

%N struggles up out of the chair.

Next you need to supply the sitting message, which people see when they look at the room and someone is sitting down in this seat. You need to be a little careful with this message if the capacity of the seat is larger than one, as it should make equal sense if there's one sitter and one empty chair, or two sitters. You should use %n where a player's name would be, and <is/are> for the verb. Don't forget that "you" will get the "are" verb.

%N <is/are> sitting in a plaid upholstered chair.

The script is nice enough to automatically give you a chance to fill in the detail for the seat, the description shown when someone looks at the seat.

A pair of brown and gold plaid upholstered hotel chairs.

Now, the script asks if you want this to be a private seat. Answer yes if you want things said or emoted in this seat to be heard only by other players sitting in the same seat.

no

Finally, the script asks if you want a message appended to the title and who display when someone sits in the seat. Answer yes if you want the room's title modified in this way. Be aware that the message will be 'sitting on the' seatname.

no

That's it. The seat is added. If you need to go back and change something, you can use @editseat or you can just change one message (@sit, @osit, @stand, @ostand, @sitting).

If you want to remove a seat, use @rmseat seatname.

To get a list of the seats defined in the room, use the command @seats.

To use a seat, a person will SIT SEATNAME. To get up from the seat, a person will STAND.

Finally, you should set the standing and sleeping messages. The standing message is the list of players in the room who are not sitting on a seat which will be displayed with the list of sitters. It defaults to 'name name and name are here.' The sleeping message is displayed for disconnected players who are not in a seat and who have not been removed to their home room by the housekeeper.

@standing here is "%N <is/are> standing by the window."

@sleeping here is "%N <is/are> sacked out on the floor."

In the case of rooms where there are going to be a large number of people, you can use a room option to put the standing and sleeping people in a different paragraph from the sitting people. To do this, set the following room option.

@room-option +separate_seats

bar

Exits and Virtual Exits

To connect your room to another room on the MOO you need to dig an exit. If you want to go to the other room and come back to the room you started in, you need to dig TWO exits. You can dig either a regular exit, which is an object in its own right, or a virtual exit which is more limited in how it can be customized, but consumes less quota. If you want to dig an exit to a room you don't own, the owner will need to issue a command to make the exit work. In the meantime, though, you can do all the customization you want on the exit.

Let's assume you want to make an exit to room #8888 (a parking lot) called "window". While in the hotel room, issue the command:

@dig window to #8888

If you want to dig both exits, such as from the hotel room to a hallway, and a hallway to the hotel room, you can instead @dig hallway|suite to #7777. To make a virtual exit, @vdig hallway|suite to #7777.

The output of that command will tell you the object number(s) of your exit(s), and may inform you that the other room's owner needs to add a legal entrance for you. Let's change the parent of this exit to a more featureful parent than the generic exit, the $DC_exit. For the $DC_exit, it's very important that you use the convert command and not @chparent. If you set your build option for dig_exit at the beginning of the tutorial, the exit will automatically have the $DC_exit as its parent, and you won't need to convert it.

convert window to $DC_exit

First, you should describe the exit. (You can only describe a real exit, not a virtual one. If you make a virtual exit, you should also make a detail with the same aliases as the exit name which provides the description.) You could simply describe what the window looks like:

@describe window as "The window is sparkling clean.

But you should be able to look through a window, especially if it's clean.

@describe window as "Through the sparkling clean window, you can see %w in the parkling lot below.

The %w in the description will be replaced with a list of players in room #8888. You can also use %c to see a list of the contents in the other room. You can use %l to see the complete description of the other room. If no players are present in the other room, %w will show the @no_one message (which is by default "no one"). If no players or objects are present in the other room, %c will be replaced with the @nothing message, which defaults to "nothing". These tricks are only available with the $DC_exit (#855) or $DC_door (#1855), not with the generic #7 exit or with a virtual exit.

On this exit parent (but not the generic or virtual kind) you can also use %<source> instead of typing the origin room's name, and %<dest> instead of the destination room's name. This makes for less updating if a room should change its name in the future.

If you use a virtual exit rather than a real exit, you should still describe the exit. You won't be able to @describe the exit, but you can make a detail for it. A person who loooks at an exit should not receive the response "You see nothing special."

There are six basic exit messages that you can set. The $DC_exit also has @smell, @osmell, @feel, @ofeel, @taste, @otaste, @listen, @olisten, and @olook. The $DC_door, an openable and closeable door exit, has a number of messages relating to the door as well. Type @messages #855 and @messages #1855 to see the list of messages available on each exit type. For the purposes of this tutorial, we'll just set the basic messages. As a user interface consideration, you should always at minimum set the oleave and oarrive messages to make it clear where a player is coming from or leaving to.

@leave window is "You climb through the window."
@oleave window is "%N climbs out the window."
@arrive window is "You fall with a splat onto the asphalt parking lot."
@oarrive window is "%N has arrived in the form of a grease spot from a window high above here."
@nogo window is "You're much too large to fit through the window."
@onogo window is "%N tries to squish through the window and fails."

If you use the $DC_exit or $DC_door, between the display of @leave and @arrive, you can optionally show the player a list of additional messages that describe the trip. To do this @edit window.travel_msgs and add each message on a separate line. For example:

You start to realize that this may not have been such a good idea.

By default this message will be shown 5 seconds after the @leave message, and 5 seconds before the @arrive message (making it a more than 10 second trip). You can change the number of seconds it takes by setting travel_delay:

@set window.travel_delay to 3

You should also set a look_msg that will be integrated into the room's description. With a generic exit, you'll need to add the property. With the $DC_exit, just use @look window is "whatever". With a virtual exit, set a look_msg on the detail you made for the exit: @detail/look_msg window is "whatever". If you don't set a look message, any players who have @ways off may never know that there's an exit here.

@property window.look_msg "The window offers the pleasant view of a parking lot."

It is also possible to add a property to an exit that will prevent it from showing up in the list of available exits or displaying its look message. To make a hidden exit like this, simply set the obvious property to 0 (zero). There is no way to hide a virtual exit.

@property window.obvious 0

bar

Exit Display Options in the #854 room parent

You may want to go back and revisit integration a little bit from the details section. A big part of the user interface of a room is controlled by three @room-options settings: integrate, tell_exits, and i_exits. On RiverMOO, for rooms using the #854 parent, players can make their preference for these three settings override the room builders'. Players who always want to see a list of obvious exits after the description can issue the command @ways on. Players who never want to see that list can @ways off. For players who haven't set a preference, you can set the tell_exits option. Set it to plus to show the list, set it to minus to hide the list.

@room-options +tell_exits

Players who set a property on their character object called integrate will override your room-options integrate setting. Players who never want to see look messages, but just a raw list of object names can @set me.integrate to 0. On a slightly less drastic note, you can integrate everything but exit look messages in the description.

@room-options +i_exits

In this case, players who @set me.i_exits to 1 will never see exit look messages when they look at rooms that are children of #854.

Believe it or not, there is still quite a lot that you can do to tinker with the settings on this room. Some of the topics that this tutorial has not covered include noises, connected outdoor rooms (where sound travels between two rooms), security, room morphing, and the computer. If you are interested in these topics, you should read the on-line help for the DC_room. Type help dc-topics for a list of general topics and help dc-index for help on specific settings whenever you are inside any room which is a child of #854.

bar

Copyright © 1994-1999 Joan Schraith Cole.
Updated February 12, 1999

Environmental Graphics from Ann-S-Thesia CD