[MUD-Dev] Persistent Worlds
John Buehler
johnbue at msn.com
Sat Feb 17 20:04:05 CET 2001
J C Lawrence writes:
> > I'd rather fight the good fight there than accept that spontaneous
> > generation is the way to go.
>
> I think you're targetting a symptom (spontaneous generation) rather
> than a cause. Spontaneous generation is just a short circuited form
> of world instantiation, and environment shorthand if you wish that
> the players and the designers both tacitly understand. It generally
> works under the assumption that "how the NPC got here" is much less
> interesting than the fact that he is here.
It all depends on the focus of the experience that you're offering. I like
the idea of having just a few systems that are very much in depth and
inherently entertaining. Along those lines, if I were to have a wilderness
with animals, I'd prefer to permit players to witness the full lifecycle of
animals, along with some interesting behaviors between being born and dying.
That gives wildlife enthusiasts (e.g. 'rangers') some depth to play with and
it eliminates a distracting sticking point. This is not unlike having my
weapon vanish from my hand while in combat for no apparent reason. The
causes of significant effects should be retained, generally be made
realistic, and ultimately presented to the player.
The value of having an actual 'spawn' process for *monsters* isn't
interesting for lifecycle reasons, unless you're interested in having
players playing social anthropologists or some such thing. But the actual
spawn process would somewhat suggest that the new monsters have to originate
from some spawn location and then move out from there. That would imply
that if a monster is killed, then if I know where the spawn location is, I
can slowly work my way towards it and ultimately destroy it, ending the
monster problem. Or I can fortify choke points between my territory and the
spawn location, etc.
> Raph in
> particular observed the general rule of (paraphrased):
>
> If I can spend time at it I must be rewarded for it.
>
> Players often don't like the fact that they can spend all day
> knitting or fishing and then not be able to sell their wares for a
> profit (why did you implement it if it isn't rewarding?), and,
> rather than this persuading them to establish markets etc. it tends
> to persuade them to find another game to play run by people who did
> make "everything rewarding".
As with many things about these games, I believe that these situations would
be dramatically improved by setting player expectations. The earlier the
better. The experience that the game provides needs to be communicated
early and often. If player expectations are that when they fish they will
get gold, they need to be retrained. The ability to set player expectations
can be a bit of a challenge when the game experience is controlled by
players or volunteer workers. Another reason that I dislike relying on
synergy between players and game publisher.
As for being rewarded, the reward is enjoying the experience of the game.
If the game experience of fishing is not enjoyable to people who enjoy
fishing (or would, if they had the money and time for it in the real world),
then it's probably not a very well-implemented fishing experience.
> The insensate requirement for immediate and
> reliable gratification in entertainment is a powerful thing, and one
> well established by our current marketing economy. The only
> effective approach I've seen is to aggressively discard those
> sectors of the population from your audience -- but it tends toward
> baby-with-the-bathwater.
But it only tends towards it. If you had the choice of having few friends
who were real versus many 'friends' who would leave you as soon as you lost
your money, your looks, your access to perks, whatever, which would you
take? I'd rather have park guests that are a joy to entertain than take
money from a bunch of folks who were after gratification in all things and
in all ways. They're almost impossible to make happy.
JB
_______________________________________________
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