[MUD-Dev] Graphic MUDS/Ultima Online

[clawrenc at cup.hp.com]

In <c=US%a=_%p=EA%l=MOLACH-970730175105Z-157 at molach.origin.ea.com>, on
07/30/97 
   at 07:43 PM, "Koster, Raph" <rkoster at origin.ea.com> said:

>On Tuesday, July 29, 1997 6:46 PM, Matt 
>Chatterley[SMTP:root at mpc.dyn.ml.org] wrote:
>> On Tue, 29 Jul 1997, Koster, Raph wrote:

>Of course the social environment is very relevant; it's crucial. It
>is  also one of the things that oddly enough, we can take for
>granted.  Provide enough environment (far LESS environment than a mud
>offers, in  fact, cf IRC, ICQ, heck, ham radio, etc) and the social
>aspect will  follow inevitably. My argument was that in terms of
>dynamic evolution,  most muds settle for solely this one thing, the
>one thing they didn't have to do any work to get. :)

Thou writeth sooth.  Its a massively ignored fundamental.

>What we do is have what we call a "resource model" in which
>everything  is defined in terms of a basic hierarchy of desires taken
>from  organizational behavior theory. Subsistence, shelter, luxuries.
>Then  we have generalized AI routines and basic decision trees to
>satisfy  these needs, hoard if you can, band together if you are so
>inclined,  defend if you must...

>Well, I work with Richard Garriott fairly closely. He favors 
>simplicity in his design. (Which may seem contradictory given how 
>complex Ultimas are). But in general, he prefers simplicity for 
>interface and also simplicity for underlying systems, as much as 
>possible. 

FWLIW my approach is to make very simple self-contained blocks, and to
then have multiple blocks interact to create very complex systems. 
The trick I find is to create unstable feedback loops and to then
ensure that their combination does not create a stable state
(simulators are excellant here).  Typically the addition of of
unstable feedback loops dependant on other resources than the loops
which created the stable state will ensure that stability is never
achieved.

>You make an item.

>It either spawns back when destroyed, or isn't destroyed, depending
>on  world-state model (repop versus save-state).

>But when does it EVOLVE? Now, some may say that in mud architectures 
>which permit dynamic attachment of scripted behaviors by players, 
>stuff evolves. To get back to my example of TinyTIM, that clock or 
>whatever it is at the entrance that by now is massively huge. But
>that  isn't evolving by itself. That's just more functionality
>slapped on it  by a builder of some sort. It is not dynamic; it is
>static save for  outside intervention. It is therefore predictable.

My model:

  All objects decay over time, eventually becoming dust.

  Certain actions can delay that decay.

  Magical objects consume mana to delay decay.  Should they be unable
to get the mana the need, they destruct.  

  "Normal" objects just decay.  Use (depending on type) can
accellerate or delay decay.  

  User programmed objects (inheriting from $NEW_OBJECT) have a short
half life.  Sufficient use resets the half-life temporarily.

Magical objects have multiple ways of destructing.  The whole object
can just turn to dust (see the UggUgg mana fight example), the magical
properties can just cease to exist, the magic properties can go latent
until more mana arrives (very expensive to create, requires a *LARGE*
hidden mana store to draw from to survive starvation), or the magical
properties can release (ie explode) with various entertaining results
as the embedded magic/mana releases and rebinds in various forms to
nearby objects.

The basic result is that given long enough, anything will destruct and
dissappear.  
  
>For muds to evolve, they need to become unpredictable.

Agreed.  Implicit in this is the need for the world to become
unstable.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...