[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

88: Re: List software

[Full Header] [Plain Text]
From: claw@null.net
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 19 Mar 97 08:40:37 -0800
References: [1]
Organization: Kanga.Nu
Note: CC'ed to the list for general indigestion.

On 19/03/97 at 12:12 PM, Wout Mertens <Wout.Mertens@rug.ac.be> said:
>On Tue, 18 Mar 1997 claw@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@null.net
----------(*)                              Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...


populated :with players would no longer propagate, which would cause remote reactions :to their rumours (cf watchers, spoofs and triggers) to no longer occurr). This, for me, can be handled completely by the update factors... and I could never run a simulation without a TuringAI controlling at least one Character in the simulation region, and TuringAIs trigger action the same as Players. TuringAIs are designed to convince Players that they are Players, thus upping the apparent Player density... and forcing people to look alive, lest they be mistaken for a poorly designed TuringAI. The less desirable Players get kind of weeded out by these things. In any case, the overhead on the system, if I ran _everything_ would be far too great. Better to run a handful of Areas where the Players are... it also keeps track of where people go quite well. :>I have attempted to balance this by programming some :>NPCs to be "marshalls" for other NPCs or controllers of city/town :>subsystems. Thus not all NPC scripts are active and consuming resources :>all the time. For instance city guard captains are programmed to issue :>patrol orders and attack orders to their charges. An interesting side :>affect is that by taking out a "marshall" or subsystem controller, a ^e? :>great amount of chaos ensues until a replacement NPC is found. :Cute. I like this. Hmmm. I tend to like everything remotely active to be completely active, thinking for itself to a greater or lesser extent. :>In a related vein, I was inspired by Nathan's description of his :>implementation of the physical laws of the universe to do something not :>altogether dissimilar in my server. While Nathan's model seems highly :>appropriate to a real world with real laws of physics, my world's physics :>are entirely subject to the whims of the gods. I don't believe in :>physics, I believe in divine intervention. (*grin*) It was my original :>intention that all immortals/deities actually be THAT. They can be :>player/administrator run and can be used literally as gods. My immortal :>pantheon is very similar to the greek mythos albeit with different names. *grin* I modeled a bit of that into my graphical project... I like it too, and hope someone will eventually run such a world with a Physmud++ base... I certainly provided enough support for that, and for alternative physical models... nonetheless, any consistant model will create a better mud, whatever the model may be. :>They demand sacrifices, quests and generally participate in mortal :>affairs. As such they are roleplayed by whomever is granted with the :>responsibility. With this in mind, I have done away with my solar/lunar :>timer events and have assigned maintenance and execution of these events :>to the Apollo NPC's and Artemis NPC's subsystems. Quite nice. How do you model the Deiatic charis :> It may be that Apollo might wish to delay the sunrise to allow a favored :>player to gain advantage in an early morning attack or Artemis decides :>that an eclipse would be appropriate to auger a significant event. With :>the NPC always "playing", it is possible for them to respond in an :>automated way to sacrifices, prayers and quests. There are many other :>possibilities, as I decide which dieties' subsystems control which mud :>events. Linking scheduling is quite simple in my system, partly because I had to allow for the distorted physics of the region around a black hole, the effects of time dialation, and simpler matters such as different planetary systems, differing gravitational fields, free fall localities, fluid environments... I think I could link in a "gods" system fairly easilly. The whole point of Physmud++ is that it can model any, _any_ set of laws to the universe. :cf the original Gods system. You can find a passable description in :Bartle's original MUD survey. Uh... what survey would this be? __ _ __ _ _ , , , , /_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn / / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone Nathan F. Yospe - University of Hawaii Dept of Physics - yospe@hawaii.edu