#OBJECTS Section

This page describes how to code object descriptions within an area file.
<< Back to #MOBILES Section Forward to #ROOMS Section >>

The #OBJECTS section describes in detail each different object you want to have in your area. Objects have fewer descriptive fields than mobs, so the basic layout of an object is simpler than that of a mob. However, there are some fields whose meanings vary with the type of the object, and there are many different types.

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

#OBJECTS
object descriptions
#0

A object description looks like this:

#vnum
keywords~
short description~
long description~
material~
type objectflags wearflags
value line (differs with type, see below)
level weight value condition
E
extended keywords~
extended description
~
A
applytype applyvalue
F
flag line

There is an example at the end of this page.

Here's what the (underlined) terms mean:

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

Although the MUD program does not care whether the vnums for objects 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 objects.

keywords
These are all the words by which the player can refer to the object. In order for the player to be able to refer to the object in 'take object' and other interaction, at least some of the keywords should be words visible in the object's short description (see below), and the long description (see below).

The simplest way to get this right is to code some keywords from the 'short name' on your object 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 or long description.

Example: You build a suit of armor. Keyword as per the object list: 'armor'. You later build a long description stating 'A shiny green suit of armor lies on the ground here'. Unless you're playing some kind of guessing game with the player, you MUST add 'suit' to the keywords so as to give the player a chance to call it 'suit' as well as 'armor'. You may also add 'green' so the player can refer to 'green armor' to keep it separate from other armors. For objects of which there are many different kinds in the game, several keywords will help single it out when using spells like locate object.

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 object, when he sees the object in his inventory, equipment or a container. This desc should only take up about half a line and fit into a sentence like 'you wear ... on your head'. 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 and the given object is lying on the ground. Example: 'A shining green suit of armor lies here.' This must be a full sentence starting with a capital and ending with a period. In spite of its name, the long description should not be very long. One line should be enough to tell the player what he is looking at. The full description and life history of the object go into the extended descriptions (see below).

If you are building a puzzle and don't want the player to see an object upon entering a room or using LOOK, then you may leave out the long description but not the tilde! This is often done with portals and containers (containing valuable items) because it makes the most sense in this context. It is absolutely necessary in such cases to mention the hidden object in the room description, though, or it will never be found. If you use an empty long description, you must still always enter a short description. Otherwise meaningless messages result when the object is manipulated.

Note that the tilde ('~') goes at the end of the line containing the long description! This is not consistent with the way it's done for #MOBILES, so you will have to remember to do it right.

material
This is what the object is made of. It seems to be immaterial, (pardon the pun) as it's shown by LORE and the IDENTIFY spell but doesn't seem to affect anything. It's there for realism and role play, mainly. So you can code any old string here that maintains credibility. The tilde, however, is mandatory, as always.

type
The single word in this field indicates what kind of object you are describing. It must be one of the keywords found in the Item Type and Value Line Table. Coding the item type correctly is crucial to producing the right object.

objectflags
The object flags encode the properties of an object. To code them, you enter either a 0 (for no properties) or an appropriate combination of the letters found in the Object Flag Table.

wearflags
Wear flags indicate how the object may be used. Most equipment items will have a TAKE flag and may have one (or rarely more) of the others. For the rare item that has no flags at all (such as a fountain, which cannot be taken, worn or anything), code a 0 (zero). For all others, refer to the Wear Flag Table.

value line
The value line must always contain 5 items. These may be keywords, single-quoted strings, flag letters or numbers. The contents of the 5 slots are different for each item type. Consult the Item Type and Value Line Table for details on how to code the value line for your item.

level
The level of the object, as a single number in the range from 0 to MAXLEVEL (currently 100). Trying to equip a mob with an item of level higher than the mob results in a bug message at load time. Please don't! This would also make valuable equipment too easy to get.

weight
The weight of the object, expressed in tenths of pounds. i.e. you want to code 10 times the weight in pounds. Be somewhat realistic.
Some guidelines:

value
The cost of the item, in silver. For Quest Items, i.e. those having an ITEM_QUESTSELL object flag, the cost is in Quest Points.

condition
The condition of an object is coded as a single letter, as follows:
PPerfectDDamaged
GGoodBBroken
AAverageRRuined
WWornIIndestructible
An indestructive item will not change condition no matter how much it is used. Coding an item as ruined makes no sense because the item can still be used but will not deteriorate further. For minimum lifetime, code the item as broken. Most items are coded as perfect.

extended keyword(s)
extended description
Extended keywords and an extended description, together with the preceding 'E' and the two separating tildes ('~') make up what I'll call a detail description. Detail descriptions are optional, that is, the MUD program won't mind if you don't have a single one in your object. But to give the players in your area a richer experience, all items should have at least one detail description. Each object can have as many of these detail descriptions as you want, one after the other, each with its own 'E', extended keywords, tilde, extended description and final tilde.
Detail descriptions are used to convey additional information about an object, which the player accesses by LOOKing or EXAMINEing the keyword.
A sword, for example, may have:

keywords: sword double edged
short description: a double-edged sword
long description: A double-edged sword gleams evilly on the ground.
first detail description
extended keyword: sword double edged edges
extended description: This sword has a very wicked looking blade. Both edges are slightly jagged but appear to be razor sharp! Some dark stains mar its surface.
second detail description
extended keyword: stains surface
extended description: Upon closer examination, the stains on the sword's surface turn out to be the remnants of old, dried blood. It's obvious that this sword was an instrument of deadly utility and no polished showpiece.

Here's how all these things interrelate:

What this means is that a general-purpose LOOK in the room will always show the object's long description ("A double-edged sword gleams evilly on the ground here"), but a LOOK SWORD will first try to match on an extended keyword. Since, in our case, 'sword' is one of the keywords for the first extended description, the player will get the story about the jagged blade with the razor sharp edges.
Thus, extended keywords are used to make sure a LOOK at an item will be directed at the detailed extended description rather than the relatively short so-called long description. To make sure this works no matter which keywords the player LOOKs at, your best bet is to duplicate all of the object's keywords into the keywords of the first detail description.

If there is no detail description with keywords matching the object's keywords, all the player sees is the long description ("A double-edged sword gleams evilly on the ground here") yet again. If most objects in an area have no detail descriptions, players will be bored by what they find and will quickly cease LOOKing at anything.

In our case, the player is curious about the sword and types LOOK SWORD. He is shown the first extended description. Note that a clever player may deduce that a 'double edged sword' has two edges, and may think to type LOOK EDGES. This is why the extra keyword 'edges' was included in the list.

Our inquisitive player is intrigued by the stains on the sword's surface (both are words he sees in the first extended description) and so he types LOOK STAINS or perhaps LOOK SURFACE. By building a second detail description keyed by these two words, we give the player the chance to find out more about the item.

Some puzzle or quest items have been known to have long strings of detail descriptions, with nouns in one extended description being used as keywords in another detail description. By continually LOOKing at words he sees in an item's description, the player can thus dive into a long and detailed story. Note that, in most cases, nouns are used to link descriptions together. Most often, the extended keywords will be one or more of the exact words found in another extended description, but for extra difficulty synonyms or other words derived from a description may also be used. However, try not to expect miracles from the players. If you think players may need prodding to dig their way through detail descriptions, you may use color coding to highlight those words in a description leading to another detail description.

applytype
applyvalue
An object can be given the ability to enhance or worsen a player's stats if equipped. This is done by specifying an Apply Type and an Apply Value, the combination of which I'll call an Apply.
The Apply Type specifies which stat is changed, in accordance with the Apply Type Table. The Apply Value specifies by how much the stat is changed.
Applies are optional; an object may have none of them, or as many as make sense and do not disrupt game balance. Each individual apply is coded as two lines, with an A in the first line and an apply type and apply value in the second.
Apply values are added to the character's stats of that type. Negative values can be used to reduce the user's stats. This is beneficial for Armor Class and SAVEs.

Example:
A
32
 
Improve INT by 2.
 
A
5-1
Decrease CON by 1.
 
A
17-5
Improve AC by -5.

Lotus, Dizzy MUD's Creator, formulated some guidelines for object stats, especially applies, which make good sense and form a sound basis for off-the-cuff balancing of your equipment:



As Lotus said, the above rules are not carved in stone. You may be flexible to some extent in that you may code some (few) objects with stats well in excess of these guidelines in individual respects, but that you will need to balance these overshoots by making the equipment inferior in other ways. If you attempt to do this, you need to be very familiar with the stats of other, similar equipment in the game because you MUST stay within the limits of game balance or your creations will be turned down.

flagline
Flag lines are actually 2 lines each. They serve 3 purposes: In all cases, these changes are applied to a character when that character wears, holds or wields the object so flagged.

Like applies, flag lines are optional. Use none or as many as required. Each apply must adhere to the syntax shown below, starting with the F line and continuing with a A, I, R or V line as shown.

Flag Line Syntax Table
Affect flag line (for affects)
F
A00Affect-flags
The affect flags are coded as a combination of letter codes as found in the Affect Flag Table. Although the table speaks of mobs, the same effects can be coded on objects, and will affect a character equipping with that item, including the same silly malfunctions mentioned for the mob affects. If in doubt, experiment.

Example:
F
A 0 0 DF
  An object flagged like this will enable its wearer to DETECT INVIS and DETECT HIDDEN.

The effects of objects flagged in this manner are PERMANENT, i.e. the object will confer the affect on the player whenever it is used, for as long as the object exists. Therefore, some affects should be coded either only for immortal use or not at all. Things like SANCTUARY make an object far too powerful; areas with such items coded in them will likely be turned down or returned for correction.

Immunity flag line
F
I00Immunity-flags

The immunity flags are coded as a combination of letter codes as found in the Immunity/Resistance/Vulnerability Flag Table. Although the table speaks of mobs, the same effects can be coded on objects, and will affect a character who wears, holds or wields an object so coded.

With possible rare exceptions, immunities should not be coded into any objects. Most immunities make the bearer so powerful any objects thus coded are a threat to game balance.

Resistance flag line
F
R00Resistance-flags

The resistance flags are coded as a combination of letter codes as found in the Immunity/Resistance/Vulnerability Flag Table.

Resistance flags confer a big advantage to the bearer of an object so coded, therefore these flags should be put on objects only in rare cases which have been cleared with the Implementor beforehand.

Vulnerability flag line
F
V00Vulnerability-flags

The vulnerability flags are coded as a combination of letter codes as found in the Immunity/Resistance/Vulnerability Flag Table.

Vulnerability flags are not subject to restrictions. Any player who equips an object which makes him vulnerable does so by his own choice and at his own risk. A minor vulnerability on an otherwise good object might be considered as an interesting way to force a player to weigh his alternatives.

Affect flag line (for applies)
F
Aapplytypeapplyvalue0

This kind of coding may be used to put applies on objects. The outcome is the same as if applies (using an A line and just the two numbers as described above under applytype/applyvalue) are used. This method is just more complicated and more confusing. While it's possible to combine an apply with, say, an affect or an immunity using this syntax, it makes for a hard-to-maintain area to code objects like this, and I strongly advise against doing this.

OBJECT example
#30015
lantern silver~
a silver lantern ~
A silver lantern spreads some light here.~
silver~
light AG A
0 0 -1 0 0
40 0 4000 P
E
lantern~
The lantern looks quite valuable. The light it spreads
seems to be very special.
~
E
light~
This light does more for you than just lighten the darkness!
It seems to be able to reveal each and everything!
~
A
26 2
A
18 2
A
19 2
F
A 0 0 DF


<< Back to #MOBILES Section Forward to #ROOMS Section >>


  This page was last updated May 15, 2001