The great empire wasn't built in a day and neither were the lands surrounding it. Careful, meticulous design has gone into everything that a user sees in the world of The Isles. Each object, mobile and room has been developed by the loving participants that like to virtualize their imaginations. Building on The Isles is open to a restricted number of volunteer positions. Not everyone has what it takes to be a builder, and if you haven't designed areas before, you're going to need to consult our newbie introductory guide entitled: Information for Prospective Authors.

But, if you're already familiar with building and you've been given the chance to prove yourself, this guide is written for you. It serves as a reference material that all designers frequently refer to when building areas on The Isles. The Guide has been designed in one big page so that you can print out the information contained here in one shot.

The Penultimate Builder's Guide to the Isles contains all the information you need to define every aspect of the world. It is kept fairly well up-to-date, and supplemental material is available online. Consult the online documentation regarding Immortal Reference and you can be assured the most up-to-date material is kept there.

This guide provides the theoretical overview to designing areas in the world database. Special consideration has been made to insure accurate illustration of these concepts. If you have a question or comment regarding this guide, please send those requests to: theisles@mugs.net.

Using the table of contents, you can quickly skip to each section to review material.

Return to the table of contents.

The virtual locations, objects, players and creatures that you see are all contained in a set of seperate but inter-referencing databases that build the "rules" of the world beyond the game mechanics. Due to the complexity of this system, a set of universal terms has been developed over time to describe various values and references within the database and how they are used within the world. We will be discussing some of the internal workings of the database processes here, because it is important in order to understand how the world can be developed, and what the limits of this system is. It is important that you familiarize yourself with the terms defined below, they will be used throughout the remainder of the Guide and are frequently used when discussing projects with other builders.

Before we continue, it is important to define the most fundamental of these terms, the virtual number or vnum. A vnum refers to the index in the hash table that holds a single database entry. In other words, the vnum is a unique number that references a specific entry in the database. In each of the three seperate database that make up the majority of the virtual objects, vnums are unique and do not repeat. A vnum in one database might match the value of a vnum in another database, but within a single database a vnum is never repeated and references only one entry.

The first database type is a Room. A Room, by its most generic definition, is an object that contains other objects, in which players can exist. Rooms are the virtual locations in which all interaction takes place, though their applications are varied and are not necessarily limited to a specific type of location, be that a loft, wagon interior, forest or cave. Rooms are the most basic of database designs, and contain fewer fields than the other main databases, Mobiles and Objects.

fig1.1: Room Template Properties

Room Properties	Description
Vnum	Virtual number - index value of the room
Sector	Type of virtual space - terrain type
Name	The Room Title - a short, descriptive phrase about the location
Wagon	Reference to associated wagon object (experimental)
Max People	Limiter to the # of occupants in the room at one time
Flags	Additional room properties (such as enclosed/unenclosed, private, etc)
Description	Description of the virtual space shown to the user
Exits	Links to other rooms with special properties (see Exits, below)
Resets	Load associations within the room (see Resets, below)

The second database type is a Mobile. Mobiles are any computer-controlled actors within the world. This consitutes anything from shopkeepers to cows and provides a basic archetype for balancing the power of each of the actors within the world. Mobiles have more properties than Rooms and can also be instilled with procedural scripts which automate their functions. We will be describing scripts further along in the Guide, but for now let's stick to the basics about Mobiles. Mobiles function within the game as vessels of other objects, and also have relations to one-another. They move from location to location just like player characters, and administrators can assume the identity of Mobiles at will, providing additional human automation of otherwise dumb creatures. Mobiles are often referred to as "Mobs."

fig1.2: Mobile Template properties

Mobile Properties	Description
Vnum	Virtual number - the primary key/index value of the mobile
Name	A list of keyword references to the mobile - how commands reference the Mobile
Short Description	The formal name of the Mobile for display purposes
Long Description	A one-line description shown to a player in a room with the Mobile
Main Description	A multi-line description seen when the Mobile is specifically looked at
Size	Height in "halfspans" - a halfspan is defined to be three English inches
Race	Racial definitions (not yet fully implemented)
Sex	Male/female/neuter
Money	Amount of money the Mobile is "born" with
Attributes	Attributes define the skill acuity of the mobile without having to define specific skill levels

The final main database type is an Object. Objects are everything else: they are clothing, levers, jewelry, coins, weapons and many other things. Objects can range from food items to special types like lists, which we will discuss later on in the Guide. Objects are not necessarily inanimate, but generally are picked-up, dropped, used and discarded by players and Mobiles alike. Objects have many different and varied properties, and for this reason are the most complex database entries in the world. They have such a variety of uses that builders and area designers often find themselves spending the most time defining objects. For this reason, a library database is being developed to aid builders by providing object templates that are commonly used. This way, builders can draw from a resource of standard objects which can be applied in many ways.

fig1.3: Object Template Properties

Object Properties	Description
Vnum	Virtual number - the primary key/index value of the Object
Name	A list of keyword references to the Object
Short Description	The formal name of the object for display purposes
Long Description	A one-line description shown when the object is on the ground in a Room
Main Description	Shown when a player looks at an object
Action Description	Utilized by only some object types, this is an additional description when used
Type	A definition of the object's purpose, which defines the properties of Values
Values	Four values that define the object's uses and effectiveness
Wear Flags	Definitions (mainly for clothing and armor) objects defining how an object is worn
Extra Flags	Defines additional Object properties (special properties)
Weight	Defines the object's weight in halfstones (for encumbrance calculations)
Size	Defines the tailoring of clothing and armor objects
Material	Defines the material the object is made from (not fully implemented)
Cost	Cost in copper coins for valuing purposes

Exits link rooms together and possess special properties of their own. Exits can have doors that are either open or closed, and possibly locked. Exits also get to have nifty "names" associated with them even if they don't open or close. This way you can add detail to the type of exit you are walking through. Exits are not the only way to locomote, but they are the most widespread way. There are ten directions that exits can travel: north, south, east, west, up and down, as well as northeast, southeast, northwest and southwest.

fig1.4: Exit Properties

Exit Properties	Description
Direction	One of four cardinal directions, up, down, northeast, northwest, southeast or southwest
Destination	Vnum link to the associated Room
Name	Keywords or "short description" of the exit (ie: "trapdoor" or "arched passageway")
Description	A multi-line description shown when a player looks to that direction
Key Vnum	Vnum to the associated key Object for locking purposes
Exit Flags	Extra properties (type of exit, conditions of exit, etc)

The term Resets refers to a list of load procedures associated with a Room. The server resets a few Rooms each time the game loops through, and so the world is always regenerating various parts of the database. Resets are the rules of loading that associates Objects and Mobiles with locations in the world. Resets have properties, too. When a room is "reset," the server goes through the list of Resets in the room it has chosen, and performs load procedures to populate the room. (See Templates and Incarnations for more about "loaded" objects.)

fig1.4: Reset Properties

Exit Properties	Description
Target Vnum	Vnum of the Mobile or Object to be loaded.
Target Type	Defines type as either Mobile or Object
Location	Either "In Room" or various wear-flags for loading objects onto mobiles
Chance	Percentage chance of loading
Times	Number of Times the reset is looped through when run
Maximum	Loads only if the value of Maximum is greater than the # of already loaded Mob/Obj

Templates are the entries in the database that define the master copies of all items found in the world. Templates are present only in the Mobiles and Objects databases. When a Reset is triggered, or an object or mobile is born, a copy is made from the original template. The copy refers to the original template and copies links to the strings associated with the master copy (template). Each object or mobile can, eventually, be made perfectly unique from the original, but in most cases only the values on the objects or mobiles change. If you change a master copy, all unmodified strings on its incarnations change accordingly. Values, however, are not automatically updated. These copies are referred to as loaded incarnations or, more technically, children. Templates are also referred to as "indexes."

Return to the table of contents.