shifting economies
Eric Pilcher
jtmiii <du...@selway.umt.edu> wrote:
>Anyone work on a mud which has switched at some point from having a
>vendor economy (NPC shopkeepers) to a player-run economy, i.e., players
>own shops, compete with one another, buy supplies, contract with the
>blacksmith, etc?
>
>What potential snags do you see in such a shift?
>
>For those of you who are familiar with these player-based economies, what
>are the 3 most important things to control/observe from an admin's point
>of view?
Well, first and foremost, you would need to implement it in such
a manner that it is fun for the players. It is unlikely that a player
will want to stand in one room for hours when they could go out and
explore. Here are some ideas which I hope a few people out there
will try:
1. Rooms and mobiles contain "raw materials" which may be harvested.
For example, after a warrior kills an animial mob, he could skin
the corpse and butcher the meat. The quality of the end result would
depend on his skills as a skinner and a butcher.
Once raw materials are obtained, the player then takes them to a shop,
or possibly another player, to have them refined. For example, the
above player takes his animal hide to a leatherworker who turns it
into a pair of boots.
2. Shops should set prices based upon supply and demand. A weaponsmith
should not be buying longswords for 200 each if he already has 50 or so.
On the other hand, if the weponsmith only has 1 longsword and there
are not a whole lot in the game, it should be very expensive.
3. In cases where shops produce items, you could combine the two.
For example, in order for the bakery to make bread, they need grain.
Grain needs to be harvested from the fields. The players could harvest
the grain, bring it to the bakery, get paid for it, the bakery makes
bread, which the players can then buy. Naturally, if players don't
bring any grain the bakers, they run short of supplies and the bread
prices go up. A surplus of grain may reduce the price of bread, but
will also reduce the payoff per bushell of grain.
--
------------------------------------------+-----------------------------
Eric L. Pilcher: ra...@PEAK.ORG | http://www.PEAK.ORG/~rasta
------------------------------------------+-----------------------------
jtmiii
Anyone work on a mud which has switched at some point from having a
vendor economy (NPC shopkeepers) to a player-run economy, i.e., players
own shops, compete with one another, buy supplies, contract with the
blacksmith, etc?
What potential snags do you see in such a shift?
For those of you who are familiar with these player-based economies, what
are the 3 most important things to control/observe from an admin's point
of view?
john
magn...@paradox.ii
Jonathan Clemens
ra...@kira.peak.org (Eric Pilcher) wrote:
>>Anyone work on a mud which has switched at some point from having a
>>vendor economy (NPC shopkeepers) to a player-run economy, i.e., players
>>own shops, compete with one another, buy supplies, contract with the
>>blacksmith, etc?
for a year, gradually shifting over from an artificial economy. Much of
that time period, I was admin (I since retired, but still code.)
>>What potential snags do you see in such a shift?
Migration! It is hard to balance an economy in real life, it's hard to
balance one on a mud. If you don't have enough goods, the players scream.
if you try to limit the money supply, they also scream. Getting it right
is an exercise in trial and error. I do not recommend that any other mud
try to convert except in a "playtest" mode. Make it absolutely clear to
players that money will be coming and going by fiat for the duration of
the testing phase.
>>For those of you who are familiar with these player-based economies,
>>what
>>are the 3 most important things to control/observe from an admin's point
>>of view?
>Well, first and foremost, you would need to implement it in such
>a manner that it is fun for the players. It is unlikely that a player
>will want to stand in one room for hours when they could go out and
>explore.
Believe it or not, we have the opposite problem sometimes. Farming and
cooking was a low-risk, tedious, high gain activity. Of course, that was
because we did spend too much time on economic issues, and not enough on
the bread and butter of muds: adventure!
>1. Rooms and mobiles contain "raw materials" which may be harvested.
>For example, after a warrior kills an animial mob, he could skin
>the corpse and butcher the meat. The quality of the end result would
>depend on his skills as a skinner and a butcher.
>
>Once raw materials are obtained, the player then takes them to a shop,
>or possibly another player, to have them refined. For example, the
>above player takes his animal hide to a leatherworker who turns it
>into a pair of boots.
One of the things to be aware of is that each economy needs outputs, as
well as inputs. If each sword or shoe lasts forever, pretty soon you have
an abundance of material goods. This not only cheapens everything (if you
have inflation/supply-and-demand) or creates too much wealth (if you
don't), but it also causes a lot of objects to be present in memory. Most
shop implementations store the objects in a "backroom" (well, most that
I've seen--I only LP) When you get 4-6 stores in each city and try and
create a whole world.... that's a lot of overhead for your economy.
What outputs should you have? Invisible NPC's who buy stuff from shops?
Equipment damage and food rot? Wipe everything every reboot? I have yet to
see a truly elegant way of doing this, because in order for PC's to become
"wealthy", they have to be able to create wealth faster than they expend
it. So what do they do with it? The answer is left as an exercise for
the reader.
>2. Shops should set prices based upon supply and demand. A weaponsmith
>should not be buying longswords for 200 each if he already has 50 or so.
>On the other hand, if the weponsmith only has 1 longsword and there
>are not a whole lot in the game, it should be very expensive.
Yes! Shops should also have varying markups, depending on the types of
items, size of inventory, etc. The standard shopkeeper object for your
PC-economy based mud has GOT to be the most key element in this whole
affair. If it's too stingy or generous, the mud economy dies of
strangulation or drowning, respectively.
>3. In cases where shops produce items, you could combine the two.
>For example, in order for the bakery to make bread, they need grain.
>Grain needs to be harvested from the fields. The players could harvest
>the grain, bring it to the bakery, get paid for it, the bakery makes
>bread, which the players can then buy. Naturally, if players don't
>bring any grain the bakers, they run short of supplies and the bread
>prices go up. A surplus of grain may reduce the price of bread, but
>will also reduce the payoff per bushell of grain.
I wouldn't recommend this approach. Since Dartmud is a skill based mud,
learning to cook on the side is a great "sideline" business, for when your
buddies aren't on to adventure with. On a level based mud, when you have
to choose to be a baker (ugh), this makes more sense.
We have skinning, butchering, tanning, leatherworking, mining, smithing,
farming, cooking, metallurgy (refining), fishing, gathering, sewing, and
woodworking as skills. A few more would be helpful, but those are the
basics.
A few more observations:
Materials costs should be balanced as well. End-to-end balancing is fine,
but what happens when one mines, another refines, and another forges
weapons? Balance each step of the process. If refining isn't profitable,
then smiths will either have to do it themselves, or underwrite others to
do it.
Plan on how you will deal with shortages. What if all your cooks boycott?
Do the other PC's have to learn to cook or starve? Your solution may
vary, but plan on how to deal with shortages in any area covered by your
economic model.
Make costs and availability vary by location. If moving between cities
isn't simply a matter of hitting your macros, (and it isn't on Dartmud;
there are monsters in the wilderness hex map) then PC's ought to be able
to turn a profit by moving goods and materials from someplace where
they're surplus, to someplace where they're needed.
I love player based economies. They offer so much more possibilities than
just killing things for money and experience. However, it is not an easy
undertaking. Balance is difficult, growing pains are real. Some players
will not like the idea, and just leave.
Jonathan Clemens
"Desla" of Dartmud
Scott Anderson
[player-based economies]
>>Well, first and foremost, you would need to implement it in such
>>a manner that it is fun for the players. It is unlikely that a player
>>will want to stand in one room for hours when they could go out and
>>explore.
>Believe it or not, we have the opposite problem sometimes. Farming and
>cooking was a low-risk, tedious, high gain activity. Of course, that was
>because we did spend too much time on economic issues, and not enough on
>the bread and butter of muds: adventure!
It doesn't bother me that there would be low-risk, tedious activity
as long as the gain was proportionate. I can go out and mug someone
and make $300 for ten minutes of my time, but this is high-risk (of
being arrested). Or I can go work at a job for $10, and take 30
hours to make as much money but not have to worry about anything
worse than getting fired.
As a player, I tend to go for the high-risk stuff myself, because,
hey - that's why we mud, to do things we wouldn't normally do. So
there's no reason this stuff can't be around, but the gain on it
should be much lower than adventure (in general).
>One of the things to be aware of is that each economy needs outputs, as
>well as inputs. If each sword or shoe lasts forever, pretty soon you have
>an abundance of material goods. This not only cheapens everything (if you
>have inflation/supply-and-demand) or creates too much wealth (if you
>don't), but it also causes a lot of objects to be present in memory. Most
>shop implementations store the objects in a "backroom" (well, most that
>I've seen--I only LP) When you get 4-6 stores in each city and try and
>create a whole world.... that's a lot of overhead for your economy.
Absolutely. Coders tend to just do create_obj() whenever they want
to pull up an object, but if you really want a closed system like
we're discussing here, you can't introduce any new elements. The
_only_ items to come into the economy have to be made from the
ground up, and then have ways to disappear as well.
>What outputs should you have? Invisible NPC's who buy stuff from shops?
>Equipment damage and food rot? Wipe everything every reboot? I have yet to
>see a truly elegant way of doing this, because in order for PC's to become
>"wealthy", they have to be able to create wealth faster than they expend
>it. So what do they do with it? The answer is left as an exercise for
>the reader.
It depends how fully you want to model the system. If you want to
be able to just create_obj() and destroy_obj() at will, you can just
have the invisible npcs you mentioned, which I prefer to think of as
the shopkeeper just throwing away stuff that doesn't sell, then
create new objects as the need arises. A slightly more difficult,
but perhaps more rewarding approach is to make a closed system where
there's only so much "stuff" in the world, divided among the
characters in some way. Thus tons of swords might mean no metal is
availible for making new metalic items, which would require melting
down the old ones. And a fixed amount of money in the world ensures
that a shopkeeper can't just buy and buy and buy, he's got to keep a
steady inventory.
>>2. Shops should set prices based upon supply and demand. A weaponsmith
>>should not be buying longswords for 200 each if he already has 50 or so.
More like there shouldn't be any shopkeeper with 50 longswords.
First of all, players shouldn't come back from forays with twenty
eight longswords in their inventory, and shopkeepers should loose
interest in buying them after about the third one.
>>On the other hand, if the weponsmith only has 1 longsword and there
>>are not a whole lot in the game, it should be very expensive.
>Yes! Shops should also have varying markups, depending on the types of
>items, size of inventory, etc. The standard shopkeeper object for your
>PC-economy based mud has GOT to be the most key element in this whole
>affair. If it's too stingy or generous, the mud economy dies of
>strangulation or drowning, respectively.
Supply and demand, if you set it up right, should take care of
everything. I remember playing Tradewars on Commodore BBS's long
before I ever logged onto my first MUD, and their supply and demand
worked great. Out-of-the-way trading posts were a bitch to get to
(wasting a lot of your precious turns), but bought and sold and
great prices. The posts near the main "roadways" were so saturated
that it was hardly worth trading at them, yet they had the advantage
of being handy. None of this was hard-coded: the formulas were
plugged in, the formulas generated at random, the players tossed in.
After a week or so the game world started to take shape out of this
pile of numbers, and it made a lot of sense, for being a game which
ran in 64k of memory.
>>For example, in order for the bakery to make bread, they need grain.
>>Grain needs to be harvested from the fields. The players could harvest
>>the grain, bring it to the bakery, get paid for it, the bakery makes
>>bread, which the players can then buy. Naturally, if players don't
>>bring any grain the bakers, they run short of supplies and the bread
>>prices go up. A surplus of grain may reduce the price of bread, but
>>will also reduce the payoff per bushell of grain.
>
>I wouldn't recommend this approach. Since Dartmud is a skill based mud,
>learning to cook on the side is a great "sideline" business, for when your
>buddies aren't on to adventure with. On a level based mud, when you have
>to choose to be a baker (ugh), this makes more sense.
Well, it's more like you'd need little NPCs running around doing all
this automatically. If the players choose to get involved, they
can, and will probably do better than their NPC counterparts because
of their ingenuity and intelligence.
>Materials costs should be balanced as well. End-to-end balancing is fine,
>but what happens when one mines, another refines, and another forges
>weapons? Balance each step of the process. If refining isn't profitable,
>then smiths will either have to do it themselves, or underwrite others to
>do it.
Again I think it's just a matter of putting a system in place and
then letting the "economy" emerge from that. Real-life economies
don't come from someone sitting down and organizing values for
money, supplies, raw materials, and so on - they just emerge. How
basic you want to get with this depends on a lot of things, but I
suppose the main constraint is getting NPCs to participate
realistically without doing a lot of pretty specific coding.
>Plan on how you will deal with shortages. What if all your cooks boycott?
Not that there is anything wrong with this, but I would assume there
would be enough cooks in the worlds (counting NPCs) that "all" the
cooks would never boycott. If someone killed off all the cooks,
they would quickly learn their lesson when they got hungry and were
forced to gnaw on a piece of raw meat.
>Do the other PC's have to learn to cook or starve? Your solution may
>vary, but plan on how to deal with shortages in any area covered by your
>economic model.
Well, you don't necessarily starve if you don't know how to cook.
Again, though, it's a question of how far you should take it -
normally we cook to make our meals more fulfilling and taste better,
but it's hard to simulate this on a MUD. (But not impossible, mind
you.)
>Make costs and availability vary by location.
Sure, but again you don't need to "code" this persay. Make some raw
materials reside near one city, and some different ones near
another. The economy will make itself when the first city runs out
of a certain material which it doesn't have much of, whereas the
city across the ocean has tons of that and not enough of some other
item. If you do this really well, it should interact with things
like geography, the weather, the time of year, and whatever else you
feel like modeling. Thus you don't have to code fruit being more
expensive in the winter: you just make fruit not grow in the winter,
and the prices will go up as it gets scarce. (Toss in a disease
like scurvy and things can get really fun.)
>If moving between cities
>isn't simply a matter of hitting your macros, (and it isn't on Dartmud;
>there are monsters in the wilderness hex map)
I think it's more a matter of moves. Arctic has a simple huge move
cost on the "road" squares that make travelling between cities for
anyone but relocate mages a rather long process, besides agg and
thief mobs. If you have a hex map as you mentioned, then you can do
this more realistically by just having a large number of squares
between you and your target city.
>then PC's ought to be able
>to turn a profit by moving goods and materials from someplace where
>they're surplus, to someplace where they're needed.
Absoultely. This actually happens whether you try to or not:
characters will tote items to places they get the most money for it,
or the shops which aren't out of money. If you take some time (like
it sounds like Dartmud does) then it can be much more than this.
>I love player based economies. They offer so much more possibilities than
>just killing things for money and experience. However, it is not an easy
>undertaking. Balance is difficult, growing pains are real. Some players
>will not like the idea, and just leave.
Their loss. When I find a mud where I can only kill I don't like
the idea and just leave. To each their own.
Chris Lawrence (Contra)
Scott Anderson (sban...@sdcc10.ucsd.edu) wrote:
: Absolutely. Coders tend to just do create_obj() whenever they want
: to pull up an object, but if you really want a closed system like
: we're discussing here, you can't introduce any new elements. The
: _only_ items to come into the economy have to be made from the
: ground up, and then have ways to disappear as well.
I've been looking into LETSystems (http://www.u-net.com/gmlets/), and
thinking about applying this to the game world, not only for money,
but for all the basic resources like magic, motion, etc. Similar
ideas have been raised before, but I don't think they've ever been
formalised to this extent.
The money side translates fairly simply and obviously, and probably
can be accepted exactly as-is.
I've been thinking along the following lines, for say magic:
--<cut>--
The sum total of "magic" in the system is __always__ zero.
There are "magic point" objects, and "null magic" objects. They are
euqal and opposite. When a magic point object meets a null magic
object they destroy each other silently after a short delay.
Magic can only be performed at locations that contain have "magic
point" objects. (cf earlier discussion of "travel points) Each magic
action "consumes" a certain quantity of magic points (ie there must be
that # of magic point objects present in the environment).
"Consuming" magic merely means that the matching magic point objects
are relocated to somewhere else in the game.
With suitable levels of expense and effort magic points can be
created. All this really means is that some number of magic points
are created, and an equal and matching number of null magics is also
created to balance the equation.
The effort required to create a magic point increases as the total
number of magic points in the game increases, possibly following with
a simple quadratic curve.
Magic points can be causitively moved about the game, so that a
sufficient number of magic points can be accumulated at a given
location to perform a specific magic action.
Magic points tend to repel other magic points. Moving magic points
into a room becomes increasingly difficult as the total number of
magic points in the room grows.
Left to their own devices, magic points and null magics slowly wander
the game, looking for their opposites so they can commit suicide. A
magic point in a room with many other magic points will leave that
room more quickly than a magic point in an otherwise empty room.
Magical items (ie items created with magical properties) are
containers which contain magic point objects. Then, as the magic
point objects slowly meet null magic objects, the magic item slowly
erodes and becomes "normal".
--<cut>---
A similar system could be done for travel points and leveling,
creation of "special" or powerful objects etc.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...