[MUD-Dev] Reality check ...

Jon Leonard jleonard at slimy.com
Fri Apr 19 23:02:53 CEST 2002


On Thu, Apr 18, 2002 at 09:40:58AM +0200, Vincent Archer wrote:
> According to Marc Bowden:

>> And your bank account? That's "just data"....linked to
>> real-world, physically affective assets. If you close your
>> account, I owe you the money the data represents.

[snipped description of fiat currency as unbacked, etc.]

> As for the money itself in the bank, one of the thing the Fed
> regulates is the amount of "virtual money" a bank can create. Bank
> routinely give away (in the form of loans) multiples of the assets
> they have received.  In terms everybody recognise, they "spawn"
> gold. All the time.

The process is more bizzare and complicated than that, and the
system probably works better with most people now knowing or
worrying about it.

Money itself is a quite complicated idea, which contributes rather
directly to the economic problems game designer run into.

The most fundamentally difficult is that players have a thoroughly
modern understanding of money, and the game worlds we're designing
frequently don't match.  Either we're building a fantasy or
pseudo-feudal world, or a world under enough stress that open
warfare is common.  In either case, the underlying assumptions the
players make about how things 'should' work don't match the
fictional world.  So there is a continual risk of players either
introducing some monetary idea (fiat guild credits, for example)
that is fiction breaking, or else being upset when the game economy
does not behave as they expect.

There's also the risk of rediscovering Gresham's Law (Bad money
drives out the good) the hard way.  For a historical example, at one
point the US legislated a ratio of 15:1 for the value of gold to
silver, by specifying the mass of gold coins and silver coins.  The
problem was that the free market value was closer to 15.5 to 1, so
people spent the silver and hoarded the gold, keeping it out of
circulation.  Later this was 'corrected' to 16:1, yielding the
reverse problem: Hoarding silver and spending gold, again
diminishing the money supply.  If a design needs to have more than
one potential currency, then the exchange rate more or less needs to
be free to float (or else be a subtext to market manipulations that
aren't viable for precious metals).

On the flip side, if there's some some economic activity that the
NPCs in the game are engaging in, the players may not understand it.
I can't think of a good way to work something like a Kula chain into
a game (a social activity in which islanders trade two kinds of
ornamental goods around a ring of islands.  It looks like gainful
economic activity, except that the trades don't affect anything
else, and goods don't enter of leave the loop...), but it could be
interesting to try.  I have no idea how to make it appeal to
players, though.  Maybe have NPCs track players they have interacted
with in the past, and have it be a mechanism to get more 'useful'
interactions on other trading.

In case it's relevant, the actual steps of US money creation are:

  - US government borrows money from someone, yielding a Treasury

This treasury is normally paid off at some later date, but in this
case:

  - The federal reserve buys the Treasury (Open Market Operations),
  paying in 'Reserves'.

  - The reserves get deposited at a bank, which pays for them in
  dollars.

  - The bank can then have more outstanding deposits, as the
  regulatory limit is that the reserves be at least a certain
  fraction of the of the total deposits in the bank.

  - The bank then loans people money, by creating both new debt to
  the bank, and matching new value in the borrowers' bank accounts.

Much more complicated than Yap Stones (large, essentially immobile
currency where the islanders track who owns the stones), for
example.  And in both cases the money isn't backed by anything
except the willingness of others to accept them in trade.

Jon Leonard
_______________________________________________
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