#ROOMS Section

This page describes how to code room descriptions within an area file.
<< Back to #OBJECTS Section Forward to #RESETS Section >>

The #ROOMS section of an area describes the structure, layout and characteristics of rooms.

The #ROOMS section consists of the #ROOMS header, one or more rooms (see below) and the #ROOMS section ender #0 as shown here:


A room looks like this:

room name~
room description
teleport roomflags sectortype
C clanname~
H hitregen M manaregen
O owner~
lockflag keynumber toroomvnum
extended keyword(s)~
extended description

There is an example at the end of this page.

Here's what the (underlined) terms mean:

Each room gets a unique vnum as assigned on your room list. Unlike mobs or objects, each room appears in the game exactly once! Remember to precede the vnum with the hash sign ('#')!

Although the MUD program does not care whether the vnums for rooms are in ascending order and consecutive, your area file will be very difficult to maintain if this is not so. Start with the first vnum you were assigned and number consecutively up to as many as you need for all your rooms.

room name
This is the name of the room. It's all a player sees of a room if he is running around with BRIEF turned on and does not do a LOOK. It's just a name, not a description, so a small number of words should be enough. Remember, it needs to fit on the end of SHORTWHO and other list output.

room description
This text describes the room to a player if he enters it without BRIEF on or does a LOOK there.

This description gives a room its atmosphere and uniqueness. Short, one-line room descriptions should be a rare exception. Normally you want the room description to bring across the feelings you want to inspire in the player as he looks around, to describe the geography, landscape, exits, and the style of furnishing, if any.

Remember that the room description is static. You want it to be valid at all times, no matter what happens to the room. Thus, it is a no-no to include in the room description any mention of mobs standing around there or of objects you plan to reset there. For a living quarters, it would be OK to state that so-and-so lives here, but not to say that so-and-so is here. It's quite possible that so-and-so has been killed and your room description is telling a lie.

It is OK to include references to objects in the room if you make sure those objects stay there (by giving the object a NOPURGE flag and no TAKE flag as described in the #OBJECTS section). A LOOK will reveal the object itself, so you should not say anything redundant like "a fountain is here". You may, however say that "people often come here to drink from the fountain standing here."

Another instance in which objects should be included in a room description is if they are 'truly invisible', i.e. coded with no long description. Popular objects of this 'hide and seek' technique are portals and fixed containers. It is practically impossible for a player to guess at the presence of such objects unless at least a hint is given in the room description. If you want to give a strong hint, you may color the name of the object.

When writing the room description, be aware that players may be intrigued by things (i.e. nouns) they see in the description and may wish to LOOK at these things. You can give them the opportunity to do so by including extended descriptions for some or all of the nouns used in your description. It may help to plan ahead for this.

Normally, you code a 0 (zero) here.

Some rare rooms in the game are teleport rooms. Entering such a room will cause a player to be teleported to another room. If you really want this to happen, you code either:

In addition, the room will only teleport people if the TELEPORT flag is set in the roomflags.
Be aware that an area full of teleports can be very annoying, especially if it is not well thought out, perhaps as a puzzle or such. Also remember that a random teleport can be fatal to a low level character. Random teleports should not be coded into low level areas.

Room flags describe some special characteristics of the room. Take your pick from the Room Flag Table or code a 0 (zero) if your room does not need any of them.

Determines what kind of terrain the room is in. The sector type is used to enhance area realism and controls such things as movement loss when a player walks through rooms of that type. The DIRT KICK skill in particular is influenced by the sector type. The chances are mostly logical with respect to your chance of finding dirt to kick in the given environment. See the Sector Type Table for available sector types and detailed information.
The "Mv Loss" column indicates how much movement is lost by a player moving into or out of a room of this sector type.
The sector type is a single value, not a flag. Thus, you cannot code more than one sector type for any given room!

The clanname line is not normally used in room coding. clanname and its preceding 'C' are optional and only used if you want your room to belong to a given clan. A room coded with a clan name is not accessible to mortal players not in that clan. clanname must exactly match the "mailname" as seen in CLANLIST for the given clan. If a clan mail name happens to be a multi word name, you can use single quotes ( ' ) to hold it together.

The hitregen and manaregen line(s) are not frequently used in normal area coding. hitregen and manaregen and their preceding 'H' and 'M' are optional and only used if you want your room to affect the hit point and/or mana regeneration rate of players in it. A room's description may indicate that it is a particularly quiet and restful room, and then values of hitregen and/or manaregen above the default regeneration rate of 100% will cause players to regenerate more quickly while in the room. Regen rates lower than 100% may be specified to slow down regeneration.
hitregen and manaregen are traditionally specified together on the same line, but it is legal to specify them singly on individual lines as well. Thus,
  H 120 M 130   and   H 120
M 130
are equivalent. The first form takes up a little less space, though.
As the example shows, it's quite OK to have different values for hitregen and manaregen.
It is Dizzy MUD's policy that rooms with regen rates above 100% must be approved by the Imp and will not be approved with rates higher than 150%.
Although the numbers represent percentages, do not write a percent sign ( % ) into the H and M lines!

Rooms coded for or by an individual may optionally have his or her name coded into it. This will prevent other players from walking into that room, and also a few of the magical forms of transporting and otherwise invading the room. Privacy is not ironclad, however, as there are still a few holes in the access control code.
Again, this line is optional. You may either code it, complete with 'O', name and trailing tilde ( ~ ), or leave out the entire line, as is usually done.

The line consisting of directionnumber and its preceding 'D' marks the beginning of what I'll call a room exit. The whole thing consists of all the lines from directionnumber to toroomvnum.
You need to code a (complete) room exit for each of the directions through which it is possible to leave the room. A room connected on all sides would have 6 of these, one each for the directions north, east, south, west, up and down.
The encodes the direction in which this exit leads. must be one of the numbers 0 through 5 to encode one of the directions, as shown here:
0 1 2 3 4 5
north east south west up down
Thus, an exit to the north would be coded as 'D0', an exit going up would be 'D4'.

The exitdesc is what the character sees when he LOOKs in the specified direction using "LOOK NORTH", "LOOK SOUTH", etc. It is possible to code an empty exitdesc by leaving this line out, but please don't! Exit descriptions make an area more alive and interesting. A player can use something other than just SCAN to see where he is going. A player can be hinted as to which direction it would be good to go in. A player can be alerted of danger.
You see a deep ditch before you. You may be able to enter it but it's uncertain whether you would be able to climb back out!
As the exmple shows, an exitdesc can have more than one line, though this is not very common.
Whether you code an exitdesc or not, the next line must consist of a tilde ( ~ ) !

If the exit is a door, gate or other openable obstruction, you should code a doorname for it. Unlike an extkeyword, this name will not work with LOOK. A player cannot LOOK at whatever name you code here; the game will use this name only to respond to UNLOCK, OPEN, CLOSE and LOCK. You may use a multiple word name for a door, e.g. "trap door". Assuming such a door leads downward, the player can either "OPEN DOWN" or "OPEN TRAP" or perhaps "OPEN DOOR" to open it. "OPEN DOOR" is guaranteed to work only if there are no other exits from this room whose doornames are also "door". The door name is also used to give the player his response: "You open the trap door." Thus, the door name should not be a random collection of likely keywords; it needs to be chosen to make sense in the response sentence.
The doorname must be followed by a tilde ( ~ ) ! If there is no doorname, you must still code the tilde (alone on the line).

lockflag specifies how impassable a door is. The possible values are:
 0 No door
 1 Normal door
 2 Pickproof door
 3 Door not passable with PASS DOOR
 4 Door neither passable nor pickable
Note that it doesn't matter how well you secure your door with this flag, the door initially resets in the OPEN position unless you code it CLOSED or LOCKED later on in the #RESETS section!
Also, of course, remember that it makes no sense to code a doorname if you code a 0 (no door) here.

This is the vnum (without the hash ('#') !) of the key, if any, which unlocks this door. If this is no door (lockflag = 0) or you do not want to make a key available to this door, code a -1.

This is the vnum (without the hash ('#') !) of the room to which this exit leads.

extended keyword(s)
extended description
extkeywords, extdesc and the 'E' and tildes around them make up what I call an extended room description. Extended room descriptions are optional; you may have none, one, or as many as you like. I strongly encourage you to code one or more. Extended room descriptions go a long way toward making your rooms interesting and alive.
When a player reads your room description (using LOOK or by walking into the room without BRIEF on), he will hopefully see a detailed description of the contents of the room. He will hopefully become curious about one or more of the objects, er, THINGS he sees in that description. He may then try to LOOK at the things he sees in the description. If you do not code an extended room description for the THING he is looking at, then he will get a response of "You do not see that here." This will quickly stifle his curiosity and his interest in your area for all but the most mundane purposes.
I realize that coding extended room descriptions, perhaps even whole chains of them as described below, is a lot of work. But your area will be more enjoyable if it has a few well done rooms than if it is a sprawling complex of barren, uninteresting equipment and mob dump sites.
The extkeywords should be a list of the words which a player might be temped to LOOK at in your room. A LOOK at any one (or several) of them will cause the game to show him the extdesc which you have coded following the extkeywords.
High-class areas often have chains of extended room descriptions on some rooms. Some of the words in the first extdesc will be found in the second or further extdescs, which can allow you to tell a whole story in one room if the player takes the trouble to follow the clues.
The extdesc must be followed on the next line with a tilde ( ~ ) !
Remember to end each room with an 'S' on a line by itself!

ROOM example

Example Room~
You are standing in the Entrance Hall of the Example House.
The floor is covered in a rich persian rug. A wardrobe stands off
to the side, and doors lead off to the north, south and west
while a corridor leads off to the east.
0 D 0
To the north lies a door leading to the Living Room.
living room door~
1 -1 6902
To the east there is a Corridor.
0 -1 6903
To the south you can leave the Example House.
entrance door~
1 -1 6904
To the west lies a door leading to the Kitchen.
kitchen door~
1 -1 6905
entrance hall~
You are standing in the middle of the Entrance Hall. Have a look to
see your surroundings.
house example~
Well, you are inside of the Example House, so you don't see much of it
but for the room you are standing in at the moment.
rug persian~
Your feet sink deeply into the rug. It seems to emanate an air of affluence.
The wardrobe is not very big, but it looks to be a genuine antique.
A spacious corridor leads to some more rooms in the east.
The door to the north is the living room door, that to the south is
the entrance door, and the west one leads to the kitchen.

<< Back to #OBJECTS Section Forward to #RESETS Section >>

  This page was last updated May 15, 2001