I'm using Phantasmal as my codebase (surprise, surprise ), and I'm looking at a kinda weird design issue that other MUDs seem likely to have as well. I actually figured out what I'm going to do about my immediate problem, but I felt like sharing the design discussion with all of you since it's not specific to Phantasmal.

You can think of items as coming in two flavors - types and instances. For instance, somewhere your MUD keeps the details of the 'steely jeweled longsword' in general, and then you may have four or five different ones being carried by players or sitting on the ground throughout your MUD. The first is a type, and then there are the four or five instances of that type.

Conceptually, rooms are the same way since there's no reason you couldn't have four or five instances of the same room, but in practice we tend to treat them differently since you'd have to decide what belonged to the parent and what to the instance, and overall it's just a pain in the neck. Easier to just say, "rooms are all real, so the type and the instance are the same thing." Fair enough.

This can cause us problems with portable rooms, though, like vehicles and tents and containers that a person can climb into. If you have a guy selling tents then clearly you have the type "tent", but then you also have a whole bunch of "tent" instances in players' inventories. So if you've got a MUD with much flexibility, your portable objects *can't* be completely different from your rooms that way, 'cause a room can be a pick-up-able portable.

Now an object (including portables and rooms) can refer to lots of other objects in lots of ways. Specifically in Phantasmal, an object can be inside of another object, can be a detail (a wholly-attached piece) of another object, can inherit from another object (a type, not an instance), can have other objects inside it or as details of it, can have an exit that leads to another object, or can have a property in a property list (Phantasmal calls properties 'tags') that points to another object.

That can be a lot of interconnectedness. It isn't always, but it can be.

There are a lot of times you'd like to separate objects out into big chunks of lots of objects. For instance, if you want to save them into a zonefile. The way most MUDs do this is just to save the types, not the instances - if you pick up a sword and move it to another zone, the MUD ignores it. It just saves the spawn-point of the sword, not where it is right now. Similarly, the MUD just saves where the monster spawns, not how many of them there are right this second and what they're doing. Zones are, in that sense, usually entirely static. Honestly, it's also because most MUDs don't have very many interesting item abilities or scripts, and pretty much nothing that makes items or creatures active unless players are around. Most MUDs have pretty boring worlds when there aren't players doing anything there.

A player's save file has a location (usually a room number) and a list of what instances of stuff he's carrying around in his inventory. Since you don't care about saving the state of the rest of the world, you don't worry about more items than that, or any types at all.

In a normal MUD world, portable rooms get special-cased. For instance, instead of making a 'real' exit that leads into or out of a tent, you might just make your 'exit' command take any tents into account. That's fine. That takes out some fun tricks like a portal-to-a-distant-mountain-in-a-bag, but those are tricks we can probably do just fine without. So tents are a fun feature, but they don't require us to do anything special to get 'em to work. At least, not enough to warrant a redesign - we're lazy.

Could we save all the *instances* of items and monsters and stuff? We might want to do that to allow a single goblin spawn point and just have the goblins run free through the MUD, for instance, so there would be a dynamic balance between guards and goblins constantly shifting, and players could try to turn the tide. We might because we were automatically generating rooms somehow, and we wanted them to stay the same from login to login, even across reboots. We might want to do it if we had a MUD that did dynamic story-generation and came up with places and people for the story, then saved them to re-use them. We might just because we really like persistent MUDs and want to see one work.

So in a world of all this interconnectedness, where you've got portable rooms (so you can't treat portables and room separately), and you've got items that can dynamically point to one place or another...

How would you do something like export a zone of your MUD to another MUD? What would zonefiles look like? Remember that not only do you have cross-zone exits to worry about, but you've also got a bunch of items that may reference things in other zones in one way or another.

How would you do it?

(Like I say, I've solved my personal problem, but I'm curious what other people have to say on this topic)

This is just a reply to the last bit about exporting a zone to another MUD.

Many MUDs are similar enough that this could be done in a meaningful fashion, if you export the type data and not the instance data. (Since the great majority of MUDs only have save/load mechanisms for type data today, I think if you want to export your instance data to another MUD you just can't.)

Basically someone should come up with a standard, say an XML format specified through an XSD file, that defines some common zone data. Then each individual MUD would have to write a converter to go from the standard format to their local format. XSLT is good for that.

One big issue is, who would be willing to write these translators? I wouldn't particularly want my MUD's zones appearing in another MUD. I guess an online editing tool could be created outside of any particular MUD, and so MUDless builders could make zones and put them out there for any MUD (that has a translator from the generic format) to use. (That is such a nice feature that even though I dread the fact that such a tool means if anybody ever stole my MUD's zone files those zones would immediately be available everywhere, I have to say its development is a good thing - you could make editing tools like you make clients today, with tons of spiffy features that immediately are useful on a wide variety of MUDs).

The actual stats on the mobs become very tricky here, because even to the extent that they map from one MUD to another, reasonable mobs in one would usually be wildly under- or overpowered in another. Ditto for items. It seems that only info that is either descriptive text or very tightly linked to the description (e.g. "this item weighs 10 kg", "this mob is a reptile") could be usefully included.

(Since the great majority of MUDs only have save/load mechanisms for type data today, I think if you want to export your instance data to another MUD you just can't.)

Yes and no. You may be able to export a zone to another MUD running a Phantasmal-based server

Quote:

Basically someone should come up with a standard, say an XML format specified through an XSD file, that defines some common zone data. Then each individual MUD would have to write a converter to go from the standard format to their local format. XSLT is good for that.

That would work. Phantasmal's also pretty good at sucking in stuff in different formats. I keep meaning to write a DikuMUD zone loader for it...

Quote:

One big issue is, who would be willing to write these translators? I wouldn't particularly want my MUD's zones appearing in another MUD. (...) (That is such a nice feature that even though I dread the fact that such a tool means if anybody ever stole my MUD's zone files those zones would immediately be available everywhere,

In the MUD world, we're so terrified of other people stealing our work that no work ever gets *published*. That's why we're stuck in 1994, feature-wise.

All the decent MUD coders I hear from, with a very few shining exceptions, are sitting in their little paranoid corners, releasing nothing, because they're desperately afraid other people will *use* it.

What's weirdest to me about that is that the coders never seem to write decent security into their MUDs, which seems like the obvious way to deal with this. Alternately, if you could export a zone well (note the current conversation) and put proper permissions on doing so, then a builder would only need to run a server at home (if you made the non-zone parts of the code available to them) and they could debug just their zone on a nice functional server. Then they'd re-export the finished zone from their home server and you could load it up on your MUD.

I avoid all this by releasing everything into the public domain, though, so I can get tetchy about all this "oh my god, they're going to STEAL my STUFF" paranoia. I just give away all my stuff. I also get annoyed at "I'll release it as soon as it's finished", since it never seems to get finished... So I release all my stuff instantly when I check it into CVS

Quote:

The actual stats on the mobs become very tricky here, because even to the extent that they map from one MUD to another, reasonable mobs in one would usually be wildly under- or overpowered in another. Ditto for items. It seems that only info that is either descriptive text or very tightly linked to the description (e.g. "this item weighs 10 kg", "this mob is a reptile") could be usefully included.

Again, this is easier if you assume you're exporting to a server that uses a pretty similar set of stats for mobiles.

First off, you can eliminate the 'types' entirely by going to a prototype based object system (think MOO, ColdC). Typically what you get under a fully persistent system like one of these is a text file containing the entire database. However, there are some things you could do: organizing objects into namespaces based on the zone that owns them, etc. There's also the potential for OID/symbol conflicts between database instances, so you'd probably need to include the instance where the object was originally created as well. As for cross-zone references, it's really no different than with the Diku system. You do fixups where you can, and otherwise you replace the reference with a broken link or null or whatever. Another problematic issue is that objects in prototype systems often contain behaviors (i.e. methods) as well as data, and these will often be highly dependent upon the specific object library present in a particular MUD, complicating matters even further.

These issues, combined with the fact that most MUD authors are downright paranoid about having their zones appear elsewhere in the first place, suggest that it's probably not worth spending a whole lot of effort on. Better to put that time into versioning and security.