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

nu.kanga.list.mud-dev

90: Re: Just a bit of musing

[Full Header] [Plain Text]
From: Wout Mertens <Wout.Mertens@rug.ac.be>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 27 Feb 1997 14:39:36 +0100 (MET)
References: [1]
Organization: Kanga.Nu
On Wed, 26 Feb 1997, Nathan Yospe wrote:

> X - node
> O - object (character or item)
> D - description
> B - blocking description
> S - screening description
> 
> D D D D D D D D D D D D D D D
> D B D D D D D D D O D D D D D
> D D X D O D D X D D D D X D D
> D D D D D D D D D S D D D D D
> D D B D D D S D D D D D D D D
> D D D D O D D D D D D D D D D
> D D D D D D D D D D O D D D D
> D D X D D S D X D D D D X D D
> D D B D D D D D D D D D D D D
> D D D D D D D D D D D D D D D
> 
> A blocking description would block things "behind" it, using the 2D
> crystal latice matrix transforms to determin "behind"ness. Screening hides
> the things behind it to varying degrees. Multiple objects can occupy the
> same location, but have volume concerns. A "node" corresponds to a room,
> and could concievably have size variation, though that is not necessary to
> the design. The nodes portrayed here have scope 5x5.

Uhm... So a wall would be a line of B's ? and a window in that wall would
be an S? And how are you going to generate all those descriptions?
Standard terrain desc+ variations or something like that?

And what about tunnels and the like... This system would be something like
nethack with levels?


A system I would love would be something like Descent in world buildup.
Thing is, you need VRML or something like that to portray that.

Anyway,

Wout.

gning 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...