[MUD-Dev] RE: Understanding Simulation
Damion Schubert
damion at ninjaneering.com
Wed Oct 2 09:59:21 CEST 2002
[Sasha Hart]
> [Kwon Ekstrom]
>> A "simulation" is not inherently instable, rather it's quite easy
>> to sustain a closed simulation. However a MU* environment is not
>> closed. Players are quite ravenous consumers and tend to produce
>> quite a bit less than they consume. Even when given appropriate
>> tools for production.
> Players can't drive rabbits extinct if you don't give them swords,
> or if you give them swords but there are too many rabbits to kill,
> or if the rabbits reproduce more quickly than they can be
> killed... Even if the players have swords and could theoretically
> kill the rabbits, but it would just take a lot of time and not
> have much payoff (not even making you angry or getting them
> recognition), they probably wouldn't do it.
> Players are only part of the system insofar as you let them be.
> You may have trouble predicting their choices, but you also have
> trouble predicting the output of MUD-ubiquitous "die rolls" as
> well. In both cases the author decides implicitly, by what he
> writes, what effect the unpredictable bits might possibly have.
So here's my point of view: there seems to be a difficult design
tension between the control and predictability of a dynamic ecology.
If the effect of a dynamic ecology is too random, then players
cannot see evident changes of your ecology, nor affect their
outcome. If paths such as extinction are made impossible, then the
realistic world model that many MUD designers are aspiring to create
becomes fraught with unrealistic controls and restrictions. If
players cannot affect the ecology of the world around them to any
meaningful degree, then the entire system threatens to become an
overly complex way of replicating systems that could be done much
simpler, offering much more value to the imp than to the player.
--d
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list