[MUD-Dev] Re: PK and my "Mobless MUD" idea
alexb at internetcds.com
Fri May 1 23:19:43 New Zealand Standard Time 1998
From: J C Lawrence <claw at under.engr.sgi.com>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Friday, May 01, 1998 2:42 PM
Subject: [MUD-Dev] Re: PK and my "Mobless MUD" idea
>On Tue, 28 Apr 1998 21:59:13 -0700
>John Bertoglio<alexb at internetcds.com> wrote:
>> From: Jay Sax <cimri1 at gte.net>:
>> Some good ideas here but doing this *right* will run you right into
>> the "UO Wall". The failure of *realistic* economic models is based
>> on two major problems:
>> (1) Players will screw it up. UO had a great system on paper. But
>> players messed it up by hoarding creatures in stables and a host of
>> other goofy things
>I have a had time with the idea that such player activities
>necessarily "screw it up". It smells to more more like insufficient
>feedbacks and dependencies. Sufficient hoarding *should* result in
>catastrophic deflation which spreads infectiously across the system.
You are correct here. "Screw up" refered to the ability of players acting
in their self interest finding holes in the system. What you described
(deflation) is what was corrected by the "stable wipe" in UO. My concern is
the (essentially) predestined failure of attempt to model a "steady state
>Of course the challenge is to create a system which tends toward
>balance and doesn't catastrophically deflate or inflate due to minor
Accomplishing this task would make one a canditate for the Nobel Prize for
Economics and Mathmatics along with a McArthur grant thrown in for good
measure. If I could write such a system I would model the behavior of
stocks and bonds and retire to a graceful life of fooling around.
>> Gotta have seasons...how else would you know what herbs to look for?
>> I got permission from a fellow with a huge database of real and
>> fantasy herbs to use it in my world. It allows you to select by
>> terrain and/or season and rarity to determine what herbs are
>Care to point us at said DB?
http://onyx.arts.kuleuven.ac.be/~ezra/gnb/www/ is the original site I
found. The home site of the author is different but is stored on my machine
at work. (Will send a quick update on Monday, May 4) Note the information
is currently in text form. When I get around to it I will import into
foxpro for use on our system. Once this is done I would be happy to share
the dbf or delimited dump with all. Using it on a live site requires
permission from the author.
>> Or you let it build itself. Or you say every town had a
>> dungeon/catacomb/sewer. Seed it and watch it grow when the town is
>> established. That is, one day the number of square meters of
>> buildings hits a certain limit and , boom, new stuff is discovered.
>*This* idea has some really neat implications, which closely parallel
>and extend some of the areas of predictive generation that have been
> Footpads: The number of game-generated footpads on a road is a
>function of the total user-traffic on that road.
Great idea. This information is already in the system logs since a coded
event is logged every time a person arrives in a location. All that would
be required is running an event every so often to check the log and take
the appropraite action.
> Cutpurses: The number of game-generated cut-purses in any gathering
>of players is a function of the size of the gathering.
Same as above. Nothing like a good NPC thief to liven things up.
>etc. Doing this on an area level with large scale generated
>constructs becomes extremely interesting. I whiffs of a wonderful old
>SF short where dieties only came into existance when a large enough
>supporting (devout or not) population existed.
God created man and them man returned the compliment.
>Hurm. One could also do this with more subtle interactions:
> The small village of Wonka lies on a tiny twisted track deep in the
>mountains. Whoops! Suddenly gold is discovered in them thar hills,
>and hordes of players wend the twisted track. Couple days later said
>twisted track is no more. Instead an 8 lane LA-style freeway fumes
>thro the mountain fastness.
Then the gold runs out and all kinds of things begin to happen...like
rumors of new strikes in distant lands made reasonable by the early
prospectors of this site who are (in game terms) "set for life".
> The city of Mushface lies at the foot of the great mountain BigRock.
>The citizens of Mushface worship the great mountain God, DoughNose.
>One day a killing horde levels the city and decapitates the entire
>population. Over the next few days the huge mountain BigRock turns
>into a flat grassy plain due to the absence of worshippers to elevate
>or, perhaps more believably:
> The small fishing village of Codsmack suddenly finds itself deluged
>with adventuring players using it as a gateway into the dangerous
>mountains beyond. Responsively the system builds roads to other
>nearby towns and villages (which react in similar if lesser fashion),
I am inclined to let players build roads. If it in their interest to do so
(charge tolls, etc.) and the tools are provided, they would be expected to
>grows the tiny mud hut village into a large gleaming stone city,
>populates it self with inns and merchant quarters, builds large
>wharves, shipping fleets and navies etc
The model I am using is based on player home bases. As more players
associate themselves with a particular area, npc and npc-build structures
will flow into an area based on vague ratios of taverns to householders.
While the concept of resource pools is somewhat limiting (UO for example),
some of this growth would be at the expense of areas which were yesterdays
news. Of course random events (and consious GM reseeding) could move the
flow back to these areas. If properly designed, a good percentage of the
new infrastructure would be player created. It would be cool for old hands
to point out the 50 x 50 meter stockade in the center of the new city that
"started it all".
>(cf the early history and
>growth of San Francisco) all in reponse the the player-thruput.
To a certain degree, creating a history is what this is all about. We are
species that is very much about story telling and the world around us seems
to limit that impulse.
>underlieing model would be that where there are playres, there are
Certainly, many of the npc's would be abstracted. But a city of a certain
size will get its Medieval Potter Barns, Gaps and McDonalds pulled from a
modular pool of available resources.
>Where there is traffic, money is spent, and
>resources are consumed. Where money is exchanged and resources
>consumed there is an opportunity for mercantile operations. Etc etc
>>> I'd like to see this implemented. Or something similar. It seems
>>> to me if one simply steps back far enough by creating all the
>>> systems to support creation, combination, fabrication,
>>> experimentation, discovery and all those neat things so many of us
>>> love to do, then let the world be defined by those systems.
>> This has been a constant theme from JC and JL.
Couldn't miss it :)
>> "Does this (feature, idea, coding, graphic, etc) advance the feeling
>> that you are living and moving through a fantasy world of heroic
>First question: Is the purpose of the game to create the sense that
>the player is living and moving through a fantasy world of heroic
The notion here is the designer should have a kind of mission statement...a
touch stone to use to test additions to the world and its system. Since I
am still welding the framework together, I haven't given a lot of thought
this phase yet. Above is a working statement, one which will not doubt
evolve. But I stand by the concept. You must test your notions of features
against whether they advance the goals of the system. (SOP for any serious
attempt at world domination, cf Pinky and the Brain)
>For me: no. Others vary.
As it should be.
>J C Lawrence Internet: claw at null.net
>(Contractor) Internet: coder at ibm.net
>---------(*) Internet: claw at under.engr.sgi.com
>...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
>MUD-Dev: Advancing an unrealised future.
MUD-Dev: Advancing an unrealised future.
More information about the MUD-Dev