Chapter 3

Objects in the Tree

As mind is the witness and reality of all dream-objects, so soul is the only reality in the diversities of this universe.
--Bhagavat Gita

There are four basic object types. Each has its own special properties, as well as those that they all share. The basic objects are mob, obj, turf, and area. There are other objects as well, but these four are the ones which are visible to players. We call them atomic objects.

The simplest difference between them is the order in which they appear on the map. Areas are drawn in the first layer. The icon of an area is often simply a solid background color. Turfs are drawn on top of areas; these usually represent some type of terrain like grass, roads, or walls. Objs are drawn next, and might stand for items such as swords or cookies. Mobs are drawn on top of everything else. They normally represent players or computer-controlled creatures. (The term mob stands for mobile object. It is also suggestive of monster, which is a common role they play.)

On the map, the mobs and objs are said to be contained by the turf. That in turn is contained by the area. It is also possible for mobs and objs to contain things. For example, a chest obj might contain a bunch of treasure items; and a player's mob could contain all the player's possessions.

Notice how I keep using words like `might,' `could,' or `normally.' That is because DM gives you, the designer, a great deal of flexibility. Many of the basic object properties were defined with a particular purpose in mind. That doesn't mean you have to use them that way. The meaning of the game objects is up to you.

Figure 3.4: Atomic Objects from Lowest to Highest Drawing Layer

area
turf
obj
mob

1. Object Properties

First let us look at the properties that all of the objects have in common. We have already seen that they each have a name and an icon. These are variables. (There are also some procs, but the discussion of those takes place later in chapter 7.) Here is a list of each variable and a description of its purpose.

  • name

    This is the name of the object, which by default is the same as the type (i.e. node) name with any underscores replaced by spaces.

  • gender

    The grammatical gender of the object may be set using this variable. The possible values are "neuter", "male", "female", and "plural". The default is "neuter".

  • desc

    This is a description of the object. It often appears in the "stat" panels when the player examines the object. Controlling the content of those panels will be discussed in section 7.3.

  • suffix

    This is some text commonly displayed after the name of the object in the "stat" panels. For example, this could indicate the status of equipment items: "(weapon in hand)", "(worn on body)", and so on.

  • text

    This is a single character used to represent the object on a non-graphical map. If you have ever played rogue or any of its derivatives, you will know what this means.

  • icon

    This is the icon file used to graphically represent the object.

  • icon_state

    Icon files may contain several alternate representations for an object. For example, a door could be open or closed. This variable is the name of the currently active state.

  • dir

    This is the direction the object is facing. Some icons may be directional, meaning that they look different depending on which way the object is pointed. This is most often used for mobs, which change direction as they move around.

  • overlays

    This is a list of icons or object types which appear on top of the object's main icon.

  • underlays

    This is a list of icons or object types which appear underneath the object's main icon.

  • visibility

    This is 1 or 0 to indicate whether the object is visible.

  • luminosity

    This is 0 to 6 to indicate how far the object emits light. Only areas are luminous by default, which has the effect of casting light on everything else in the area.

  • opacity

    This is 1 or 0 depending on whether the object blocks light. An opaque object will block the view of objects behind it.

  • density

    This is 1 or 0 to indicate whether the object fills up the space it occupies. Only mobs are dense by default. Normally, no two dense objects may occupy the same position (but you will see how to circumvent that in section 7.1).

  • contents

    This is a list of all the objects directly inside of an object. The term often used in the case of mobs is inventory. You will learn more about this and lists in general in chapter 10.

  • verbs

    This is a list of the verbs (that is, commands) associated with the object. These will be discussed in chapter 4.

  • type

    This is the type path of the object. For example, it might be /turf or /turf/trap. You could look at this value in a procedure in order to find out what type of object you are dealing with.

    1.1 Location

    The following location variables apply to all object types except areas, which never exist inside other objects. These variables are only used in proc code, which will be discussed in chapter 6.

  • loc

    This indicates the container of an object. In other words, if object A contains object B, B's loc will be equal to A, and B will exist in A's contents list.

  • x, y, z

    These indicate the position of an object on the map. Valid coordinates start at (1,1,1). The x and y coordinates represent east/west and north/south positioning, respectively. The z coordinate specifies the map level.

    1.2 Additional Mob Properties

    In addition to these commonly held variables, mobs add a few of their own.

  • key

    This is the login name of the player. By default, when a new mob is created for a player, the mob's name is set equal to this. Every key is unique--even when stripped of punctuation and ignoring case. That makes it a good way to keep track of people.

  • ckey

    This is the player's key in canonical form (stripped of punctuation and converted to lowercase). This is useful when saving information about the player for future use. More will be said about doing that in chapter 12.

  • client

    This is the player's client object (if any). The client object will be described in chapter 9.

  • sight

    This value controls special visual powers of a mob, permitting sight of invisible or obscured objects. It can be one or more of the following numerical constants added together: SEEINVIS, SEEMOBS, SEEOBJS, SEETURFS, BLIND.

    ( Normally, one uses the bitwise OR operator | to combine sight values. However, you can use a plain old + as long as you don't include the same value more than once. )

  • group

    This is a list of one's mob friends. It serves the very practical purpose of avoiding traffic problems. When a friend tries to move past another, the two switch places. Otherwise it can be rather annoying to continually bump into each other. This variable would be manipulated in the proc code.

    2. Assigning Variables

    By assigning a few variables, one can create a wide variety of objects. This is done in the object definition. For example, here are a few different combinations of opacity and density.

    turf
       floor
          icon = 'floor.dmi'
    
       wall
          icon = 'wall.dmi'
          density = 1
          opacity = 1
    
          secret_door
             name = "wall"
             density = 0
    
       window
          icon = 'window.dmi'
          density = 1
    

    This example defines four turfs: floor, wall, secret_door, and window. One can walk and see across the floor but not the wall. The secret door is just like a wall, except one can walk through it. To round out the set, the window is transparent but not traversable.

    Notice how we had to explicitly set the name of the secret door to wall to prevent the default secret door from taking effect. You would also need to do this if you wanted the name to contain a character that is not allowed in a node name.

    2.1 Constant Values

    This example illustrates three basic types of values: numbers, text strings, and resource files. These are called constant values.

    2.1.1 Numbers

    Numerical constants may be positive or negative, integer or floating point, and can make use of scientific notation. For example 3.15e7 or 31500000 is approximately the number of seconds in a year. The maximum possible value is 3.4e38 and the smallest is 1.4e-45. (The numerical limits are those of a single-precision IEEE floating point value, in case you were wondering.)

    2.1.2 Text

    Text constants are often simply called strings by programmers because they consist of a string of characters. They begin and end with a double quote. There are several special text macros that can be used inside the text. For example, a name is assumed to be a proper noun if it is capitalized. You can override that by using the \improper text macro.

    obj/CPU
       name = "\improper CPU"
    

    Like all text macros, \improper begins with a backslash. The space after it serves merely as a separator and is ignored. A complete description of this and other text macros will be given in section 11.3.

    In this particular example, the purpose of using \improper is to modify how the name of the object is treated in output text. As an improper noun, it would produce sentences like "You insert the CPU." rather than "You insert CPU." You will see exactly how to construct sentences like that later.

    2.1.3 Resource Files

    Resource files, such as icons or sounds are specified inside single quotes. For instance, to access an icon file located at C:\myworld\man.dmi, you would enter the value 'man.dmi'. You can make use of sub-directories within your project to organize things as you wish.

    2.2 Constant Macros

    If you use a particular value in several places, you might want to define a macro for it, rather than repeatedly entering the same value. This is also useful if you want to be able to easily change the value in the future. Rather than hunt for it in your code, you can simply change the definition. To easily identify them in the code, it is standard practice to capitalize macros. Example:

    #define MASTER_KEY "Dan"  //The all-powerful super-user!
    
    mob/DM
       key = MASTER_KEY
    

    This example defines a special mob type for use by the DM (Dungeon Master, Dream Maker, Dan Maestro, or whatever self-serving title you desire). No code has been included to this effect, but one could give the DM all sorts of awesome powers to manage the game. By defining the MASTER_KEY macro at the beginning of the code, it is easy to notice and change at a later date (say if someone else takes over).

    When players log in, before creating a mob for them, a search is first made to find an existing mob or type of mob with the corresponding key. If one is found, that mob becomes the player's avatar. Otherwise, a new mob is created for the purpose and assigned the player's key. Therefore, a player who logs out and comes back later would normally re-inhabit the same mob.

    3. Putting It All Together

    As a demonstration of all four basic object types, consider the following example:

    area/dark
       luminosity = 0
    
    obj/torch
       icon = 'torch.dmi'
       luminosity = 3
    
    turf
       floor
          icon = 'floor.dmi'
       wall
          icon = 'wall.dmi'
          density = 1
    
    mob/DM
       key = "Dan"
       density = 0  //I can walk through walls!
    

    Make the necessary icons and a map. Spread the dark area out over part of the map to see what effect it has when you walk around in it. If you change the name of the DM's key to match your own, you should be able to walk through walls.

    If you play around with this code a bit, you will undoubtedly run into things that you are not sure how to do yet. For example, what if you want the DM to be able to turn off the special ability of walking through walls at will? How about a command to create a torch with the wave of a hand? Such actions require the stronger magic of verb procedures. Read on!