[MUD-Dev] Graphic MUDS/Ultima Online
root at mpc.dyn.ml.org
Wed Aug 6 07:31:40 New Zealand Standard Time 1997
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
> 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
> 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
> 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.
> >> 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.
> 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.
"Speak softly and carry a big stick." -Theodore Roosevelt
More information about the MUD-Dev