#MOBILES Section

The #MOBILES section consists of the #MOBILES header, one or more mobile descriptions (see below) and the #MOBILE section ender #0 as shown here:

#MOBILES mobile descriptions #0

A mobile description looks like this:

#vnum keywords~ short description~ long description ~ extended description ~ race~ Actflags Affectflags Alignment S level hitroll hitpoints mana damroll damagetype ACpierce ACbash ACslash ACmagic Offensive Flags Immunity Flags Resistance Flags Vulnerability Flags position1 position2 sex silver 0 0 size 0

There is an example at the end of this page.

Here's what the (underlined) terms mean:

#vnum

Each unique mob gets a unique vnum as assigned on your mob list. Remember to precede the vnum with the hash sign ('#')!

Although the MUD program does not care whether the vnums for mobs are in ascending order and consecutive, your area file will be very difficult to maintain if this is not so. Start with the first vnum you were assigned and number consecutively up to as many as you need for all your mobs.

keywords

These are all the words by which the player can refer to the mob. A more sensible name for this field would be 'name'. In order for the player to be able to refer to the mob in 'kill mob' and other interaction, at least some of the keywords should be words visible in the mob's long description (see below), which he sees when he first encounters the mob, and the short description (see below), which he sees when he interacts with the mob. The simplest way to get this right is to code some keywords from the 'short name' on your mob list, then code the long and short descriptions, then come back to the keyword list and add any keywords you think the player may consider using after having seen the short and long description.

Example: You build a dragon. Keyword as per the mob list: 'dragon'. You later build a long description stating 'A huge green creature flies overhead, spewing flame everywhere'. Unless you're playing some kind of guessing game with the player, you MUST add 'creature' to the keywords because that's the only noun the player sees. How is he to guess the critter is a dragon? It's a good idea to add 'green' and maybe 'huge' to allow the player to choose between this and other dragons, and because he may prefer to call it 'green' rather than 'dragon'. Also, for mobs of which there are many different kinds in the game, several keywords will help single it out when using spells like locate life.

Don't forget the tilde ('~') at the end of the keywords line!

short description

This is the description the player sees when interacting with the mob, when the mob does something, or when the player sees it in a scan. This desc should only take up about half a line and fit onto the end of a sentence like 'you viciously slay ... '. There should be no period at the end of the short description.

Don't forget the tilde ('~') at the end of the short description!

long description

This is the description the player sees when he looks in the room or enters the room. Example: 'A huge green dragon flies overhead.' This must be a full sentence starting with a capital and ending with a period.

Note that the tilde ('~') goes into the next line after the end of the long description!

extended description

This is the description a player sees when he looks at the mob itself, or examines it. This is usually the lengthiest description, including details such as the color of the mob's scales and the smell of its breath.

Note that the tilde ('~') goes into the next line after the end of the long description!

race

The race of a mob determines what kind of critter it is. Although the race designator itself is only visible in a high-level CON and to immortals, it's a very nice touch to make it consistent with the description of the mob. Much more important, though, is the fact that the race determines which affect flags, offensive abilities, immunities, resistances and vulnerabilities (all these terms are defined below, don't worry for now) the mob is born with and will have regardless of what else you code into it.

Examples:

• Bats are always created with the ability to fly and a vulnerability to light.
• Bears are created with offensive abilities of crushing, disarming and berserking.

When adding actflags and offensive capabilities to a mob, remember to consider the ones it gets automatically so you don't unwittingly create a monster!

For a complete list of races available in Dizzy MUD, refer to the race table.

Note the 'unique' race at the end of the table. This race has NO flags on it and can be used as a starting point for a special kind of creature unlike any of the others. It will only have whatever flags you code into it.

If you code a race that is not in the table, the MUD will substitute unique by default.

There are two more fields in a race description which are not covered in this guide and not included in the race table: 'form' and 'parts'.

Form

describes basic attributes like 'edible biped animal mammal'. In DizzyMud, nobody bothers much with coding this field. The predefined mob types from the Race Table all have reasonable forms for their type and coders just leave it that way.

Parts

is a list of the body parts of which the mob consists and into which it can potentially decompose when it dies. Again, there are sensible defaults in the Race Table and coders don't pay any attention to parts.

Actflags

Actflags are the first flag field in this guide. There are several others, and the rules for their formation and significance are the same for all although each flag field means something different. An explanation of flag field coding for act flags follows, but you are welcome to take a quick side trip to Flag Fields Explained for an explanation of how to code flag fields in general. This general explanation will be referred to for all other flag fields which follow.

Actflags describe the way a mob may act. For example, the ACT_SENTINEL flag makes the mob stay put in the room you reset it in. The ACT_HEALER flag turns a mobile into a healer. ACT_AGGRESSIVE would make a mob attack players.

Nobody wants to type lengthy keywords like ACT_IS_HEALER into each of their mob descriptions, and happily these keywords are replaced by numbers in most MUDs and by letter codes in DizzyMUD.

The Act Flag Table shows all act flags available in DizzyMUD, their letter codes and their meanings.

The Actflags field is assembled by sticking all relevant letters together into one contiguous string.

Example: We want to code an aggressive, no-push mob that stays in its room: Looking up ACT_AGGRESSIVE, ACT_NOPUSH and ACT_SENTINEL in the table, we find the letters 'F', 'Z', and 'B'. We rearrange these letters in alphabetical order to make it easier for someone else (perhaps ourself!) to decode, and come up with an Actflags field value of BFZ.

Notes:

1. The letter codes are case sensitive! This means that 'a' does not mean the same as 'A'.
2. Every flag field such as the Actflags field must have at least one character in it, or... well, it isn't there, and whatever you meant to code for the next field falls into the one that you coded nothing for. If you want no flags, you must code a '0' (zero) for that field.
3. Several of the lines in a mob description contain more than one flag field in a row. Obviously, you cannot run the letters from one flag into those of the next; you must use a space (' ') to separate one field from the next.

Affectflags

Affect flags specify a large variety of spells and spell-like conditions (called 'affects' in MUD terminology) to which the mob is subject from the time of its creation. Although many affects do the same thing as spells or skills of the same name, many do not work the same way; look at the affect flag table for details! Also, affect flags have no timer; they stay with the mob for its entire life unless someone manages to dispel them.

Affect flags are coded as letter groups just as Actflags are; refer to the explanation, above, or to Flag Fields Explained if you're fuzzy on how this is done.

All Affectflags in use in DizzyMUD can be found in the Affect Flags Table.

A few tips on affect flag useage

• Carefully consider what kind of mobile you are coding, and give it affects appropriate to its race and profession if it does not have them already (check the Race Table for this). Dragons, birds, and bats are the standard examples of mobs which should have AFF_FLYING. But if you put the 'stock' race of 'dragon', 'bird', 'bat', 'vampire' or 'wyvern' in the race field, they will have this affect by default. On the other hand, if you code a Martian and that Martian is naturally able to fly, he should have AFF_FLYING coded into his affects. You could code a leper into your area, permanently affected by AFF_PLAGUE. If you code a public servant, you may want an AFF_SLOW on him.
• Some of the affect flags are very powerful. AFF_SANCTUARY, for example, means that the mob affected by it will always be hit only half as hard. This affect should rarely be given to mobs below level 40 and routinely to mobs above level 60. Mobs above level 60 without Sanc must be 'toughened' some other way, either by giving them many HP and/or ACT_AGGRESSIVE and/or AFF_HASTE.
  Be aware that PROTECTION GOOD and PROTECTION EVIL are half as effective as Sanctuary, meaning they should also be applied with care, and that a mob affected by HASTE does a lot of damage in a short time, and should be the exception.
• AFF_DETECT_INVIS and AFF_DETECT_HIDDEN are good for the occasional guard mob if you want to make sure players have a hard time sneaking by. But if you give these abilities to all the mobs in your area, it makes the INVIS and HIDE spells useless to players, needlessly frustrating them. Better to let them think they have found a clever new way to outsmart some mob.

Alignment

Just like players, mobiles can have alignments from -1000 (satanic) to 1000 (angelic). Alignment-based coding in the game tends to put players in the -350 to 350 range into a 'neutral' category for spells. Alignment-based experience adjustment happens outside the -200 to 200 range. Anyway, 0 is neutral for sure. Really evil mobs give good players good exp, and really good mobs give evil players good exp. Nobody really likes neutral mobs.

At low levels, say below 30, mob alignments should not hit the extremes, a few hundred either way is enough at these levels. Low level players gain so much exp from killing that it's OK to code 0 alignment mobs too.

In all cases, remember to make the mob's alignment match its character and the role it plays in your 'story'. Assassins are usually evil and firemen are usually good. If you're clever, you could come up with reasons for coding either of these with the opposite alignment, but your area would have to contain a good story to make this plausible to the player.

S

The line ends in an 'S', which some say stands for 'simple'. Some other MUDs code so-called 'mob groups' into this field, these groups forming a basis for mob assists. Dizzy gives you so many other complicated fields to think about that you can do without this one. But no matter what you do, this S needs to go here! If you leave it out your area won't load into Dizzy. There is no tilde ('~') after the S.

level

Mobs can be coded into any old level from 1 to 120. You want to make your area header and the levels of your mobs match to some extent.

hit roll

Hit roll determines (in part) how likely a character is to hit a target in combat. Higher values of hit roll indicate greater chances of hitting. Mobs have a certain amount of basic hit roll based on their strength and level; this field only encodes an additional bonus. For low level mobs, it should be left at 0 or even pushed into small negative numbers. Level 90 mobs may attain values of about 18 for this number if you want them to be great fighters. Levels in between may be given correspondingly lower values, a rule of thumb being 'no more than 1 for every 5 levels.' Note that even a level 90 mob can handle itself well with a 0 value in this field.

hitpoints

The 'hitpoints' field determines how many hit points a mob is created with. Unlike player characters, whose hit points are closely determined by race, class, level and equipment, mobs get a number of hit points 'rolled' (i.e. randomized) by the game based on what you code into this field. The basic format for this field is:

XdY+Z

where
X represents a number of imaginary dice,
Y represents the number of sides on each of these dice and
Z is an additional constant bonus added to the results of the roll,
and the d and the '+' need to be there verbatim to separate the numbers.

Example: You code 2d5+9
With 2 dice of 5 sides, you can roll any number between 2 (two ones) and 10 (two fives). 9 is always added to the result, so your range is from 11 to 19. The average result is probably more interesting. The average value for XdY+Z comes up to

( X times Y + X ) divided by 2 + Z

so for 2d5+9 the average hitpoints would be (2*5+2)/2+9 = 12/2+9 = 6+9 = 15.

You may want to skip all the fancy math and just code a fixed number of hit points for your mob; this will save you sleepless nights wondering just how it will come out. For a fixed number of hit points, just code

1d1+(one less than the number of HP you want).

To get a 100 HP mob, just code 1d1+99 . Presto.

For a good starting point on how many HP to give your mob, you can use

Etaine and Whitey's HP Guide for Mobiles,
quoted from Lotus' Area Coding Guide

level range	HP per level
level 1-10	10-15 HP per level
level 11-20	15-20 HP per level
level 21-30	15-30 HP per level
level 31-40	20-35 HP per level
level 41-60	20-55 HP per level
level 61-70	35-70 HP per level
level 71-??	50-100 HP per level

High level mobs in Dizzy, especially in Divided Souls, often have far more HP than indicated by this table. These mobs take forever to kill, are boring for players and cause the area to be generally avoided. We recommend sticking to this table and using other means instead to make mobs more challenging. Affects, offensive abilities, etc. can help achieve this.

mana

The amount of mana you give a mob is coded the same way as hit points (see right above), as a random-rolled value plus a constant bonus:

XdY+Z

At the moment, mobs in DizzyMUD do not use mana, thus what you code here does not matter much. However, there are future plans to have mobs use up mana when they cast spells, and then this field would end up being important. For simplicity's sake, for the time being just give them a lot less mana than HP. You can CONsider some mobs in a similar-level area to the one you're writing to get some ideas.
Although currently unimportant, you may not leave this field out or your area won't load.

damroll

A mob's dam roll determines how much damage a hit from the mob will do in a fight. The dam roll you give a mob is coded the same way as hit points and mana, as a random-rolled value plus a constant bonus:

XdY+Z

The XdY component simulates a dice roll and is random; the Z component is a constant tacked on. A mostly-constant dam roll will make your mobs' hit strength very predictable and this is considered boring; a completely random dam roll may leave your mob sometimes much wimpier than appropriate for its level, so you want a sensible mix.

A rule of thumb is: The average damage (see 'hitpoints', above. for the formula) should be

(level divided by 2) + 5

Example:
Suppose you want to make a level 50 mob. The above formula says it should have (50/2)+5 = 25+5 = 30 average damroll. Split this about halfway between your constant factor and your random dice rolls and this means your Z will need to be 15 and you have to come up with an average random damroll of 15 as well. A little trial and error comes up with 5d5 as reasonable numbers. So this mob would get damroll coded as: 5d5+15.

Damroll is one of the factors you can vary to compensate for strengths or weaknesses elsewhere. Mobs with few capabilities and affects will need more damroll to be a challenge, while mobs armed to the teeth should hit a little less hard to not kill the player too fast.

damagetype

If a mob is wielding a weapon, that determines the damage type and message when the mob gets a hit on an opponent. However, when the mob is not fighting with a weapon, its damage type (and resulting message) are taken from this field.

Because these damage types also apply to weapons, the information about which string you must code, the resulting damage type and the message which is seen is linked into the Damage Type Table.

Check out the 'Explanation' column for my own rough guess at what some of the more common messages signify. If you can't make up your mind or can't think of anything appropriate, just code 'none' and the game will call the damage a 'hit'.

ACpierce ACbash ACslash ACmagic

I'll describe these 4 fields together because they all work the same way.

ACpierce	is the armor class against piercing (DAM_PIERCE in the program).
ACbash	is the armor class against bashing (DAM_BASH in the program).
ACslash	is the armor class against slashing (DAM_SLASH in the program).
ACmagic	is the armor class against exotic damage (other DAM_ types).

A rule of thumb for mob armor class calculation is: Each AC should be negative ten times two thirds of the mob's level. The 4th (magic/exotic) AC should be a little worse.Example: For a level 60 mob, -10 * 2 * 60 / 3 = -400.
So a sensible set of ACs would be: -410 -390 -400 -340 .

The next thing to know is that AC is coded at 1/10th of what you want to end up getting. So to get -410 -390 -400 -340, you would code:
-41 -39 -40 -34.

If you want your mob to have exactly the AC you figured out here, your problems are not over yet. Due to the intricacies of mob creation, you have to take into account several factors which change the mob's AC in creation:

Armor

Obviously, if you're going to have your mob wearing armor, this will enhance its AC the way it will for any character. If all mobs of a given type will be wearing the same armor, you may want to subtract its effect out before you code the mob. Note that it's not enough to simply subtract out the sum of the armor classes; the AC effect is multiplied by anywhere from 0 to 3 depending on where the mob is wearing it. Consult the Armor Wear Location Table for details.

Dexterity

A mob's dexterity will affect all 4 AC's by +60 to -120. So to get the AC for your mob right, you will need to check out
Mob Stats to find out your mob's dex and
Dex Effect on AC to get the effective AC.

Offensive flags

Offensive flags describe the offensive abilities of a mob, i.e. those tactics it can (and usually will) employ in a fight. Also included in this category are a few ASSIST flags, i.e. flags which determine that a mob will assist another character fighting in its room if that other character meets the requirements for that particular kind of assistance.

Offensive flags are yet another flag, coded like ACT flags and AFFECT flags, above. The names of the flags, their correct encoding and their significance can be found in the Offensive Flag Table.

Be careful not to go overboard with offensive flags on low level mobs. OFF_FAST, in particular, makes a mob very powerful. Newbies with little weapon skill have hardly a chance of hitting a mob with OFF_DODGE or OFF_PARRY. Mobs above level 60, on the other hand, should have both OFF_DODGE and OFF_PARRY. If they are missing either one, they should at least have OFF_TRIP, OFF_BASH or OFF_BERSERK to compensate.

Immunity Flags

The Immunity Flags field encodes all those attacks a mob is immune to. To the player, an immunity translates to: The mob is not affected by an attack of this type. The encoding for these immunities is found in the Immunity/Resistance/Vulnerability Flag Table.

Be very sparing with immunities. Immunity should only be used if it is needed to make a mob fit into the context of its surroundings and the area's story. Special care is needed before giving mobs immunities to MAGIC or WEAPONS, as the one completely disadvantages mages and the other, warriors.

Some important examples of legitimate uses for immunities are mobs of public interest, such as shopkeepers, healers, trainers and guildmasters, whom you want to be unkillable so they can serve the public at all times. To achieve this, you need 'ABCD' to protect them from SUMMON, CHARM, MAGIC and WEAPONS. Another kind of useful invulnerable mob is a so-called 'chainpost'. Which attacks you make it invulnerable to is up to you, of course.

Resistance Flags

The Resistance Flags field encodes all those attacks to which the mob is resistant. If the attack is a spell, resistance to it improves saves by -2. If the attack does damage, resistance reduces damage by one third.

The encoding for these resistances is found, along with immunities and vulnerabilities, in the Immunity/Resistance/Vulnerability Flag Table.

Vulnerability Flags

The Vulnerability Flags field encodes all those attacks to which the mob is vulnerable. If the attack is a spell, vulnerability to it worsens saves by 2. If the attack does damage, vulnerability increases damage by one half.

The encoding for these resistances is found, along with immunities and vulnerabilities, in the Immunity/Resistance/Vulnerability Flag Table.

If you code a general immunity to magic (IMM_MAGIC) or weapons (IMM_WEAPON) in the Immunities field but then code vulnerability to a specific attack type, the vulnerability partially cancels the immunity, resulting in the attack affecting the mob as if it was only resistant to the attack.

Position1

This is the position in which the mob is loaded when it resets. The following positions are available, and must be coded verbatim as one of these words: stand, sit, rest, sleep.

Position2

This is the position which the mob assumes after a fight, should it survive. The following positions are available, and must be coded verbatim as one of these words: stand, sit, rest, sleep.

Sex

The following are possible choices for the mob's sex and must be coded verbatim: none, male, female, either.

none encodes the neuter sex, which gets the pronoun 'it'.
either indicates that this mob may randomly reset as either a male or female. Be careful how you write the description for an 'either' mob! It's not easy to write a description containing no personal pronouns which give away the fact that you had a certain sex of mob in mind when you wrote the description.

A mob's sex is relevant only for role playing and area plot purposes; male, female and neuter mobs act identically in every way, including in a fight.

Silver

This is (approximately) the amount of money which the mob owns when it resets. A random factor is applied to the amount you code, which is always assumed to be in silver coins. The actual amount is then partly converted to the equivalent worth of gold coinage so the mob usually ends up holding a mix of silver and gold coins.

A recommended rule of thumb is: No more than 100 silver per level, usually considerably less.
A hard and fast rule is that mobs should only own money if this makes sense in the area story and role playing context. In general, only intelligent mobs should own money. It makes no sense to find a boar deep in the forest carrying gold and silver coinage.

Size

This field encodes the size of your mob. You can choose from the following sizes, which appear in ascending order of size and must be coded verbatim: tiny, small, medium, large, huge, giant.

Obviously, you should code your mob's size to make sense relative to its description. Giant caterpillars and tiny dragons will stretch your players' credulity.

The mob's size affects its function in the game in a few places. Large mobs bash and trip more successfully and are in turn harder to bash and trip. The starting strength and constitution of a mob are also influenced by its size, as shown on the Mob Stats page.

Important note: Remember to code two 0's (zeros) before the size field and one 0 after it. These 0's are placeholders for fields full of information DizzyMUD does not bother with, but they are necessary to keep the area reader in sync.

MOBILE example #6901 example mob~ An example mob~ An example mob stands here, awaiting your next move. ~ It would be just an ordinary example mob, were it not for the fact that it is more famous than the others. It found its way HERE! ~ unique~ BG 0 0 S 10 0 2d6+130 10d9+100 1d8+4 thwack 5 5 5 8 F 0 0 0 stand stand either 150 0 0 small 0