[MUD-Dev] Graphic MUDS/Ultima Online
clawrenc at cup.hp.com
clawrenc at cup.hp.com
Wed Aug 6 17:21:35 New Zealand Standard Time 1997
In <c=US%a=_%p=EA%l=MOLACH-970730175105Z-157 at molach.origin.ea.com>, on
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
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
>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.
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
The basic result is that given long enough, anything will destruct and
>For muds to evolve, they need to become unpredictable.
Agreed. Implicit in this is the need for the world to become
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...
More information about the MUD-Dev