[MUD-Dev] DESIGN: Active and Inactive currency

Rayzam rayzam at travellingbard.com
Tue Apr 20 20:53:13 CEST 2004


From: "Freeman, Jeff" <jfreeman at soe.sony.com>

> This is not an essay, so accept apologies ahead of time.  This is
> more of a stream-of-consciousness sort of thing.  Just gonna type
> in what's on my mind and click send.  And I promise not to quote
> any domestic terrorists this time.  Ready?  Here I go!

No probs. Streaming back at ya :)

<SNIP>

> For example, a friend of mine has made over 100 million credits
> (more than half of that was made during a period of time where
> more money is leaving the system than entering it overall).

<SNIP>

> Could the number of transactions be more significant than the
> total amount of those transactions?

> Now, where I'm stuck here is with the idea of developing a
> 'healthy ratio' of available money to active money.  i.e. in the
> real world there's a 1:1 ration, all the money which is available
> is actively being used (or nearly all of it - people do hoard
> coins, I guess).  In the game world the ratio is much, much lower,
> particularly when0 we consider money attached to inactive accounts
> to still be "in the system".  For that matter, forget 'banks',
> because just carrying around the money on-hand doesn't make it
> active...

> So, the problem I see is determining what impact active/inactive
> money has on a) the individual and b) everyone else.  My 100
> million credit friend has a huge bank balance, her account is
> active, but most of that money is not active.  She trades in about
> 25 million credits per week (with an average of +10 million to her
> favor).  So right now there's maybe 90 million 'inactive' credits
> there, and next week there'll be 100 million inactive credits.
> Her balance may drop to 90 million some time this month, but it'll
> be back up to about 140 million by the end of the month... And
> next month instead of 90 million inactive credits, there'll be 130
> million.  She's unlikely to gift her balance to another player
> when she quits the game, but even if she did, it would be inactive
> money moving from her to them, and the bulk of it would likely
> remain inactive.

I'm going to start with some assumptions here, please correct me if
I'm wrong. Though if I'm wrong, insert a 'hypothetical friend' in
here instead.  I think the points/questions are general.

I presume that the 100M credit friend has gained those credits by
providing goods or services. I assume that those goods or services
were produced by the individual. In a player-driven economy, that's
a faucet to me. The items created have value as do the services
[example: slicing a weapon in SWG makes it a better weapon,
increasing it's 'value'].

Thus, inactive money is a measure of an unbalanced faucet. In an NPC
driven economy, where gold and items appear on the spawns, and where
manufactured goods are sold to NPC merchants, the value can be and
often is tracked. But in essence, the gold paid by NPC merchants for
manufactured goods is really just a measure of the manufacturing
faucet. That faucet can be controlled by adjusting the prices paid
by the NPC merchants.

When items are player-created and sold to other players, in a
player-driven economy, there's no easy measure of what those items
are worth, of what the value of that faucet is. Yet they are created
and added to the economy. So how is that tracked?

One measure of manufacturing faucets is the amount of inactive
money.  Inactive money can be gained from multiple faucets, in fact
from all of them. But the proportion of inactive money is related to
the manufacturing in the player-driven economy.

So I view that example as a case of inflation. There's a problem in
that economy. Thus, removing inactive money from economy equations
would mask or ignore the problem. Inactive money isn't a drain, it's
a sign of an open faucet.

rayzam
www.travellingbard.com
_______________________________________________
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