[MUD-Dev] DGN: MMOG Game Economies

Christopher D. Chapman chris at chapmanholdings.com
Wed Nov 2 21:16:13 CET 2005


On 11/1/05, Jaycen Rigger <jaycen.rigger at sbcglobal.net> wrote:

> My proposal for a money sink includes a sliding scale and is based
> on cities or other "groupings" of players.  Taxation of players
> for city services and property ownership can grow automatically as
> the tax base grows, or even as the size of the tax pool grows
> (accumulated revenue assumes that the wealth of the tax base can
> afford the higher rate, if the accumulated revenue drops, the rate
> auto-adjusts back down).

i don't believe controlling inflation through taxation would
work. even if you built the sliding exponential scale, some folks
would have 90% of their income taxed for it to work.  that's just no
fun.  they need voluntary reasons to spend their money.  otherwise,
say, your tax scale sat in the tolerable 15%-50% range or so.  you'd
have a sliding scale, but not an exponetial sliding scale.

you start taxing folks exponetially and you'll have a revolt on your
hands.  you have a linear scale and it doesn't solve the problem.

tax systems are set up to collect money for 'the greater good,' not
to deplete the wealth of the population or keep inflation in check.

> No, because you are more wealthy, you are required to pay more
> taxes.  Look at it any way you like - you consume more because you
> can afford a larger family, more livestock, more servants, etc.
> Ultimately, taxation increases simply because it can.  Look at any
> point and any governmental system in our history.

agreed.  i wasn't talking about standard taxes.  i was referring to
the fact that the same good or service cost more depending on who
made the purchase as an 'arbitrary tax.'  something along the lines
of when you buy that next snickers bar, it costs you $6 and the guy
in line ahead of you $0.60.  again -- revolt causing.

> Arbitrary taxes would suck.

yep, yep.

> That's why the system I propose pays the players back with skill
> and stat bumps or with services not normally available to them in
> the game.  By rewarding gold with a "service", you don't inflate
> the junk-pool in the game and create another source for creating
> gold.

again.  yep.  great thoughts.

> I'm a fan of item decay.  I'm also not much of a fan of "repairing
> items".  I say allow 80% of an items total HP to be repaired each
> attempt thus forcing the item to decay no matter what happens.

me too.  from a design perspective.  however, as a player, i don't
find it that much fun.

> Paying for training doesn't keep the economy in check.  It creates
> situations where players become gods in days instead of weeks or
> months.  It engenders phrases like "the grind".  I remember when
> "grinding" really meant "playing the game and gaining the
> experience you've actually earned".

> There exist an arsenal of excuses for not "playing the game and
> gaining the experience you've actually earned", but I'm sure
> others will be glad to detail those out for me.

i just think this one was me not explaining it very well.  i'll have
to revisit that.

you aren't just buying skills.  you'd have to earn them first.  so,
earning xp would essentially open up slots you could purchase.  so,
for example, if you wanted to take a skill from 10 to 11, it might
take 1100xp AND 1100gp.  not just the money.  gold (or copper or
silver or dinars) is the currency and earning xp acts as increasing
the supply for you to purchase.

if you haven't earned any xp, there's nothing to spend your money
on. you could, in essence, have a wimpy little character with an
enormous stockpile of cash.  or, a big, gnarly uber-powerful
character who's broke.  in theory there should be an equilibrium
somewhere in there.

i think that's where the price index formula william was talking
about would help tremendously to balance exactly how much a single
point of xp is worth in cold hard cash.

chris.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list