For the Zone Writer

Manual

How to QueryStyle GuideManualFlagsFAQPquill


Contents

1.  Introduction
2.  Sample Zone
3.  Zone Format
 
3.1.  Comments
3.2.  Headers
3.3.  Difficulty
3.4.  Mobiles
 
3.4.1.  Fields Used to Describe Mobiles
3.5.  Objects
 
3.5.1.  Fields Used to Describe Objects
3.5.2.  Doors
3.6.  Locations
 
3.6.1.  Fields Used to Describe Locations
4.  Specials
5.  Color Coding
6.  And Finally...


Introduction

A zone is just a text file. No coding knowledge is necessary. This manual explains how to format your zone for submission to Phoenix.

Formatting can be done automagically by using our proprietary zone editor Pquill. If you prefer another text editor we ask that you error check it before submission using Pquill's validator tool.

 

Download Pquill here.

IMPORTANT: Before writing, please read our FAQ and the style guide outlined elsewhere. Before submitting your zone, please read our submission guidelines, and have it proofread by at least two other people. Spelling, grammar and punctuation count!

 


Home  Top

Sample Zone

Here is an example of a complete zone file containing one mobile, two objects and two locations.

Submitted zones are expected to follow a similar format with respect to alignment (use spaces, not tabs) and clarity.

#include "exits.h" 
#include "cflags.h"
#include "undef.h"

/* This is a comment. */

%difficulty
Level = 5

%mobiles

Name        = orc1
Pname       = "Unk"
Altname     = "orc"
Location    = cave1
Sflags      { Female }
Mflags      { CanDisarm SeeInvis }
MMflags     {Bashes}
Strength    = 100
Speed       = 0
Aggression  = 0
Damage      = 10
Armor       = 0
Gold        = 5
Setin       = "Unk crawls in on all fours."
Setout      = "Unk crawls %s."
Taunt       = "Enraged by the color of your hair, Unk attacks!"
DeathMsg    = "Unk lets out a piercing scream and collapses."
Description = "&+RUnk&* is scratching her fleas here."
Examine     = "
Not the sort of girl you'd bring home to meet Mom."
FamHintExam = "Salulon, she looks dangerous!"
FamHintKill = "Do you think that was wise?"
End         = orc1

%objects

Name        = biscuit
AltName     = "food"
Location    = IN_ROOM:cave2
Oflags      { Food }
Tflags      { }
Durability  = 50
Desc[0]     = "A stale &+Bbiscuit&* has been dropped here."
Examine     = "
It's better than starvation, although not by much."
FamHintExam = "No thanks, I'm not that hungry!"
End         = biscuit

Name        = club
AltName     = "stick"
Location    = WIELDED_BY:orc1
Oflags      { Weapon Lightable Extinguish }
Tflags      { }
Damage      = 15
Durability  = 50
Desc[0]     = "A heavy &+Bclub&* has been discarded here."
Examine     = "
Dried bits of its victim's brains are encrusted on this heavy club.  Don't
drop it on your toe!"
FamHintExam = "It might provide you with light, too, Salulon."
End         = club

%locations

cave1 n:cave2;
lflags { Dark }
Dark Cave^
    This is where the text of the room description goes. Line length must be 
less than 80 characters, not including color code.
^

cave2 s:cave1;
lflags { Dark }
Tunnel^
    The walls of this underground tunnel close in on you like the 
hands of some angry and powerful Earth God.
^
FamHintRoom = "I don't like it in here, Salulon!"
^

Home  Top

Zone Format

Comments

Comments may appear anywhere in your zone file. Any text enclosed with within /* these marks */ is not read by the MUD. Comments may be any number of lines, and may not be nested.

Headers

Every zone starts with the following three lines:

 

#include "exits.h"         
#include "cflags.h"      
#include "undef.h"

Difficulty

The next lines specify the approximate player level that the zone is aimed for:

%difficulty
Level = 16

Mobiles

Mobiles are the monsters that you meet on the MUD. Begin the section of your zone file that describes your mobiles with this line:

%mobiles

Explanation of the Fields Used To Describe Mobiles:

The order these fields are laid out in the file generally does not matter, however the Name and End fields must always be the first and last, respectively, for each mobile.

Field Name Required? Description
Name Yes This field is used to uniquely identify any mobile in the zone. Every mobile in the zone must have a unique name. If you have alot of orcs, for instance, and you want them all called "orc", you can put Orc1, Orc2, Orc3 etc in the name field.

 

PName No This is the name players will see when interacting with your mobile. Maybe your orcs are named Sally, Ted and Jeffrey. Those would be the names you'd put in the PName field.

 

AltName No This field provides a second way for the player to identify the mobile. Sally, Ted and Jeffrey could all have "Altname = Orc". The player can then type either "kill Sally" or "kill orc".

 

Location Yes This is the mobile's starting location. If the mobile starts in the zone, only the location name is required here (in our above example, cave1). If the mobile starts in a different zone, that zone must be identified. For example, if Sally the Orc started in the Temple of Paradise, her location would be temple@start.

 

Sflags No Sflags describe various traits of a mobile or a player. A list of flags you might need for a mobile is provided.

 

Mflags and MMflags No These are flags particular to mobiles. A partial list of flags you might need for a mobile is available for examples. A complete list is available upon acceptance of your query.

 

Strength Yes

This is the strength of the mobile.

0 - 99 is "very weakly built"
100 - 199 is "weakly built"
200 - 299 is "fairly well built"
300 - 399 is "well built"
400 - 499 is "very well built"
500 and up is "nearly invincible" (level = strength / 100) - 5)

 

Damage Yes This is the maximum damage that a mobile can do to a player in 1 hit. This does not include any weapon a mobile maybe be wielding, or spells/skills that the mobile can cast.

 

Armor Yes Armor quantifies the amount of protection a mobile has against player hits. The higher this number, the less chance of hitting a mobile the player has. This number does not include any armor items a mobile may be wearing. Worn armor is added to the mobile's natural armor.

 

Aggression No This defines how likely a mobile is to attack. If aggression is 0, the mobile never attacks first. If aggression is 100 it will attack as soon as it sees you. If this field is left blank, default aggression is 10%.

 

Speed No Speed is how quickly a mobile moves from room to room. If you want your mobile to stay put, set its speed equal to 0. If left blank, the default value is 5.

 

Gold No This value represents how much money in clinkers a mortal will get from killing the mobile. Check worth on various mobs in the game to get an idea of how much gold to give the mob, keeping in mind that inflation must be kept low for a healthy economy.

 

Wimpy No The mobile will eat any food it carries or attempt to flee from a fight if its strength is reduced to (or below) the number set in this field.

 

Visibility No This is the player level below which the mobile is invisible to a player. The default value is 0. Setting visibility to 52 makes the mobile invis to all mortals unless they are affected by a DetectInvis object or SeeInvisPotion.

 

Setin No What people in the room see when the mobile enters. The default is "has arrived".

 

Setout No What people see when the mobile leaves. Use %s for the direction. The default is "has gone %s".

 

DeathMsg No What people see when the mobile dies. The default is "has has died".

 

Taunt No What the victim sees when the mobile attacks. There is no default.

 

Description Yes This is what the player sees for the mobile's sethere, or on typing "look".

 

Examine Yes This is what the player sees on examining the mobile.

 

FamHintExam No If the player has a familiar, this is what the familiar will say to the player when the player examines the mobile.

 

FamHintKill No This is what the player's familiar will say to the player when the mobile has been killed.

 

End Yes This marks the end of the mobile. It must always be identical to the name field.

 

Objects

Objects are the items in the MUD - the things you can examine, push, pull, get, wield, wear, etc.

Begin the section of your zone file that describes your mobiles with this line:

%objects

Explanation of the Fields Used To Describe Objects:

The order these fields are laid out in the file generally does not matter, however the Name and End fields must always be the first and last, respectively, for each object.

Field Name Required? Description
Name Yes This field is used to uniquely identify any object in the game.

 

PName No This is the name by which the player refers to an object.

 

AltName No This field provides a second way for the player to identify the object. For instance, if the object is called TheBigBadDemonSlayingSwordFromHell, let's have an AltName of "sword". Note: all edible objects must have an altname of food.

 

BValue No This is the base value of the object when pitted. The value of the object when pitted is based on this cross referenced with the number of mortals running.

 

Damage No If the object is a weapon, then this is the maximum value of the damage that the weapon may do.

 

Armor No This quantifies how much protection an armor object affords its user. When assigning armor value to an object, consider that the max armor a player can wear ranges from 35-45, depending on guild, and that players become encumbered if they wear too much armor. Thus armor values under 10 allow players to wear a variety of pieces.

 

Size No This is the size of the object. The larger the object the more cumbersome it is to carry. With containers, this field represents the sum total of the objects' sizes that may be put into the container. For example, a bag with size 10 can carry one size 10 object or 10 size 1 objects.

 

Weight No Weight of the object. (Generally unused)

 

Price No This is how much the object will cost, if it's for sale in a shop. Generally speaking, the price of an object is related to it's bvalue, but there are certain objects that we would like to have a fixed price regardless of the number of players on the MUD at the time. For these objects, use the price field.

 

Counter No This is a field used mostly with objects such as torches that burn out after a given period of time. The counter on burning things decrements once every 2 seconds, so a torch with a beginning counter value of 15 will burn out in 30 seconds.

 

State No This specifies the starting state of an object which has more than one state. If the object's starting state is greater than 0, a maxstate must also be specified. See sections on doors, getflips and pushtoggle for examples of the uses of state and maxstate fields.

 

MaxState As above This field tells the game how many states an object has. A MaxState must be declared for all objects with states.

 

Oflags No General object flags. A list of them is available here.

 

Eflags No Magical effect flags. A list of them is available here.

 

Wflags No Wear flags, which control where and how an object can be worn. A list of them is available here.

 

Tflags No Special flags. A list of them is available here.

 

Linked No Used for creating doors. See later.

 

Key No If lockable, this is the only key that can unlock it. If blank, any key will work.

 

Location Yes

This is the starting location of the object. An object may start out sitting in a room, inside a container, carried by a mobile, worn by a mobile, wielded by a mobile or both worn and wielded. This must be specified in the zonefile thusly:

CARRIED_BY:Hound
IN_ROOM:Undead1
WIELDED_BY:Tinkerbell
BOTH_BY:Kether
IN_CONTAINER:sack
WORN_BY:Lucifer

 

Desc[0..3] Yes The descriptions seen when a player types "look" and sees the object in the room. You can specify a different text for each state, from 0 to 3.

 

Examine Yes The text seen by a player when they examine the object.

 

FamHintExam No If a player has a familiar, this is what the familiar will tell the player when the player examines the object.

 

Durability Yes for Weapons, armor, food and boats The amount of time a weapon, armor, piece of food or boat will last while carried.

Food and boat durability decrement about once every 2 minutes.

Food rots only if carried by a player (in a container or not).

Boats rot only while on water.

Weapon and armor durability decrement on high damage hits, so high damage weapons will wear out more quickly, and armor hit with high damage weapons will wear out more quickly.

Armor: At each hit, if a random number between 0-100 is less than half the damage dealt on that hit, the durability of a random piece of armor worn by the victim is decremented by 1. Armor with durability greater of 5000 or more does not degrade at all.

Weapons: At each hit with a non-magical weapon, if a random number between 1-100 is less than half the damage dealt on that hit, the durability of the weapon is decremented by 1. If the victim has the mmflag Toughskin, the chance of decrementing durability is doubled. If the weapon has the Magical oflag the chance of decrementing durability is halved.

 

Examples
Food
Calamus - durability = 200, will last just under 4 rl hours or so while carried.
Boat
Raft - durability = 200, lasts just under 4 rl hours while on water.
Armor
Durability = 300 will last a long time depending on how hard it gets hit.
Weapon
Durability = 200 is medium, wears out faster if it hits harder. See other objects around the mud for reference.

 

Power (or Int, Char, Wis, Agil, Con) No Plus values boost a player's corresponding stat, negative values decrease it. Stat modifiers on objects only affect remorts, not players in their first incarnation. See INFO ROLLSTATS for the effects of the various stats on character performance. Objects can modify any of the stats in the same way. An object can have more than one stat modifier. Stat modifiers on ordinary objects must total either 0 or less than 0. Boats are required to have a negative agility componant.

 

End Yes The name of the object. Must match the "Name" field.

Doors

A door is created by linking two objects together. In the example below note that the two objects reference each other in their "Linked" fields:

 

Name     = InsideDoor
PName    = door
Linked   = OutsideDoor
State    = 2
MaxState = 2
Location = IN_ROOM:Sith1
OFlags   { Openable NoGet Lockable }
Desc[0]  = "The door is open."
Desc[1]  = "The door is closed."
Desc[2]  = "The door is locked."
End      = InsideDoor

Name     = OutsideDoor
PName    = door
Linked   = InsideDoor
State    = 2
MaxState = 2
Location = IN_ROOM:Sith2
OFlags   { Openable NoGet Lockable }
Desc[0]  = "The door is open."
Desc[1]  = "The door is closed."
Desc[2]  = "The door is locked."
End      = OutsideDoor

Here is an example of how the door we just created might be used to connect two rooms:

Sith1 n:^InsideDoor;
LFlags {}
Inside Brughadir^
   You stand within the great hall of the Brughadir. All around is
desolate and barren, the hall long ago ransacked by forces of
unimaginable evil.  The only obvious exit is a small wooden door to
your north.
^

Sith2 s:^OutsideDoor;
LFlags {Outdoors}
Within the great gardens^
    You emerge from the dank, dark Brughadir and find yourself in the
once great gardens of Brughadir. All around you is now a natural
wasteland. Plants and vines are tangled in an eternal battle for light.
Rosebushes are choked with vine and weed and all around there are
echoes of ancient beauty from a time long forgotten.  To your &+Csouth&* 
lies the main hall of the Brughadir.
^

Note that the exits from these rooms have the ^ after the colon. This is required when an exit points to a door. You do not have to worry about the door, it will take care of itself. As long as you ensure that the rooms reference the door objects with the ^ symbol, and that they are LINKED correctly and in the correct LOCATION, everything will operate properly.

Locations

A room is any location at which a player may stand and get a description.

Begin the section of your zone file describing the locations with this line:

%locations

When writing your locations it is advisable to work from a map. When you have completed your zone, go back over the map to ensure that all the exits lead to where you expect them to.

Explanation of Fields Used in Location Descriptions:

Locations follow the following basic template:

RoomName Exit:RoomName;
LFlags {Room's LFlags}
Room Title^
  Room Description
^
FamHintRoom = 
^

For instance:

entrance n:road e:cornfield w:orchard;
LFlags {Outdoors NoMobiles}
Kingdom Of Tolmansith^
   You stand at the entrance to the Kingdom of Tolmansith. As far as
the eye can see, low flat lands sprawl. It seems agriculture is a
mainstay of this kingdom's wealth as all around you lie cultivated
fields of many different crops. Strangely all the fields seem deserted,
all work abandoned. You can but wonder where everyone has gone. To
your &+Cwest&* lies a vast orchard. To your &+Ceast&* is a field of golden
corn. The road continues to the &+Cnorth&*.
^
FamHintRoom = I wonder if something is buried here.
^

Room Name: In this example, "entrance" is the name the code knows the room by. Please use descriptive names here, not numbers. The MUD will automatically number your locations and if you number your locations myzone1, myzone2 etc, massive confusion will result when your hard coded room names do not match those automatically generated by the MUD when it builds. If you submit a zone this way, expect to have it returned.

Room description: Please use a fixed width font such as Courier for your room text, using no more than 79 chars/line. See the style guide for guidelines for room descriptions.

Exits: Following the name, list any exits from this location. Our example room has exits to the north, east and west to other rooms in the zone. See the section on doors for handling of doors. If the exit from a location leads to a location in a different zone, that zone must be specified (i.e. s:shady@blizzard).


Home  Top

Specials

At some point you are going to want to do something that is simply not possible using only the above information. Maybe you want to push a boulder off a cliff in order to kill a hideous troll. How do you do this? Well, you don't. What you have to do is let the coder know that you wish this to be done when the zone is implemented. A second file must be sent along with your zone file containing descriptions, in plain english, of what you want to have happen in these special circumstances.

For example:

I would like a special that when the boulder in location ledge is pushed off the cliff it falls down and squashes the troll in location ledge_bottom. The boulder is moved to ledge_bottom and the troll is killed.

When the player pushes the boulder they should get the message: "You watch as the boulder plummets of the edge of the cliff and hurtles towards the troll, at the last moment the troll looks up, but his Neanderthal brain cannot process the danger and is squashed to a pulp before he can move."

Other people in the room should see the message: "<player name> pushes the boulder off the cliff."

Remember to try to outline all the different scenarios that might occur when your special is executed. What if the troll is already dead before boulder is pushed? What if a Player is in the room with the Troll, what should they see? Please do not try and tell the coder how to write the special, just write in plain English what you want to have happen.


Home  Top

Color Coding

Zones that are accepted for Phoenix mud must conform to specific color coding requirements:

Mobiles: Mobile names are in high red (&+R) in their descriptions.

Objects: Object names are in high blue (&+B) in their descriptions.

Directions: Direction names are in high cyan (&+C) if they appear in room descriptions.


Home  Top

And Finally...

Have fun writing your zone! Make it fun and take your time to get it right. Ask peoples' advice and bounce your ideas off of them. You may be surprised how ideas can change once you begin to write a zone.

Again, most importantly, have fun. If you enjoy writing the zone it will show in the quality of that zone.

This manual may not be used by other MUDs without express permission of Phoenix MUD.


Home

 

Last updated January 3rd, 2004