The NakedMud Tutorial :: Inheritance
Abstract Contents
You may have noticed that certain zone contents are flagged as abstract. The very first editor option for rooms, objects, and mobiles is whether or not they are abstract. If a game content is abstract it means it is a real game content, but it cannot actually exist in the game on its own. Abstract contents are used for inheritance, which is the topic of this section. They supply important information about 'child' contents that inherit from them, but they themselves can never actually exist.
Inheritance
Distinct rooms, objects, and mobiles often share common features. When this commonality must be defined separately for each case, it becomes a hassle. Even worse is when it is decided that this commonality needs to be changed. NakedMud supports inheritance for rooms, objects, and mobiles -- unique versions of zone contents can inherit from a parent version, automatically copying over all features of the parent to the child.

One application of inheritance is to store all generic information about city streets in a parent room, and then have individual rooms within the city inherit from the parent. Here is an example of a parent location called mainstreet, from which specific locations along the street will inherit.
[mainstreet@moonhaven]
1) Abstract: yes
2) Inherits from prototypes:

3) Name
Main Street
4) Description
The street is nicely kept cobblestone.  Buildings of various sizes dot the 
north and south sides of the street.  [if is_night()] The doors and windows on 
most are shut, suggesting the town has gone to bed for the night.[/if] [if 
is_evening() or is_night()] Flames flicker at the tops of tall polls lining 
either side of the streeet.  They give the street basic illumination.[/if] 
L) Land type [City]
B) Set Bits: 
Z) Room can be reset: no
R) Room reset menu
X) Extra descriptions menu
T) Trigger menu
E) Edit exit
F) Fill exit
   north      : nowhere                   east       : nowhere             
   south      : nowhere                   west       : nowhere             
   up         : nowhere                   down       : nowhere             
   northeast  : nowhere                   southeast  : nowhere             
   southwest  : nowhere                   northwest  : nowhere             

C) Extra code

Enter choice, ? [topic] for help, or Q to quit: 
Once the parent is created, new rooms can be edited and set to inherit from this room. Each one that does will, by default, gain all of the information of the parent. The information can also be extended. For instance, names can be over-written and descriptions can be added to. Here is an example that inherits from mainstreet, changes its name, and adds to its description.
[mainstreet01@moonhaven]
1) Abstract: no
2) Inherits from prototypes:
mainstreet
3) Name
Mainstreet, Before the Tavern
4) Description
A large tavern can be seen on the north side of the street.  [if is_evening() 
or is_night()] Silhouettes of moving people are projected against the smoky 
windows of the tavern from inside lights.[/if] The sound of music emits from 
within.
L) Land type [leave unchanged]
B) Set Bits: 
Z) Room can be reset: no
R) Room reset menu
X) Extra descriptions menu
T) Trigger menu
E) Edit exit
F) Fill exit
   north      : tavern                    east       : nowhere
   south      : nowhere                   west       : nowhere
   up         : nowhere                   down       : nowhere             
   northeast  : nowhere                   southeast  : nowhere             
   southwest  : nowhere                   northwest  : nowhere             

C) Extra code

Enter choice, ? [topic] for help, or Q to quit: 
Note that in this example, the name is changed but the description is only added to. When using inheritance, editing a child's decription will add to the parent's, not erase what was previously there. Other descriptive fields that are edited will be overwritten. If you would prefer not to overwrite a field, simply leave it blank in the editor.
Heirarchical Inheritance
When a parent is inherited from, all contents the parent inherits from are also implicitly inherited. In this sense, inheritance is heirarchical. One way this can applied is to make all lines of inheritance trace back to a single unique content -- a generic content, so to say. If you ever want to globally apply new functionality to a room, you can then simply add it to the generic room and all other rooms will automatically have it.

If your mud implements a death system, one use of this would be to supply a generic trigger that handles a person's death, while still leaving open the possibility that certain rooms might change how death is handled by replacing that trigger. To give a classic example, some DIKU muds implement deathtraps. Normally, if a player were to die, their corpse might be transfered to a graveyard for easy access. However, if a player were to die in a deathtrap, their corpse remains in the trap. And what if you want variations of death traps? Often these sort of extentions are supplied within the game's code, using bits or flags to mark important information. NakedMud allows you to have different rooms, mobiles, and objects that exhibit different behaviors through inheritance instead. The game code need never be touched.

Here is an example from my mud; all chains of inheritance for rooms are rooted at a single room: generic_room@templates. This room specifies a generic trigger to run when someone dies, and assigns a location to transfer their corpse to.
[generic_room@templates]
1) Abstract: yes
2) Inherits from prototypes:

3) Name

4) Description
L) Land type [leave unchanged]
B) Set Bits: 
Z) Room can be reset: no
R) Room reset menu
X) Extra descriptions menu
T) Trigger menu
E) Edit exit
F) Fill exit
   north      : nowhere                   east       : nowhere             
   south      : nowhere                   west       : nowhere             
   up         : nowhere                   down       : nowhere             
   northeast  : nowhere                   southeast  : nowhere             
   southwest  : nowhere                   northwest  : nowhere             

C) Extra code
me.attach("generic_death@templates")
me.setvar("graveyard", "graveyard@templates")
All rooms that inherit from generic_room@templates have the trigger, generic_death@templates attached to them. Whenever a player dies in a room inheriting from this one, their corpse is created and transfered to the standard graveyard. However, these are properties of the room not the game. So another room that inherits from this one can easily change the death behavior -- say, moving the corpse somewhere else -- by setting the graveyard variable to something new. For instance, an inherited room that had this line of extra code would leave the corpse where it is:
C) Extra code
me.setvar("graveyard", me.proto)
Or perhaps you want a room where death is handled in a completely different manner. Maybe you want dying to be the neccessary event to progress in a quest -- for instance, in a trial of courage. Then you could detach the generic death trigger and attach your own special one that doesn't let players die, but instead transfers them in-tact to the next area of the quest.
C) Extra code
me.detach("generic_death@templates")
me.attach("trial_of_courage_death@myzone")
Multiple Inheritance
Game contents can inherit from more than one parent. Rooms, objects, and mobiles can be chimeras -- blends of multiple things, but not tracable back to a single unique lineage. Defining multiple inheritance, like single inheritance, is done through the OLC editors. However instead of supplying a single parent, any number of parents are entered, comma separated.
[black_beetle@moonhaven]
1) Abstract: no
2) Inherits from prototypes:
generic_mob@templates, beetle@templates, hostile@templates
For instance, suppose you want to design a zone of beetles. All of those beetles are beetles, and thus share a unique set of properties which you might define in beetle@templates. However, some beetles might also be hostile, and have an additional hostile behavior associated with them. You could set this up as a heirarchy, so there were two classes, one called hostile_beetle which some of the beetles inherited from another another called friendly_beetle which the others inherited from, both of which inherit from beetle. This would be a valid approach.

But if you have other creatures that could also be hostile -- trolls, necromancers, mothers -- and it would be cumbersome to make a hostile heirarchy for every individual type of creature. With multiple inheritance, you can just cut to the chase and have a separate template, hostile, that any creature can inherit from to gain scripted, hostile behavior.

The one caveat with multiple inheritance is that you have to be aware of the fact that one parent may override information set by another parent (names, attaching and detaching scripts, changing races and genders, etc). Parent information is applied serially, first in the list to last in the list. So the last parent processed is the one whose information you can gaurantee will be represented in the child. However, with careful design this should be a non-issue.