[MUD-Dev] (fwd) Re: MUD Economies
J C Lawrence
claw at koala.kanga.nu
Mon Mar 15 00:21:18 New Zealand Daylight Time 1999
-- forwarded message --
From: mwilley at my-dejanews.com
Subject: Re: MUD Economies
Date: Fri, 05 Mar 1999 16:54:42 GMT
In article <36dfaca7.3875372 at news.uk.ibm.com>,
scatter at thevortex.com (Scatter) wrote:
> On Thu, 04 Mar 1999 17:46:54 -0500, cercocebus at mindspring.com
> (Siobhan) wrote:
> >I am interested in ideas which other admins out there have about generating
> >economies on their MU*s. On ours, we've come to something of a glass ceiling
> >in terms of having a use for gold beyond buying a selling equipment. I was
> >hoping those who have had experience with things like player-run shops,
> >player property, trade, or other things might lend us some of your wisdom.
> >We've tried reducing the amount of gold in play, but players still accumulate
> >vast sums due to sheer amount of time spent on the mud. Anyone have some
> >ideas about developing and implementing some more sophisticated economies?
[WOW! A real topic on r.g.m.admin! Who wudda thunkit?]
> The usual model is the 'faucet-drain' where there is a method by which
> value trickles into the world and a method by which it trickles out
> again. Ideally you need to make it trickle out at the same rate it
> trickles in. You have the faucet without the drain - value trickles in
> in the form of equipment loaded into npcs, and is converted into gold
> through selling. There is no drain.
> What is needed is a way to pull that value out of the world again,
> something to make players convert that gold into something
> insubstantial - either buying something temporary that can disappear
> and needs to be bought again, or things like services which are
The 'faucet-drain' model of mud economies is a common topic on the MUD-Dev
list at kanga.nu, which is a source I'd highly recommend if you're interested
in breaking new ground.
I'm trying something different with an economic system on my new project,
that I hope will clear up some of the underlying problems with typical mud
economies. I think the most basic problem is that we're looking at economics
in a sideways manner in most muds: "value" is a fixed attribute of an object,
expressed in a single form of currency. Our current system at least
addresses the second type: we have different currencies for each of our
cosms, and a currency tracking system that adjusts their exchange rates based
on supply and demand. What I intend to do is to use a similar system to
encompass the whole economy, tracking supply and demand for a large range of
objects and adjusting their value accordingly. I hope that this will level
out the bumps in the faucet-drain system.
My "faucet-drain" model, then, has three parts: the faucet, the drains, and
the tracker (which I've called the Resource Handlers, or RHs). The faucet is
easy to identify - any time an in-game object is cloned. It's the
responsibility of any in-game object to notify the local RH that it has been
created, and passing certain data to the RH: the materials it is made of, and
the mass of each material used.
The drains are any method which remove an in-game object from the game world.
Again, they're not difficult to identify - any time an in-game object is
cleaned up. The drain notifies the local RH of the materials reclaimed by
that drain, if any. For instance, a shop can attempt to "recycle" an item,
trading it back to the RH for it's value in raw materials (probably to clear
shelf space for a more valuable item). The material reclaimed from that is
dependant on the skill of the recycler (i.e. the local blacksmith for a
sword), the axioms of the RH (a higher tech level can recycle more kinds of
materials than a lower one), and a few other factors. Alternately, an
"off-screen cleanup" (removing an object from memory not because it's been
destroyed, but because it's not been touched in too long) credits the RH with
the complete value of it's materials - it's not gone, it's just "off-screen".
That allows the object to be restored in it's last location without making
odd workarounds for the RH.
The RHs are a collection of local economic trackers. They use an abstract
system to track the supply and demand of resources: Instead of trying to
track the total amount of stuff in the world, they define 0 as a balance
between supply and demand, and try to keep the resource totals at 0. A
negative resource means that demand is greater than supply, making values
higher. A positive sum means supply is greater than demand, lowering
resource values. An RH uses it's calculated resource values to "buy" and
"sell" raw materials from the world. (They make a slight profit on each
transaction, preventing players from manipulating the RH into producing
infinite wealth.) When a resource is negative, the RH notifies a class of
AGENT NPCs of it's demand, and they can attempt to obtain that resource from
the environment to sell to the RH. There are a number of types of AGENTs that
I've worked on, from miners to farmers to shepherds to craftsmen. I'm
currently trying to work out systems where players can be agents (that aren't
painfully boring, ridiculously easy or ludicrously profitable).
Similar tracking functions in the RH can be used to track population growth,
which I'm planning to use to allow populations to expand and contract. I'd
been planning to use something simple to figure population growth rates (a
direct correlation to food supply, similar to Civilization), but my wife has
been talking to me about simulations she did in college for bacterial growth.
It sounds interesting.
(There was also a problem I cleared up earlier, where NPCs who have never
been created before have to pay for resources they use during creation with
money they haven't earned yet. Their starting resources and cash have to be
taken as a loss by the RH, representing whatever number of years they were
supported by the society before becoming adults (cheezy, but effective). The
RH draws a low-interest loan from the Bank when it needs cash, and repays
that loan with it's profits from resource sales. The Bank is the object that
determines currency exchange rates - this has been accomplished in the past
by expressing object values in Generic Currency Units (GCU), and tracking
each currency's value in GCU. With multiple currencies associated with
multiple RHs, we can factor in values of the RHs to currency values as well,
like their cash and resource supplies/deficits.)
[Blatant plug: We're still looking for development help for the DS2 project.
If the above sounds like the kind of thing you'd like to help develop and
code, contact me!]
Visit us at Dreamshadow today! - dreamer.telmaron.com 3333
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev