[align=center]
An interesting area will always attract more players than a bland one. There are many ways to
make an area interesting. Try to be as descriptive as possible; don’t hold back on writing extra
descriptions. Players are so accustomed to not having richly described areas that finding an extra
description can often be a real treat. Also, one oft forgotten thing to describe are the door exits.
Describing all of these can give a feel of standing out in a field and looking off to the north and
seeing something like:

     The fields stretch off towards the large hills on the horizon. Far to the north you see
     what appears to be a plume of smoke.

  With door descriptions like these, an area will feel more fleshed out to the player. Many players
  (both experienced and first timers) read the descriptions carefully the first time they walk through
  an area, and having many extra descriptions helps them fill out their idea of what things actually
  look like.

  One thing that should never be done is to have generic room descriptions like “You stand in a
  big room. It is very dark.” Descriptions like these detract in general from the rest of the world, and
  if they are found room after room can bore a player to tears. Such a description could be changed
  to:

     You stand in a room of very large size. Shadows cower along the walls and almost
  seem to be moving as you look around yourself. The floor is made of heavy stones
  which are very dark in color. The ceiling is quite some distance above you, but you can
  still make out objects hanging from it, ruining the smoothness that is characteristic of
  the rest of the room.

   Another way to make an area interesting is to create some sort of plot line for it, or a coherent
theme, rather than a collection of haphazardly related rooms. The plot can be complex like infiltrating
a castle to garner the war plans of the evil Lord Zygol, simple like ridding the caves of goblins,
or anything in between. Often the plot in an area can be advanced by some fairly simple puzzles
or descriptions. With the help of special procedures written in C by the MUD’s coder, involved
puzzles of Zork-like complexity can be readily created.

   Not all monsters have to be designed to be killed, nor does every shopkeeper have to buy or
sell something – they could just be created so that they refuse to trade with any player characters.
The players will then wonder why the shopkeeper exists. Perhaps giving him a jewel will make him
more friendly. In this way, an area can be made infinitely more exciting by coding some special
procedures for it. Perhaps random teleporters throughout the area, perhaps some procedures that
have monsters respond to questions from players.

   All in all, the best way to make an area interesting is to use variety, intelligence, and imagination
in building. Try to imagine what it would be like for you to walk through and what you might
try looking at or doing, and then try to incorporate that into your area. Show your area to others
and take their advice. By taking all of this extra effort in creating your area, you will be rewarded
by leaving a lasting memory of your area in the minds of many players.
[/align]

[align=center]
In the old days, the only tool that was used (or required) to write a MUD area was a simple text
editor. However, in the course of time, various people have written programs to help builders
create worlds without having to understand the complex details of the world file format. Worldbuilding
programs are becoming more popular, especially the fancy graphical builders that run
under Microsoft Windows. You may prefer to use one of them rather than trying to use a simple
text editor and understanding the format on your own. New world-builders are constantly being
written and released, so any attempt to describe them here will almost certainly be obsolete by the
time you read it. However, some of them can be found in the contrib/ section of CircleMUD’s
official FTP site <ftp://ftp.circlemud.org/pub/CircleMUD/contrib/>.
[/align]

[align=center]

   CircleMUD’s world is divided into distinct sections called zones. Each zone typically consists of a
single, modular, geographically coherent region of the MUD’s virtual world with a consistent storyline.
Each zone can define its own physical space (the world), monsters (usually called mobiles),
objects (such as armor, weapons and treasures), and shops, in which a mobile in a particular room
can buy and sell objects to players.

   A single zone typically contains up to than 100 rooms, 100 monster definitions and 100 object
definitions, but a large region can be subdivided into several zones at the author’s discretion. For
example, the City of Midgaard is divided into two zones, one for the main city and one for the
southern residential area. In addition to this, with the new zone system describing top and bottom
rooms of a zone, zones can contain very few rooms and indeed can overlap with other zones if
desired. A zone can also use mobiles and objects defined by another zone, but this practice is
discouraged because it makes zones less modular, meaning that it becomes more difficult to add or
remove one zone without affecting another zone.

   Each room, mobile and object within a zone is given a unique number called a Virtual Number
or Vnum. The Vnums for the rooms, mobiles and objects are independent, so there can be both
a room number 3001 and an object number 3001. When defining and referencing parts of a zone,
the zone author always refers to each entity by its Vnum and never by name. Vnums are normally
not seen by players. Each zone itself also has a Vnum. A common convention is to number the
zone with the Vnums of its component rooms, divided by 100. For example, Midgaard is zone 30,
consisting of rooms 3000 to 3099. Mobile and object numbering follows the same convention.

   The author of the zone can define aspects of each room such as the terrain type, special properties
like whether the room has its own light source or is a death trap, and other parameters. A
very important aspect of each room is the position of other rooms in relation to it; for example, from
room 3014, one can go north to reach room 3005, east to room 3015, etc. Great care should be given
to making the room links logical and consistent. A player who moves east and then immediately
west should find herself back in the same room in which she started.

   Each mobile is given characteristics such as number of hit points, bare hand damage capability,
strength, and special skills and abilities. Objects have parameters such as weight, value, and magical
properties. The author can also choose how these three pieces of the world are combined to form
the initial state of the zone: for example, the number of each mobile that exist and in which rooms
they stand, the equipment that each mobile uses, objects which might be on the floor, and the doors
which may be initially locked or unlocked.

   When the CircleMUD server runs the zone, it sets each zone to its initial state as defined by
the author, and then makes the zone “come alive” by randomly making mobiles wander through
the zone and, if desired, attack players. While the players are using the zone (killing the mobiles
and picking up equipment) the server periodically resets the zone to its initial state (a zone reset)
to prepare the zone for the next group of players.
[/align]

Before descending into the details of MUD building, it should be noted that the formats of the world
files are sufficiently complex that it is probably not possible to gain a complete understanding of
them merely by reading this documentation. This document is designed to be a reference manual
and therefore may not serve as a particularly good tutorial. While there are examples provided at the
end of each section, they are only meant to be representative and are not comprehensive examples
of all possible ways to use the features that will be described. The most effective way is to learn by
example: examine some of the areas that come with CircleMUD and try to figure out the meanings
of the numbers in different rooms, objects, mobiles, and zone files, using this manual as a guide.
Once you’re proficient at reading world files, you’ll find that creating them is a much easier task.

Each CircleMUD zone is defined by five types of files: world files, mobile files, object files, shop
files, and zone files. World files (*.wld) define the actual rooms and the links from one room to
another. Mobiles (*.mob) are the monsters which inhabit the MUD. Objects (*.obj) are the weapons,
armor, treasure, and other objects manipulated by players and monsters. Shop files (*.shp) define
the MUD’s shopkeepers, controlling what they buy, sell, and say. Finally, Zone files (*.zon) bring
all the previous elements together to define the initial state of the zone, describing how monsters
should be equipped, where monsters should be placed, where objects on the ground should be,
which doors should be locked, etc. These five types of files are collectively referred to as the
world, or sometimes the tinyworld files.

   CircleMUD uses split world files to make the world easier to manipulate. Instead of all the
rooms being lumped together in a single, cumbersome file, the rooms are split into many different
files, one file for each area of the world. All five types of files are split in a similar manner.
Circle has one directory for the room files (lib/world/wld/), one directory for the object files
(lib/world/obj/), and so forth.

   Circle doesn’t care how the world files are split or what the names of the files are, but certain
conventions have developed to make management of the world easier. Each file typically contains
information for only a single zone and the filename is typically the zone number, with an extension
indicating one of the 5 file types. For example, the file 30.wld contains rooms 3000 to 3099 of
zone 30; 42.mob contains mobiles 4200 to 4299 of zone 42, etc.

   Also in each of these directories is a file called “index” that tells the server which files from
that directory should be loaded when the server boots and a file called “index.mini” which
(minimal) set of files should be loaded when the server is booted with the -m option.

   Every world file used by Circle (including the index files) must be terminated by the dollar
sign ($) to tell the server that the file has ended. Without the dollar sign, the server will not boot
properly.

   The split utility that comes with CircleMUD can be used to divide a large file into a number
of smaller files; for example, if you have a large zone that you’d like to break into several smaller
zones. See the CircleMUD Utility Manual for more information on how to use split.

When learning about the formats of CircleMUD world files, you’ll frequently see references to
bitvectors. A bitvector is a group of flags which each can be either on or off. Bitvectors and their
flags are used in many ways within CircleMUD, such as to define the personality of mobiles, the
characteristics of rooms, etc. Understanding how to use bitvectors is essential if you want to build
a CircleMUD world.

  At every point where this document says a bitvector is required, it will be accompanied by a
  table describing the flags which you can use with that bitvector. The table will look something like this:

      1 a DIRTY The room is dirty.
      2 b STINKY The room stinks.
      4 c MUSHY The floor of the room feels mushy.
      8 d SWAMPY The room resembles a swamp.

   Note there are four columns in the table. The first column contains the numeric value of the
flag. The second contains the alphabetic representation of the flag. The third is the name of the flag,
and the fourth is a description of what the flag does.

   There are two ways you can construct a bitvector with the table above: the numeric method
and the alphabetic method. The numeric method is to select all flags you’d like to activate, take the
numbers of those flags as listed in the first column of the table, and add them all up. The resulting
sum will be the bitvector. The alphabetic method is much easier: just write down all the letters of
the flags you’d like to use with no spaces in between. For both numeric and alphabetic bitvectors,
use “0” to indicate a bitvector where none of the flags are set.

   For example, imagine you want to create a room that is dirty, mushy, and resembles a swamp,
but does not stink. Using the numeric method, you’d look up the numbers of those three flags (1 for
dirty, 4 for mushy, and 8 for swampy), and add them up to get 13. Using the alphabetic method, the
bitvector would simply be “acd”. Bitvectors are case-sensitive; “acd” is very different from “Acd”
and “ACD”.

   At every point where the CircleMUD format requires a bitvector, you can write either a numeric
bitvector or an alphabetic bitvector. They are completely interchangeable. However, be forewarned
that if you use alphabetic bitvectors, your area will not be compatible with MUDs based on the
original DikuMud. Alphabetic bitvectors are a CircleMUD enhancement and may not be supported
by MUDs based on Gamma Diku.

   In some bitvector tables, you will see values whose descriptions say “Reserved for internal
use” or “Do not use”. You should never set those flag values in your world files.

After an area is written, there are three steps required to add it to the MUD for testing: copying the
files into the proper directories, adding the new filenames to the appropriate index files, and running
the MUD in syntax-check mode to make sure the new area is formatted correctly.

           All world-related files go in the directory lib/world/. In this example, we will imagine

that your new area is zone number 57 (which should consist of rooms, objects and mobiles numbered
5701-5799). Your zone probably has 5 files: 57.wld, 57.mob, 57.obj, 57.shp, and
57.zon. The first step is to copy each of these files into their appropriate subdirectory: 57.wld
should be copied to the directory lib/world/wld/; 57.mob should be copied to the directory
lib/world/mob/, and so forth.

   The next step is to add the name of the newly copied world files to the index file contained
in each of the world subdirectories. Note you will need to change 5 index files: one for each of
the world files that you copied in the previous step. Adding the filenames to the index files tells
CircleMUD that the files should be loaded; they will not be loaded simply by virtue of being in the
correct directory. First, edit the file lib/world/wld/index; you should see a list of the current
world (room) files. Add a single line that says 57.wld in the correct numeric order. Next, add a
similar line in the other index files: add 57.mob to lib/world/mob/index; add 57.obj to
lib/world/obj/index, etc. At the same time, if the area is to be a central core area for the
game, it should also be added to the index.mini file.

   Now you can try to boot the MUD with the new world. If you’re adding a new area which
hasn’t been debugged yet, it’s usually a good idea to run Circle in its syntax-checking mode first.
From Circle’s root directory, type bin/circle -c to run Circle’s syntax checker. If the check
runs with no SYSERR messages, the syntax of the area is probably correct and the MUD can be
safely booted. Otherwise, check the CircleMUD SYSERR List for more information on how to
correct the formatting errors. also, see the CircleMUD Administrator’s Guide for more information
on how to run CircleMUD.

The format of a mobile is:

#<virtual number>
<alias list>~
<short description>~
<long description>
~
<detailed description>
~
<action bitvector> <affection bitvector> <alignment> <type flag>
{type-specific information; see below for details}

The format of mobiles varies depending on the Type Flag. See below for documentation of the
formats of the various types.

     Virtual Number This number is critical; it is the identity of the mobile within the game. It is the
  number that will be used to reference the mobile from zone files and is the number used to
  “load” mobiles from within the game. The virtual numbers must appear in increasing order
  in the mob file.

     Alias List The list of keywords, separated by spaces, that can be used by players to identify the
  mobile. The mobile can only be identified using the keywords that appear in its alias list; it
  cannot be identified by a word that appears only in its name. Great care should be taken to
  ensure that the spellings of names and aliases match. Fill words such as “the,” “a,” and “an”
  should not appear in the Alias List.

     Short Description The description of the mobile used by the MUD when the mobile takes some
  action. For example, a short description of “The Beastly Fido” would result in messages
  such as “The Beastly Fido leaves south.” and “The Beastly Fido hits you hard.” The Short
  Description should never end with a punctuation mark because it will be inserted into the
  middle of sentences such as those above.

     Long Description The description displayed when a mobile is in its default position; for example,
  “The Beastly Fido is here, searching through garbage for food.” When the mobile is in a
  position other than its default position, such as sleeping or incapacitated, the short description
  is used instead; for example, “The Beastly Fido is lying here, incapacitated.” Unlike the Short
  Description, the Long Description should end with appropriate punctuation.

     Detailed Description The description displayed for a mobile when a player looks at the mobile by
  typing “look at <mobile>.”

     Action Bitvector A bitvector (see section 2.4 on page 8 ‘Using Bitvectors’) with the following
  values:

1                        a SPEC            This flag must be set on mobiles
                                                which have special procedures
                                                written in C. In addition to
                                                setting this bit, the procedure
                                                must be assigned in spec_assign.c,
                                                and the specproc itself must (of
                                                course) must be written. See the
                                                section on Special Procedures in
                                                the file coding.doc for more
                                                information.

2                         b SENTINEL    Mobiles wander around randomly by
                                                default; this bit should be set
                                                for mobiles which are to remain
                                                stationary.

4                         c SCAVENGER The mob should pick up valuables
                                                 it finds on the ground. More
                                                 expensive items will be taken
                                                 first.

8                         d ISNPC          Reserved for internal use.

16                       e AWARE          Set for mobs which cannot be
                                                  backstabbed. Replaces the
                                                  ACT_NICE_THIEF bit from Diku
                                                  Gamma.

32                        f AGGRESSIVE  Mob will hit all players in the
                                                   room it can see. See also the
                                                   WIMPY bit.

64                        g STAY_ZONE    Mob will not wander out of its own
                                                    zone -- good for keeping your mobs
                                                    as only part of your own area.

128                       h WIMPY           Mob will flee when being attacked
                                                    if it has less than 20% of its hit
                                                    points. If the WIMPY bit is set
                                                    in conjunction with any of the
                                                    forms of the AGGRESSIVE bit, the
                                                    mob will only attack mobs that are
                                                    unconscious (sleeping or
                                                    incapacitated).

256                        i AGGR_EVIL    Mob will attack players that are
                                                    evil-aligned.

512                        j AGGR_GOOD Mob will attack players that are
                                                    good-aligned.
                        
1024                        k AGGR_NEUTRAL      Mob will attack players that are
                                                                neutrally aligned.

2048                        l MEMORY               Mob will remember the players
                                                            that initiate attacks on it, and
                                                            initiate an attack on that player
                                                            if it ever runs into him again.

4096                         m HELPER    The mob will attack any player it
                                                  sees in the room that is fighting
                                                  with a mobile in the room. Useful
                                                  for groups of mobiles that travel
                                                  together; i.e. three snakes in a
                                                  pit, to force players to fight all
                                                  three simultaneously instead of
                                                  picking off one at a time.

8192                         n NOCHARM           Mob cannot be charmed.

16384                       o NOSUMMON         Mob cannot be summoned.

32768                       p NOSLEEP             Sleep spell cannot be cast on mob.

65536                        q NOBASH             Large mobs such as trees that can
                                                             not be bashed.

131072                      r NOBLIND             Mob cannot be blinded.

262144                      s NOTDEADYET      Reserved for internal use.
                                                             Do not set.


      Affection Bitvector A bitvector (see section 2.4 on page 8 ‘Using Bitvectors’) with the following
   values:


1                  a                   BLIND Mob is blind.

2                  b                   INVISIBLE Mob is invisible.

4                  c                   DETECT_ALIGN Mob is sensitive to the alignment
                                        of others.

8                  d DETECT_INVIS                   Mob can see invisible characters
                                                                and objects.

16                 e DETECT_MAGIC                 Mob is sensitive to magical
                                                                presence.

32                 f SENSE_LIFE                        Mob can sense hidden life.

64                 g WATERWALK                       Mob can traverse unswimmable
                                                                 water sectors.

128                 h SANCTUARY                      Mob is protected by sanctuary
                                                                (half damage).

256                 i GROUP                  Reserved for internal use.
                                                   Do not set.

512                 j CURSE                  Mob is cursed.

1024                k INFRAVISION                  Mob can see in dark.

2048                  l POISON                  Reserved for internal use.
                                                        Do not set.

4096                 m PROTECT_EVIL                  Mob is protected from evil
                                                                   characters. No effect at present.

8192                 n PROTECT_GOOD                 Mob is protected from good
                                                                    characters. No effect at present.

16384                o SLEEP                                Reserved for internal use.
                                                                    Do not set.

32768                p NOTRACK                          Mob cannot be tracked.

65536                q UNUSED16                         Unused (room for future
                                                                                     expansion).

131072                  r UNUSED17                  Unused (room for future
                                                                    expansion).

262144                  s SNEAK Mob                  can move quietly (room not
                                                                                                      informed).

524288                  t HIDE                  Mob is hidden (only visible with
                                                                                                      sense life).

1048576                  u UNUSED20                  Unused (room for future
                                                                                                      expansion).

2097152                  v CHARM                  Reserved for internal use.
                                                                                     Do not set.

               Alignment A number from -1000 to 1000 representing the mob’s initial alignment.

                            -1000...-350 Evil
                            -349...349 Neutral
                             350...1000 Good

              Type Flag This flag is a single letter which indicates what type of mobile is currently being defined,
    and controls what information CircleMUD expects to find next (i.e., in the file from the
    current point to the end of the current mobile).
    Standard CircleMUD 3.1 supports two types of mobiles: S (for Simple), and E (for Enhanced).
    Type C (Complex) mobiles was part of the original DikuMUD Gamma and part of
    CircleMUD until version 3.0, but are no longer supported by CircleMUD v3.0 and above.
    Check with your local implementor to see if there are any additional types supported on your
    particular MUD.

For type S mobs, the type-specific information should be in the following format:


<level> <thac0> <armor class> <max hit points> <bare hand damage>
<gold> <experience points>
<load position> <default position> <sex>

Level The level of the monster, from 1 to 30.

            THAC0 “To Hit Armor Class 0” – a measure of the ability of the monster to penetrate armor and
    cause damage, ranging from 0 to 20. Lower numbers mean the monster is more likely to
    penetrate armor. The formal definition of THAC0 is the minimum roll required on a 20-sided
    die required to hit an opponent of equivalent Armor Class 0.

            Armor Class The ability of the monster to avoid damage. Range is from -10 to 10, with lower
    values indicating better armor. Roughly, the scale is:
    AC 10 Naked person
    AC 0 Very heavily armored person (full plate mail)
    AC -10 Armored Battle Tank (hopefully impossible for
    players)

    Note on THAC0 and Armor Class (AC): When an attacker is trying to hit a victim, the
    attacker’s THAC0 and the victim’s AC, plus a random roll of the dice, determines whether or
    not the attacker can hit the victim. (If a hit occurs, a different formula determines how much
    damage is done.) An attacker with a low THAC0 is theoretically just as likely to hit a victim
    with a low AC as an attacker with a high THAC0 is to hit a victim with a high AC. Lower
    attacker THAC0’s and higher victim AC’s favor the attacker; higher attacker THAC0’s and
    lower victim AC’s favor the victim.

            Max Hit Points The maximum number of hit points the mobile is given, which must be given in
    the form “xdy+z” where x, y, and z are integers. For example, 4d6+10 would mean sum 4
    rolls of a 6 sided die and add 10 to the result. Each individual instance of a mob will have the
    same max number of hit points from the time it is loaded into the game right up to the time
    it dies; the dice will only be rolled once when a particular instance of the mob is created. In
    other words, a particular copy of a mob will always have the same number of max hit points
    during its life, but different copies of the same mob may have different numbers of max hit
    points.
    Note that all three numbers, the “d” and the “+” must always appear, even if some of the
    numbers are 0. For example, if you want every copy of a mob to always have exactly 100 hit
    points, write 0d0+100.

            Bare Hand Damage (BHD) The amount of damage the mob can do per round when not armed
    with a weapon. Also specified as “xdy+z” and subject to the same formatting rules as Max
    Hit Points. However, unlike Max Hit Points, the dice are rolled once per round of violence;
    the BHD of a mob will vary from round to round, within the limits you set.
    For BHD, xdy specifies the dice rolls and z is the strength bonus added both to BHD and
    weapon-inflicted damage. For example, a monster with a BHD of 1d4+10 will do between
    11 and 14 hitpoints each round without a weapon. If the monster picks up and wields a tiny
    stick which gives 1d2 damage, then the monster will do 1d2 + 10 points of damage per round
    with the stick.

            Gold The number of gold coins the mobile is initially loaded with.

            Experience The number of experience points the mobile is initially loaded with.

            Load Position The position the mobile is in when loaded into the game, which should be one of
    the following numbers:

      0       POSITION_DEAD       Reserved for internal use.
                                              Do not set.

      1       POSITION_MORTALLYW       Reserved for internal use.
                                                        Do not set.

      2       POSITION_INCAP       Reserved for internal use.
                                               Do not set.

      3       POSITION_STUNNED       Reserved for internal use.
                                                    Do not set.

      4       POSITION_SLEEPING       The monster is sleeping.

      5       POSITION_RESTING       The monster is resting.

      6       POSITION_SITTING       The monster is sitting.

      7       POSITION_FIGHTING       Reserved for internal use.
                                                    Do not set.

      8       POSITION_STANDING The monster is standing.

            Default Position The position to which monsters will return after a fight, which should be one of
    the same numbers as given above for Load Position. In addition, the Default Position defines
    when the mob’s long description is displayed (see “Long Description” above).

            Sex One of the following:

              0       Neutral (it/its)
              1       Male (he/his)
              2       Female (she/her)

#3062
fido dog~
the beastly fido~
A beastly fido is mucking through the garbage looking for food.
~
The fido is a small dog that has a foul smell and pieces of
rotted meat hanging around his teeth.
~
afghq p -200 S
0 20 10 1d6+4 1d4+0
0 25
8 8 1

            This is mobile vnum 3062. The Fido’s action bitvector indicates that it has a special procedure
    (bit a), is aggressive (bit f), stays in its own zone (bit g), is wimpy (bit h), and cannot be bashed (bit
    q). Also, the Fido cannot be tracked (affection bit p), and has an initial alignment of -200. After the
    S flag we see that the Fido is level 0, has a THAC0 of 20, an Armor Class of 10, 1d6+4 hit points
    (a random value from 5 to 10), and will do 1d4 hit points of bare hand damage per round. The Fido
    has 0 gold and 25 experience points, has a load position and default position of STANDING, and is
    male.

Type E mobiles are specific to Circle 3.1 and are designed to provide an easy way for MUD implementors
to extend the mobile format to fit their own needs. A type E mobile is an extension of type
S mobiles; a type E mobile is a type S mobile with extra data at the end. After the last line normally
found in type S mobs (the one ending with the mob’s sex), type E mobiles end with a section called
the Enhanced section. This section consists of zero or more enhanced mobile specifications (or
E-specs), one per line. Each E-spec consists of a keyword followed by a colon (“:”) and a value.
The valid keywords are listed below. The literal letter E must then come after all E-specs to signal
the end of the mob.

        The format of an E mobile is as follows:

  <level> <thac0> <armor class> <max hit points> <bare hand damage>
  <gold> <experience points>
  <load position> <default position> <sex>
  {E-spec list}
   E

Let’s say that you wanted to create an enhanced Fido like the one in the previous example, but one
that has a bare-hand attack type of 4 so that the Fido bites players instead of hitting them. Let’s say
you also wanted to give this Fido the a strength of 18. You might write:

#3062
fido dog~
the beastly fido~
A beastly fido is mucking through the garbage looking for food.
~
The fido is a small dog that has a foul smell and pieces
of rotted meat hanging around his teeth.
~
afghq p -200 E
0 20 10 1d6+4 1d4+0
0 25
8 8 1
BareHandAttack: 4
Str: 18
E

In the above example, the two E-specs used were BareHandAttack and Str. Any number of the Especs
can be used in an Enhanced section and they may appear in any order. The format is simple:
the E-spec keyword, followed by a colon, followed by a value. Note that unlike type S mobiles,
type E mobiles require a terminator at the end of the record (the letter E).

            The only keywords supported under Circle 3.1 are BareHandAttack, Str, StrAdd, Int, Wis, Dex,
    Con, and Cha. However, the E-Specs have been designed such that new ones are quite easy to
    add; check with your local implementor to see if your particular MUD has added any additional
    E-Specs. Future versions of CircleMUD will have considerably more features available in the
    Enhanced section such as the ability to individually set mobs’ skill proficiencies.

            BareHandAttack This controls the description of violence given during battles, in messages such
    as “The Beastly fido bites you very hard.” BareHandAttack should be one of the following numbers:

                        0             hit/hits
                        1             sting/stings
                        2             whip/whips
                        3             slash/slashes
                        4             bite/bites
                        5             bludgeon/bludgeons
                        6             crush/crushes
                        7             pound/pounds
                        8             claw/claws
                        9             maul/mauls
                        10             thrash/thrashes
                        11             pierce/pierces
                        12             blast/blasts
                        13             punch/punches
                        14             stab/stabs

    Messages given when attackers miss or kill their victims are taken from the file lib/misc/messages.
    The attack type number for weapons is 300 plus the number listed in the table above, so
    to modify the message given to players when they are mauled, attack type number 309 in
    lib/misc/messages should be changed. Note that adding new attack types requires
    code changes and cannot be accomplished simply by adding new messages to lib/misc/messages
    (see the CircleMUD Coding Manual for more information).

            Str, Int, Wis, Dex, Con, Cha The mobile’s Strength, Intelligence, Wisdom, Dexterity, Constitution
    and Charisma, respectively. These values should be between 3 and 18, but can be between
    1 and 25 (which is the default statistic maximum).

            StrAdd The mobile’s strength addition, which can range from 1 to 99.