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

nu.kanga.list.mud-dev

80: Re: List software

[Full Header] [Plain Text]
From: "Chris Gray" <cg@ami-cg.GraySage.Edmonton.AB.CA>
Newsgroups: nu.kanga.list.mud-dev
Date: Tue, 18 Mar 97 06:57:31 MST
Organization: Kanga.Nu
:How important/useful would the following be?
:
:  Digest support for the list.
:
:  Monthly archives of posts.
:
:  Archives of the old list (Wout's and before).
:
:  Email requestable files (such as archives, code bases, etc).

I'd be somewhat interested here. I just sent out a request for possible
code snippets of Jon's NPC subsystems. I'm probably more interested in
low-level stuff than others might be, so what interests me might be more
detail than others want. A small setup of requestable files might work.
If needed, a small amount of space on my little ftp site at work could
probably be made available.

--
Chris Gray   cg@ami-cg.GraySage.Edmonton.AB.CA
l-scale GIS, so why not use the techniques found in other GIS implementations? The digital nature of things means that there has to be at least an implicit gridding to the system. All that means is that there is some finite number of locations that any object may occupy. So we'll give everything a pair of coordinates. To keep it easy we'll go 2-D and use a pair of 16 bit values for about 4 billion distinct locations. Since we don't want to explicitly code descriptions for each of the 4 billion locations, we'll use some spatial data structure (point quadtrees come to mind) to index objects, critters, and players. It's small, relatively compact and let's you do neato things like determine the distance to another object, find the closest object etc. Implement terrain features as thematic layers. Something simple like a region quadtree for each terrain type would do nicely. Again, they're small and efficient. ("one entry" in the region quadtree is the whole forest, rather than having to mark each individual location as forest/non-forest). No reason some terrain types can't overlap. Now when a person moves, you intersect their new location with the various themes. For each one that qualifies, you send a description. (i.e. if the player's location is coincident on a region in your forest theme, and the person is "outside", you add a line to any other descriptions sent that says "Yer in a forest". If they are "inside" skip the step. Interestingly, you can use this same kind of trick to let them look out a window) Now we need rooms. Sticking with quadtrees for the moment, just implement one that holds rectangles. Each rectangle is a room and has a description associated with it. The nifty bits: You can encode a _lot_ of info in relatively small structures. The structures can preserve spatial relationships... i.e. if they throw or shoot something you know if it hits a wall just by extending a ray from the player's location and testing for intersections in your "room" structure. Use "windowing" operations in the spatial structures for area effects. No reason you can't have a thematic layer of non-magic areas, of lawful and chaotic areas. The idea extends to 3 dimensions as well, but computational overhead goes _way_ up. But, if you host your mud on a bruiser machine, no reason not to. Sorry for the long post, -Todd ---------- > From: Nathan Yospe <yospe@hawaii.edu> > To: Multiple Recipients of MUD Design Mailing List <mud-dev@null.net> > Subject: Just a bit of musing > Date: Wednesday, February 26, 1997 7:31 PM > > A thread on rec.games.mud.admin has recently turned to combat interaction. [snip]