[MUD-Dev] Neighborhood watch

[Nathan Yospe]

On Sun, 29 Jun 1997, Chris Gray wrote:

:[Notice how I'm carefully avoiding exploding my brain with all this
:neighbourhood stuff!]

*chuckle* I rather mixed terminology (Jargon, people, HEAVY Jargon) from
Mathematics, Physics, certain areas of Software Engineering. On later
review, that post of mine was quite confusing.

:[Nathan Y:]

::You are aware that I consider the trend toward complete seperation of
::server and behavior a negative one. I suppose I am a minority on this one,
::like the "levels" people on that issue, but there it is. I like having
::support for what I consider fundamental constructs inherent in the server.
::Locations, Physicality, and so forth... As such, I use my neighborhoods as
::the center, and having Physical manifestations within them is not a
::requirement. A physical object CANNOT, however, exist outside of a
::location.

:I'm curious as to your reasons for avoiding the separation. Could you
:say something more on that? I certainly agree that the two have to
:aware of each other (c.f. my discussons with Caliban), but why not make
:them as independent as is reasonable? My main concern in that aspect
:is that of efficiency. If I find that something I want to do is not
:very efficient with the server, then I feel fully justified in adding
:some wierd builtin function (appropriately generalized of course!) to
:the server and using it.

There are a few reasons. Number one, I suppose, is that, while there are
obviously a LOT of people here better than me at designing a virtual
machine and a language for it, there always seem to be limitations on the
language, and not one of the existing languages supports what I am
attempting to build. This sort of strikes me as rather defeating the
point. So, what we have is a server that is by itself useless, being used
to run a mud that is limited by server limitations. Now, I could write my
own server, completely seperate from my codebase, and implement the
codebase in that. This would seem to solve some of these concerns. But my
server would be, because of my imperfect skills in server optimization,
inferior to others out there, except when applied to a game similar to the
one I am designing. On the other hand, what I have done so far, a library
of tool classes, written in C++ and completely modular, could be applied
to any similar design. On top of that, the system is flexible and
modifiable, to a greater degree than anything currently hardcoded out
there that I have seen, so it does not suffer the inflexibility problems.
Using it to write a mud in another genre would require some hardcoded
changes to one or two libraries, Physical and Composition at the least,
but once done, would be extendable in that genre from that point. I
seriously doubt that many people online code from a server to a fully
functional mud without ever going offline or relaunching the executable.
In addition, I find the language, being a well known and not overly
difficult one, well suited to these purposes, as long as people stay out
of the core libraries, which are, I will admit, less readable. On top of
this is the fact that a number of the core concepts that run through the
mud, the universal behavior chains and message passing, for example, have
close-tied analogies in the game world, to a degree. For example, the
location/containment concept is tied into (rather, inherited by) the
concepts of spacial positioning in the mud... but it is also the basis of
primary database access, and of the GC/ref count system (inverted).
Therefore, all Physical objects MUST have Location. This is a functional
system, and has a number of advantages over a straight database, not the
least being ease of creation of a fast (checked, and it is between log and
linear) collision detection system. Like I said, this puts me in the
minority on this one, but I can handle that.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu