[MUD-Dev] Re: Quotes from Marcus Ranum

[Nathan F Yospe]

On Fri, 26 Jun 1998, J C Lawrence wrote:

:>  Nathan Yospe's model (which has been partially admpted by a few
:>others) is compute heavy as he dynamically simulates fragments of the
:>world by computing its current state by extrapolation from the last
:>time it was fully generated (almost no fixed data definitions, only
:>fixed formulae and an axiomatic base of laws of physics).

:How has it worked out in practice?

I suppose I should answer this. In practice, I don't know. Experimentally,
it has advantages and drawbacks. An advantage is that the primary limit on
capacity is the number of active users. A disadvantage is that CPU usage is
the most intensive bottleneck, and clever caching mechanisms can only go so
far. I'm thinking of experimenting with G3 chips... a dual G3 Rhapsody
server might be just the thing for a local server node's host.

I've found that
 - The optimum timespan for switching between the deterministic and
probabalistic update methods seems to be about 10 minutes. Under 10 minutes
results in the cost of probabilistic evaluation being higher than the cost
of calculating every event in those ten minutes sequentially when
reactivated.
 - The optimum timespan for switching between probabilistic and contextual
update methods seems to be about 35 minutes, but contextual updates look a
little fishy if performed in an area that has been visited in the past 36
hours. Therefore, the benifits of contextual updates (which use trends for
a from-base update on the basis of a modifier table, and a fudge factor)
are not realized for a couple of days. I finally settled on four days, at
which point only a pedantic player has any right to expect the grass to be
trodden in an exact spot, as opposed to a vague trail... there's no way a
player can guarantee that someone else didn't come by and move that rock,
et al.
 - The majority of situations can be handled without resolving any detail
beyond the most general until a player requests greater detail. If I have
a balloon with a picture on it, the details of the picture will be stored
as a key to a client to server data request. These details will *not* be
fed to the client unless the client requests them. The client will present
a "balloon with a picture on it" unless greater detail is noticable (IE, 
the player is close to the balloon) or the player pays attention to the
balloon. Detail requests are originated by the client in all cases. The
server will happily never serve optical information seperate from spacial
data to a client handling a blind or sightless (alien) character. Likewise,
there is no thermal data passed unless specified by client (no, these are
not all case-by-case transactions, most are stored serverside until the
client modifies them, with a sort of agent-for-the-client class acting on
the client's behalf), and no tactile data when the client has not sent a
request, or made contact. (I've given thought to restricted information,
but, I figure if they want to hack for more info, let them. A little
incentive to the programmers out there.) The beauty of it is, if there is
no request from the client, a lot of this stuff remains unresolved. I call
it lazy instantiation. The world only exists where you are aware of it.
All the rest is just potential.
 - My inheritance structure, which is key to the lazy allocation scemes,
needs to be placed into a better DB design. I hate databases! Damn, I'm not
looking forward to writing the replacement for my (too slow to resolve) DB.
(The DB as it exists is transparently in memory or on disk... which means a
frightfully large in memory ref table, sort of like 68k mac handles, but a
bit slower to resolve.)
 - I can generate worlds far vaster than anything that currently exists. I
have given thought to hosting each stellar system on a seperate sever
process, and hosting one to 50 server processes on any given machine. Some
of these stellar systems are rather dull, and a bunch of systems with no
habitable planets could be jammed on one machine.
 - I can easilly transport things between one server process and another. I
have to handle a bit of overhead each time when every base object on one
server is present on the next. Numbers must be maintained from one server
to the next. I handle this by assuming I will never have more than 4000
servers, and snagging the first 12 unused bits (out of 58) for a server ID.
If I ever end up with more servers than that, I'll have to overhaul
everything and switch to 128 bit longs. :P It is possible to inherit from
an object that originated on another server. Non-generalized objects are
broken by category, and have the first 96 "server IDs". The search method
is optimized (yeah, right... but that's what my design docs claim) for those
96 first, then the local server ID, then all others.
 - object clusters do not make permanent inheritable copies of themselves
in the database unless inherited from, at which point, they do copy and
reserve an ID. Object clusters function as temporary object types. All
objects are clusters. An object will resolve into clusters of finer
granularity on sufficient investigation, using dynamic resolution, until it
becomes a random association of componant substance (with impurities).
This should never actually happen. The entire server is one object cluster.
It should also never have to be called upon for investigation directly, as
there is no parent location to call it. I have found that most objects are
treated in terms of clusters of approximately 1 to 500 primary objects.
A primary object is an instance of something grabbed from the database and
inserted into the gameworld. A character, chair, or book might be a
primary object. A primary object of a (filled) bookshelf would have generic
books in it, but a cluster of 500 individual primary objects (books) and 1
primary object (bookshelf) would have books of some significance. The
contents would have to be individually entered, or the client would get a
resolved set of giberish on pages. I have no idea if a builder would do a
thing like that... but it could be done, at high cost in memory allocation.
Builders will have to be doled out limited memory resources.
 - how does it work out in practice? I don't know. In experiment, it has a
tremendous amount to offer... and costs like hell.
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/