September 4, 2002

Objects

There’s going to be stuff scattered around the world of my IRC-based MUD, and I need a way to represent that stuff. Here’s the system I use:

The game has a set of base objects, which the system understands by default. This includes objects like doors, weapons, and containers (chests and bags). These objects each have a few basic attributes, like a description (“It’s a door.”).

In addition to the base objects, I have a file that defines a bunch of objects which inherit from other objects. So, for example, I have a chest object which inherits all the attributes of a “container” object, and adds more attributes, such as “weight,” and changes some of the attributes, such as the description (“It’s a chest.”).

So, with this system, you can define very specific object types that piggy-back on existing objects, so that you don’t have to define every little detail of every object.

This is made even more interesting by the fact that there are two kinds of attributes: normal attributes and player-modifiable attributes. Player-modifiable attributes can be changed by players. One example of this would be a “locked” attribute on a chest. The player can lock or unlock the chest at will.

Each room can have an object file defined for that room, which lists the objects stored in that room. If the object has any player-modifiable attributes, those attributes are listed in the object file, with their current state, so that players can modify that individual object without modifying either the original object definition or any other objects of the same type that are lying around the world.

So, a room description might look something like this:

On the floor is a chest, a knife, and a small amulet.

But there are some complexities here. For example, what if there are things in the chest? Well, first off, the chest has to be opened, and then the room would have to be described something like this:

On the floor is a chest (which contains a book and a scroll), a knife, and a small amulet.

This also means that, if someone tries to pick up the chest, they’ll have to get the scroll and the book along with it, and they will have to stay inside the chest when they’re moved. That can be tricky.

Moreover, a container can have other containers inside it, which can lead to complex situations like this:

On the floor is a chest (which contains a book and a jar (which contains a sack (which contains a brooch), a scroll, and a torch)), a knife, and a small amulet.

Also, it should be possible to have more than one object of the same type in a room, like so:

On the floor is a chest, a knife, a knife, and a small amulet.

So, what if the player wants to pick up the second knife in the room? I’ll have to implement “first,” “second,” “third,” etc. keywords, like so:

! get second knife

This is actually not too difficult, as the system can notice and keep track of each duplicate using numbers for each duplicate (the original is #1, the first duplicate is #2, etc.), then if the player specifies “first,” “second,” “third,” etc., the system will translate that into a number (“first” = 1, “second” = 2, “third” = 3), and go to that object in the list of duplicates.

In other words, just sensibly implementing objects can be an amazingly intricate operation.

I haven’t finished it yet, but I want to mention a really interesting book I started reading this week: Tears of the Giraffe by R. A. McCall Smith. It’s set in modern-day Africa, but it’s not about racism or genocide or starvation. It’s about Africa as a place where people live. They get married, they have children, and they go about their lives. It’s wonderfully refreshing. The book’s written in a style not unlike that of a children’s book — direct and unassuming — but I believe it’s a detective story. Highly recommended.