[MUD-Dev] Introduction

[Dan Root]

Ling <K.L.Lo-94 at student.lut.ac.uk> writes:

> > The 300k goal wasn't for the database itself, but for the amount of
> > code.  I was disgusted when I discovered that TinyMUCK was over 1.2M
> > of code.  300k is high itself.  I'm honestly hoping for around
> > 175-200k.  The database itself is likely going to be huge. :)
> 
> Hmm... Strange you guys talk about this sort of stuff.  Personally, I
> don't care coz I think my server will take up less space than an LP
> therefore it's small. :)

This goal came out of the fact that several of the codebases I played
around with over a meg or two of code, and I found it an exercise in
great fustration to locate anything useful in it.  Then I grabbed Jim
Aspnes SMUG (TinyMUD 2.4, sorta), and it was 136k of code that did a
large portion of what I needed to do.  (Unfortunately the language was
somewhat restrictive, and there weren't quite enough features).  

The other two code bases I was primarily interested in (UnterMUD and
UberMUD) were quite small as well, with most of the features I wanted,
but with quirky coding (MJR's code is beautiful... if you can
understand it) that made modifaction hard.

> [Rest of the stuff about languages and stuff]
> 
> Whoosh!  Straight over my head!

Basically it comes down to how much power and performance you
want/need and are willing to code, versus how 'user-friendly' it is.  


> I may as well drop in my extremely vague aims:
> 
> Majority of mud specific stuff coded into the server itself, eg: combat,
> standard object, room, people, elastic bands.

Definitely

> Attachment of code to any object.

I'm still mixed on how this will work.  Part of me wants all programs
to be 'special' and live in their own little space.  Part of me wants
the model of attaching code to objects, and the rest of me wants
*everything* to be coded functions.  (For example, my description can
be a function that just returns a string, or actually does a bunch of
work and returns the string based on calculation and lookups).

> Disk based.

Definitely.  My initial code does everything from disk, no objects are
kept in memory for more than a single 'cycle' of the server.
Eventually I'll add some more intelligent caching, but my machine has
lots of memory which makes for a wonderful buffer cache right now. :)

> *Portable*

Also a must.  I've gone so far as to not use real threading (just a
pair of process communicating via UDP loopback, and plans for
cooperative internal threading of programs) since that's not portable
across all the machines I'm interested in running on.  (nor are unix
domain sockets, though I could probably get by with those).

(FWIW, someone mentioned that process context switching was
expensive.  This is true, but your server is going to be switched out
anyways, as it's unlikely that nothing else is running on the machine
at all.)

	-DaR
--
Dan Root - dar at thekeep.org