The task of creating objects with which to populate your world has many problems in common with the issue of creating the map. Once again, the basic approaches are to either rely on a templated database from which to draw your items, or to use a more object-oriented approach.

As we have seen from the preceding discussion, the great strength of LPMuds (to choose one object-oriented system) is the fact that they are so flexible and programmable, and the great strength of Diku derived muds (to name a templated system) is that they are not. The more complex the system required to build or to get the game running, the less likely that said system will ever be successfully set up. This is why the template approach of Diku-style muds proved so popular. They are very easy to set up, all the databases even among the different code bases are remarkably similar (i.e. converting areas between stock Diku, Merc, Circle, and other Diku-derived codebases is extremely easy, if indeed any conversion is necessary), and large muds can be opened from scratch by spending a few hours with FTP downloading pre-built data files from various repositories on the Internet.

This is also the great weakness of Diku of course--they are fill-in-the-blank muds.

Object-oriented muds have the opposite problem. To make a unique LP implies a certain level of ability at coding in LPC, which is, to be honest, as rare as the certain amount of ability required to code in C on a Diku. The result is that most LPMuds take a standard mudlib off the shelf, and run with it, in effect acting as template-based muds even though they have a wonderful and powerful architecture underneath.

I don't think there is any question that LP is far more powerful than Diku-derived code bases. You could write a fully-Diku-compatible mud in LP, and make it better. But Dikus (and similar architectures) will not go away because they are much, much, much easier to use for the most part. (Yes, a well-designed mudlib can be easier to use as a Diku, but the work required to get it to that point is not generally done).  The name of the game in a template-based system has to be making the templates they load more flexible yet backwards compatible. Adding new sections to the template that are optional but permit greater detailing, customization, etc, permitting each builder to find their own level.

¨   Template based system

The most basic approach to a template-based system is to start with a few generic object types. In the most primitive systems, such as Diku-derived systems, all these object types must have exactly the same data structure. Examples of typical types might include container, weapon, armor, and boat. All of these types will share common elements, such as fields for textual descriptions and appearance, weight or size, value in currency, and other such generically applicable pieces of information.

However, past a certain point, they vary. For a weapon you will need to know how much damage it does; for a piece of armor you may need to know how much protection it affords. In the most simple of templated systems, the basic object definition includes a field for object type, and a set of generic fields which hold arbitrary numbers. When referencing an object in the server, the code knows that if the object is of type “weapon” that the first field means how many times to roll the dice for damage, and if the object is of type “boat” it means how many people the boat holds.

Obviously, this system is not particularly flexible. The only behaviors a given object can have are the ones defined by its type. And the only sorts of parameters it can have are the ones that those generic fields can hold. For example, since the generic fields only hold numbers, forget about being able to name the boat—much less give it a damage rating for when it rams another vessel!

With good design, this restriction, which is quite severe, can be turned into an elegant solution to minimize load and maximize the ease of creating new objects. A basic enhancement which can be done to this system is to provide the ability to inherit other objects, so that you can use them as a basis from which to modify values. With a centrally controlled database in a goal-oriented mud, this can prove a real boon to game balance, ensuring that all creatures of level 11 have basic statistics derived from an ur-creature of level 11.

A system like this is also ideal for a database front-end. Whereas most muds that use this system still rely on text files for their template databases, the basic design of the system is perfect for storing object definitions in structured formats, such as tab-delimited files or basic database software. Since all the different types of objects have exactly the same format, the design of the database is trivial, searches and queries are easy and fast, and large-scale revisiting of the mud’s database is blessedly easy (“check every weapon that does slashing damage over 20 points in one blow”)—no small consideration for a goal-oriented mud, where revisiting object statistics is a depressingly common occurrence as the game’s playerbase develops over time.

An interesting aspect of object types is that they often preclude realistic physics. A good example is the handling of liquids—since things that hold liquids (such as fountains and “drink containers” are often object types, liquids are handled as just values on the object. There’s no physics behind liquids as a separate object or object type. Worse yet, the nature of the liquid is often coded into the container rather than the liquid, so you can’t pour milk from one jug into another jug that holds water—the milk will turn to water when the liquid is poured.

Of course, there are some types of objects that cannot fit into the object type paradigm. Primary among these are characters. In fact, in the Diku family of of muds, characters are considered a completely different sort of beast from objects. Generally speaking, the mud knows of three sorts of entities within the game: objects, mobiles, and avatars (generally called characters in this context).