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.
Read More “Object Behaviors: How Virtual Worlds Work part 4”