[MUD-Dev] Removing the almighty experience point...

Sean Middleditch elanthis at awesomeplay.com
Mon Sep 20 18:03:50 CEST 2004


On Wed, 1969-12-31 at 23:59 +0000, neild-mud at misago.org wrote:
> On Fri, 17 Sep 2004 11:03:41 -0700
> brian at thyer.net wrote:

>> How is this really different than an experience system?  You go
>> out, you kill a bunch of things, you accomplish something
>> (becasue killing 150,000 goblins for your next level *is* an
>> accomplishment) and you get your level.

> If you look at it that way, there is no difference.  "Achieve ten
> tasks to reach level 10" is the same as "each task gives 1
> experience point, get ten experience points to advance".

> Experience points, however, are almost always directly tied to
> killing monsters: Kill an orc, get 5 points.  Different games have
> tweaked the formula, but I can't think of any major ones that have
> abandoned it entirely.  (DAoC has it's "camp bonus" to discourage
> sitting in one spot; WoW offers very large quest xp rewards to
> make questing a viable alternative to grinding; pretty much
> everyone stops awarding experience for killing low-level mobs.)

> The problem with this, as Vincent said, is that experience points
> are fungible.  There's no difference between xp earned for
> whacking rats, saving the princess, or killing the troll king--it
> all goes in the same pot.  It's this form of fungible achievement
> that is the problem.

Domain XP solves the problem nicely while keeping the simplicity of
an XP based system.  Each task has a certain domain attached to it,
and different skills/classes also have domains attached.  Killing
things with a sword gives you Warrior XP.  Casting spells gives you
Caster XP.  Picking locks and disarming traps gives you Rogue XP.
If all you do is go around bashing monsters, all you can get better
at are the skills related to bashing monsters.

> The result is inevitable: Players will find the single most
> efficient means of generating xp per hour, and grind on it.  They
> will make tourist excursions to look at other content, but return
> to the efficient grind when they want to progress.

> This is hell on game balance.

> A bug which makes one monster species trivial to kill rapidly can
> throw off the balance of the entire game, as players level up far
> faster than intended.  In a system where methods of advancement
> are not fungible, this would unbalance only the parts of the game
> which apply to that species.

Assuming that bugs get fixed and such a bug wouldn't last long, I'll
assume you mean some more of a design problem.  Simply, if you're
going to give XP for killing monsters, the XP given should be based
on the difficulty of the fight.

Using just some pre-written "level" field for the monster is not
going to work.  A monster might be a very difficult fight for a
level 10 wizard but a very easy fight for a level 10 warrior.  The
difficult should instead be determined by either a) the individual
attributes, or b) measurements taken during the actual battle.

In the first case, you'd just compare things like defense, attack,
health, magic abilities, magic resistance, equipment, etc.  If the
player has weak attack, weak defense, and high magic (a wizard), and
the monster has high attack, weak defense, and strong resistance (a
golem or something else made for killing wizards), the system will
see that the wizard is at a severe disadvantage.

In the second case, you'd just measure what happens.  How many
resources did the wizard lose?  (prepared spells, mana points,
health points, item uses/charges, etc.)  How many resources did the
monster lose?  How many successful attacks did each make?  How
damaging on average was each participant's attacks?  If the wizard
used up a crap load of healing potions, almost none of his spells
worked, and his physical attacks rarely hit and even more rarely did
noteworthy damage, and the golem just sat there and beat the piss
out of the wizard, you can bet the fight was a hard one.  This
system isn't easy to cheat at, either.  In a system based only on
_some_ combat measures (like damage dealt, damage received) you can
easily farm monsters.  Get them to beat on you while a healer keeps
you up, for example.  In this system, that won't do much - you
aren't losing any resources.  Sure, you keep losing health, but you
also keep gaining it during the battle "for free."  The healer isn't
getting anywhere either, since they're casting a spell that's very
easy and familiar to them; there is no difficulty or danger in the
casting, just some resource loss, and even then not a whole lot (in
most games; in games where magic is harder to use or rarer, you're
no likely to have a healer able to just sit there and heal you
repeatedly anyhow).  The system knows precisely how hard the battle
was, how hard the task was, because it isn't guessing, it's
measuring.

> Experience point systems are fragile.

Any system relying solely on numerics and raw computational logic is
fragile when dealing with something as natural as learning and
improvement.  Even if you had a GM dedicated to each player to watch
them and assign improvements, you'd still end up with mistakes being
made, the GM misjudging difficulty, etc.

One of the best things you can do is record what is going on in the
game, and monitor for problem spots.  Character foo has managed to
gain 10 levels in a day.  Which areas did Foo visit?  Which monsters
did Foo kill?  Which players did Foo party up with?  Which items did
Foo get a hold of, and from where?  If the logs show that Foo got a
sword +1,000 from a much higher level character Bar, and that Foo
spent most of the day fighting cave trolls.  Now the developers can
see where the problems lie and, at the very least, be able to start
working on fixes.  (Maybe a bug makes the measurements wrong for
cave trolls, and another bug is incorrectly measuring the difficulty
a player with a +1,000 sword has.  Perhaps you'll be able to update
the algorithms for determining difficult from the measurements to be
more accurate after you test the scenario you know gives bad
results.)

>> So is it grinding?  Certainly, but it's *mission* grinding.
>> Which I think is what you're describing as well.  The focus goes
>> to the missions on your plate and you become more interested in
>> working your way through them than you do working through the
>> level you're in.

> Grinding isn't the key problem of experience points, though.
> Fragility is.  To use your example of City of Heroes: Players have
> discovered that a character with good defenses and area-of-effect
> attacks can run around a zone, provoke vast numbers of mobs to
> attack them at once, and then kill them all simultaneously.
> People who do this have a ridiculously fast rate of advancement,
> of course.

> In a system which didn't hand out xp for every monster killed, an
> issue like this would still be a balance flaw--but it wouldn't be
> one that utterly destroys the balance between different
> archetypes.

Assuming, again, that the XP awarded is based on _actual_
difficulty, the game wouldn't award much XP at all for this act, if
any.  Agian, though, the system has to base things on _actual_
difficulty, not estimated difficulty.

> The exact same thing goes for the game economy, substituting
> gold/credits/etc. for experience points.  Since gold is infinitely
> fungible, a single means of making gold rapidly can destroy the
> entire economy.

> A Tale in the Desert has an interesting solution to this: There is
> no game currency.  If someone finds a more efficient way of
> producing a resource such as iron, the price of iron drops--but
> the economy as a whole remains stable, since there is no means to
> directly convert iron into any other resource.

The Real World(tm) functions fine with currency.  The problem with
game economics tends to be a lack of realism in the economics.  For
example, there is an infinite number of coins in the game.  As time
passes, more coins come into being.  In the real world, there is a
fixed amount of coinage.  Even when the government mints new coins
or prints more bills, it's usually at a rate fairly near the
estimated loss/destruction of existing currency.

In a game, the solution is to provide a fixed amount of coinage and
goods.  For example, say you have some monsters (orcs) that normally
have coins and equipment.  Well, simply, give the orcs a pool of
coins and equipment.  When spawing an orc, remove the coins and eqp
from the pool.  To replenish the pool, the orcs will have to
actually get more coin and eqp.  This can be done by having the orcs
raid NPC merchants, loot PCs (that can make for a *LOT* of fun RP, I
might note - having to go to the orc caves to seek out the orc that
took your sword, Bone Grinder.)

One problem is when you have a high player density in a game area.
Players in most games tend to be adventurous types.  That's what's
fun.  But, in a real world (with real economics), adventurers are
_not_ all that common.  The player density needs to be kept high
enough to provide social-type fun to the players, but low enough
that the area isn't saturated with players that subsequently require
a high amount of coins and goods for them to "win" through
adventure.  Making your game world large and varied enough, and
keeping the players-per-server count low enough, can help.  If you
have more than a handful of groups of players exploring a single
specific area, and there isn't some good special reason (the king
has put a bounty on some monster's head, for example), you are
probably getting too high of a player density for the area.  The
available (limited) resources will be exhausted too quickly with
little to no chance of them being replenished.

Getting a good economics system is, I believe, a lot harder than
managing the XP "problem."  It requires not only good code for
tracking the system, but also requires a lot of effort on the part
of the designers and the server administrators.

--
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.
_______________________________________________
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