I've been testing Quest's viability as a MUD codebase and am very pleased with what I've been able to accomplish. In my tests, I've been able to utilize LPC-like commands for dynamically creating rooms, exits, modifying properties, spawning objects and a multitude of other admin-type commands. I've been able to use login/user scripts. I've had some success with various emotes and emits, and the use of proximity. Quest can definitely be used to run a MUD, but in my opinion, it lacks a few things to make it even better. The following is my wish list, in order of importance:

1) The ability to destroy objects. For good. Generally, a multitude of base objects are created before the game goes live. These objects are then "spawned" to create copies (i.e., you have a base sword coded in the .ASL, but may have 50 swords spawned from that base sword in the .QSG. A MUD will eventually gather a lot of clutter. Because MUDS, more than regular IF games, will use the for each command rather extensively, lag will eventually become a problem.

2) The ability to either "fold" the .QSG file into the .ASL file or edit the .QSG file directly. Because a large chunk of the game will be modified or added to dynamically, it would be helpful to have the ability to re-organize or change the .ASL file containing the stuff that's changed while the game is running.

3) The ability to write scripts "on the fly." This would go a long way toward creating a more usable LPC.

Other than that, Quest holds its own against some of the codebases I've played with, and wins with ease of use.

Thanks for this. What other systems have you tried? I've not actually looked at other MUD systems in a great amount of detail, since I designed QuestNet as an extension of Quest rather than as a new MUD system in its own right.

1. "destroy object" is on the "to do" list. It won't appear in v4.0, but it will appear shortly afterwards.

2. Interesting idea about merging a QSG file into an ASL file. In principle this should be quite possible. I will think about it as a feature for QDK.

3. Not quite sure what you mean by this - do you mean somehow being able to write scripts from within Quest? This would be fairly nasty to implement - but if you were able to merge in QSG changes to your ASL, would that make it easier to do what you wanted to do?

If you save an online quest game then shut the server down, then change the asl file it's using. then load the saved file it will load the updates from the updated asl file, so updating online games is not a problem.

Alex,

There's the entire gambit of MUD codebases out there. Some of the more popular ones are CircleMUD, PAINMud, Smaug and Diku variants. I understand that Quest was never intended to do what these do and, out of the box, it doesn't. But it can programmed to do most of the things most MUD codebases do with the obvious exception of handling LPC-like coding. The obvious draw of using Quest over these is 1) its ease-of-use and learning curve and 2) Quest gives you complete, simple control over your entire world where most MUD codebases need to be deconstructed and put back together from scratch if you want to implement certain ideas.

As for on-the-fly scripting, this sort of thing is handled in most of today's MUD codebases. It allows for the ability to manipulate and modify, create timers and code while the game is running. For example, I want to be able to spawn a sword and modify it to be magical, and then want to change it's "swipe" command to emit something magical. Some of this can be done now. Some can't. In order to implement my idea, I'll need to write a script that handles the "swipe" action.

If you could merge the .QSG into your ASL, yes, it would go a long way toward handling that aspect.

elexxorine,

Yes, but I'm talking about game changes that take place while the game is running, and objects manipulated and stored in the .QSG file. If you clone an object while the game is running, there's no way to go in and modify that object, because it's stuck in the .QSG, not the .ASL.