Monster Modules

[specialobjects]

[objects]

The [specialobjects] section

The [objects] section

The [specialobjects] section is used to manage the placement of objects that are not defined within the area file; like hand-coded, or specially-coded monsters and treasures, perhaps created with the Blob.

The [objects] section is used to manage the placement of objects that are not defined within the area file; like hand-coded, or specially-coded monsters and treasures, perhaps created with the Blob.

The [specialobjects] section is is broken up into a series of individual objectdefinitions. Each description starts with a line that begins with object:

The [objects] section is is broken up into a series of individual objectdefinitions. Each description starts with a line that begins with object:

[specialobjects]

[objects]

• item (an item you can look at). Can have many of these.

• item (an item you can look at). Can have many of these.
  Items should be defined to match the set of nouns defined in the long description, and in other items. They are not things the player can get but they can be looked at.
  The basic form is 'item_name(s):adjective(s):description(s)' or 'item_name(s):description(s)'
  In any section multiple values are entered separated by a |
  A player is able to look at one of the item_name values, prefix by any combination of the adjectives. What they see will be a randomly chosen description.
  Adjectives are optional.
  The description may be the special value of ##item_name, in which case it is the same as looking at 'item_name'.

This needs completing:

ToDo? * domain

An external room block is used to tell the area engine about a room which exists outside the current area.

Examples include rooms that have been hand-coded by a wizard and rooms within other areas controlled by the area engine.

When linking to a room which has been hand coded by a wizard (or builder) you must specify:

• domain (optional, defaults to the domain for this area)

When linking to a room which is part of another area-engine controlled area you must specify:

• domain - the name of the domain (optional, defaults to the domain for this area)
• area - the name of the area
• name - the name of the room (from the Map section. Optional, defaults to the default start room)

The specified MODULE_NAME is the most important bit - it determines which module you are using, and thus what advanced effect you are applying.

or more simply:

   MODULE_NAME {
      KEY: VALUE
      KEY: VALUE
   }

The KEY/VALUE pairs are used to configure the module. For example in the "exit" module called "guild_block", there is a keys which indicate which guild you have to be in to be able to use the exit.

The specified MODULE_NAME is the most important bit - it determines which module you are using, and thus what advanced effect you are applying. The next most important things is the pair of braces {}. The opening brace MUST appear on the end of the line containing the MODULE_NAME, and the closing brace MUST appear on a line of its own.

The KEY/VALUE pairs are used to configure the module. For example in the "exit" module called "guild_block", there is a keys which indicate which guild you have to be in to be able to use the exit, and in the "exit" module called "door" there is a key to indicate whether the door is lockable.

The following is an example of using the "guild_block" module to stop non-thieves from using the exit going "east" from "room1" to "room2".

The following is an example of using the "guild_block" module to stop non-thieves from using the exit going "east" from "room1" to "room2", and the "door" module to make the exit a steel gate.

# use 'guild_block' module to stop non-thieves

# use 'door' module to add a gate door {

id

mydoor

type

steel_gate

# and closes

# and closes. See the 'door' exit module for help on how to do this.

ToDo?: Describe how to define a door. something like type: door { adj: wooden long: A large wooden door. locked: 0 key: front_door_key }

ToDo?

This needs completing:

* short (brief description) * long (verbose description) * light (0 for dark, 1 for daylight) * inside (0 for outside, 1 for inside) * chat (a message that displays occassionally in the room). Can have many of these * item (an item you can look at). Can have many of these. Format is "itemname":description. You can have the itemname several times and the user will get a randomly chosen one of the descriptions You can have a description of ##otheritemname, then the item is considered to be using the description of the "otheritem"

Advanced stuff

For example you might want exits to only be traversable if a certain monster is dead, or you might want a weapon to have a certain special attack, or ability when wielded.

This advanced functionality is provided through the use of extension modules .

Extension modules are things that you can use on almost anything facet in the Area Engine to make it behave in new and exciting ways.

Possible "targets" for extension modules are:

• Exits: Modules might do things like only allow you through if a monster is dead, or give special messages when the player passes through.
• Rooms: Modules can do anything at all to the room, such as making it slowly leach the life from all living things inside it, or they might make it change its description or exits.
• Monsters: Modules can alter the behaviour and everything else for the monster. Such as providing special attacks, or making them pick up items they find.

Modules are applied to a target using a common syntax. Within the target you write

   module: MODULE_NAME {
      KEY: VALUE
      KEY: VALUE
   }

The specified MODULE_NAME is the most important bit - it determines which module you are using, and thus what advanced effect you are applying.

The KEY/VALUE pairs are used to configure the module. For example in the "exit" module called "guild_block", there is a keys which indicate which guild you have to be in to be able to use the exit.

Available Modules

Exit Modules

Module example

[map]
# Just two rooms, and we give the exit from room1 to 2 a special name.
room1: blockedExit=room2
room2: west=room1

[exits]
# configure the exit called 'blockedExit'
exit: blockedExit
# make it go east
direction: east
# use 'guild_block' module to stop non-thieves
module: guild_block {
   guild: ThiefGuildId
   message: You have to be a thief to go east!
}

[exitnames] # This section defines exit names/doors/etc

[exits] # This section defines special exits - doors/blocking/etc

The [exitnames] section

The [exits] section

The [exitnames] section is sort of optional.

The [exits] section is sort of optional.

In this section you define the details of exits. At this time you can only define the "full name" for an exit.

In this section you define the details of exits. Details include things like

• the actual direction of the exit (if you want it to be a different word to the actual exit name),
• a door in the exit.
• special blocks on the door, like the player having to have completed a quest, or be in a guild.

So, for example, in the map above there are exits described as "e", "w" and so on. In this section you can define the full detail of "east" and "west".

So, for example, in the map above there are exits described as "e", "w" and so on. By default this means the exits in the rooms will be exactly that: "e" and "w", not "east" and "west".

More interestingly the definition for room "lounge" has an exit called "frontdoor", which leads to the outside. For simplicity we could add an entry into the [exitnames] which says "frontdoor" is "east". The player would then never see an exit called "frontdoor", and the lounge would contain an "east" exit.

More interestingly the definition for room "lounge" has an exit called "frontdoor", which leads to the outside. It seems unlikely that we want the player to see that - rather we want them to see an "east" exit, and for it to be a wooden door.

The following shows the configuration for the "frontdoor" exit

[exitnames] # define normal directions e=east w=west n=north s=south u=up d=down

[exits]

frontdoor=east

exit: frontdoor direction: east ToDo?: Describe how to define a door. something like type: door { adj: wooden long: A large wooden door. locked: 0 key: front_door_key }

[specialrooms] # This section manages links to hand-coded rooms

# and defines the external rooms (links to other areas)

The [specialrooms] section

The [rooms] section

The [specialrooms] section is used to define rooms that are not to be controlled by the area engine, but are linked to by the rest of the map.

The [rooms] section defines the appearance of rooms - the description, items, light levels, etc. This section DOES NOT define the exits/connections between rooms - that is done in the [map] section.

In our example map above the "outside" room is such an example. It is not to be created by the area engine, but we want the "lounge" to be able to connect to it.

The [rooms] section is broken up into a series of individual room descriptions. Each room description can apply to one or more of the rooms which are defined in the [map] section. This is deliberately done to allow you to use a generic room description for multiple rooms in your area.

At this time it is only possible to link to hand-coded rooms such as those created by the blob. It is not possible to link to rooms in a different map controlled by the area engine.

The [rooms] section also identifies rooms that are outside your area, or have been specially hand-coded by a wizard. You need to identify these rooms and tell the Area Engine how to find them so that your rooms can link to the rest of the mud.

To link the lounge to a hand-coded room called "thestreet.c" would require the following:

Rooms that are part of your area

[specialrooms] outside=thestreet.c

For this to work the "thestreet.c" file would have to be in the same directory as the area engine map configuration file. In most builder-managed domains this is not the case, the "thestreet.c" file is in the rooms directory:

[rooms] room: # this is the first room description # and so is this

room: # this is the description for the next room

The [rooms] section

The [rooms] section defines the appearance of rooms - the description, items, light levels, etc. This section DOES NOT define the exits/connections between rooms - that is done in the [map] section.

The [rooms] section is broken up into a series of individual room descriptions. Each room description can apply to one or more of the rooms which are defined in the [map] section. This is deliberately done to allow you to use a generic room description for multiple rooms in your area.

Rooms that are outside your area or are hand coded

Each room description starts with a line that begins with room: All subsequent lines until the next room: are considered to be part of the room description.

Each external room description starts with a line that begins with external: . All subsequent lines until the next room: or external are considered to be part of identification of the external room.

external: outside # this is the 'outside' room and is a room that is probably a room in an adjoining area. # The Area Engine will expect to be told where to find the file/map for the external room.

The Area Engine uses room descriptions whenever it needs to create a room.

The Area Engine uses room descriptions whenever it needs to create a room - it does not use this process when linking to external rooms.

The rooms that get created are totally controlled by the [map] section.

Putting a room in the [rooms] section doesn't cause the room to be created, the actual rooms that get created are controlled by the [map] section. The Area Engine examines the [map] section to work out which rooms should exist.

1. get the entire set of room descriptions,

1. check to see if there is an external definition in the [rooms] and if so then use that external room.
2. assuming no external room can be found then it will get the entire set of room descriptions from the [rooms],

The important thing to understand is how the Area Engine performs the second step - the process of working out which room descriptions can apply to a given room. It is possible for you to create an area with a single room description which can apply to all rooms, it is also possible to create an area in which each room has only a single applicable room description (in which case you have as many room descriptions as you do rooms in your [map]), and anywhere in-between.

The important thing to understand is how the Area Engine performs the third step - the process of working out which room descriptions can apply to a given room. It is possible for you to create an area with a single room description which can apply to all rooms, it is also possible to create an area in which each room has only a single applicable room description (in which case you have as many room descriptions as you do rooms in your [map]), and anywhere in-between.

# This tells the Area Engine where to find the 'outside' room. # It tells it that it is the 'street1' room in the 'town' domain. external: outside domain: DOM_TOWN file: street1

What can go into an external room identification block

Essentially it is a single "controller" that creates the rooms for you based on an area file. As a builder you write the area file and the area generates itself - no more creating rooms. At this time the area file only controls the rooms and their exits, but it will soon provide the ability to place monsters, and then to define monsters. After that, I'm open to suggestions.

Essentially it is a single "controller" that creates the rooms for you based on an area file. As a builder you write the area file and the area generates itself - no more creating rooms. At this time the area file only controls the rooms, their exits and descriptions, and the placement of externally created objects/monsters. It will soon provide the ability to define objects and monsters. After that, I'm open to suggestions.

[specialmonsters] # This section manages hand-coded monsters

[monsters] # This section defines monsters for your area

[specialobjects] # This section manages hand-coded objects like monsters # and treasures

The [specialmonsters] section

The [specialobjects] section

The [specialmonsters] section is used to manage the placement of monsters that are not defined within the area file; hand-coded, or specially-coded monsters, perhaps created with the Blob.

The [specialobjects] section is used to manage the placement of objects that are not defined within the area file; like hand-coded, or specially-coded monsters and treasures, perhaps created with the Blob.

The [specialmonsters] section is is broken up into a series of individual monster definitions. Each description starts with a line that begins with monster:

The [specialobjects] section is is broken up into a series of individual objectdefinitions. Each description starts with a line that begins with object:

All subsequent lines until the next monster: are considered to be part of the same monster definition.

All subsequent lines until the next object: are considered to be part of the same object definition.

[specialmonsters] monster: rabbit

[specialobjects] object: rabbit

monster: duck # this is the description for the 'duck' monster

object: table # this is the definition for the 'table' treasure

Each monster: line has the format:

Each object: line has the format:

monster: monster_key

object: object_key

The monster_key is a unique keyword used to identify the monster in other parts of the area file. You can use any keyword you like.

The object_key is a unique keyword used to identify the object in other parts of the area file. You can use any keyword you like.

What can go in a monster description block

What can go in a object description block

At least one room_key must be specified. The room_key can include wildcards. Multiple keys can be specified by separating them with commas. If the specified room_keys match more than one room then the monster will be randomly placed.

At least one room_key must be specified. The room_key can include wildcards. Multiple keys can be specified by separating them with commas. If the specified room_keys match more than one room then the object will be randomly placed.

A value of "default" will cause the monster to be recreated (if it is dead) following the normal mud rules. A value of "none" will mean the monster is never recreated after it is killed. This defaults to "default".

A value of "default" will cause the object to be recreated (if it is destroyed) following the normal mud rules. A value of "none" will mean the object is never recreated after it is destroyed. This defaults to "default".

table.columns { border:1px solid black; } table.columns .header{ border-bottom:1px solid black; background-color:grey; } table.columns td { padding-left:5px; padding-right:5px; border-right:1px solid black; border-bottom: 1px solid black; vertical-align: top; } table.columns th { padding-left:5px; padding-right:5px; border-bottom: 1px solid black; border-right: 1px solid black; background-color:gray; } tr.altrow { background-color:rgb(189,244,244); }

background-color:lightgray;\

background-color:lightgrey;\

border

1px solid grey;\

border

1px solid gray;\

border

1px solid grey;\

border

1px solid gray;\

border

1px solid grey;\

border

1px solid gray;\

The [specialmonsters] section is used to manage the placement of monsters that are not defined within the area file - hand-coded, or specially-coded monsters, perhaps created with the Blob.

The [specialmonsters] section is used to manage the placement of monsters that are not defined within the area file; hand-coded, or specially-coded monsters, perhaps created with the Blob.

The [specialmonsters] section is is broken up into a series of individual monster definitions. Each description starts with a line that begins with monster:

All subsequent lines until the next monster: are considered to be part of the same monster definition.

[specialmonsters]
monster: rabbit
# this is the definition for the 'rabbit' monster
# and so is this

monster: duck
# this is the description for the 'duck' monster

Each monster: line has the format:

monster: monster_key

The monster_key is a unique keyword used to identify the monster in other parts of the area file. You can use any keyword you like.

What can go in a monster description block

keyword: value

Possible keywords, and their meanings are:

h3 { background-color:rgb(227, 223, 212); border: 1px solid grey; margin-top: 50px; margin-bottom: 5px; display:block; } h2 { background-color:rgb(200, 200, 190); border: 1px solid grey; display:block; } h1 { background-color:rgb(198, 189, 168); border: 1px solid grey; display:block; }

TOC: No TOC in "Website.UsingTheAreaEngine"

# This section defines the layout of your area

# This section defines exit names/doors/etc

# This section manages links to hand-coded rooms

[rooms] # This section defines what your rooms look like

[roomdescriptions]

[specialmonsters] # This section manages hand-coded monsters

[monsters] # This section defines monsters for your area

The [roomdescriptions] section

The [rooms] section

The [roomdescriptions] section defines the appearance of rooms - the description, items, light levels, etc.

The [rooms] section defines the appearance of rooms - the description, items, light levels, etc. This section DOES NOT define the exits/connections between rooms - that is done in the [map] section.

The [roomdescriptions] section is broken up into a series of individual room definitions. Each room definition can apply to one or more of the rooms which are defined in the [map] section. This is deliberately done to allow you to use a generic room description for multiple rooms in your area.

The [rooms] section is broken up into a series of individual room descriptions. Each room description can apply to one or more of the rooms which are defined in the [map] section. This is deliberately done to allow you to use a generic room description for multiple rooms in your area.

Each room definition starts with a line that begins with room: All subsequent lines until the next room: are considered to be part of the room defintion.

Each room description starts with a line that begins with room: All subsequent lines until the next room: are considered to be part of the room description.

[roomdescriptions]

[rooms]

# this is the first room definition

# this is the first room description

# this is the definition for the next room

# this is the description for the next room

The [roomdescriptions] section defines the appearance of rooms - the description, items, light levels, etc.

The [roomdescriptions] section is broken up into a series of individual room definitions. Each room definition can apply to one or more of the rooms which are defined in the [map] section. This is deliberately done to allow you to use a generic room description for multiple rooms in your area.

Each room definition starts with a line that begins with room: All subsequent lines until the next room: are considered to be part of the room defintion.

[roomdescriptions]
room:
# this is the first room definition
# and so is this

room:
# this is the definition for the next room

Understanding how room descriptions are allocated

# This comment is just describing the layout below, the area creator ignores it completely

# This comment is just describing the layout below, # the area creator ignores it completely

lounge: nw=kitchen,n=dining,e=outside

lounge: nw=kitchen,n=dining,frontdoor=outside

The [exitnames] section is sort of optional.

In this section you define the details of exits. At this time you can only define the "full name" for an exit.

So, for example, in the map above there are exits described as "e", "w" and so on. In this section you can define the full detail of "east" and "west".

More interestingly the definition for room "lounge" has an exit called "frontdoor", which leads to the outside. For simplicity we could add an entry into the [exitnames] which says "frontdoor" is "east". The player would then never see an exit called "frontdoor", and the lounge would contain an "east" exit.

[exitnames]
# define normal directions
e=east
w=west
n=north
s=south
u=up
d=down

# define the frontdoor as a normal east exit.  In the
# future we might define this as an actual door which opens
# and closes
frontdoor=east

The [specialrooms] section is used to define rooms that are not to be controlled by the area engine, but are linked to by the rest of the map.

In our example map above the "outside" room is such an example. It is not to be created by the area engine, but we want the "lounge" to be able to connect to it.

At this time it is only possible to link to hand-coded rooms such as those created by the blob. It is not possible to link to rooms in a different map controlled by the area engine.

To link the lounge to a hand-coded room called "thestreet.c" would require the following:

[specialrooms]
outside=thestreet.c

For this to work the "thestreet.c" file would have to be in the same directory as the area engine map configuration file. In most builder-managed domains this is not the case, the "thestreet.c" file is in the rooms directory:

[specialrooms]
outside=rooms/thestreet.c

The map section is used to define all the rooms in the area and the exits between them.

This section does not define the contents of rooms, nor the room descriptions, just the exits/links between rooms.

Each room is defined on a single line. The line has the format:

After the ":" are the exits for the room, separated with commas. Each exit is a direction, an "=" sign, and the room_key for the destination.

So - the following map is used to describe a 2 story house with several rooms:

[general]
# Make people start in the lounge
startroom=lounge

[map]
# This comment is just describing the layout below, the area creator ignores it completely
# The ground floor map looks like:

# kitchen   -  dining  
#    |      \     |
# hallway    lounge - outside
#    |
# hallway - bedroom
#    |
# hallway - bedroom
#    <

# The second story looks like

# bedroom - onsuite
#   |
# landing
#   >

# The "outside" room is not in this area, it's the room for entering this area

# Below here are the actual rooms with their exits
kitchen: e=dining,s=hallway1,se=lounge
dining: w=kitchen,s=lounge
lounge: nw=kitchen,n=dining,e=outside
hallway1: n=kitchen,s=hallway2
hallway2: n=hallway1,s=hallway3,e=bedroom1
hallway3: n=hallway2,e=bedroom2,u=landing
bedroom1: w=hallway1
bedroom2: w=hallway2
landing: d=hallway3,n=masterbedroom
masterbedroom: s=landing,e=onsuite
onsuite:w=masterbedroom

Note that there is no room with a room_key = "outside". This is because the room is specially coded - it is either a hand-coded room which you want to connect with, or it is a room managed by a different area engine.

%META:TOPICINFO{author="FantoM" date="1164021660" format="1.0" version="1.1"}% %META:TOPICPARENT{name="BuilderPages"}%

The Area Engine

Overview

Essentially it is a single "controller" that creates the rooms for you based on an area file. As a builder you write the area file and the area generates itself - no more creating rooms. At this time the area file only controls the rooms and their exits, but it will soon provide the ability to place monsters, and then to define monsters. After that, I'm open to suggestions.

File Format

The file is broken into a series of sections, each section having a heading and some content. Headings have the form [heading-name], and a section is all the content from its heading until the heading for the next section. Section headings have to be on a single line of their own.

The following shows you the outline of the file. A complete area file will probably include the sections shown here as well as having lots of content inside each section

[general]

[map]

[exitnames]

[specialrooms]

[roomdescriptions]

Comments

# I am a comment
[general]
I am not a comment.

[map]
# I am another comment
# that goes over multiple lines
I am not a comment

The [general] section

Supported constants at this time are:

Each constant goes on a line of its own and is assigned a value using the = operator.

For example:

[general]
# Define 'domain' to be 123
domain=123

#define 'startroom' to be 'hallway'
startroom=hallway

The [map] section

The [exitnames] section

The [specialrooms] section

The [roomdescriptions] section