[MUD-Dev] Graphic MUDS/Ultima Online

[Matt Chatterley]

On Tue, 5 Aug 1997 clawrenc at cup.hp.com wrote:

> In <Pine.LNX.3.96.970730072419.133B-100000 at mpc.dyn.ml.org>, on
> 07/29/97 
>    at 11:46 PM, Matt Chatterley <root at mpc.dyn.ml.org> said:
> 
> >Yes. One way I reach towards some sort of development is with a
> >system of 'tribes' of monsters which behave like real population
> >groups might. Not enough time to go into depth now, though.
> 
> The Orc breader/warrior/noble/king scenario which I'ce mentioned
> several times (repost on request) is a simplistic to implement and
> surprisingly complex and detailed in practice in the game.  What I
> find most interesting is that it is purely a linear extrapolation of a
> couple base principles:

Your orc example is probably what sparked my idea; I don't actually
recall wholly, but thinking back, it seems the same premise. It's
certainly not hard to implement, even in a generalised form.
 
>   Think of a neat/elegant system which uses a feedback loop to
> establish a desired state.
> 
>   Extend the same feedback loop to also remove the desired state once
> established.  
> 
>   Repeat repeatedly with new feedback loops which affect the same
> tokens modified by the first two clauses.

Yup. One example of how I apply this system of logic: A population of
Kobolds in the hills by a town grows, hampered by natural predators
(virtually anything that can stomach them, which isn't really much at the
end of the day - but many NPCs and PCs will attack on sight). If their
population passes a certain amount, there is a mounting probability they
will send a scouting party to a nearby town. If it passes another higher
amount, they will send a small party to attack its borders, and if it
passes a third, even higher amount, they will send a war party to attack
it. This of course reduces their population and returns us to the
beginning. There is a capacity for the population to permanently increase,
but this is fairly unlikely given players hunting them for bounties on
occasion.
 
> The result is an unstable system which builds to a state, tears it
> down, rebuilds it etc, all dynamically and without any concept of a
> reset.  Given a little elegance in the feedback design, or enough
> compeating loops, the teardowns can be to any of a large number of
> possible states, and the build-ups can equally be to any number of
> other possible states.  The only requirement is that there be multiple
> loops attempting teardown/buildup to different targets.
> 
> The Orcs were a very nice case in point.  So did the wandering
> population model I used for the "rescue the kidnapped princess quest"
> scenario here.  

Heh, Heh.
 
> >> Now, I know the arguments against it; it's expensive (man hours, 
> >> money, computation, space, etc). You can trick the player into 
> >> thinking it is there when it really isn't, far more cheaply. (And in 
> >> fact, we have used "cheats" many places where portions of the model 
> >> were deemed less important to actually simulate, but we needed the 
> >> appearance). But having a solid sim layer enables so much... and it 
> >> renders future growth possible. For one thing, the next direction 
> >> which I would like to take it is towards conquering that last barrier 
> >> of "staticness"--changing the setting based on simulated environmental 
> >> factors. Given a good model, there is no reason why roads could not be 
> >> formed by players as they walk on the grass repeatedly and kill it. 
> >> And so on.
> 
> <cheer!>
> 
> Agreed.  Build a system that runs itself, that grows, dies, changes,
> mutates, and generally has *some* form of inbuilt ecology, and you
> have just created a vast pre-functioning play yard for players to have
> fun int, and affect.

A true 'virtual world', as it were.

Regards,
	-Matt Chatterley
	http://user.itl.net/~neddy/index.html
"Speak softly and carry a big stick." -Theodore Roosevelt