prev| toc| next
 

Creating Rooms and Areas (cont'd)

Describing Rooms:

Room descs are a somewhat demanding genre. You need to convey a sharp sense of place in a very brief space. You often need to describe a number of rooms with similar characteristics without becoming repetitive. The description often needs to incorporate cues that geographically orient the player. Since other events online are competing for the reader's attention, your writing needs to be exceptionally clear. The following discussion first covers technical aspects of setting room descs, then offers some editorial suggestions for writing them.

As with any other object, the description of a room can be set with the @desc command. And, as with any other object, you may want to do some hanky-panky with lsedit and MPI to provide formatting (indentation, paragraph breaks, etc.) or flexibility (dynamically generated text describing the time of day, players present, or random events). A desc string bracketted with an MPI {eval} function will cause any MPI in the desc itself to be parsed. The following description of the tavern uses this technique to include the names of present players in the description.

====================================
> @desc here = {eval:{list:maindesc,here}}
  Description set.
> lsedit here = maindesc
  <    Welcome to the list editor. You can get help by entering '.h'    >
  < '.end' will exit and save the list. '.abort' will abort any changes. >
  <    To save changes to the list, and continue editing, use '.save'   >
  > Insert at line 1>
    The tavern is little changed from days when pirate sloops found haven
  in the coves nearby: the beams are still low and smoke-stained, the tables
  still rough-hewn and knife-hacked, the floorboards still trecherously
  uneven. What light there is comes from three flickering oil-lamps and a
  sharp-scented wood fire burning steadily on the hearth. Glasses and
  bottles along the back wall catch and toss the dim, moving light. The
  innkeeper standing easily behind the bar is a grave of secrets.
  {eval:{prop:_folks,here}}
  .end
  < Editor exited. >
  < list saved. >
> @set here=_folks:{if:{commas:{lremove:{contents:here,player},{owner:me}}},
  {commas:{lremove:{contents:here,player},{owner:me}}, and ,item,{name:
  {&item}}} are here\, at various places in the room,Currently\, you're the
  only other one here}.
  Property set.
====================================

If you don't want formatting such as paragraphs or the two-space indentation in the example above, it would be more efficient not to embed the desc in a list

====================================
> @desc here = The tavern is little changed from days when pirate sloops
  found haven in the coves nearby: the beams are still low and smoke-,
  stained, the tables still rough-hewn and knife-hacked, the floorboards
  still trecherously uneven. What light there is comes from three flickering
  oil-lamps and a sharp-scented wood fire burning steadily on the hearth.
  bottles along the back wall catch and toss the dim, moving light. The
  innkeeper standing easily behind the bar is a grave of secrets.
  {eval:{prop:_folks,here}}
  Description set.
====================================

Including queues that indicate looktraps and local commands is a common and helpful convention. A clueful MUCKer would deduce from the following room desc that it's worth taking a look at the innkeeper and sign:

====================================
> @desc here = The tavern is little changed from days when pirate sloops
  found haven in the coves nearby: the beams are still low and smoke-,
  stained, the tables still rough-hewn and knife-hacked, the floorboards
  still trecherously uneven. What light there is comes from three flickering
  oil-lamps and a sharp-scented wood fire burning steadily on the hearth.
  bottles along the back wall catch and toss the dim, moving light. The
  'innkeeper' standing easily behind the bar is a grave of secrets.
  {eval:{prop:_folks,here}} There is a small 'sign' sitting
  on the end of the bar.
  Description set.

> @open ip;is = $nothing ( create a local command )
  Exit opened with number 4808.
  Trying to link....
  Linked to do-nothing.muf(#97)
> @succ ip = {exec:{&cmd}}
  Message set.
> @set ip = ip:{null:{tell:Ishmael {&arga}},{otell:Ishmael {&arg}}}
  Property set.
> @set is = is:{null:{tell:Ishmael growls, "{&arg}"},{otell:Ishmael growls, "{&arg}"}}
  Property set.
> @set is = D   ( set the exit dark, so it won't show up as an obv-exit )

    ( set some looktraps to indicate the presense of local commands )
> @set here=_details/innkeeper:Call him Ishmael. This ancient wolf looks
  old enough to have been on a first name basis with the aforementioned
  pirates. ('look sign')
> @set here=_details/sign:{list:signtext}
  lsedit here = signtext
  <    Welcome to the list editor. You can get help by entering '.h'     >
  < '.end' will exit and save the list. '.abort' will abort any changes. >
  <    To save changes to the list, and continue editing, use '.save'    >
  < Insert at line 1 >

  The innkeeper, Ishmael, is interactive:

    ip <pose> ....... Ishmael <pose>
    is <comment> .... Ishmael growls, "<comment>"

  .end
  < Editor exited. >
  > list saved. >

> l sign

  The innkeeper, Ishmael, is interactive:

    ip <pose> ....... Ishmael <pose>
    is <comment> .... Ishmael growls, "<comment>"

> is What will you have, stranger?
  Ishmael growls, "What will you have, stranger?"
====================================

(Note that we avoided creating a puppet object for Ishmael... the room desc says that he's here, and a named object in the room's contents list is not really necessary for our purposes. Also, the two commands — `ip' and `is' — are created using one exit object, and we could modify the action to provide additional local commands using the multi-action technique discussed in Section 4.2. It is especially worthwhile to follow such dbase-conserving practices when building large areas.)

Some builders feel that the obvious exit list after room descs is intrusive and artificial looking. If you decide not to use an obvious exit list, you should include text in the desc that will tell a careful reader which ways she can go.

====================================
> @desc here = The tavern is little changed from days when pirate sloops
  found haven in the coves nearby: the beams are still low and smoke-,
  stained, the tables still rough-hewn and knife-hacked, the floorboards
  still trecherously uneven. What light there is comes from three flickering
  oil-lamps and a sharp-scented wood fire burning steadily on the hearth.
  bottles along the back wall catch and toss the dim, moving light. The
  innkeeper standing easily behind the bar is a grave of secrets.
  {eval:{prop:_folks,here}} There is a small 'sign' sitting
  on the end of the bar. A sturdy wooden door opens onto a hallway
  to the west; another, at the front of the tavern, opens onto the
  village green.
  Description set.
====================================

Modern graphic workstations can display a huge amount of text, but the standard computer terminal only displays a screen 80 characters wide and 24 lines tall. While standard character terminals may seem obsolete to some, it's worthwhile to respect this `lowest common denominator': a number of people do still access M*'s through standard terminals... either UNIX/Linux computers on which they have chosen not to install or run graphics, or virtual terminals being run from a shell account. Further, the vast majority of these UNIX folks will be using TinyFugue as their client. With TinyFugue's `visual' mode turned on, the bottom four lines are used as a typing window. Additionally, not all clients can display the full width of 80 characters. So, if you want people to be able to see the entire desc in one screen (a good thing to strive for), you should limit descriptions to a 78 x 20 field of text. You can choose to violate this guideline, of course, and often will be justified in doing so... but be aware of the tradeoff you make.

A further `less-is-more' point: a common mistake made by new builders is to create rooms that serve only to provide a way to get from point A to point B. A forest path leading from the stream to the glade, a foyer leading from the street to office lobby, etc. Such rooms (and the extra exits required to link them) seldom earn their keep: they take up extra space in the database, eat up your quota, and make the area feel bland or `loose'. As an alternative, consider setting detailed @succ and @drop messages that convey a sense of travel over a distance. Or, in cases where the effect is still too fast and a greater sense of distance is required, consider writing or using a program that generates a travel event of some sort (one such program is provided here).

prev| toc| top| next