mjr@hussar.dco.dec.com (Marcus J. Ranum) (06/20/91)
Archive-name: games/mud/untermud/1991-06-18 Archive: decuac.dec.com:/pub/umud1.0.tar.Z [192.5.214.1] Original-posting-by: mjr@hussar.dco.dec.com (Marcus J. Ranum) Original-subject: Re: the meg mud Reposted-by: emv@msen.com (Edward Vielmetti, MSEN) mlg@dew.cs.odu.edu (Snickering) writes: >Two questions: > 1) is unter publicly available? > 2) is unter programmable? (as in lp) Unter is publicly available for anonymous FTP from decuac.dec.com in pub/umud1.0.tar.Z. This is the pre-final-cut release, in fact, and is (unless any final nits crop up) the V1.0 release version. Unter is programmable to a *degree* but nowhere NEAR as programmable as LPMud or UberMUD, as it lacks notions of looping, temporary variables, or list traversal. The way I think of Unter is as a macro-MUD rather than a programmable MUD. In other words, you have the capability of tying fairly powerful macros, which are basically commands, to objects - any command that a player can type can be used for a macro - the execution is governed by the same mechanism. As far as programmability, then, if you're a die-hard LPMudder, you'll probably think Unter doesn't cut it. If you're used to TinyMUD and use TinyTalk macros, Unter is like TinyMUD+Talk on steroids. Now that I've lost your interest, let me elaborate a little more: UnterMUD has no fixed limit on the number and variety of data types or object attributes (Unlike TinyMUD) and was designed from the start to be eas easy to modify as possible. I didn't want or see fit to add a native programming language to UnterMUD *BUT* I left the server code as open as possible to allow (pretty much) any number of possible interpreters to be "wedged" into the server. The only limitation is how UnteerMUD handles attributes - as newline terminated strings, so byte-compiled interpreter ops is out. (unless you byte-compile to a string of opcodes) >>[...] huge Mega-Servers with 80Meg >>core images are dinosaurs - they consume too many resources and are >>not resilient enough against the vicissitudes of the net. > > granted, the area still needs improvement is in resource >management, size and speed. Well, I think UnterMUD *IS* a vast improvement. For one thing, it's disk based, with a pretty clever caching layer that makes it perform fast enough that you usually won't realize it *IS* disk-based. As a result, the server's executable size will stay small (though if you have a room with many many objects, the server will "stretch" to fit the worst case). In addition, UnterMUD has a variety of disk-basing schemes, data conversion tools, runtime resizable cache, fast online backup, and so on. Fast? It runs fast enough that I can't tell the difference when it is running on my DECStation3100 as opposed to a heavily nntpd-laden MicroVAXII - it (unlike some MUDs) seems to actually be network band- width-limited. When you step into a LARGE room full of junk, the disk will gronk a little - a HUGE room full of junk and it'll gronk a lot. (HUGE == more than 2,000 objects) I claim (with some basis in fact) that UnterMUD solves the resource management problem - by spreading the work around - people who want to build elaborate "zones" can do it on their own machines, manage it themselves, maintain it, edit it, back it up, etc, and *NOT* have to rely on the wizard of some overladen CPU's largesse. Since the databases are stored and coded in a standard format, they can easily be manipulated, mailed back and forth, etc. For an example of an OIF-coded database, the TinyBASE database is also available for anonymous FTP from decuac.dec.com, in pub. >>building of large MUDs but with a degree of fault tolerance, by actually >>having the MUDs be linked servers in a local geography. If one portion >>of a realm goes down, or is shut down by site policy, the whole universe >>does not crumble. > ON NO!!!! ITS IRC MEETS MUD!!! Run for your LIFE!!!! *laugh* I don't know enough about how IRC works - I suspect that IRC does some kind of data-propagation, which UnterMUD *ONLY* does when someone tries to "walk" from one MUD to another. This works very well in practice, since if the remote MUD is down, the connection fails, and it's the exact same as trying to walk through a locked exit. If the other MUD is up, only then is a burst transmission of transactions sent, and acknowledgement received, and the "walk" is completed. Maybe I should look at how IRC works - did they do it right? mjr. -- THIS IS A DISCLAIMER. That's because there is always some IDIOT out there who sees a posting by me, gets the idea that I have an inside line on corporate policy, and gets bent out of shape. If you can figure out how someone smart enough to slobber on a keyboard can make such a leap of faith, please tell me. -- comp.archives file verification decuac.dec.com -rw-r--r-- 1 388 system 229785 Jun 17 21:13 /pub/umud1.0.tar.Z found untermud ok decuac.dec.com:/pub/umud1.0.tar.Z