This edition of the guide is not intended to be used by mortals
and should not be distributed without the explicit permission of the chief builder.
Players entering builder contests will get a slightly different version.
INTRODUCTION
Welcome to the Builder's Guide for AVATAR Mud (immortal/builder edition). This guide is intended to offer not just step-by-step instructions for building an area for use in the mud, but all the resources you need in helping you create your area.
This guide includes:
Instructions on every section of creating an area
Examples for each of the sections
All the information tables you'll ever need
Hints for creating the best possible areas
What you will not find within is information that will allow you to build an area for any MUD other than Avatar. Avatar's code has been heavily modified from the original Merc code, so while any generic area built for generic Merc will run on AVATAR, any areas built with this guide can't be guaranteed to run with any other MUDs. Hopefully, you'll find all the information in this guide you need to create a good, credible area.
Like all reference material, this guide was obsolete the moment it was released. Chances are, by the time you read this, new spells, functions, and options not covered in this guide will have been added to AVATAR. We'll be releasing updated versions of this guide as the situation warrants it. In the meantime, though, do not be afraid to ask other Immortals or Builder staff for assistance. They will gladly help (well, most of the time) and might be able to show you a thing or two in the process.
The formatting specified in this document is not just the preferred format. It is the required format. The area validation tool listarea is designed to enforce the format of the files as specified here. If your area fails the checks of the program, it will not be implemented until the errors are corrected. Listarea can be downloaded at: www.outland.org > Resources > Guides > Builder Guide (deperecated?).
Getting Started
General Rules, Tips, and Formatting
You will need a word processor capable of saving files in ASCII (plain text or -text only-) mode. If you are using anything other than a simple ASCII editor (i.e. Notepad), make sure it has the ability to export to (or save as) pure text (.txt).
All AVATAR area file submissions MUST have the file extension .ARE (e.g. "outland.are").
Choose a descriptive filename - we are approaching 300 areas on Avatar - naming your file cave.are will NOT work.
All quote marks must be straight "", not the quote marks which curl. When in doubt, copy quote marks from Notepad or disable the feature in your word processor.
Do not use tabs. EVER. Each MUD client renders them differently.
Do not use tildes ~ unless the Guide explicitly asks you to do so.
The ONLY place you can use asterisks * is in #RESETS. Do not use this special character elsewhere. See section #RESETS Syntax for more information.
DO NOT LET LINES WRAP. EVER. Always hit return. Most player clients do not wrap lines automatically. It's ugly. The general rule is to keep each line around 72 characters, NEVER more than 80.
72 character line, 80 character line:
123456789012345678901234567890123456789012345678901234567890123456789012
12345678901234567890123456789012345678901234567890123456789012345678901234567890
Copy/paste the 72 character line to your area file and make sure none of lines exceed this limit. NEVER go past 80 characters. Keeping a slightly smaller limit (e.g. 70) will make it easier to fix grammar/spelling mistakes later. While it is possible to compose an area in Microsoft Word and save it as .txt, Notepad makes it much more obvious if you have line wrapping issues.
Graph paper (or scrap paper) is very useful. Graph paper is good for mapping out your area, while scrap paper is good for keeping notes about what monsters go in each room, where to place doors, etc
Fantasy material (mythology or gaming books, medieval texts, etc) are useful to keep on hand for inspiration or reference, however, imagination must come from within. Everyone has creative potential; the best builders develop theirs constantly.
The very outdated builder program AvMZF (circa 1998) has been replaced by Malaclypse's area building program. As a rule, first time builders are to build 'by hand' to get maximum exposure in the intricacies of building and how area files come together.
One required step before area submission is running the program Listarea (Windows only), written by DaWiz. It is used to verify that your area is setup correctly. Listarea can be downloaded by Immortals at: (deprecated link)
Keep in mind that you have vnum limit which you should not exceed. Try to build within that limit; doing so will make it easy to account for all areas within the system and in turn helps in the implementation of new areas and the replacement of old ones.
There are two different standard ways to represent the return character at the end of a line; for historical reasons, they're called DOS and UNIX. Many common text editors will save area files with the line breaks in DOS format -- unfortunately, Avatar's system requires you use the UNIX style. The easiest way to perform the conversion is to use a utility called dos2unix. As of this writing, copies of this tool are available freely online and can be accessed either at http://www.iconv.com/dos2unix.htm or at: http://freedownloadscenter.com/Utilities/Misc_Utilities/DOS2UNIX_UNIX2DOS.html. Note that Macs have another different way of representing line ends. Please ensure that your line endings are formated in UNIX style when submitting.
Building within AVATAR's Theme
All areas must have a fantasy/medieval theme. Fantastic or medieval places include dungeons, castles, forests, lairs, villages and the like. You should not, however, reference television shows or books that may be based on fantasy themselves. The Smurfs were fun little cartoons, but they won't exist on Avatar. You definitely should not create modern-day or futuristic settings, and in fact you should avoid anything anachronistic. Please see Appendix F: Backstory by Devastant for ideas and inspiration.
Though this theme may seem confining, in fact there is plenty of room for exploration. If you've compiled some reference material of the medieval genre, you might use it to spark your creativity. Again, while drawing inspiration from these sources is an excellent idea, don't steal from them. We strive for originality in areas and ideas behind these areas.
With that said, bear in mind that AVATAR is in the process of creating a world of unique, well-elaborated themes. Notice that the word 'areas' did not appear in that sentence. One area must mesh well with the others; the resulting continuity makes it possible to tell compelling stories. To help this process, the people currently in charge of building areas will request certain types of areas to be built rather than taking whatever you produce. A key component of membership in the AVATAR area building staff is the idea that you are creating part of a world rather than just building an area.
Your First Area and Beyond
Once you have gained approval to write, the Builder Admin will work with you to determine the specifics of your first project. It will probably be fairly small, and you may be rather constrained in your building choices. You may be told you need to replace some existing items with ones in your area; items will be discussed later in this guide.
Freedom must be earned. Regardless of your Immortal rank, your first few projects will be assigned by the area administrators. As you progress, and as your building becomes more consistent with the overall vision for areas, you will be granted more freedom. Everyone has had to earn this freedom.
Note that building Lord areas is exceptionally hard, and only experienced and proven builders will be granted the chance to make them. These areas have their own specific set of rules which must be followed to maintain a rewarding and challenging atmosphere. See Appendix C for a brief overview of these rules.
What is a Vnum?
You'll be seeing the term "vnum" a lot in this guide. Vnum stands for Virtual Number. The vnum keeps track of everything in AVATAR. Each monster, object, and room - everything you see in AVATAR - has its own vnum. This number lets the system keep track of what's going on.
The same number (e.g. 1000) can be used once each for a room, object, and a mobile. This may seem confusing, but you'll catch on quickly. Just remember that mobiles, objects, and rooms are all completely different categories; so there's no conflict if a mobile, object, and room all share the same vnum. It's economical (there are less numbers to keep track of), and it actually makes things easier.
Sometimes it is necessary to give the same vnum to an object, room, and/or mobile to achieve a specific effect. Those effects will be
discussed later in the guide.
The Area File: Organization and Overview
The standard writing format can be thought of as an outline composed of several sections, listed below. While you are writing your area, you may want to work on the sections out of order; for instance, many builders start to lay out their #ROOMS first. However, when you are done, you should ensure the sections appear in the alphabetical order listed below; this standard makes it easy for you and others to read and edit your area. The final order is:
These will be explained one by one. All sections but #$ are optional, but you won't have much of an area without them!
#AREA
The #AREA section
This should be the first thing you see when looking at your document. The #AREA section is very simple. This is the header for the area; it contains the name and information that will show up in the area list. This header must be spaced carefully, so that the #AREA section of each area file will line up when you type 'area' within the game.
Note that it is possible to leave this information out. If there is no #AREA section, your area will use the name and data of the area that loads before it. Do not leave this out unless specifically instructed to do so.
#AREA Syntax
The #AREA syntax is:
#AREA <## ###> Creator Area Name~
In general, the spacing of the section is exact - this ensures that all the area information is aligned properly when someone looks at it with the area, range, or sector command.
You must have 6 spaces within the <>. Inside the spaces should be two numbers, formatted as above example. These two numbers are the level range, visible when you type "where" (while in the area") or "area".
Hero areas are listed as <51 51>
Elite hero areas are listed as <*HERO*>
Lord areas are listed as < LORD >
Legend areas are listed as by <LEGEND>
Areas for low mortals should list the recommended levels a player should attempt your area. For instance, if your area is designed so a level 8 player would gain experience there, the level range should include 8. Most area ranges should be between 5 and 10 levels, e.g. <10 20> or <27 32>. If the range is too small, players will not stay there too long. If the range is too large, there will not be enough mobs for any particular level to make the area worthwhile.
There is one space between the levels and the area creator's name. The creator's name space can only hold 7 characters from your name, and it should be followed by a single space. (If your name is shorter than 7 characters, pad this part with spaces so the next part will align properly.)
The title of an area should be at most 21 characters long. If it is any longer, it may be truncated when you see it in the area command, although the where command will show the full name of the area.
#AREA Example
Here is a sample #AREA section:
#AREA < 1 4> Crom The Meadow~
This area will show up in the area list as:
< 1 4> Crom The Meadow
NOTE: The tilde ~ at the end of the line must be present in order for the area to operate properly. The use of the tilde character is essential to the proper formatting of your area file. Missing tildes cause many errors; be very careful to account for them.
Also note the spaces between Crom and 'The' there are 4 spaces. (Crom is 4 spaces long, so you need 3 more spaces to ensure there are 7 total for the creator name, plus the 1 natural space that goes between the name and the area, for a total of 4.)
You have now finished the first part of your area.
#AREADATA
The #AREADATA Section
This section should appear second in your area file. It is optional, and in some cases you may not need to specify any of the information #AREADATA concerns itself with. However, it is a powerful section. If you are writing a lord area, this is where you specify what plane it is on. This section also contains information about the treatment of outlaws. Further, it describes the behavior of guild_guard mobiles (guards who blackjack nonmembers). Finally, #AREADATA can be used to set an entire area with a special set of flags that modify game mechanics or prevent certain actions from occurring in that area.
#AREADATA Syntax
The #AREADATA syntax is:
AREADATA
P #
F #|#
O # # # # #
K # # # # text~
M # # # # # # 0 0
G # # # # # # 0 0
S
P field:
This field defines a plane #, and should only be used for Lord+ areas. If you are writing an area for Lowmorts or Heros, do not include a 'P' field at all. The available planes are listed in Table A.
F field:
This field defines a flag for all the rooms in your area.
DO NOT USE THE F FIELD UNLESS YOU HAVE BEEN ASKED TO DO SO.
See Table A2: Area Flags for available options.
O field:
This field defines the rooms used by the outlaw and justice system in your area. If you are not using any outlaw or justice features (if your area neither is a lawful city nor has spec_guild_guard mobs who blackjack), you should not include an 'O' field at all. This field affects mobile special functions and room flags. If the field is left blank, the default Midgaard-based settings are used.
Justice system values are declared in the following way:
O
Here are what the five fields represent, in order:
dumpvnum#:
The room to which blackjack victims are moved by mobs with spec_guild_guard, and where corpses are taken by mobs with act_graverobber. Defaults to the alley in Midgaard.
jailvnum#:
The room which serves as jail for any outlaw-code-using mobs in the area, and to which mobs with act_capture take any defeated enemies. Defaults to the jail in Midgaard.
deathvnum#:
The room to which outlaws are moved when they're condemned to death. Defaults to death row in Midgaard.
exevnum#:
The room to which outlaws are moved to be executed. Defaults to the block in Midgaard.
justice%:
Defaults to 100%. Higher numbers mean harsher justice, or more executions and less leniency by the jailer.
If you want to specify only some of these values, put -1 for the others. This will use the default room values in Midgaard for any you have not defined.
When you set up an area using justice, note that the arrangement of jail, deathrow and block rooms to each other doesn't matter, since the mob doesn't actually walk between them. Additionally, your area will need another room for the jailer; the jailer's room is not included in the O field of #AREADATA.
This field defines a seeker conditional. This is optional and will only work for Lord-areas.
Seeker system values are declared in the following way:
K text~
Here are what the five fields represent, in order:
condition#:
1: Planeshift. Executes when a player shifts into the area.
command#:
1: Spawn. Loads a new mob at the room specified and sets it hunting the player.
2: Page. The first non-hunting mob of the matching vnum is set hunting the player.
3: Page-Spawn. As Page, but if no free mob is found, one is loaded.
4: Swarm. All non-hunting mobs of the matching vnum are set hunting the player.
5: Swarm-Spawn. As Swarm, but if no free mob is found, one is loaded.
6: Alarm. All mobs of the matching vnum are set hunting the player.
7: Alarm-Spawn. As Alarm, but if no mob is found, one is loaded.
mobvnum#:
Vnum of the mobile that is affected or created.
roomvnum#:
Vnum of the room that the mobile is to be loaded in. If roomvnum is -1, any mobs loaded will load in the room with the player who triggered the conditional. If no mob is to be loaded, the roomvnum should be set to -1.
text~:
The text is played only to the player who triggers the conditional, and must be terminated with a tilde ~ even if no text is included. Note that in order to hunt, mobs must be able to reach the player. It won't work on sentinel mobs, or mobs in different areas than the player, etc.
Example from outland.are:
K 1 2 15473 -1 ~
When a Lord planeshifts (1), the first non-hunting mob with the vnum 15473 is set to hunt the player (2) in the same room as the player (-1). All the group will see is the mob glaring and snarling as it attacks; there is no text which is played to the player alone.
M field:
The Area Modifier field allows you to fine tune the way certain mechanics are applied to characters in rooms that belong to your area. The regen and xpgain factors stack with other modifiers, e.g. regen from infirmary. Set the value to 0 for any of the fields to use the default.
Area modifier variables are declared as follows:
M 0 0
All fields except respawn_room take values from -100 to +100 in percent. 0 denotes no deviation from standard.
Here is an explanation of each field, in order:
xpgain_mod
modifier of xp gained for killing a mob in the area
hp_regen_mod
modifier of hp regen rate in the area
mana_regen_mod
modifier of mana regen rate in the area
move_regen_mod
modifier of move regen rate in the area
statloss_mod
modifier of the chance that a death leads to statloss,
expire is exempt of statloss, except for +100 setting.
(+100 always, +50 double, 0 normal, -50 half, -100 never)
respawn_room
vnum of the room where a char after death in the area.
0 denotes use of standard respawn room for tier.
0
unused, future expansion
0
unused, future expansion
G field:
The Group Size Limit fields listed below are to be used with care, as they can potentially result in a severe shift of balance of reward v. risk. Check with the Head builder before use and consult a coder if in doubt of the particular effects a setting may have.
Group size limit variables are declared as follows:
G 0 0
Here is an explanation of each field, in order:
size
group size limit for xp gain calculations
level
mob level in relation to which the group size limit is applied
healer_mod
group size weighting mod for healer chars, not yet implemented
caster_mod
group size weighting mod for caster chars, not yet implemented
archer_mod
group size weighting mod for archer chars, not yet implemented
melee_mod
group size weighting mod for melee chars, not yet implemented
0
unused, future expansion
0
unused, future expansion
The group size limit is applied during the calculation of xp-gains. It does not constitute a limit to the actual number of people allowed in the group. Use is primarily suggested for small-group Lord areas and for EHA.
The group size limit is set relative to a mob level limit, e.g. for a level 65 mob the expectation is for a group size of 7. For mobs of lower level the same group size is applied. For mobs of larger level a higher group size is permitted. If the number of group members exceeds the limit for the mob defeated the xp-gains are ramped down sharply.
The group size is weighted, i.e. different classes have different factors for the group size as checked against the limit (e.g. bzk higher than war). These factors vary by tier, but are fixed for a class.
Depending on the nature of the area it may be appropriate to modify the weightings for class types, e.g. in an area which has predominantly mobs that are immune to melee melee and archer classes should not count to the group size limit as much as in others. Set the size_mod value for the class type to a negative value to reduce the weight, or to a positive value to increase. The numbers are interpreted as percentage values, e.g. a value of -50 for size_mod_healer would mean that a healer character will only count with .5 towards the group size.
Example 1:
G 6 65 0 0 0 0 0 0
EHA setting which sets the standard expected group size to combat a level 65 mob to 6. No size weighting modifications are applied.
Example 2:
G 3 140 -50 100 -50 -50 0 0
Potential setting for a Lord area designed for off-peak runs by small groups. Roughly (ignoring the mods for specific classes): A caster duo will receive a group size penalty to xp gained, while a group of 6 non-casters does not receive a group size penalty.
S Field:
Note you must end the #AREADATA section with an S; it is required unless you have not included #AREADATA at all.
#AREADATA Samples
Example 1 - New Thalos (a former area):
AREADATA
O 9529 9757 9758 9544 150
S
Example 1 is on the Midgaardia plane. It does not have any general area flags. Players who are blackjacked by guild guards in this area will be moved to room vnum 9529. Players who are captured in this area by guards will be sent to room vnum 9757, then transferred to room vnum 9758 if they are to be executed. If a player is to be executed, the killing will occur in room vnum 9544. The justice factor is set at 150% of Midgaard's (that's high).
Example 2 - The Astral Plane:
AREADATA
P 10
F 1|2
S
Example 2 is on the Astral Plane. Plague cannot spread in this area, and no summonings into this area will work. Note the use of the pipe | to add flags; 1|2 is preferred to 3 because it's easier for humans to edit later, and the system doesn't mind adding powers of 2. This convenient method will be stressed later.
The S field in both examples completes your #AREADATA section.
#HELPS
The #HELPS Section
This section should appear third in your area file. It is optional, but under most circumstances you should write a help for your area. (In most cases, this is the only help that should be contained within your area.)
All areas should have their own help files; these should tell, briefly, what is widely known about the area, should vaguely suggest where it is, and should mention what players can expect to encounter there.
The keywords for this help should be the name of the area, exactly as it appears in #AREA. Keywords with more than one word (like BORLEY MANOR) must be enclosed in apostrophes; an unfortunate result is that you won't be able to use apostrophes in your help file's keywords.
#HELPS Syntax
The #HELPS syntax is:
HELPS
~
~
0$~
level:
For area helps, the level should be 1 unless they fall into the following categories:
Lord areas - use level 125 for help files.
Legend areas - use level 250 for help files.
keywords:
The standard for keywords is text in ALL CAPS; having keywords in lowercase will not break your area, but it is nonstandard. As noted above, your area's help's keywords should at least include the area name from #AREA. If there are apostrophes, just take them out; so Red Dragon's Lair would have the keyword 'RED DRAGONS LAIR'. If your
area's name starts with an article like "a", "an", or "the", you should add another keyword without the first word - for instance, The Veil of Ecstasy has both keywords 'VEIL OF ECSTASY' and 'THE VEIL OF ECSTASY'.
As indicated above, helps can have multiple keywords. Always surround strings of keywords with an apostrophe - otherwise each word will be a keyword, and you might even overwrite an existing help file! (For example, a hero contest area's help had keyword line "1 isle of the beast~" and as a result responded to the keywords isle, of, the, and beast - this is not what the author intended.)
The last keyword of a help must be followed by a tilde ~.
helptext:
The text of a help file can be any length, but each line should be at most 80 characters long. Choosing a smaller maximum length like 72 will make it easy to revise your helps later. The text should be followed by a carriage return, then a tilde ~ on a new line.
Ending the #HELPS section:
When you are done, end the #HELPS section with a 0$~ on a new line.
Useful tips:
If you need to insert more helps, simply repeat the level, keywords, and text as above; there should be a total of two tildes per help.
If necessary, you can make multiple versions of help files with the same keywords for different level readers. Place your higher level help files in order in your #HELPS section ABOVE lower level ones. When your #HELPS section is organized this way, a level 125 player will see the 125 level version of a help file and a level 48 player (for example) will see the level 1 help.
It might be useful to include a short summary of important or spare vnums in a higher level helpfile (at least 800), or to include information about a particularly tough quest to help out Immortals who might not be as familiar with the area. For an example, try HELP TRANSFIGURED FOREST INFO in-game.
#HELPS Example
Here is a sample #HELPS section:
HELPS
1 STONEHALL~
*
'Ello adventurer! Why not rest your feet at Silverbeard's *
Stonehall?! We have food, we have drinks, we even have a *
healer chained to the floor! Need maps? We got maps. Need *
to practice? We got a guy here who could teach a dog to *
talk! So if you ever pass by the meadow, look right *
across White Stone Road and there we are. *
*
- Silverbeard the Dwarf *
*
~
0$~
The example shown is from Stonehall. It can be read by any player level 1 or higher, and it has the text as shown. You can see how this help looks by typing HELP STONEHALL from within the game.
#MOBILES
The #MOBILES Section
This should be the fourth section of your area file. This section will list every type of mobile you use, regardless of how many of each particular vnum you load. This section is optional; if your area has no mobile creatures, do not include it.
Notes for recording mobile vnums may come in handy for later sections such as resets or objects. In terms of working order, you may want to write this section after ROOMS or OBJECTS or both.
#MOBILES Syntax
The #MOBILES syntax is:
MOBILES
~
~
~
~
S
0 0
0d0+0 0d0+0 0 0
0 0
R
C
L
K ~
0
vnum#:
Remember that mobiles, objects, and rooms have independent vnums. You should list your mobiles in order of increasing vnum; while it isn't required, it makes it much easier to keep track of vnums and to edit an area later.
keywords:
These are what players will use to interact with your mobs. Any commands that take a target will work on one of these mobiles only if the target is one of the keywords you specified.
short-descr:
The short description is what players will see when interacting with a mobile. Anything a mobile does uses the short description. For instance, the short description is seen in every line of combat. Short descriptions can begin with articles ("a grue" or "the wanderer"). Capitalize names; don't capitalize articles or other nouns (the MUD will capitalize where appropriate).
long-descr:
This line is what players will see when they see a mob in a room, either by scanning into the room or by typing "look" in the room. You should make it fairly easy to guess the keywords of a mobile from its long description. If you do not include any keywords here, players will have a hard time doing things to your mobiles. (This won't faze them, but it may annoy them.)
Both short and long descriptions should be limited to one line.
description:
Surrounded on both sides by tildes, this line (or set of lines) is the description which players see when they look at your mob. The description can be as long as required. For mobiles which take tickets or are involved in ticket quests, this is a prime location for hints about the quest.
act-flags:
These will cause behavior in a mobile based on a number of available directives. A mobile can have multiple actions specified by act-flags; the best way to add several act-flags is to separate each flag with the pipe symbol |. As mentioned earlier, the pipe symbol will cause the game to add the flags' numbers together for you; this makes your mobiles much more readable than they might be if you do the addition yourself.
Table B lists of the available act flags and brief descriptions of their behavior. Some act_flags should never be used when building an area; they are marked clearly.
At a bare minimum, ALL MOBILES MUST HAVE THE ACT-FLAG 1, which marks them as non-player characters.
affected-flags:
These are effects which are given to a mobile when it is loaded; unlike spell effects, these will not wear off in any amount of ticks. A mobile can carry multiple effects; as before, it is best to separate each affect by the pipe symbol |.
This value can range from 1000 to -1000. 349 to -349 is considered neutral. A mobile's alignment can affect when it assists in combat with or against other players; for more information on this behavior, see Appendix B.
level:
Mobile level can be set to any number desired for your area. Typically, all low mortal mobs will have levels within the range you listed for your area in the #AREA section. At the hero tier, mobiles can have a wider range of levels to provide different level of challenges for heroes who choose to fight larger mobs. Level 110 and 118 mobiles each have a massive bonus to their statistics and should not be used for any mobiles you expect players to fight. At the lord tier, mobiles also have a large range to provide different levels of challenge for lords.
Mobile levels should roughly fit to the type of creature you have created. If you make a level 52 rabbit, it had better live in a cave of death and have a madman at the entrance to the cave who tries to keep people out.
After the level, on the same line, put 0 0 - this is required by the code and should not be changed.
On the next line you should copy what is shown in the syntax exactly: 0d0+0 0d0+0 0 0 - this is also required by the code.
sex:
On this line should put 0 0 followed by the sex of the mobile:
0 = neuter (default); 1 = male; 2 = female.
There are no inherent differences among neuters, males, and females except pronouns players see when using socials and certain commands (like consider).
race:
The line defining a race is straightforward; a list of all available races by number is available in Table D.
NPC's have the racials of their race; you can see these by typing racial
in the game. Ghosts and elementals (numbers 32 and 30) have no body parts, so they are immune to some rogue attacks. NPC's of sufficiently high level have attributes based on their race.
Race MUST be stated for all mobiles. Do not leave this field blank. Many racials work for mobiles as well as players, and several mobile races are not available as player races. You should choose the race and most suitable to your mobs. Choosing a race that is not really suitable for your mobile just to circumvent a particular effect of racials (like dragon armorancient or similar) is discouraged - and may be an obsolete decision with future changes to mobile AI or racial abilities. If none of the available options seem appropriate for the mobiles in your area, use the generic races Animal (24) or Mobile (22).
class:
Your mobile's class is defined just like its race, but you use the letter C instead of R to denote the field. A list of classes current as of this guide's writing is available in Table E.
Class is currently significant only if the mob has ACT_PRACTICE, since the player and the teacher must have the same class for skills between 16 and 51. Otherwise, class has no bearing on a mob's combat. If you want a mob to behave like a member of a particular class, use a SPEC_FUN (see section X).
Like race, class must also be stated for all mobiles in anticipation of future enhancements to mobile AI.
team:
This optional flag applies to legend and quest mobiles only. Syntax is the same regardless of area type; precede the number with L to indicate that it's a team; then choose a number. Acceptable values are listed in Table F.
If you're writing a legend area, you should give mobs team numbers.
Quest teams are, as the name indicates, for setting up temporary quests. Do not use these as part of permanent area setups, as quest staff or immortals may change the permitted interactions between these teams.
K-Spawns:
When your mob is killed, the optional Kill-Spawn flag can be used to print a message, spawn an item or mobile, or trigger a mobprogram. Details are listed in section V.2.a: Kill Spawns.
Ending the #MOBILES section:
After you have made all the mobiles for your area, place a single #0 after the last mobile's definition to end this section of the area file.
Kill Spawns
The syntax is:
K ~
condition#:
1:
Death: when the mob dies, the spawn is invoked
2:
Clear: when the mob dies and the room is empty, the spawn is invoked
3:
Genocide: when the mob dies and no other mobs with the same vnum exist, the spawn is invoked
4:
Massacre: when the mob dies and no other mobs with massacre-type spawn exist in the area the spawn is invoked
Choose exactly one condition# above.
spawn-type#:
0:
death message is played but no mobile or object is loaded
1:
a mob specified with is loaded
2:
an object specified with is loaded on the ground
4:
If a mob and object specified with is loaded (with 1 and 2), the mob attempts to wear object. Depending on object and mob's alignment, object might zap and fall to the ground. The object must also have a wear location set.
8:
If a mob with is successfully loaded (with 1), it is set to hunt killer.
16:
If an object with is successfully loaded (with 2), the object is given to killer.
32:
If an object with is successfully loaded (with 2), the object is bound to killer.
64:
send the to the room and execute a mobprog check for the "KS" mobprog option on a mob with
128:
No death message is played to the room. Instead, the death message field is used as a text parameter for the mobprog C command = "msg". This allows a mob to react to diferent K-Spawns. Again, a mobprog check for the "KS" option on the mob with is done.
For 64 and 128, The mob that is checked for a KS mobprog is chosen as follows:
if the kspawn loads a mob, then that mob is targeted as the mprog executioner.
if the kspawn does not load a mob then the list of mobs in the game is checked, and the first mob found with the right vnum is chosen as mprog executioner. If no mob is found, nothing happens.
NOTE: 64 and 128 cannot be used together, although they can individually be used with other spawn types listed, using | as shown in the examples.
spawn-vnum#:
The third number is the vnum of the item or object to create or mobile to spawn. Whether the object loads on the ground or not depends on which spawn type you use.
room-vnum#:
The fourth number is the vnum of the room that the object or mobile is to be loaded in. Set this to -1 to load the mobile or item in the same room as the kill that triggered the spawn.
text:
After the fourth number you can place the text that will be shown to (only) the killer when the mob dies. This message can span multiple lines and has to be ended with a tilde. Blank lines can be used. Each k-spawn will have the ability to display text; you only need to use spawn-type 0 (death message) when a message is the ONLY thing you want to happen.
If you do not want a message, place one space after the fourth number and then a tilde ~, as shown in example 2 and 3.
Example 1:
K 1 1|2|4|8 -1 A guard rushes into the room.
He takes one look at his master's fallen body and attacks you with his spear!~
This would load a mob (1) and object (2) of , make the mob attempt to wear the object (4) and set it to hunt the killer (8), loading in the player's room (-1). Note ONLY the player who killed the mob will see the displayed in this example. The blank line between text lines is acceptable, as long as the text is ended with a tilde (~).
Example 2:
K 1 2|16|32 -1 ~
This loads an object (2) in the killer's inventory (16) and binds it to the killer (32). Note that the object is NOT placed on the ground (2) because it is overwritten by 16; however, 2 is still needed to spawn the object itself. The is of no consequence in this example, so it is set to (-1). No text is displayed.
Example 3:
K 1 1|2|8 30209 ~
This loads a mobile (1) and an object (2), places the object on the ground (2), and sets the mob to hunt the killer (8). The mob in this example will load in room 30209. No text is displayed.
Example 4 (advanced):
K 1 128 16231 -1 robberdeath~
Exerpt from an associated mprog file
begin 16231
T KS
C command = "robberdeath"
& room = 6560
A say The robber is dead! Yay!~
E
Q
end 16231
With the death of the mob (whichever one the k-spawn listed as), The phrase "robberdeath" is sent to mob 16231. Since it has a command k-spawn set to that phrase, on the death of the first mob, it will exclaim in joy when the first mob dies (whatever room it is currently in, does not have to be the same).
Repeat this format for each mobile you create in your area.
#MOBILES Examples
Example 1: rabbit
8104
rabbit~
A rabbit~
A rabbit scampers about in the weeds.
~
This plump rabbit seems just the right size for a kettle of boiling water.
It senses your thoughts and starts to hop away.
~
1|64 0 250 S
2 0 0
0d0+0 0d0+0 0 0
0 0 0
R 24
C 3
Example 1 is a level 2 NPC, which cannot leave the area it is placed in, called rabbit. A rabbit is neutral with a slightly positive alignment. A rabbit is a neuter (the last 0 in 0 0 0), animal (24), warrior (3).
Example 2: Nom
8113
nom meadow shaman~
Nom~
An ageless shaman sits here smiling at you.
~
This is Nom. He's the eternal keeper of the Tree of Knowledge. Throughout
time he's been here and could teach you a thing or two. He can HEAL you.
If you type 'heal', you can peruse his pricing for this service. He also
sells items of vital importance to those who are in need. To see those,
type 'list' and perhaps haggle with him. Feel welcome to stay awhile.
~
1|2|2048 8|32|128|512 1000 S
60 0 0
0d0+0 0d0+0 0 0
0 0 0
R 0
C 3
K 1 2 9999 -1 Nom's kneecap falls off and lies beside the corpse!~
Example 2 is a level 60 NPC (1), which does not move (2) and can heal players for a price (2048), with the keywords nom meadow shaman. It is angelically good (1000 S) and can detect invisible (8), detect hidden (32), has sanctuary (128) and can see in the dark (512). Nom is a neuter (the last 0 in 0 0 0), human (R 0), and warrior (C 3).
Nom has a k-spawn. When it dies (1), item with vnum 9999 will appear on the ground (2) in the room that the kill occurred in (-1). Note that we have a death message, even though the spawn-type is 2. We only use 0 as a spawn-type if no other spawn-types are needed.
Example 3: an evil night hag
277
night hag~
An evil night hag~
A night hag reaches out to steal your soul.
~
You see a shadowy creature with long talons and an evil grin, whose sole
Purpose is to hunt down and slay mortals in order to obtain souls for her foul
master to torment.
~
1|8|64|262144 8|32|128|512|32768 -1000 S
165 0 0
0d0+0 0d0+0 0 0
0 0 2
R 24
C 3
K 1 0 0 -1 The witch cries, "What a world!"~
Example 3 is a level 165 NPC (1), which will attack all mortals (8), cannot leave the area it is placed in (64), and when skinned by a player with skin corpse will produce an object with the same vnum as it (277, act flag 262144). This mob has keywords night hag. It is demonic evil (-1000 S) and can detect invisible (8), detect hidden (32), has sanctuary (128), can see in the dark (512) and sneaks (32768). An evil night hag is a female (the 2 in 0 0 2), animal (R 24), warrior (C 3).
It has a k-spawn, so when it dies (condition 1), it will emit a custom death cry (spawn-type 0); no item or mob will be loaded, so spawn-vnum is 0.
Notice that NONE of these examples contains the last line of the syntax, #0. None of these example mobiles were the last ones in their area. The #0 appears ONLY at the end of your #MOBILES section; it indicates that no more mobiles will be named and the section is over. You will need to add #0 after the last mobile in your area file.
Tips and Tricks for Your Mobiles
Keep to the theme of your area and, more importantly, to the theme of AVATAR. AVATAR is medieval fantasy based; it would be inappropriate to create President Bill Clinton in your area. (Besides, unless he loaded in a safe area, the Secret Service might investigate us.)
Learn to love your | and ~ keys. There's nothing more frustrating than trying to debug or edit an area where the builder's elite math skills were honed by adding ACT flags. And when a stubborn area refuses to load, half the time the problem is a missing tilde. Separate all your concurrent flags with the | key, and put your ~s where they belong.
Make your mobs something you (or your character) would be terrified or intrigued to encounter. But don't go too far and make ALL of your mobs too interesting and colourful. For every High Leader of the Demons, you need at least ten average lower-level demons for him to rule over. If every mob in your area is a ferocious juggernaut that takes an army to kill, either players will be scared off or they won't be properly impressed. With mobiles, as everywhere in AVATAR, balance is key.
If you want a highly populated area, the amount of mobiles should be at least twice the size of the number of rooms you have for that area.
Take care not to load one mob too many times. Your area will be boring, and - worse from some players' perspectives - it will rapidly run out of experience. If you want 15 centaurs instead of making 1 centaur and loading him 15 times, make 5 centaurs with slightly different long descriptions and descriptions and load them 3 times each. Wherever it is possible, use a new vnum for every instance of the mobiles you wish to load; this will keep the value of experience high enough for players to enjoy longer after a reboot.
If you make mobiles which train, heal, or repair the armor of players, it is good form to place them in rooms where they cannot be attacked. Likewise, if you create a mobile which offers a reward to players, it is a good idea to make sure that the mobile can be seen - unless the challenge is to find it.
#OBJECTS
The #OBJECTS Section
This should be the fifth section of your area file. This section of your area file will list every type of object you use, regardless of how many of each particular vnum you load. This section is optional; if your area has no objects, do not include an #OBJECTS section. You may want to write this section after ROOMS or MOBILES or both.
#OBJECTS Syntax
The #OBJECTS syntax is:
OBJECTS
~
~
~
~
0
E
~
~
A
Q
0
vnum#:
See Section I.4 for more information on vnums. You may need to use certain vnums to achieve certain effects (for instance, fountains and tickets). For the sake of those reading your area file (including your future self), be sure to sort your objects in order of increasing vnum.
keywords:
These are what players use to type to interact with objects. Any commands which require a target will work on your object if a keyword of the object is supplied. Multiple keywords should be separated by a space. Your item's keywords should not contain apostrophes, since the single-quote character is often used to access multiple keywords
Keywords warning: Using the word 'quest' anywhere on an item can bind the item to a player when they attempt to insure it. This includes the keywords field and the long description field, plus possibly more fields. When in doubt, don’t use the word.
short-descr:
This line is what player will see when the object is in
their inventory, in a container, or in their equipment list. A general rule
of building requires that if players are able to pick up the object, its short
description should contain at least one of its keywords.
Short descriptions should be limited to one line.
long-descr:
This line is what players will see when your object is lying on the ground in a room. If you want players to interact with an object, its long description should make its keywords easy to guess. Please note that items with NO long description (ie there is only a tilde on the long description line) will NOT show up in the room when a player types look (previously the player would see a blank line).
Long descriptions should be limited to one line.
action-descr:
This line is used to display additional text to players in a variety of ways. Any number of lines can be used for action descriptions. You can also include some AVATAR variables in adescs; see Table G.
The adesc message will display either to the room the object is used in or the player who uses it; the behavior depends on the type of the object whose adesc is being invoked. Some items such as wands, staves, and portals display their adesc to everyone in the room when they are invoked. Other items, like armor, pills, potions, weapons, and certain levers, display their adescs only to the player who uses them. Be sure when you write an item adesc that it will make sense for everyone who sees it.
If you have any questions about how an adesc will work with a particular item, ask a Builder or Immortal.
item-type:
This number defines the type of object you are creating. There is a full list of item types in Table L. This is perhaps the most important value in #OBJECTS; make sure your object is of the right type!
extraflags:
After the item type, the next number to be specified is the extra flag. Extra flags can change how an object appears to players or how an object is affected by certain spells or actions. An object can have multiple extra flags on it; each must be separated by the pipe symbol (|). The identify spell will list all an object's extra flags. See Table J for a complete list of extra flags and their effects.
wearflag:
This value in #OBJECTS is specified immediately after the extra flags. The wear flag controls whether your object can be picked up and where it can be worn. All items which players can pick up need at least a 1 flag (to make the object takeable). If an object can be worn, it requires a 1 followed by the pipe | and the number for the slot it can be worn in. Table K lists all wear flags. It is generally not a good idea to make an item that can be worn in more than one place. There is no special wear flag for lights; they need only have the flag 1.
value0, value1, value2, value3:
The meaning of each of these depends on the type of the item, which you set above. These values create variety within each item type. See Table L for a detailed listing and explanation of every item type's values.
For object value0, value1, value2, and value3, you may find you want to use more than one option in a single value. Where this is possible, the numbers are all powers of two (1, 2, 4, 8, ...), and you should use pipe addition (|) to combine the values in this section of your area file.
weight:
The weight of an object can be set to any nonnegative number. The heaviest object any player can pick up weighs 999 pounds. Weight also affects whether a player can wield a weapon.
worth:
The worth of an object is calculated automatically for most item types and you should place a 0 for it.
Exceptions are pills, gems, potions, scrolls, tickets and money. For these types of objects you should give a worth in the appropriate range for the future level of the object. This is especially important for items that are to be sold in shops, as objects with worth 0 will NOT be sold by shoppies.
Note that the selling price for these exceptions would be calculated as such: selling price = (assigned worth) x profit_sell in #SHOPKEEPERS.
Example:
The fiery red vial has a worth of 2800 and the alchemist has a profit_sell of 150%. Thus, (2800 x 150%) = 4200 coins to buy it.
After worth add a 0 to complete this line. The zero is a placeholder which is required for your area to be loaded.
E field:
Now, let's look at the optional extra section. Extra descriptions are a powerful tool for adding additional depth or information to your objects. If you choose to have one or more extra descriptions on your item, they should be placed after the weight line. Each extra description must start with a line with the single character E; the next line is the list of keywords, and the next line or lines contain the information seen when a player performs "look ".
If one of your extra descriptions has as its keywords the keywords of the object, the look command will provide a new description for your item (instead of just showing the item's long description). While the keywords must be one line, the description contents can be as long as you want.
If you want to use two+ keywords as a phrase, you should NOT enclose it in apostrophes. For example, if you tell the player to look at "final fury", you can simply type:
E
final fury~
A berserker's rage never ends.
~
The player can then type "look final fury", "look final", and "look fury". (When the player types "look final fury", the code just translates that as "look final", and ignores the extra argument.)
A field:
Next, let's look at the optional apply types. While you can freely change the order of the E and A sections, for the sake of accessibility you should put the apply flags at the end of your item.
An item can have multiple apply flags; each must be on its own line, preceded by A. The apply type field specifies what characteristic is modified by the item. If the value alters a numerical statistic, you do not need to explicitly write a +, but you should write a - before the apply value if the effect is negative. For values which are on-or-off, just use 1 to turn on the apply. See Table N for a list of all available apply flags.
Apply 50 - Immunities:
Immunity apply (50) is special. Items with this apply MUST be given the inventory (8192) extra flag, and they must have no wear flag. Do not use this apply unless you have been asked to do so, as it prevents all damage from certain sources. The immunity value is chosen from the following table; multiple apply immunities can be given with | addition.
Spell-boost Items (Lord):
Another special type of apply is used for spell-boost items. These applies only have an effect if the object is wielded. The values given for the applies define the percentage chance of the effect actually happening. Negative values have no effect.
Syntax: a
e.g., the eye of the Oni is: A 111 25
Spell_boost items should not be created for levels below Lord, as they would be a benefit for Lords to use but potentially obtainable much more easily.
Apply Flag Guidelines:
You cannot make player-usable objects that are "better" than any current item available at that level. This includes all apply flags as well as weight. Obviously unusable objects (weight 1000, no take bit, inventory flagged items) can be used to spice up a mobile, for instance by adding 500 hp.
An item which is the "best" for its level (or "first-tier", in the parlance of the Lords) should be placed on an appropriately difficult mobile or require the player solve a quest of sufficient difficulty. Don't give a 10/10 sword to a level 51 chipmunk or a double heal potion to a level 15 rabbit.
If you want to create an object of "better" quality than the best currently available (this includes both wearable and consumable items), you should seek permission from the leader of the project you are working on. Changes will be made by the head builder Immortal if necessary.
Q field:
The optional Q field should be placed after any apply flags and should be the last line of your object. The number you specify represents a quality out of 50 which will affect the hp the item loads with. A quality of 100 would result in an item with double the standard item hps; a quality of 10 would make an item with one-fifth the normal item hps.
If no Q field is present, the default quality of 100% is used. Most objects do not need Q flags, and you should only use them for special objects with especially good or poor quality. (For instance, a rusty, cracked sword might have Q 25 since it has 50% of the quality of an average weapon.)
After all optional the flags (E,A,Q) you want have been added, you can start another object with the same syntax as above.
Ending the #OBJECTS section:
After you've written your last object, insert the sequence #0 on a new line to end the section.
#OBJECTS Examples
Example 1: a scrap of paper
2399
scrap paper designs~
a scrap of paper~
A muddy, trampled scrap of paper bares what appear to be armor designs~
Nenba says, "Oh great! And you have enough leather for me to
make it, too! Since you got it, I guess it's only fair I make
some for you, too. Hold on, this will take me a couple of hours."
"Hey, what do you know? I'm done! Didn't the time just FLY BY?"
~
6 0 1
2399 2394 -2395 1
1 0 0
This item has vnum 2399. Its keywords are "scrap paper designs", and when in a player's inventory it will appear as "a scrap of paper". When a player sees the item on the ground, the player will see:
A muddy, trampled scrap of paper bares what appear to be armor designs.
Since the item has no extra descriptions (edescs), the player will also see this long description as a result of "look scrap".
In this case, the item is type ticket (6), it has no extra flags (0), and it has only the TAKE wear flag (1).
Its value0 is 2399; this is the vnum of Nenba, the mobile who accepts the ticket. This item is the kind of ticket which gives a player an item (because value3 is 1). The item the player receives has vnum 2394 (value1). Because value2 (-2395) has a negative value, the player must have items with vnums from 2395 to 2399 in order to turn in the ticket.
This scrap of paper has weight 1; the placeholders 0 and 0 tell us nothing about its value. It has no apply flags, no extra description, and its item quality is the default for its level (100% of normal).
Example 2: a metal hook
1764
metal hook thief mark lever~
a metal hook~
A thief mark points right at a metal hook on the wall.~
You twist the hook, and a door opens in the southern wall!~
30 0 0
0 2 1 1
0 0 0
This item has vnum 1764. Its keywords are "metal hook thief mark lever", and when in a player's inventory it will appear as "a metal hook". The long description is "A thief mark points right at a metal hook in the wall." Since there is not an edesc with keyword lever, "look lever" will also show the long description.
This item is of the type ITEM_MARKINGS (30), which encompasses markings and levers. This item has no extra flags and no wear flags (0 0) - so it cannot be taken.
There is no level restriction that would prevent players from seeing this mark (since value0 is 0). When pushed or pulled, it affects the door to the south (value1=2); it sets it to the default "door" state, which causes it to be opened (value3=1). Without rogue lore, this item cannot be seen on the ground (value2=1).
The adesc, played when this item is pushed or pulled, is "You twist the hook, and a door opens in the southern wall!"
This item has zero weight, and the placeholder worth and zero values tell us nothing. Since this item's extra flags are 0, the adesc is played to the entire room. If the item were dark (extra flag 4), the adesc would be shown only to the player who pulled or pushed the lever.
Example 3: the Eria sceptre
729
eria sceptre silver glowing eye~
the Eria sceptre~
An unadorned silver sceptre with a glowing eye at the top is here.~
A pale green light bursts from the sceptre's eye!~
1 1|64 1
0 0 -1 0
3 0 0
E
Eria sceptre silver glowing eye~
The eye of the sceptre lights your way, and its piercing gaze
punishes those who stand against you.
~
A 14 150
A 19 2
A 18 2
This item has vnum 729. Its keywords are "eria sceptre silver glowing eye", and the short description, seen in a player's inventory, is "the Eria sceptre." The text seen when the item is on the ground is:
An unadorned silver sceptre with a glowing eye at the top is here.
However, since there is an edesc with the keywords "Eria sceptre silver glowing eye", whenever a player looks at the item using any of those keywords, the text seen is:
The eye of the sceptre lights your way, and its piercing gaze
punishes those who stand against you.
The Eria sceptre is of type ITEM_LIGHT (1); it has extra flags 1 and 64, so it is both glowing and magical. It has only wear flag 1 (TAKE). However, it can be picked up -and- used as a light; notice that the wear flags table has no entry for WEAR_LIGHT.
This light has infinite duration and does provide light (value2=-1); the rest of its item type-specific values are 0 (unused).
It has weight 3; the placeholder "0 0" have no effect but are necessary for the object to parse properly.
This item has three apply flags. The first affects moves (14) by 150. The second affects damage roll (19) by 2; the last increases hit roll (19) by 2.
You may have noticed that the line with #0 was not included in the examples above. Again, the #0 is used ONLY at the end of your #OBJECTS section; it signifies that there are no more objects.
Tips for Creating Objects
Keep in theme. Don't create shotguns, Toyotas, Big Macs, phasers, calculators, or CD-ROM players. AVATAR's theme is one of Medieval Fantasy. Keep your objects in theme with the overall theme of AVATAR, as well as the theme of your particular area.
Make your items interesting. There are already nearly a million and a half swords in AVATAR. If you're creating a weapon, try making a glaive, morningstar, or a spiked whip. In other words, make it something unusual. If it *has* to be a sword, make it an unusual sword.
Use the | and ~ keys! Use them well! Separate your extra flag and wear flag values with | to add them. Perform the addition manually for all fields in value0, value1, value2, and value3. (This is the only place you will have to add values yourself.) End your lines properly with ~ where the syntax requires it. Otherwise, your area will not parse, and you will be sad.
#ROOMS
The #ROOMS Section
This should be the sixth section of your area file. Without rooms, you usually don't have much of an area, so this section is rather important. There are some specific instances where it can be useful to have an area without rooms (extended reset times and similar).
If you're taking pen-and-paper notes on your area, you should keep track of your room vnums; you'll need to know them when you're setting up other sections like #RESETS.
Many builders like to complete this section first and then go back and finish the rest. If you choose to do this section first, you may wish to consider laying out your area in Malaclypse’s area builder. This tool allows you to map out doors and exits and see your emerging area more visually.
#ROOMS Syntax
The #ROOMS syntax is:
ROOMS
~
~
0
D
~
~
E
~
~
A
C
S
0
vnum#:
These are explained in Section I.4. You should sort your #ROOMS section in order of ascending vnum (6700, then 6701, etc); while the area will still load if its vnums are out of order, it will be much more difficult to edit later.
name:
This is the title of your room, which players see when they are in it or when they use various commands which show the title of the room. Room titles cannot be longer than 1 line.
descr:
This is the text players will see when they look in a room. It should detail the appearance of your room and give clues to any extra descriptions you may have used. It may contain as many lines as you feel is necessary to properly describe the room. Connected rooms and large, distant, visible landmarks can be mentioned here but should not be described fully, especially if they have their own rooms.
The next line after the description starts with a 0. Then insert the room flag and sector flag on the same line.
roomflags:
These determine many actions that can be taken or not taken in a room, how mobiles react in a room, and even how many characters are permitted in that room. A room can have multiple flags for it; to add multiple flags, separate them with the pipe | symbol. Table P contains a full list of available room flags.
sector:
These are types of terrain. Terrain type will affect the movement cost of a player that walks into a room. Generally it is hard for players to notice when they change sector types; these flags are most useful for preventing mobiles from bunching in any one portion of your area. A room must have exactly one sector flag; see Table Q for an exhaustive list of sector flags.
D Field:
Doors and exits are a bit complicated. They are also very important! Each room can have from zero to six exits; there can be at most one in each direction a player can travel.
When you make a door, its type and characteristics are specified in this part of your area file. Its initial state is given in the #RESETS section.
If you create a direction exit leading from vnum A going west to vnum B, it is expected that you will create an exit in vnum B leading east back to Vnum A. If you are making a maze, direction exits need not make sense; it is possible to make a room which has exits leading players in circles, back to the same room they are in, or along some other illogical path.
It is also possible to create a maze by randomizing the exits of a room in #RESETS; see VIII.2 #RESETS Syntax.
Door syntax:
D
~
~
door#:
Each door will have a new D line. This line defines in what direction your exit leads; it consists only of the letter D and a number from Table R.
door-descr:
This is displayed when a player types . This can be as many lines as necessary, but each line should be at most 72 characters. A tilde should be placed at the end of the last line of description, on its own line.
door-keywords:
IMPORTANT: If you want your door to be visible to players, it MUST have the keyword "door". If you do not have a door, leave only a tilde on this line. Valid keywords include "north, south, east, west, up, down, door". Other keywords will NOT work.
locks, key#, to_vnum#:
The last line in each door or exit is made up of three sets of numbers. The first number affects the attributes of the locks in your door. Its value can be determined from Table S. The second number is the vnum of the key, if any exists (if not, put 0), and the third number is the vnum to which the door or exit leads.
WARNING:
It is not enough to create doors within the #ROOMS section. You must also define the "state" of the door (open, closed and unlocked, or closed and locked) within the #RESETS section. Your doors will not load otherwise. It is highly recommended that you keep track of each individual door that you make for when you go back and do #RESETS.
E Field:
Room extra descriptions are optional but add flavor to a room. This section is similar to the #OBJECTS extra description.
The E line begins an extra description in a room. Each new description must have its own E line.
Next you should list the keywords, separated by spaces and ending with a tilde on the same line. The keywords for the extra description should be mentioned in the room description, on an item which stays in the room, or within another extra description. Otherwise players will never know to look at the keywords you have given the extra description.
Unlike item extra descriptions (unless the item is flagged 'lock'), a player must type the full keyword of the room extra description in order to see it; no partial matches will be accepted. There is no exception for room edescs - all must be typed in full.
If there's a carving on your wall, or a set of carvings, you should consider an edesc with the keywords "carving" and "carvings". You might even have the same edesc also contain the keyword "scratches", if something in the room suggested that someone had carved some scratches into the wall.
The description appears after the keywords. It can be as long as required, though no line should exceed 72 characters in length, and it should end with a tilde.
A field:
In addition to making a room private or solitary, you can also use the optional A field to prohibit players of a particular alignment from entering a room by walking, or by using magic to enter (teleport, portal, being summoned, nexus, etc). It has no effect on mobiles. The only number on the line is the alignment flag, which can be any combination of these flags (as always, use | to add):
Flag
Effect
1
blocks evil (align
2
blocks neutral (align
4
blocks good (align >= 350)
So a room flagged A 1|4 would be accessible only to neutral players.
C field:
This field will block players of a particular class. It functions identically to the A Field. You can specify as many classes as you like from the following list, again using pipe addition of flags:
Flag
Class that may NOT enter room
1
Mage
2
Cleric
4
Rogue
8
Warrior
16
Paladin
32
(Ranger)
64
Psionicist
128
Monk
256
Archer
512
Sorcerer
1024
(Sage)
2048
Priest
4096
Berserker
8192
Assassin
16384
Wizard
32768
Shadowfist
65536
Mindbender
131072
Druid
262144
Black Circle Initiate
524288
Bodyguard
1048576
Fusilier
2097152
Stormlord
4194304
(Soldier)
8388608
Bladedancer
16777216
(Vizier)
So a room flagged C 2|32768|8388608 will not permit the entrance of clerics, shadowfists, and bladedancers.
Ending Each Room:
After you have added every flag and field you want for a room, you should end that room with a new line that has just the character S.
Repeat this format for each room you create in your area.
Ending the #ROOMS section:
After you have made all the rooms for your area, type #0 after the last room to end this section of the area file.
#ROOMS Examples
Example 1: West Side of Tree of Knowledge
8128
West Side of Tree of Knowledge.~
You enter the campsite of an old man named Nom. He looks frail in his
robes, yet great power emanates from him. Sitting with his back to a huge
spreading oak, he smiles at you and nods, encouraging you to draw near to
, or .
Behind him is the hollow of the tree, wherein resides all the knowledge
adventurers seek. To the west is the meadow, teeming with wildlife. Those
new to this land should explore to the east. A carved stone sits here.
~
0 4|8|1024 2
D0
~
~
0 0 8120
D1
~
~
0 0 8174
D2
~
~
0 0 8136
D3
~
~
0 0 8127
E
carved stone~
Here is a small quest for you, tiny adventurer. Within this meadow
is a golden hawk. The only one of its kind. Kill it and gain a treasure you
will cherish for levels to come.
~
S
Example 1 is the room with Nom the Healer in the meadow. Mobiles cannot walk into this room (4), it is indoors (8) and no aggressive actions will work here (1024). This is a field terrain (2) with rooms to the north, south, east and west with no doors. This room also has an extra description, accessible by typing "look carved" or "look stone".
Example 2: Hidden Hallway
3335
Hidden Hallway~
To the north you see a narrow door. A golden light can be seen along
it's edge as if the door was carved out of the stonework. The light
draws your eye so much that you almost don't notice the flicker of
light through a crack to the west.
~
0 1|8 0
D0
~
~
1 0 3303
D1
~
door~
1 0 3336
D3
~
~
1 0 3474
S
Example 2 is a room in the city of Midgaard near the mage and psionicist guilds. It is dark (1) and indoors (8). This is an inside terrain (0 after 1|8) with 2 hidden doors going north and west and a normal door going east.
You can tell this room has doors and the previous example does not because of the "1 0 " in example 2. Example 1 had "0 0 ". The "1" from "1 0 " comes from Table S: Door Lock Values; since example 1 did not have doors, that first value is 0.
When a player enters "Hidden Hallway", they will see: Exits: East->closed. This is because "D1" (east) has keyword "door"; this tells the code to make it visible. (It is closed because the door state which is set in #RESETS is "1" - closed and unlocked.) Since "D0" (north) and "D3" (west) do not have keyword "door", they are not visible on "look", etc.
Neither of these examples contains the line with #0. They don't appear there because #0 is not part of each individual room; it appears only once, at the end of your rooms section. You will need to insert #0 after the last room in your area file.
Hints for Creating Rooms
Write good descriptions. Nothing brings an area to life better than excellent, exciting prose. "You see a tree here." isn't that interesting. "A huge oaken tree looms before you, weathered and aged by time." sounds much more interesting and is far more likely to be read.
It's complicated to create a pet shop. You need to create one room with the room flag 4096 (pet shop), then create a store keeper mobile to be reset in that room. After that, create a pet store room with no outside access (do NOT use flag 4096 for this room) immediately *after* the first room (the vnums must be sequential), then reset the pets you want the store keeper to sell in that second room. Simple, eh?
Make sure your doors are sane. Remember that doorways are one-way only, and unless you specifically intend to make something like a maze or a pit, be sure that your exits connect rooms both forward and backward. For each door that is created, there is also a #RESET which defines its state (open, closed, etc).
When creating rooms with closeable/lockable doors, remember that you need to create the same door in *both* rooms. If it's lockable and you can lock it from both sides it should (logically) share the same key. Also remember to reset the locked/closed door in *both* rooms, not just one.
Rooms with healers in them should be safe rooms. Otherwise, a player could buy heals from the healer while killing him. Not a very sporting thing to do.
Private rooms add another level of difficulty to an area. If you want to insure that that special dragon you created (the one that's carrying the +10/+10 Mace of Might) is a challenge, you might consider making him a highly aggressive Sentinel and making the room private. That way, only one player at a time can enter the room to fight the mob.
No_recall rooms can also be very useful since the flag also blocks teleporting INTO the area. If you don't want your mob to be accessed any other way than by the long trek though the haunted woods you've designed, you might consider adding the no_recall flag to the room.
Use terrain types (set in #ROOMS) along with stay_terrain flags (set in #MOBILES) to keep different mobs in different parts of the area.
Note that levers can override door settings. Levers will set both sides of a door to the same value.
#RESETS
The #RESETS Section
Resets are the glue that holds an area together. In this section, you place every mobile, instantiate every object, and set every door your area is to use. Though each line is very simple, a misplaced reset can give rise to all sorts of unexpected behavior. Check and double-check this section!
Within the #RESETS section, any text on a line after the reset is ignored. One standard way of explaining what a reset does is to write an asterisk (*) and then a description of what your reset should do, on the same line. You should explain each reset in this way at the very least; documenting what each of your resets does will make it much easier to update and modify your area.
#RESETS Syntax
The #RESETS syntax is:
RESETS
M 0
G
O 0
D 0
R 0
S
There are seven kinds of resets, grouped above in the way that you should group them. The M reset loads mobiles on rooms; the G reset gives items to loaded mobiles from M; the E reset equips an item on a loaded mobile from M. The O reset places items on the ground in a room, while the P reset puts items into containers. The D reset sets up doors. Finally, the R reset randomizes exits.
M reset:
M 0
This reset loads mobs in rooms. It is recommended, but not required, that each mobile in your area be one with a unique vnum and a unique reset. (For lord areas it is required that they all be unique.)
If you use multiple resets of the same mobile vnum, the resets will occur in the order they appear here. If you wanted to load four of the same mobile into four different rooms, you would need four different resets, each with the mobile vnum, the limit of 4, and the respective vnum of each room. Note that if only the fourth mobile were killed, the first reset would be called, so that you would end up with two mobs in the first room and none in the fourth the next time resets were called. This "bunching up" effect can be countered by loading only unique mobiles; it can also be exploited to create some interesting effects (see the Tips section, VIII.3).
The order of these resets also affects the order in which they appear in a room. If you use M resets to load a cat, a dog, and a fish in that order in the #RESETS section, a player looking at the room will see the mobiles in the order fish, dog, cat.
G reset:
G
The G reset puts items in a mob's inventory. It must immediately follow the M reset of the mobile which is to receive the object. The object will load at the level of the mobile, plus or minus 2. Mobs between levels 51 and 124 will load objects at levels 50-52, and mobs at or above level 125 will load objects with levels in the range 124-126.
If you want the object only to be given to the mob after a reboot, use -2 instead of 0 as the value immediately following the G. A negative number in this position will limit the total number of times the object is loaded to 1 less than the number (a -4 will load 3 times, -6 will load 5 times etc.).
The value following the vnum is ignored, and should always be 0.
E reset:
E
The E reset will place the item in the mob’s worn equipment; and otherwise works exactly like G. It is also placed immediately below the M reset which it accompanies. You do NOT need both a G and E reset; use only one. NOTE: items can zap and fall to the ground at the moment of repop, if the mob’s alignment and the object share conflicting alignment flags - just like for players.
The last argument in the E line specifies the wear location, taken from Table T. Note that this reset does not check an item's wear flags, so it can be used to put an item on a mob in a place where a player couldn't wear it. Avoid doing this unless you have a good reason.
Note also that items equipped in the FLOAT slot will disappear when a mobile dies; however, the preferred way to make this happen is to use the inventory flag on an object.
O reset:
O 0
This is used to place an object on the floor in a room. Only one item with a given vnum is allowed per room. If one already exists in that room, another will not be loaded. If players are present in the area, the object will not reload. The level of this object is based on the level of the last mob loaded in the area in the same way that the items get levels from G resets. As a result, you should NOT make the first reset an O. The default item level when no mobs have loaded is 1.
P reset:
P 0
This places an object into all containers with the given vnum. The object will not load if no container exists or if the container already holds one of the objects to be loaded. You can't load the same object more than once into a container; use multiple vnums if you must have two of an object load.
Note that this reset will load items in containers players are carrying; be careful what you load in this way. NOTE: this will change in the future, so inquire if you think it will be an issue or to see if this is still the case. The item level is determined in the same way as the O reset, and the same caveat holds about not putting P resets in an area before any mobiles have loaded.
D reset:
D 0
The D reset sets the status of a door in a room. The door number is just the number, without the D, from Table R.
Door State
0: open (like the north and south gates to Solace)
1: closed and unlocked
2: closed and locked
If an exit has no door, a door reset is NOT needed!
Be very careful that your door resets and exit flags in your rooms section are coordinated, or you could be creating closed and locked doors which have no keys.
Door resets MUST be done in pairs, one for each side of the doorway, and each pair must have the same state. If you have doorways which you want players to be able to open or close and remain in the open or closed positions even if the area repops, make doors in your rooms section and do not include a reset for them here.
R reset:
R 0
On every reset, the room with vnum specified in this line will have its exits randomized. You also have to specify the number of exits the room has. This reset only changes the door number, so a command like "look north" may show an inaccurate room title. For this reason, when using the R reset, you should make each exit have the same title or similar titles; this will keep players from getting too confused.
Follow this format for every reset you create in your area.
Ending the #RESETS section:
After you have made all the resets for your area type S after the last reset to end this section of the area file.
Example of #RESETS:
Note that documentation with * is highly preferred if not required. This example has been edited and embellished slightly.
RESETS
M 0 10717 1 10783 * featureless druid in "Along a stone path"
E 0 10733 0 16 * wields: wooden crossbow
E 0 10779 0 17 * holds: standard bolts
G 0 133 0 * inventory: fletching kit
D 0 10752 3 2 * locked door into "Rotten core"
D 0 10753 1 2 * locked door out of "Rotten core"
O 0 10757 0 10740 * fountain (keyword statue), container, in "Within a..."
P 0 10767 0 10757 * clay shard within fountain
R 0 10770 3
S
#RESETS Tips
Because M resets are evaluated in the order they appear, you can take advantage of the global maximum field and multiple M resets of the same to create gear which only loads if all mobiles which could be carrying it are slain or when a reboot occurs. You could, for instance, have 5 distinct M resets for a mob (with a limit of 5) and after only the last reset include a G or E reset to give only that mob the item. Then the mob with the item would repop only after every instance of it had been killed or after a reboot.
Once-per-reboot mobiles can also be made by giving 2 rooms each a limit of 2 mobs. The first room must be a room which cannot be accessed by players. Make a room that is cursed with no entrances and set a reset in that with a limit of 2, then set a limit of 2 in a room which players can access. When players kill the second mobile, the reload will occur in the inaccessible room.
The order of your resets affects how objects will appear in a room. For example, if you use O resets to add a bed, chair, and a desk and put the O resets in that order in your #RESETS section, a player will see the items in the room in the order desk, chair, bed.
#SHOPS
The #SHOPS Section
This section of your area file is optional and can be used to allow mobiles
to buy and sell various item types. Shopkeepers are immune to certain forms
of aggressive actions taken by players.
#SHOPS Syntax
The #SHOPS syntax is:
SHOPS
0 23
0
mobvnum:
This is the vnum of the mobile which will act as the shopkeeper.
otypes 1-5:
These represent the types of objects the shop can buy and sell. The numbers can be found in Table L. If the mob receives items from a G reset and they are of the types specified, it will sell unlimited amounts of those items. If the mob receives items from an E reset and subsequently has them placed into its inventory by a spell like deception, it will also sell unlimited amounts of those items provided they are of a type specified in these 5 fields - so be careful!
If there are unused object type slots, place a 0 for each unused type.
profit_buy/sell:
Profit_buy is the markup for players buying items, and profit_sell is the markdown for players selling items to the shop. The standard markup is 150 and markdown is 50. Do not set profit_buy below 100 or profit_sell above 100.
0 23
This line represents the shop's opening and closing hours. At the time of writing, the game's time system is in an unfinished state of development; you should not change this line, because your shop will be unavailable to players for vast amounts of time.
Ending the #SHOPS section:
Repeat this format for each shop you create in your area. After you have made all the shops you desire, type 0 after the last shop to end this section of the area file.
#SPECIALS
The #SPECIALS Section
When you want your mobs to do something really spectacular, something that isn't covered in its ACT or AFFECTED flags or governed by equipment, you should turn to special functions.
#SPECIALS Syntax
The #SPECIALS syntax is:
SPECIALS
M
M
S
A mob can have at most one special function.
The list of possible special functions, along with explanation of their
effects, is given in Table U.
Tips for Adding SPEC_FUNs
Since a mob can have at most one special function each, choose carefully.
Special functions should make special mobiles. Don't be afraid to use them, but don't give every mob in your area a SPEC_FUN - if you did, they wouldn't be special.
If you're not satisfied with any of the existing special functions, it may be possible to write your own. You'll have to know how the C programming language; if you're interested, ask the Immortal in charge of your project for more information.
#$
The #$ Section
At the very end of your area file, after every other section, put the string:
$
This will end the area.
Finishing Up
You're Done!
Congratulations! Once the #$ is in place, you've finished your area. Debug it as much as you can, both by rereading the file and by testing it in the Listarea program mentioned at the beginning of this guide. When you've done as much revision as you know how, send your area off to your project leader for review.
Be prepared to make liberal amounts of additions, deletions, and revisions to your area. Once your area is handed in, it may be changed as necessary by the Immortal pantheon of AVATAR. If you're especially possessive of your work, be sure to think hard about this possibility.
After you've finished revisions and, if necessary, resubmissions, then you can get to work on your *next* area. Good luck, and don't take any wooden vnums!
