Builder Port Tutorial


Introduction:  This document instructs on the use of the builder port


Index

1. What is the Builder Port? 
2. The Database
3. Object Types
4. Logging In and Getting Set Up
5. Loading Areas and Modifying Objects
6. Creating Markers
7. Creating Moveables 
8. Creating Books
9. Creating Keys
10. Creating Locations
11. Creating Doors
12. Creating Mobiles
13. Creating Mergers
14. Creating Money
15. Creating Weapons
16. Creating Wearables
17. Creating Food
18. Creating Boats
19. Creating Ropes
20. New, Copy, Rename, and Delete
21. Non-MudObject Objects
22. Creating Spells and Skills
23. Creating Specials
24. Creating Quests
25. Creating Actions
26. Creating Levels
27. Creating Races
28. Creating Texts
29. Creating Bulletin Boards
30. Creating Inclinations
31. Creating Talents
32. Creating Chatlines
33. Using Color
34. Where do I start?
35. I want to make this do that. Can I?




1. What is the Builder Port?

   The AIME code provides a separate port for all building activities.  
It allows for online creation of areas and should provide the builder 
an efficient method for putting their ideas onto the mud.  Some may ask, 
why create a separate port divided from the game port for building?  We 
did this to provide a functional division between building and game play. 
This way, all building will be done on the builder port, and functions 
specific to game play and administration can be accomplished on the game 
port. To gain access to this building port you need to talk to a mud admin 
to give your player the correct permissions for port access. 




2. The Database

	The MUD stores all information in "objects".  A location is an 
object that contains the location description, where the exits go, 
and other data pertaining to that location.  Each mobile is an object, 
and each door is an object.  For the most part, anything you can examine, 
get, or talk to is an object.  In the MUD, we call these objects MudObjects.

	The MUD stores all MudObjects, along with several other types of
objects (Actions, Spells, Specials, etc.) in a series of area files.  An area 
file is a collection of objects, ranging from Mobiles to Doors to
Locations that have some functional connection.  One example is the 
Elven Forest.  The entire Elven Forest is stored in the area "eforest". 
The entire Camelot section is stored in an area called "camelot". 
When you combine all areas together, they make up the MUD. 

For those who are interested and have some knowledge of databases, all 
MudObjects are stored in an area binary tree.  Each area binary tree is 
then stored in a mud-wide binary tree.  So it is in essence a bunch of 
trees in a tree.  If you have no idea what I am talking about, don't 
worry about it; it is not important for you to understand this to 
create areas. 



3. Object Types

	There are many different objects that make up the MUD, each with 
its own unique attributes.  Markers are objects that take up a small amount 
of memory, and are used for a non-moveable object that you can examine.  
Doors are links between locations that can be opened, closed, locked, or 
magically locked.  Books are objects that, when read, will print the 
contents of a file.  Locations are, well, locations in the world.  Keys 
are objects that are used to open one or multiple doors.  The key will 
only work on a door if that door is specified as working for that key. 
Mobiles are game people, creatures, or anything that can die.  Most 
mobiles you can talk to and will respond to you.  Moveables are items 
that you can get, but aren't usually good for anything but taking up 
space.  They could be an item that adds to the "feel" of an area (like 
a skull head) but has no real use. 



4. Logging In and Getting Set Up

	In order to be able to log on, you will need to ask a game admin
to give you the proper permissions and access.  Once you have been 
configured for building, telnet to the builder port of the MUD and 
log in with the username and password you use on the regular game port.  




5. Loading Areas and Modifying Objects

   On login, you will see a prompt that looks something like:

([AREA]:[MUDOBJECT]) B> 

   The [AREA] indicates which area you have loaded, and the [MUDOBJECT] will 
indicate which MudObject you are set to modify.  To modify a particular 
object, you'll first need to load the area file it's in, then load the 
object.  For example, suppose you want to change the title of a location 
called "stinky" in the area called "swamp".  You would first type "load 
swamp". Your prompt would then change to:

(swamp:[MUDOBJECT]) B>
<
To modify the location "stinky", you would type "modify stinky".  Your prompt 
would then change to:

(swamp:stinky) B>


   While more than one person can modify an area at the same time, only one 
player can modify a particular object at one time.  While you are set to 
modify "stinky", no other player can modify it.
	At this point, you can view the attributes of the location "stinky".  
Typing "describe" (or "desc" for short) will give you the attributes and 
values of each attribute that make up the location "stinky".  You will see 
the title, description of the location, where the exits lead, and other 
data pertinent to the location. 



6. Creating Markers

	Markers have several purposes.  First, they provide something to 
examine without letting the user know that it is there directly.  An 
object that you can move would normally have a brief description which 
would appear to the player, like "You see a bone lying here."  (We call 
this a "brief".)  The player will only know that a marker is there if the 
builder identifies the object in the location description.  For example, 
the room description:

	"You stand in a small room, complete with a table, chair, and a 
small uncomfortable-looking bed in the corner.  The dust covering the floor 
indicates that nobody has been here for days."

Given this room description, you should ideally create a marker for the 
table, chair, bed, and dust.  That way, when the player types "examine 
table", you could provide the description "A small amount of rotten food 
covers the wooden surface." 

	A second reason that a marker would be used is to attach a 'special'
to it (this will be described in detail later).  If you have a torch on a 
wall, and want a wall to open when the user moves the torch, you would create 
a torch marker and attach a special to it. 




7. Creating Moveables

	A moveable object is an object that a player can carry.  In 
actuality, Books, Keys, Wearables and Weapons are all Moveables, but 
with added features.  A Moveable is the simplest of all carryable objects. 
You use this object when you want to create an object just for show, 
or to attach a special. It could be a skull to create atmosphere or 
a magical stone that glows when picked up.  You can make moveables more
functional by adding flags to them.  For example, setting the flag 
'Container' will permit that object to hold other objects.  So one
could create an object "bag" and set the 'Container' flag and suddenly
this object is a useful container. 




8. Creating Books
	
	Books provide a method for displaying a large amount of text 
without using the massive amount of memory that storing all the text 
would take.  A book indicates the name of a text file, which when the 
user reads the book, it displays the contents of that text file to the 
user.  This way, only the filename needs to be stored in memory, instead 
of the entire text. Books are gettable, and provide an "examine" as 
well as the file that "read" displays.  




9. Creating Keys

	Keys are identical in attributes to moveables. The only 
difference is that you can't use a moveable to unlock or lock a door. 




10. Creating Locations

	Locations are the "meat" of an area.  They are the rooms that 
the player stands in and which contains most Markers, Moveables, and 
all Mobiles.  The locations contain exit pointers for each of the ten 
directions, and point to either another location or a door.  They also
contain location flags which define special attributes about the location.




11. Creating Doors

	A door is like a mix between an object and an exit.  It allows 
a link to be created between two locations, and depending on the door 
state, either allows passage or blocks the exit.  Doors provide great 
flexibility in descriptions.  Each door has a separate description for 
the inside and outside of the door.  It also allows you to set your own 
brief message depending on the door state.  You set a door by first 
assigning the inside and outside location of the door to the two 
locations that the door will exist in.  Then on both of those locations, 
you set the appropriate exits to the door name.  Say your door is called 
"reddoor" and your two locations are called "room1" and "room2".  These 
attributes should be set:

Room1:
East: reddoor

Room2:
West: reddoor

Reddoor:
	Outsideloc: Room1
	Insideloc: Room2

This will make the door a link between those two locations.

Doors are also used when linking two rooms with a rope.  You define the
door with the RopeTie itemflag and connect the door like you would any 
other door.  The RopeTie flag prevents players from opening the door by
normal means.  They actually have to tie a rope to the door (the rope
must be long enough) to open the door.  For a rope door, the brief 0 is
for when a rope is tied to the door, the brief 1 is when no ropes are tied,
and brief 2 is for when the rope is tied but not long enough.  Brief 3
is not used for a rope door.  

Special doors are doors that can only be opened using a special.  For
instance, if you have thorns blocking a path and the player must light
the thorns to clear the path, you set up a special door and create
a pre_light special that will open the door when the thorns are lit.  To
set up the door as a special door, you need to set the SpecialDoor
If you don't want the exit to show up on "exits", you need to set the 
HiddenDoor itemflag.  This will also prevent briefs from being shown.  




12. Creating Mobiles

	A mobile can be defined as any non-playing character.  This can 
range from creatures that want to kill you to shopkeepers that want 
to sell things to you.  It could include peasants, lords, and thieves.

	Mobiles contain a tell/reply feature. It allows the builder to 
create replies to specified keywords. When a player does a tell to a 
mobile, the tell string will be searched for certain keywords. If it 
finds a certain keyword that has a reply, the mobile will reply with 
the specified string. In general, you will want to create a reply to 
keywords "hello hi" for each friendly and some unfriendly mobiles.  
This way, users can start with "tell bob hi" in order to get information 
from Bob.  The replies should help lead the conversation as well.  
Nobody is going to know that if you tell the dragon "what about the 
glove" that the dragon will tell you where the magical glove is 
unless you provide a clue somewhere.   An example of an effective leading 
of the conversation would be:

"tell mayor hi"
Mayor replies "Welcome to my town!"
"tell mayor town"
Mayor replies "Yes, I am the mayor of this town. It isn't much but it
does survive."
"tell mayor survive"
Mayor replies "Oh yes, we have had our hard times as of late, what with
the big storm and all."
"tell mayor storm"
Mayor replies "Nearly wiped out every building!  Was a devil's storm if you
ask me!"

Using this technique of leading the conversation, you can provide hints
for the players to home in on.  For the most part, all keywords should
have something directing the player to them, even if it is a mobile on
the other side of the mud giving a hint.  New tellreplies can be created
by typing "new reply (keywords)" and the replies can be changed
by typing "set reply (reply number)".  Tell Replies can be deleted by
typing "delete reply (reply number)"

Mobiles can perform abilities much like a player can.  They can also
have certain weapons they are skilled at using.  These are called
proficiencies and can be assigned to a mobile using the command 
"new proficiency (objname)" where objname is either the name of a
spell or skill in the abilities area, or a weapon class.  When a
mobile has proficiencies assigned to it, a message will appear
when the user types "describe" indicating proficiencies exist.  These
proficiencies can be viewed by typing "describe proficiency".  In this
list, ProfName indicates the ability or weapon class.  Rank indicates
how adept they are at using the ability or weapon.  It tops out at around
40 for most abilities or weapons.  Finally, probability is the probability
that each combat turn the mobile will use that ability and does not apply
to weapons.  You can remove proficiencies with "delete proficiency (number)"

Mobiles can also run a shop, where the user can buy objects from
the mobile in exchange for a certain amount of money.  Each shop contains
a name attribute, which the mobile will use when referring to their
shop, like "Bob's Bugs and Beetles".  Also, each shop contains a currency
attribute stating the denomination of currency in which the shopkeeper
lists his prices.  These currencies (whether gold, silver or copper) have
to be pre-defined MudObjects (such as gold@courtland).  Shops can be
created by typing "new shop (name of shop)" and deleted by typing
"delete shop"

Each shop contains a list of shop items which consist of an alias,
an object name, and a value.  The alias is the name that the shopkeeper
will use to refer to the object.  The object name is the name of the
actual object.  For example, the object "shortsword" could have an alias
of "sword".  Theoretically, the alias and the object name could be 
unrelated (ie, you could give the item an alias of sword when it is 
really a rock) but this would be misleading to the player and isn't
recommended.  To create a shop item, simply type "new item (alias)"
and a shop item by that name will be created.  To delete a shop item,
type "delete item (alias)".  The "value" is the cost of the object, 
and is specified not in terms of currency but rather in terms of 
the money index.  To get more information on the money index and 
money objects in general, see the section on Money.

Mobiles have a list of flags, called IndFlags (Individual Flags).  See the
flags document for information on IndFlags and other game flags.




13. Creating Mergers

   A "merger" is an object that will merge together and break apart as 
needed.  An example of this would be a group of arrows.  If you carry 
those arrows and do an inventory, you will see:  arrows(10) meaning you 
hold ten arrows.  Actually you hold one arrow object with 10 
units.  If you type "drop 5 arrows", it will clone the arrows object, 
set each to 5, and drop one copy of the arrows.  Now you will hold in
your inventory "arrows(5)", and on the ground there will be "arrows(5)".  
If you then type "get arrows", it will destroy one arrows object and 
you will now hold "arrows(10)" again, because the two objects will have 
been merged.  Mergers can be used for any type of object that will 
normally exist in multiple numbers.  Money is an example, but money is 
a different object that will be talked about later.  Weapons ammunition 
like arrows, bolts, and slingshot pellets would use mergers.  Reagents 
could also use mergers.  

   To create mergers, you create a template object which is never used 
in actual gameplay.  All mergers will then be generated from this template as 
needed.  All object types have a clone attribute where you can specify 
mergers that start in that object.  For example, a bow may be created
with five arrows in it.  This object ability excludes actual merger
objects, since you can't place a merger within a merger.  Another example
is having a merger start in a specific location.  Say we create a location 
called "forest1" and in that location, we set Clones = "arrows@castlezone 7". 
This means that on loading of the zone, it will place an arrows(7) object 
at that location. 




14. Creating Money

A money object is a merger with one additional attribute: index.  The index
reflects how much a single unit of that currency type is worth relative to
other currency.  For example, let us create three types of money:
gold, silver and copper.  We assign an index of 200 to gold, 20 to silver,
and 1 to copper.  Therefore it would take 20 coppers to equal one silver,
and 10 silvers to equal one gold.

Keep in mind that if you give weight to the money, each piece of money will
weigh that much and if you give a weight of 1,200 gold will be quite heavy.
You may want to give it size but no weight.  

See price.txt for a list of objects and recommended cost to use as an 
approximation of how expensive you should make things when designing shops. 



15. Creating Weapons

   Weapons are objects that can be wielded and cause damage to others.
Weapons contain a damage attribute, which stands for the maximum damage
that the weapon can cause.  The damage that is actually caused depends on
how direct the blow is, the damage of the weapon, and how heavily armored
the mobile is.

The DepStr attribute is the dependency the weapon has on the user's 
strength, from 0 to 100 where 0 is not at all dependent, and 100 is 
fully dependent.  A lightweight sword would have a low DepStr level, 
while a heavy warhammer would have a high DepStr level.  DepDex is the 
dependency the weapon has on the user's dexterity.  A bow and arrow 
may require a higher player dexterity than an axe.  For both of these 
attributes, if the object has a high dependency on either of these levels, 
then the user should have a high level of strength or dexterity for 
them to have any accuracy with the weapon.  This also affects chance of 
deflecting the enemy's weapon.

The weapon class is a string that defines a weapon in a certain class.
If you create a sword, you should place that in the "sword" class, and
this will allow a player who trains on "swords" to gain an advantage
with "sword" class weapons.

Weapons must be wielded in either one hand or both hands to be effective.
Some weapons, like a short sword, may only require one hand to use.  Other
weapons, like a two-handed sword or a bow would require both hands.  The
wield type attribute defines whether the weapon requires one or both hands
to wield.

If you set the class to a range weapon such as a bow, it will make it act 
quite different.  You will need to first set the container flag on the bow 
and ensure the capacity is enough to fit your arrows.  To limit what the 
player can put in the bow, attach a special to the bow with the trigger 
"preput_receptacle" and ensure the special code allows only the object types
you want, such as arrows.  Here is a sample bit of code that does just that:

goto_if_eq("end", is_string_eq(get_parent_name("primary"), "arrow@global"), 1);

send_actor("You can't use that with the bow!\n");
return_invalid_criteria();

end:

When the player attacks with their bow, the mud will look for an object 
inside the bow with a special attached to it with the "on_launch_hit" 
trigger and will use that to fire with.  It will run that special then.  
An example of that code is:

send_actor("Your arrow sinks into ", get_title("primary"), "!\n");
send_room_except_dual("primary", "this", get_title("this"), "'s ", 
   get_title("secondary"), " sinks into ", get_title("primary"), "!\n");
send_to("primary", get_title("this"), "'s ", get_title("secondary"),
   " sinks into you!\n");
set_counter(25);

decrement_number_of("secondary", 1);
goto_if_neq("end", 0, get_number_of("secondary"));
destroy_this_obj();

end:

It determines damage by what the counter is set to, hence the set_counter(25) 
line which causes 25 points in damage.




16. Creating Wearables

   A wearable is an object that can be placed on the body of the
player or mobile.  It could be anything from clothes, jewelry, 
armor, etc.  A shield is considered a wearable object, but it does
not get worn per se as it is wielded.  You need to set the Wielded 
wearflag to make the shield wielded.

   Each wearable object is a moveable object, with a few additional
attributes.  The armor value is the maximum amount of damage that a
piece of armor will deflect or absorb.  It does not decrease the
enemy's chance of hitting you, but it will decrease the damage
they cause if they do strike you.

   Wearable objects have wearflags that indicate several attributes
of the object.  First, they indicate on what part of the body an
object will be worn.  An object can be worn on several parts at once.
For example, a chainmail vest would be worn on the back, chest, and
arms.  The TopLayer flag indicates that this item of clothing will
always be the top layer on a body part.  You can only wear one top
layer item of clothing at a time.  This way, nobody can wear two
platemail items at the same time.




17. Creating Food

   A food item is an item that can be consumed, and will often give
the user energy.  Energy is important as it will affect how you
fight and some other game aspects.  A good player will keep their
energy level high by eating food often, so that they can
perform at their optimum level.  Food is a merger with one special
attribute: energy.  This is a value from 0-10 that states how much
energy eating one of these pieces of food will provide to the player.




18. Creating Boats

   A boat item is an item that a player can enter and will allow
that player to travel across water.  It is a carryable object, but
in all actuality most boats would be tough to carry without dropping
everything so it would be wise to set the size and weight high.  For
a boat to work properly, you must set the container flag and set a
capacity high enough to carry the players that you want.  The 
default individual size is 180, so for two players you should make
the capacity 360 or higher.

The boats do briefs a little bit differently.  If the boat is on
water, the waterbrief is used.  If the boat is in a shore location
(meaning that both regular players and water-dwelling mobiles or
boats can go there), then the brief0 is used.  Otherwise, brief1 
is used.




19. Creating Ropes

  Ropes are merely moveables with one additional attribute, length.
The length attribute will define if a rope can be used in a specific
"rope door".  If it is not long enough, it will not reach far enough
for the rope door.




20. New, Copying, Renaming, and Deleting

The builder port supplies methods for manipulating objects. To create an 
object, the "new" command is used. The "new" command syntax is: "new 
(objecttype) (objectname)". The type is either one of the object types 
(like a weapon or a location), atellreply or a special. To create a new 
weapon, you might type "new weapon shortsword". Each object name has to 
be unique for that area. For example, you can have several weapons called 
"sword" in the game, but only one per area. For tellreply, the (objectname) 
is where you put the keywords for the tellreply (separated by spaces, like: 
"hi hello") that will activate the reply. For instance, if you want the 
mobile to reply to "hi" or "hello", you would type "new tellreply hi hello". 

For copying, renaming, and deleting objects, you first need to have an object 
set to modify. (See Loading Areas and Modifying Objects) To copy, the 
command syntax is "copy (newname)" where (newname) is a unique name for that 
area. The syntax for rename is "rename (newname)" where (newname) is a 
unique name for that area. Copy and rename do not work for tellreplies or 
specials. You will have to delete and recreate these.

To delete anything, you must first have an object set to modify. To delete 
objects, you simply type "delete" and it will ask you if you really want 
to delete this object. Say yes and the object will be deleted. It does 
save the deleted object to a recovery file, so if later you decide you 
didn't want to delete the object after all, let someone with site access 
know and they will recover it for you.  To delete tellreplies, type "delete 
tellreply (number)" where the number is the one given to the tellreply 
under "describe".




21. Non-MudObject objects

   Not all items that you can modify on the Builder port are classified
as MudObjects.  The following objects are objects that the player wouldn't
necessarily be able to pick up, look at, or be at.  They range from quests
to spells and skills and are an integral part of making the mud come alive.
In most cases, you have to load a special area to edit these.  This will
be described in each object.




22. Creating Spells and Skills

   Spells and Skills are both Abilities, so in order to edit them you
must load the area "abilities" into memory  (See the Loading Areas and 
Modifying Objects section for more details).  Once this is loaded, you 
can modify, create, and delete abilities as needed.

   There are two types of abilities, Spells and Skills.  Except for the name 
and the fact that one casts a spell and performs a skill, they are very 
similiar.  On both, one can set dependencies which limit how the user can 
perform the ability.  If, for instance, you want a spell that requires 
intelligence and wisdom to cast, you would need to create a dependency on 
both intelligence and wisdom.  The value of that dependency would determine 
if the the user can even use that ability and if they can, the chances of 
them being able to successfully carry out the ability.  To create a dependency, 
you would type "new dependency (type)" where type is the type of dependency.  
This ranges from ReqIntel for requiring intelligence to ReqStrength for 
requiring strength.

   Both spells and skills have strings that are displayed during combat to the 
target, the caster or performer, and finally to bystanders.  The "acting" group 
of strings is displayed when the player casts or performs the ability.  If 
the cast or perform was successful, the "success" group of strings is 
displayed.  If it was a failure, the "failure" group of strings is displayed.  '
All in all, you have 9 strings to customize your ability with.  <br><br>

   It also supplies limitations to the spell casting or ability performing.  For 
instance, with a certain spell you may require that they be holding an emerald 
staff.  The "MustHaveItem" dependency will allow you to specify these limitations.
The drain attribute will allow you to specify how much the casting or performing
of the ability will drain the player (magical energy drained for spells, endurance
drained for skills).  

   Finally, when a spell or skill was successful, it runs the special specified 
in the Specials attribute.  This is what actually runs the "meat" of 
the ability.  For the fireball spell, the following code is what makes 
it work:

goto_if_eq("ind", 1, is_individual("primary"));
goto_if_eq("light", 1, is_itemflag_set("primary", "lightable"));
goto("end");

light:
set_itemflag("primary", "lit");
goto("end");

ind:
damage_individual("primary", 25);
fight_player("primary");

end:

You can probably see by this code that if you cast fireball on an individual
(player or mobile), it does 25 damage while if you cast it on an inanimate object
that can be lit, it lights the object.  With the special code, you can make a
spell to do most anything.  From picking a lock to summoning a demon, a spell
can be anything you would want it to be.




23. Creating Specials

   Specials are objects that define unique activity that is not supported
in the mud code.  For instance, if you want a sword to give the player a
shock when they pick it up, you would attach a special to the object that
does this.  Once attached to an object, specials activate using triggers.  The
trigger defines the action that will cause the code to be run.  In the case of
the shocking sword, the trigger would be set to "pre_get" or "post_get" which
would give the shock before the sword is picked up or after the sword is picked
up.  The list of triggers in triggers.txt will describe each trigger to you.

   The code for the special is in interpreted format (don't worry if you don't
know what that means) and is described in the specials tutorial located 
in the file specials.txt.




24. Creating Quests

   Quests are actual defined puzzles for the player to embark upon and solve.
Your MUD may not have quests defined so they will not even come into play, as
quests can be done without actually defining them (creature won't teach you a
spell until you get a dragon's tooth for example).  If the MUD does have quests
defined, you can create them by loading the "quests" area (See the Loading 
Areas and Modifying Objects section for more details).

   The attributes in the quest object allow you to indicate attributes of
the quest, ranging from the quest points awarded for completion to the 
description of the quest the player will see when typing "qinfo (questname)". 
The actual quest will be awarded to the players using a special (See 
the Creating Specials section and the award_quest
special command.)




25. Creating Actions

   Actions are things that the player can do that are really just for fun or to
provide an easy way to express themselves.  It can range from smile to laugh, from
bopping them on the head to giving them a rose.  They are just verbs that display
text when executed to the room and to a target if specified.  Many other muds
call these as "socials".

   The action objects consists of five strings which are displayed to different
people in different circumstances.  The Actor string is displayed to the player
performing the action when there is no target involved and the Crowd string is
sent to the bystanders witnessing this action.  For a targeted action (directed
towards somebody), the Target string is sent to the target of the action while 
the Sender string is sent to the recipient.  The Bystander string is sent to
those witnessing the action.

   All strings provide special characters to insert names and pronouns into the
text as appropriate.  For example, %a inserts the actor's name into the string.
%t inserts the target's name.  The full list is as follows:<br><br>



%a                                  The actor

%t                                  The target

%!                                  "his" if actor is male, "her" if female

%~                                  "him" if actor is male, "her" if female

%[(malestring)%(femalestring)]      displays first string if actor is male, 
                                    second if female

%<(malestring)%(femalestring)>      displays first string if target is male, 
                                    second if female




26. Creating Levels

   Levels are used to indicate how far a player has progressed on a specific
track or chain.  All levels are stored in chains, where a chain may be 
the "Wizard" chain containing all levels of the wizard's guild.  This way, 
a player can be level 6 in the wizard's guild (wizard's chain) and level 12 
in the warrior's guild (warrior chain) simultaneously, making them a 
strong warrior with some magical abilities.

   Players advance to the next level once certain specified criteria are met.
This criteria is contained in the level object in several ways.  A few attributes
of the level object allow you to specify specific criteria, such as the MinStr
attribute which allows you to set a minimum strength for the player to be at.
MinDex, MinIntel, and MinExp all provide a means of ensuring the player has
certain attributes before the level is awarded.  You can specify specific
criteria using the SpecialReq attribute.  When a special is attached with the
trigger "on_level", it will run the special and if the special return with
the return_invalid_criteria function, it will not award the level.  This way
you can specify specific things that must be true, such as the player has to 
have an object in their inventory to gain level.

   By using the WhenAwarded attribute, you can reward the players for their
level advance by performing most anything your imagination can come up with,
from increasing their attributes to awarding them priviledged objects.  You
could even give them some adminflags, such as when they make master level.




27. Creating Races

   Races define a race of creature.  It contains attributes that indicate
what a player from that race starts out with.  It can indicate spells and
skill they initially know, how strong they are initially, how dexterous
they are, etc.  

   Many items in the game will depend upon what race the player is. 
Their communications will depend on what race they are and what they
can understand initially.  An elf will not understand what a dwarf
says and visa versa. 

   Races will determine where a player starts in the game.  It will also
determine where a player is transported to when they die.  This way, a dead
player could be transported to the shaman's hut of their race who has
resurrected them.  

   Races also set which tutorial the players travel through when they first
create their character.  When a race object is being modified, the builder
can type "new tutorial (name)" which will create a tutorial.  The tutorial
is basically a special that can display text, transport a player to a
tutorial zone, or whatever else you want it to do.  The player does not
exit the tutorial until the special function exit_tutorial is executed using
another special.  If you have transported a player to a specific tutorial
location, then you could set up a special to run exit_tutorial when a
player tries to leave the tutorial area.  It is important that, while in
the tutorial, the player is not given the opportunity to exit into the game
as they have not finished building their character and will be disadvantaged.
Tutorials can be renamed with "rename tutorial (name)" and deleted with
"delete tutorial (name)".  Other attributes for tutorials are described in
the race attributes section.


28. Creating Texts

   Text objects provide a means to edit various texts througout the game.  
This could range from help and info files to the banners that players see 
when they logon and quit the game.  The type of text object depends on the 
area you load.  To edit and create help files, you would load the "help" 
area.  For info files, the "info" area should be loaded.  The "banner" area 
will provide a means to edit the specific banner files that are used.  
Currently, two banners exist.  The bldrbanner is the banner that will 
appear when a player logs onto the builder port while the gamebanner is 
displayed to players logging onto the game port. 
   Text objects are fairly simple, in that they only have the Title (with 
the exception of Banners which don't have this) and the body.  You create 
the texts by typing "new (type) (name)" where type is either Help, Info, 
or Banner.  The type must match the area that is loaded.  One point to 
note on texts: you can't save these to a temporary file.  Once you have 
modified them, the only way to store them is to commit, which will write 
them to their permanent files and incorporate them into the mud.




29. Creating Bulletin Boards

   Bulletin boards can be a good forum for players to express ideas to other
players on the game.  They can be used to put out ideas or even add to the
roleplaying environment of the game.
   Bulletins can be set up to be global, meaning players can access it from
anywhere on the game, or set to a specific object so that players must be
at that object to access.  They include several attributes that permits you
to tailor who can access the board and who is denied access.  If denied
access, the player won't even know the board exists.
   You can create a bulletin board by first loading the "bulletins" area and
then typing 'new bulletin (name)' where (name) is a name that the players
will refer to it as if the global flag is set.  If the global flag is not
set, the players will have to use the object the bulletin board is attached
to in order to access the board.


30. Creating Inclinations

   Inclinations are used during the initial login for new players.  It
permits builders to define and players to select certain inclinations for
the race.  For instance, in the elven race, most would not be exceedingly
strong but amidst the elves you would find those that are stronger than
most and those that are even more dexterous than others.  Inclinations
could include musclebound (stronger but stupider than most), scholar
(more intelligent but weaker and clumsier), and on and on.  Inclinations
only define offsets, meaning how much the attributes increase or decrease.
This means that a dwarf who selects musclebound inclination is going to be
much stronger than the elf who picks the musclebound inclination.  Builders
should take care when developing inclinations so that one is not more
advantageous overall than others or players will discover and continually
select that inclination.  Balance is the key.

   Inclinations are maintained in the inclinations area.  Loading this
area will allow a builder to modify, add, or delete inclinations.  If you 
do not wish inclinations to be availble to the players, just delete all 
inclinations in the inclinations area and the players will not be asked
to select an inclination.

31. Creating Talents

   Talents are used to fine-tune the character creation.  The game
developer can offer several attributes for the players to start out with,
all tailorable via a special.  Implementors can offer a dexterity
increasing talent or a strength decreasing deficiency (which gives more
talent funds).  It allows for players to set indflags, such as night vision
or any other flags that exist.  Players use talent funds to spend on talents.  
The amount of talent funds players start out with is determined in the 
aime.conf configuration file.
   As with inclinations, talents should be balanced so they do not offer
too great an advantage.  Talents could even be coupled with deficiencies,
so that a player who selects a talent would suffer somewhere else, providing
a balanced trade-off.
   The talents area allows builders to add, delete, and modify talents.  If 
the game implementor does not want talents to be offered to the player,
merely leave the talents area empty and the player will not be asked to
select talents.


32. Creating Chatlines

   A Chatline is a capability that permits players or builders to transmit
messages across the entire mud.  It could be anything from a regular chat
line to a line for coders or administrators to discuss issues.  A chatline
requires two seperate permissions.  First, one must have permission to
transmit over a chatline (see the user's manual for how to set this) and
second, the users must have permission to see the messages.  A player could
have permission to receive but not to send (such as a system message), or
to send and not receive (such as a wish line that goes to the immortals).
   The Chatline object contains attributes that define the format of the
message that is sent.  It also contains lineflags, which define who the 
message will go to.  


33. Using Color

   Color can add to the atmosphere that you are trying to create in your
area.  For instance, if you are creating an area of cold and ice, using
white and blue will heighten that effect.  For a volcanic area, reds will
certainly make the player "feel" the area better.  Green colors can also
emphasize forested areas, while yellow can portray a desert area (relentless
sun).  A list of color codes can be found on the game port by typing "info
colorcodes"



34. Where do I start?

Below are some suggestions for creating a good zone.

Before you even create your first MudObject, you want to plan out
your location.  First, think of the overall "feel" of the zone that
you mean to portray.  If it is a mountain zone with a small village, 
imagine what a mountainous village would be like.  A village needs
to have a reason for being, so plan out the industry that drives the
village, how the villagers live, what they live in, and what traditions
and cultures that they may have.

Next, map out the layout of the zone.  Keep in mind the things you
decided already, and develop the map accordingly.  A mountainous
village would probably have buildings made partially of stone
and wood, and could even contain a mine or two.  It would have a
store to buy food, a blacksmith, a woodworker, and maybe a bowsmith.
Most settlements would have a pub or some other form of entertainment
for the inhabitants.

Adding mobiles to this village would come next.  This and the next step
of planning underlying "events" almost come hand in hand, since the 
people are what will help make the village interesting.  A village 
will probably have a village leader, or a council that runs things.  
It might have shopkeepers, workers, and some kids as well.  Wives of 
miners could dwell in the houses, and maybe some hermits living away 
from the village.

Next, you need to plan out the underlying "events" and "turmoil" that
dwells just below the surface of the village.  When a player talks to
a wife of a miner, they may say that "Sylva" is a good person, but
talking to another villager you may find a feud between this wife
and Sylva that when you ask them about it, they go on and on about this
person.  You could create underground societies, hidden traitors, and
insurgency warriors fighting against the king.  All this for the player
to uproot with a thorough investigation.  Often, the more complex the
underlying puzzles are, the more interesting the zone will end up
being.  It might be a good idea to create links to other zones, meaning
someone may have a brother in Courtland, and then add tellreplies to
that person and the brother.  You may have to get permission from the
maintainer of that zone to add to it.  While you're at it, plan out
the puzzles to be solved, hidden passageways to find, etc.

Finally, you create.  Start with the locations, and add markers as you
create these locations.  Add mobiles and tellreplies, and inventories
to shops as you see fit.  Add specials to appropriate objects, and
finally, when you feel that you have a fully functional zone, test and
test some more.  Login as a regular user and travel down every possible
path (including social and verbal paths, tellreplies and stuff) 
and ensure the user can chase these paths as well.  When it is tested,
your masterpiece is ready for the users to marvel at your creativity!

Again, this is just a suggested way of doing things, you are free to
find the method that works best for you.




35. I want to make this do that. Can I?

   If there is something you want to put in your zone and either you
don't understand how to do it, or the tutorial doesn't explain a way,
be sure to tell a coder.  They will be able to tell you if it is
possible and how to do it, or explain to you why it is not possible and
offer possible alternatives.  The last thing we want to do is stifle the
creativity of your zones, so please ask.  For requests for more features,
contact either the implementors of this mud or Slate at noelg@acm.org 
(the mud code designer) to request the new feature.