Greetings. :)

[coder at ibm.net]

On 01/04/97 at 09:47 AM, Michael Hohensee <michael at sparta.mainstream.net>
said: >On Mon, 31 Mar 1997 claw at null.net wrote:

>> I've not actually assigned a name to my server.  
...
>Well, I was going to call it "MyMud" for a while, but then I found that 
>name was already taken.  

That's the Pascal-based MUD server, no?

>> >	A way of treating all objects (players, creatures, rooms, etc) as 
>> >if they were the same for certain common uses. (common-use being
>> >defined  as anything you want everyone to be able to do.)
>> 
>> Hehn.  I actually make no distinction among players, mobiles, rooms,
>> objects, utility objects, etc.  There are just no unique object types. 
>> They're all the same to the server.
>
>Doesn't that waste memory?  

No really.  I don't run in memory.  I run off a heavily cached disk-based
DB, so there is no in-memory class structure.  

Part of the key here is that my server actually knows nothing about the
game it is representing, or in fact anything about any games at all. 
Truth to tell, my server has no concept that it has anything to do with
games at all (that was one of the design criteria).  What the server does
know about is its databse, how to submit queries to that database, and
that's pretty well all it knows.  Everything else, all the game stuff, the
command parsing etc happens as code written inside of database records.

This is probably better understood from the inside oot, rather than trying
to look at the server side:

  Everything is an object.
  Objects are defined in a database.
  Objects have Unique IDs.
  Objects may contain methods, attributes and verb templates.
  Objects may inherit from other objects (multiple inheritance).
  Methods may call other methods during their execution.
  Everything that happens is part of an event.
  An event is a grouped set of state-changes which occurs to the DB 
    atomically as of a known time.
  An event may log future events.  (ie A method, should its event 
    succeed, may log future events)

Essentially what happens from there is that the server determines that
there is an event to be executed, and calls a specified method on a
specified object with particular arguments.  That method then executes
from there, calling other methods on other objects etc as needed.  At some
point the event terminates, all the changes to the DB are commited
atomically, and the server goes back to doing nothing.  

Internally the DB, pr at least object ineractions, may be viewed as a
message passing system.  Methods send messages to other methods, which in
turn acknowledge/respond with messages (possibly after calling other
methods).

  An object consists of an inheritance tree (multiple inheritance), 
    methods (code), attributes (values), and verb templates.
  Verb templates conditionally match and auto-parse user commands, 
    matching them to methods on the defining object (see ColdX).
  Any object's method may call any other object's method, whether or 
    not it knows that method exists or is defined on the target 
    object.
  Such a call is actually a message, and may be handled in any manner 
    by the receiving object.  As such, it is up to the receiving object 
    to respond appropriately to the message with its own message back to 
    the caller.
  In this manner the receiving object can reply that it doesn't support 
    the method called for, does support it but its internal security 
    processes prevent it being called, a standard return value from the 
    call, etc.

>I did that for a while, but I couldn't see 
>why a jar needed to have a sex value... 

The difference is that I don't require anything to have a sex value.  If
someone wants to insert one at the appropriate place in the inheritance
tree, then a bunch of objects will suddenly gain one (can be done at
runtime).  You could ask a jar on my system for its sex, and it could well
respond with a stated value, a "Huhh what?", raise an exception, or do
anything number of things.  The real point is that I don't prevent
anything from _asking_ the sex of anything else.

>I treat liquids as independant objects.  I've got an update pulse 
>(modeled after dikumud pulses) that will have the liquid check to see if 
>it is in a watertight container.  If it isn't, some of it "leaks" out.  
>The liquid object has an "amount" variable, and this is decreased when 
>some leaves the container.  I've also got one function for moving things 
>around, and it checks to see if the liquid has all been spilled (move 
>whole object to outer container) and checks to see if there is a liquid 
>of similar type in the outer container (sum the amount variables, and 
>recycle one object.)

Ahh, minus the update pulses (mine is a totally event driven server) I
pretty much do the same here with my mana flows (mana flows about the land
much like a liquid (actually more like a gas)).  An area I'd really like
to crack is liquid flow such that free liquids would puddle, flow in
streams, form rivers etc.  

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