Making objects in a virtual world actually do something is way harder than just drawing them – and as we have seen, drawing them is already fraught with challenges.

Items as pure data

Once upon a time, in the old days of DikuMUDs, every object in the game was of a type – ITEM_WEAPON, ITEM_CONTAINER and so on. These were akin to what I referred to as templates in the last article. But they were hard-coded into the game server.

If you added new content to the game, you were limited by the data fields that were provided. You couldn’t add new behaviors to a vanilla DikuMUD at all. That item type defined everything the item could do, and a worldbuilder couldn’t change the code to add new item types.

To extend the behaviors a little bit, there was a small set of “special procedures” also hardcoded into the game – things like “magic_missile” or “energy_drain.” The slang term for these was “procs,” and to this day players speak of weapons that “proc” monsters. You could basically fill in a field on a weapon and specify that it had a “spec proc,” choosing from that limited menu.

If we look back at the previous article, and think about what this means for portability of object ownership, one fact jumps out at us: the functionality of a given object in a DikuMUD is inextricably bound up with the context in which it lives: the DikuMUD game server. There wasn’t any code attached to the item that could come with it as it moved between worlds. Instead, it really was just a database entry. The meaning of the fields was entirely dependent on the game server.