World Overview

The world file describes the room and links it to other rooms.  It shapes what the players see of the world itself.  Customarily at Elite, zones are parceled into 100 room blocks starting from 00 and running to 99.   If a zone needs more than 100 rooms, the zone number will remain the same, but the first part of the room number will not reflect the zone number.

For example, Tynstri is 200 rooms, starting with 6600 and ending with 6799.  It is all still in zone 66.  This means there is just one zone file, and the zone number in every room in the zone is 66, even for those rooms whose room number begins with 67.  If this doesn't make a lot of sense yet, don't worry.  There are very few zones over 100 rooms, and if you are writing one it will become clear long before you get to your 101st room!

A room
             
#<Room Number>
<Room Name>~
<Room Description> 
~
<zone #> <room flags> <terrain>
[<Exits>]{0-6 possible}
[<Extra descriptions>] {0+ possible}
>room proc (if any)~

Room proc message ~ S                      {End of Record Mark}

     Each of these fields have their own formats as described below:

Room Number (VNUM)

Format:  #<number><cr >

This is the room's unique identifying number.  The first room in a zone normally ends in "00".  For example in zone 3, the first room would be 300.   The rooms must appear in the file in numeric order, but there may be gaps.  If you are missing room number 310, for example, the zone will still load and function normally.

 

Room Name ~

Format:  <name>~

This is the name of the room and should be descriptive! It is all that is seen when:

a player has toggled "brief"
a player types "cast "locate object" pcorpse
an immortal types " rlist < start room> <end room>"

 

It should begin with a capital letter and end with a tilde (~) .  You may choose to capitalize all the important words ... or not!

 

Roolz for Room Names

Room names are capitalized and uncolored.
Do not end with punctuation
The room name should summarize the room itself. 
Several rooms can have the same name if they are part of a grouped area or maze, but generally should have slightly different names to make the player feel they have moved.
Keep it short and sweet (under 72 characters)
donkey.wmf (5078 bytes)

Room Description

Format:  <3 space indentation><3 lines of description><cr>~

(Note:  <cr> stands for "carriage return" and just means you hit the enter key right there.)

When you walk into a room or type "look" when you are in a room, this is what you see.  It should give you a feeling that you are actually IN the room, and shouldn't assume that you came into the room from any particular direction.  You should descrbe obvious exits to the room.

Guidelines and Standards for Room Descriptions

The room description must begin with a 3 space indentation and be at least 3 lines long.  Follow it with a tilde (~ ) on a line by itself. 
Use color sparingly.
Stick to a medieval way of describing what a player sees in a room.  All items should be from a fantasy story, not something contemporary or science fiction.  There are no guns, but maybe you might find an arquebus.  No bathrooms, but privies and chamber pots. The description sets the stage for the action.  Your role is to help the player visualize the room.
Describe what a character sees REGARDLESS of where they entered or are pointed. Use compass directions (East, west, south, north) instead of pointing directions (left, right, ahead, behind).
Extra descriptions help focus attention to things that may or may not be important.   Use them!
Do not refer to mobs or items in the description or room name as the mob might be dead, or charmed and following someone else.  An item might be taken or sacrificed.  It is okay to refer to a mob in the description as if they aren't here, like "the long wooden bar is where the bartender serves drinks when he is on duty."
don't make a hard reference to time related events, such as weather, moon or sunrise, seasons, etc.
Don't refer to special Elite landmarks as within sight.  They may move or be removed, or your zone may go in somewhere other than where you expect.
Do not use directions (north, south, up, etc) as keywords for extra descriptions.   The mud will check the direction instead of the extra description..     
If you want to hide mob from scouting, you need to have ups and downs (stairs, ladders, etc) to block players with scout.
Death Traps
Death Traps (DTs) don't always give time to be read, so make them short and sweet, but let the player know why they died there.
Do not overuse death traps.
When making a DT (deathtrap -- a room with a death flag) make exits back to the rooms that lead to it... so people in those rooms can hear the scream.
Make a DT room light, so the title shows up, making it look innocent.
You can track through a Death trap.  If you want to prevent players from auto-tracking a mob, you can put a DT in the path ... or you can put the mob in a room marked no_track.

Zone Number

This is the 2 or 3 digit number that the mud will use to refer to all the rooms in your zone.  If your zone is 100 rooms or less, this is the number you were given when you began writing.  If your zone is more than 100 rooms, this is the lowest number you were given.

Room Flags

These are a series of letters give the room special characteristics.  This, for example, is the way we create a death trap.  Not all of the flags listed below have been implemented.  As with other tables you will find in the guide, options which do not work or should not be chosen for some other reason have been marked with pale yellow.

 

Room Flags
Name code Notes
Dark a Can't see without light.
Death b Death Trap.  You enter.  You die.
No mob c No mob chooses to enter unless they are tracking down someone who attacked them (!).  If they do enter when tracking a player, they lose the track.
Indoors d No outdoor msg effects
Lawfull (sic ) e No steal/aggressing/summon , like temple.  Charm does work, though
Neutral f To be defined
Chaotic g Leave random exit regardless of direction.  Annoying, but it can make a small area seem huge.
No magic h No spells castable in room
Tunnel i To be defined: One person in at a time
Private j If 2+ people in no scry or magical entry.  (You can walk in but you can't trans in.  You also can't tell to someone in a private room ...)
Godroom k No mortal entry wo/transing, no track through
BFS mark l Not defined:Breath for sec mark (holdbreath)
Zero Mana m Removes all mana & puts player to sleep
Dispell (sic) n Removes noninnate player affects
Silent  o  Only qs,  say, wizline work in here
In Air p  In air movement only (fly)
OCS q INTERNAL ONLY:Changed in OCS mark
PKOK r PK allowed in the room wo/KILLER Flag.  Room is also no-summon
Arena s Not defined: No penalty fighting
Regen t Faster HP growth
No teleport u No random teleporting into
No Scry v (not working) Can't see in by spell/skill.  Scout will not allow you to see into this room.
No Flee w Not working:Can't wimp/flee in room
Damage x Lose a token set of hitpoints while in room
No Track y No track.  You can't track anything FROM this room, and anyone tracking something from outside this room will not be "routed" through this room.
NoSweep z NoSweep. Objects left lying on the ground in this room will remain on the ground.
NoScout A Can't scout into the room
NoSleep B Can't sleep in the room
NoSummon C Can't summon mob or player from room
NoQuit D Player can not quit in the room
NoDrop E Player can not drop item in room

Terrain (Sector type)

The terrain, or sector type, tells the mud how many moves it should cost the player to move in the room.  It is much more difficult to climb up a mountain than it is to walk across your room, and this is the mud's way to reflect that effort.  Some types of terrain require special skills, for example climbing, swimming, or under water breathing.  Remember, though, that a player who is flying does not need to be able to climb or swim.

0 Inside No movement cost
1 City Inside a town, village, city
2 Field Fields, scrub, caves
3 Forest Woods, jungle
4 Hills Rough caves, canyons, hard terrain
5 Mountain Climbing skill or flight required
6 Water_swim Swimming skill or boat (or flight) required
7 Water_noswim Boat required (Note: I don't think this works yet)
8 Underwater Dive skill (Not yet implemented) or underwater breathing (semi-implemented) required. If you don't have them, you take token drowning damage while here.
9 Air Flight required
10 Void Don't code
11 Desert Costs an extra thirst point while here
12 Frozen Waste Effects uncertain. Like field but with cold damage/slipping
13 Frozen Mountains Effects uncertain. Like mountains, but with cold damage/slipping
14 Frozen Underwater Dive or U/W breath required. Plus damage from cold.
15 Frozen Ocean Cold damage as above, boat required.

 

Exits

D<
direction>
<Exit description>
~
<door keywords>
~
<door flag> <key VNUM> <exit room>
D3
Through the bars of the gate, you can see the splendors of Rome.
~
gate gates
~
1 -1 12011

This exit has an unlocked gate leading west into Rome.

Direction Codes:

0 North
1 East
2 South
3 West
4 Up
5 Down

Exit Description

The exit description is what is shown when the the player looks that direction, i.e., look <direction>, like, look north.

Door Keywords

This is another "alias list".  You will see many of these throughout the file.  It is a short list of words that the player can use to interact with something (a door, in this case).  The player will use one of these words to open, close, lock, bash, pick , and unlock a door.  The first alias is the one the mud will use when responding to a player.  In the example below, if a player enters:  Open oak   the mud will respond with You open the door.   Alias lists always end with a tilde (~ ).

door oak~ 

If more than one door leads off from a room, give each a different alias.  If you have exits leading north and east, each with a door and each using the alias "door", the mud will always assume you are referring to the door to the north, and the player will have to use door+direction to open/close/unlock the door to the east.

WB00700_.gif (2148 bytes) Key names: Be sure not to name the doors and the keys with the same aliases.  For example, if you have a large iron gate with the door keywords "iron gate", you must not use the keywords "iron" or "gate" to describe the key.  Otherwise you will get the message back from the mud "You can't open that!" (because, of course you can't open a key).

Door Flag     

The door flag is coded as a bitvector.  This means that there are many possible values, and you choose the number(s) associated with the value(s) you want, and add them up.  There are several examples below.

Number Value
0 There is no door.  This would be the normal case in open terrain or for an archway or other unrestricted exit.  All other choices below require doors!
1 There is a door (gate, window, etc) that can be opened and closed.. 
2 Closed.  This is actually controlled in the zone file, and I'm not sure it has any real meaning here.
4 Locked.  Requires you to also code 1.  A code of 1 (door) +2 (closed) + 4 (locked), with the proper zone file coding, results in a door that is closed and locked when the zone resets.
8 Unused?
16 Unused?
32 Pickproof.  Requires you to also code 1, and it doesn't make sense without 4.
64 Trap, part 1.  Traps do not require doors to go off.  They have a 40% chance of going off any time a player walks through them, and they cause random loss of hp to the player, from 1 to 10% of the player's maximum hitpoints.
128 Unused?
256 Bashproof.  Requires you to also code 1 (so it's a door).
512 Unused?
1024 Unused?
2048 Trap, part 2.  (see Trap, part 1)

Please see the example .wld file for examples of these codes in use.

The initial state of all doors is open, but doors can be opened, closed, and locked automatically when zones reset (see the zone file documentation for details).

Key Vnum

The virtual number of the key required to lock and unlock the door in the direction given.  A value of -1 means that there is no keyhole; i.e., no key will open this door.  If the Door Flag for this door is 0, the Key Number is ignored.  The key virtual number (VNUM) is the same as the key's virtual number that unlocks this door.  If there is no door, use -1 for this value.

Exit Room

The vnum of the room that this exit leads you to.  If this number is -1, the exit will not actually lead anywhere.  This is a sneaky way to get the exit to show up on 'exits', or to add a description for 'look <direction>' without actually adding an exit in that direction.  The mud will not check for how " logical" your exit is, so you can also code the room to exit back into itself.

Extra descriptions

are used to make rooms more interesting, and make them more interactive.  Extra descriptions are accessed by players when they type " look < thing>", where <thing> is any word you choose.   For example, you might write a room description which includes the tantalizing sentence, "The wall looks strangely soft."  Using extra descriptions, players could then see additional detail by typing "look wall".  There can be a large number of Extra Descriptions in each room.

E
<keyword list>~
<description>
~
E
table oak~
A large shining oak table sits squarely in the middle of the room.  It looks like there may be some papers on it.
~
E
papers~
Upon closer inspection, you see a map.  Perhaps it is a treasure map!
~

Keyword list

This is the same concept that you will see used throughout the mud to provide a word for players to use to interact with a mob, an object or a room.  It is an alias list.   It should be fairly obvious from the room description, or the player will never discover it.

Extra descriptions are wonderful for describing things seen in the room's description which don't need an actual object in the room.  Examples are for pictures, signs, notes, special furniture pieces, and people who are there (if you don't want the people to be killed by players) .  This is a good way to hint at hidden exits, such as a fireplace that opens.

Description

The text that will be displayed when a player types "look <keyword>".

Room procs

We now have special procedures that you can attach to rooms to added some extra versatility. Currently, we have only three available - %trans, %echo and %push, however, helm has coded these in such a way that we can add more procedures as and when we need them. They are added to the .wld file -after- the room Extra descriptions, before the end of record mark ("S"). The exact syntax varies for each one:

%trans This allows you to have a certain percentage chance that instead of leaving a room by the normal exits, a player will be transferred to another location of your choice. You can specify a message to display on the players screen in order to explain the sudden change in location. For example, in a maze, you could have a 5% chance that the player will find a shortcut to the centre, or discover a hidden treasure room, or a sudden death trap!. There are two different trans_procs, which trigger in slightly different circumstances. These are coded as follows:-

>trans <percent chance> <destination room vnum> <direction>~
message to player
~

The MUD will check the trans proc whenever a person attempts to -leave- the room in the given direction (0 - north, 1 - east etc as for doors). Putting -1 for the direction tells the mud to check when a person attempts to leave by -any- exit.

>ttrans <percent chance> <destination room vnum>~
message to player
~

The mud will check the % chance on a zone pulse (about 10 seconds).

%echo The %echo_proc allows you to add atmosphere to a room, by sending descriptive messages to players. The mud checks approximately six times per tick (every zone pulse) whether the %echo_proc triggers, you can add as many as you like to each room, but be wary of adding too many!

>echo <percent chance> ~
message to player
~

%push The %push_proc is checked on a zone pulse, like %echo. When triggered, it pushes all players within the room in a specified direction. This can be used to make rooms 'flow' The direction is entered as a value in the same way as exits are written. ie. O for north, 1 for east etc. Just make sure there is a exit that way or else the push-proc will fail.

>push <percent chance> <direction>~
message to player
~

>pushall <percent chance> <direction>~
message to player
~

The pushall proc will push players -and- mobs in the specified direction.

Glob : Special notes on room progs.
# If using multiple room progs in the same room the TRANS must be written first in the .wld file or the other progs will not be executed.
# The mud will have the in the .wld file listed room progs in reversed order, so if you want to split a exit into two using TRANS to randomize if the player goes to either of the rooms, the .wld file must have the 100% chance before the 50% chance, as the example below shows.
# The mud does not care about other hinders when transing or pushing people around. So if you PushAll into a NoMob room the mobs will come too. Push into DTs works well too.

 

Example of a room

#2300 
First Room~
   Snazzy descriptions are all well and good, but it is so much nicer
to just have the room say what is needed.  This doesn't mean your
rooms should be poorly written, however. 
~
23 cd 1 
D2
You see the exit.  It is a locked, pickproof, bashproof door.
~
door~
295 -1 2302
E
exit~
This is the way out!
~
S
#2301
Second Room~
   Snazzier descriptions have a tendency to become oversnazzy, so be
restrictive and do not use superlatives all the time.
~
23 eg 8
D2
You see the exit.
~
~
0 -1 2302
E
exit~
This is the way in!
~
>trans 80 2303 2~
There is a 40% chance each time you move south that you get transferred
to room 2303!
~
>trans 50 2304 2~
There is a 50% chance each time you move south that you get transferred
to room 2304!
~
>echo 5~
Every 10 seconds(a zone pulse) there is a 5% chance that this message
will appear in room 2301!
~
S

Style

Room names
Describe the door as well as what you see when you look in that direction
For a working door, the rooms on each side must have matching doors.  Generally speaking they will also have matching doorflags.
Terrain - don't be a slave to the terrain name.  Use one that makes sense.  Remember:  terrain (sector) is a means of controlling movement cost for players.
All indoors should have the " indoors" roomflag.  Caves should be dark, unless lit by torches along the walls (or unless there is some other source of illumination).  Regen should not normally be found in a zone.  Use the other flags where they make sense.
Don't overuse death traps.  There should be some hint that the room may be dangerous, such as "You are standing at the edge of a high cliff.  Ahead you see only air."
Don't use flags marked as "to be defined" or "INTERNAL ONLY"
No_teleport is useful for blocking someone from entering a special room just by accident.  Do not make a whole zone of no_teleport rooms.

Ideas

Confusing subareas can be done several ways. 

You can skew the exits so those coming from the east, may go somewhere else when backtracking west, for example. 
You can use the chaotic room flag. The chaotic flag sometimes has the player leave in a different direction then they think they did, and they get a message "You are disoriented.".
Keep the room names and descriptions in maze like areas the same, provided the rooms DO look the same.  
Use the "R" zone command, which will randomize the exits to affected rooms each time the zone resets.

To make an area appear larger then it is, wrap the west most exit to the east most room and the east most exit to the west most room. This makes a circular set of rooms that repeat as you continually go east or west, (Like summer reruns) making the path appear longer then it really is.

Hidden doors can be disguised as many different types of things, bookshelves,  fireplaces, trap doors, rugs, and other common objects, like walls.  Some are noticeable in the description, but players don't always think to try them.

Intermediary rooms can be used to show a time related event.

X04<-->
X05
 ^      |
 |      |
 v      v
X07<-->X06                         
This means you can enter X05 from X04 and go to either X04 or X06 from X05, but can't return to X05 from X06.  To get back to X04 from X06, you go through room X07. 

Now, X05 and X07 are the same "room", but at different times, like a ferry crossing a river. X05 is the ferry going eastward across the river, while X07 is the ferry moving west.  They can have different mob or slightly different descriptions or special procedures.  It can give the illusion of something changed.

The Guide