mjr@hussar.dco.dec.com (Marcus J. Ranum) (02/27/91)
Archive-name: games/mud/untermud-doc/1991-02-26 Archive: decuac.dec.com:/pub/umuddoc.tar.Z [16.67.32.1] Original-posting-by: mjr@hussar.dco.dec.com (Marcus J. Ranum) Original-subject: Re: Re: Security in MUDS Reposted-by: emv@ox.com (Edward Vielmetti) mjp@otter.hpl.hp.com (Mike Prudence) writes: > > What's UnterMUD ? > UnterMUD is a MUD server that is just about on the verge of going into alpha development (IE: the thing's done, it just needs all the silly user cmds, like WHO, and take/get, drop, etc). It's not vapor. Some of you have seen it, and I will start making source public as soon as the basic command set is done. After that, I'll act as a central broker for new stuff that gets added and release control. What is UnterMUD ? Well, it's a couple of things, so I'll run down some of the features: * Server is architected in rigidly separated modules. IE: network layer is "snap out" and can be replaced - the rest of the MUD shares no data structures with it. The database and object storage code is "snap out", etc. V1.0 *may* ship with a VMS TCP/IP layer as well as a BSD socket layer. * Programmability is not supported, but what amount to a (I think) very powerful and intuitive macro langauge is. Basically it is a lot like having TinyTalk macros and c-shell aliases built into the MUD, rather than in the client. * Objects are stored to disk and paged into memory with a runtime settable cache (no HUGE processes). The object storage module is rigidly partitioned from the cache, which, in turn is rigidly separated from the rest of the server - so if you're on a machine with a db-engine, you can use it (with some coding). * Objects are stored internally in an "open" format, so there is no effective limitation to the number of attributes an object may have. Plus, the MUD has a very easy sematic for coding new data-types into it, and new attributes. A simple "Object Interchange Format" (OIF) is used to store objects in a portable manner. * Objects can be carried between two UnterMUDs. (this will be in 2.0 because I can't finish the transaction code until stuff like the inter-room movement commands are written) Thus a player can walk through an exit in MUD 'A' and find h*self in MUD 'B' with all h*'s stuff. There are a lot of issues in this, and they are all (unless there's one we've all missed) covered, but this is not the place to discuss them. * Connections between UnterMUDs are "on the fly" - IE: UnterMUDs can be brought up and down as desired. The model is that a given "wizard" might make a realm or small world or whatever on a local MUD, and make an exit (looks just like any other exit) to another MUD and vice-versa. Thus, people can visit the realm while it is up. MUDs no longer have to stay up 100%, though presumably nexii MUDs will. There are also a lot of issues here, most resolved, some not, but suffice to say that the objects here are that you can have your cake and eat it to: + If you want to put a LOT of effort into a realm, you can own it and manage it yourself, and not have it get jerked out from under you. + If you want to just hang out someplace, you can just hang out someplace and not run your own server, and if the MUD you hang out on will go away, you can just walk to another one. + If you want to have a small MUD with its own local "reality" you can, just hook it to another UnterMUD and you can step from a combat-MUD to a cuddle-MUD or whatever. + Server extensions can be localized, but your objects (as long as the wiz doesn't break OIF specs) will work between MUDs. * OIF coded objects can be dumped to a player. Thus you have an easy way of storing objects and re-creating them if they do happen to get stuck somewhere on a MUD that dies forever while you're visiting. In the V1.0 database routines, objects are stored in a UNIX-filesystem directory hash, in ASCII and can be editted with vi, your favorite editor, ;) backed up with whatever utilities you like, put under RCS, etc. This approach is suprisingly fast, BTW. * Most parameters that you normally hard-code into your MUD are runtime-settable. Cache sizes, sync times, hash table sizes, MUD name, network ports to use, etc. ** UnterMUD is designed from the ground up to survive success. What does this mean? It means that where something could be made a separate module with a distinct interface, it was. The low-level routines are all separated from the higher-level ones, and a person can pick the level they want to work at. (Most people won't probably want to muck about in the network layer and won't HAVE to) The motto of UnterMUD is: "don't write code that will require a kludge later". For example, the player commands are all formed into a library in a separate directory. The entire command-table is linked into the MUD through a single table in a single file. Adding a new command is trivial. More importantly, if there are a VARIETY of commands, choosing which ones to turn on or off is a matter of #ifdeffing one line of code, in one file. The emphasis of UnterMUD is to do *EXACTLY* 180degrees the opposite of UberMUD. UnterMUD is intended to be simple to use - if you play TinyMUD and use TinyTALK, you are already (almost) an experienced UnterMUD user. Some of the commands will be different, because I simply couldn't stomach parts of the TinyMUD command syntax (Building will be simpler). There's a talk I "hosted" on ASYLUM that discusses some of this in more depth, and there is some rough internals documentation. I've made a tar file of the current state-of-the-UnterMUD docs, and put it in ~ftp/pub on decuac.dec.com I expect I'll start agressively alpha'ing this guy in a week or so, and then beta-ing it with the source released. The interMUD network code will be done in a bit longer, since I want to make sure the core server is thrashed out. When I start beta-ing, I'll start a mailing list, and maybe look for volunteers - don't ask yet. mjr.