[Mud-Dev] Broken currencies

Ben Sizer brsizer at kylotan.eidosnet.co.uk
Wed Apr 18 17:24:52 New Zealand Standard Time 2001

On Wednesday, April 11, 2001 11:14 AM,
Adam Martin <amsm2 at cam.ac.uk> wrote:
> From: "Ben Sizer" <brsizer at kylotan.eidosnet.co.uk>

>> But I came to the conclusion that the best way to deal with
>> currency issues in my game would be to omit currency
>> altogether. Keep everything on the barter level, and let the
>> players decide the relative worth of an item, rather than me as a
>> designer trying to second-guess what is going to have more utility,
>> and thus more value. It makes having NPC traders a little more
>> tricky, but not impossible.

> Out of interest, what did you do about NPC traders?

Well, I've certainly not got a perfect solution, but I figured this
was ok, since the real world hasn't got a perfect economy either. So,
the first thing I did was to stop worrying about getting everything
perfect, and instead looked to minimise the damage dealt by things
being 'wrong'.

In essence, what any character wants from a trade is a 'good deal'.
Rather than worry about trying to quantify how good a deal it is, I
made some loose but generally fair rules to decide whether an NPC will
make a certain trade or not.

As mentioned previously on this list, value is generally a function of
scarcity and utility. Utility can be pretty subjective, so in general
I ignore it. However, it is certainly possible to make NPCs that ask
for certain types of items, and will reject others. Scarcity is much
easier to measure. You could do it statistically, by scanning the
database and seeing how many of each item exist. (This works most
easily with template-based objects where there aren't so many
individual types. eg.  Diku Mud. With procedurally generated items,
eg. Diablo, it's probably best to check for the scarcity of the
component parts of the item rather than the individual item itself.)
Also, in a large world, especially a very persistent one, you are
likely to find that certain items are commonplace in some areas but
are rare in others. This correlates directly to real-world trade in
ancient times (think of silk traders from the Orient) and is easy to
do, providing you have some way of tracking which items are common in
which places. This could be done statistically, as above, or perhaps
hard-coded on a per-object (a 'native region' variable on object
archetypes) or per-trader (list of specific item ID numbers he or she
will accept).

So, an NPC trader will have an inventory of items that he considers
'low value', and will accept items in exchange that he considers 'high
value'. The inventory can be generated in the ways detailed above, but
generally work best if the trader has a selection of items common to
one region of the game, which are not common in the area that the
trader works. The player makes an offer of an exchange, the NPC checks
to see it's valid, and then swaps the items.

Of course, this is sometimes (often?) going to produce a trade where
the player character is left somewhat surprised at how good a trade
they got. ("Wow... The Goblin Reaver +9 for my cloak of
hail-protection!")  But, that's ok. Maybe the NPC trader would be
thinking the same thing ;) But occasionally, a trade is so good that,
if repeated, it could break the game. Therefore, I don't allow it to
be repeated. My traders don't hold lots of stock. Instead, they have
an inventory of essentially unique items, and when an item is gone,
it's gone. It can be replenished by picking random items the same way
that the original inventory was picked. You might want to bias the
choice so that items that get traded quickly are less likely to
reappear (to prevent abuse). Of course, it might make sense to bias it
the other way (items that get traded quickly have more chance of
coming back, to make the traders more useful) but it's up to you.

It also helps if you don't make equipment the be-all and end-all of
your game. That way, an imbalanced trade doesn't catapult a newbie to
dragon-slaying status or whatever. Upkeep costs and the like help
here, too.

-- Ben Sizer

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list