List software

[claw at null.net]

On 19/03/97 at 12:12 PM, Wout Mertens <Wout.Mertens at rug.ac.be> said:
>On Tue, 18 Mar 1997 claw at null.net wrote:

>> 'Course if I do that, I may also try and revive something like
>> MUD-RolePlay-L or Marcus' Wizard list.  I suspect from the groups that
>> there's still a huge unfilled need for concentrated, guaranteed high
>> signal MUD discussion.
>
>Sounds nice... (I won't be on them mind you, I haven't got any time
>left to wizard. I'm happy enough that I still have time to remember
>that I have to write a mud...)

Heck, at the rate things are moving right now, I'm not sure I'll have
any time to even look at moving the list base to Steward.  <sigh> 
Still, the idea's there.

>Which reminds me: How did you write your mud? from scratch? based on
>some routines you had lying around and them fused together?

Oooh boy.  Long story.  Short answer: From scratch, with lots of
retries, restarts, and abandoned dead ends.  I was contracting pretty
much the whole time, so also borrowed lots of ideas from various
workplaces and folded them in (more or less successfully) as I went
along.

Back in, oh, roughly late '84 timeframe I was playing Shades and SX
MUD (MUD1/MUD2) a lot, and started talking to Pippin Caudry (cf IOWA
and Bartle's MUD survey for placement/reference) about writing a MUD
server for him to run on a BBC micro on direct dial-in lines.  About
the time that I actually started work on designing the beast (an
absolute hack I now would shuddered if it had seen the light of day),
Pip instead decided to run with a local PL/1 chap who said he could do
the neatest thing since sliced bread (never happened -- Mirrorworld,
which was already in development, took its place).

However, I was hooked on the idea of a really *NEAT* MUD server.

I had hold of a PC, a PDP-10, and was infatuated with the parallel
processing concepts of the the then new Inmos Transputer and Occam. 
I'd also just bought a copy of Zorland C (nee Datalight, later
Zortech, now Symantec) and was teaching myself C.  I generously
figured that by the time I had the damn thing designed and partly
written that I'd have a Transputer based machine with at least three
or four T400's to do the rest on, and Occam would probably have
succumbed to C (pray pray).  <kof>

<<Still got all those early notes and design drafts too>>

By about 1Q87 what with the rest of real life and trashing everything
I'd done a couple times, I had a DB layer all done along with area
import/export, along with offline room, object, and mobile coding. 
<<Can you say three byte longs?  I thought you could.  I used them
*everywhere* in the DB to conserve space (lotsa arrays).  <unghh>>> 
Never did touch the actual run-time aspect then -- was still waiting
for decent MP hardware to do the event stuff on (it was event driven
from the start -- I never even thought of a polling loop).

Nearly went to work for CIX with an aim to doing a MUD server on the
side for them.  Came back to the States instead.

About the same time I started get on the 'net seriously, and
discovered LP, the Tiny-* clan etc.  Trashed everything I'd done
again, dropped the three byte longs, and decided to go with a simpler
DB, and event architecture running atop MINIX.  Fell in love with Aber
(as a player) and spent an awful long time playing Northern Lights. 
Later decided to move the OS base to XINU.  

MOO (the original, pre-Lambda) happened about this time.  Thought it
was a wonderful idea, but buggier than crap.  Thought the design
concept was neater than sliced bread (everything in the DB, totally
dumb server, objects/methods etc in the DB too, objects animated
themselves).  Also thought the everything-in-memory model was stupid,
and didn't like the polling architecture.  

Started working a lot with OS/2 back when 2.0 came out.  Decided that
this multi-threading thing was a pretty damned neat replacement for
full parallel processing and Transputers, even if not quite as slick. 
Started recoding, moving everything to OS/2 and MT.  Went to a
disk-based DB model with a central MOO-style DB running everything.

Back in Oh, '94-ish decided to do C++ the thing.  Started again. 
Cleaned up the event model a LOT.  

Everything is homegrown.  Major inspirations (mostly in time order):
Shades, MUD2, Transputers, Marcus Ranum, Uber, Unter, LP, Aber, Tiny*,
Northern Lights, MOO, Stephen White, LambdaMOO, a large bunch of IBM's
OS/2 developers, Cool, Interlude (neat!), Dave Engberg, C++, Cold,
Mike Cowlishaw, Legend, ColdX, Greg Hudson, MUQ, BeOS, Inferno, Limbo.

>And in what order did you develop everything? Like for example the
>DB. Pretty convoluted stuff to just spew out and hope it works... No?

I believe in test drivers built into the code so a conditional compile
will make an executable that will excercise the entire class,
encluding (if possible) ALL flow paths.  It makes unit testing a LOT
easier. Then run a basic level/key sensitive trace/report class that
lets you watch at any level of detail you want and you've got Gawds
own homegrown sniffing system.

I tend to do large, reasonably self-contained blobs on each attack. 
Thus the DB end (which I'm re-doing now for transaction support and
rollbacks) will be done as a self contained unit.  Next after that
will probably be the cacheing class which will be a two layer beast (a
general cache and a tailored representation of the DB).  Similarly the
network IO, Collector, Dispatchor, etc are all pretty black box, and
developed stand-alone.

What lump gets down in what order?  Truth to tell: whatever the heck I
feel like.  Usually its whatever seems "neat" and doesn't have too
many dependancies on code I haven't written yet.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
..Honourary Member of Clan McFud -- Teamer's Avenging Monolith...