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

[Sean Middleditch]

On Wed, 1969-12-31 at 23:59 +0000, neild-mud at misago.org wrote:
> On Mon, 20 Sep 2004 11:25:41 -0700
> Sean Middleditch <elanthis at awesomeplay.com> wrote:

>>> 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.

> This merely subdivides the problem.  If casting spells gives you
> caster xp, you just end up with hordes of players casting spells
> at air.

And why should casting spells into the air give you XP?  If I just
sat and explained a system that measures the work you put into
combat determining the XP gain, it should be fairly self evident
that casting spells should only gain XP when something is overcome
by doing so.

Casting a spell you have mastered already doesn't teach you anything
new.  Targeting combat spells on nothing doesn't teach you anything
new.  etc.

> At one point when I was playing Morrowind, I wanted to increase my
> lockpicking ability.  I sat in front of a door for a while,
> repeatedly casting a spell at it to lock it, and then picking the
> lock.

Well, there's two ways to look at that.  First, that's a clever
method of performing legitimate practice.  ;-) Of course, that's
game unbalancing, so...

The second way to look at it is that Morrowind shouldn't have given
you XP for picking a lock you already knew exactly how to pick.
Which is your point, of course.

>> 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.

> That sounds wonderful in theory.  In practice, it's an ideal that
> no game ever reaches.

> It also has issues in that high-danger, high-xp fights are
> generally viewed as poor risk/reward to players.

There's a careful balance.  You don't want to say that the only XP
you can gain is by near death experiences.  You just want to say
that you can't walk around taking zero-effort swings at practically
helpless monsters and somehow become better at advanced techniques.

Fighting equal or even greatly lesser skilled opponents can still
provide a good learning experience.  I have a friend I can almost
always beat in one-on-one combat.  He's getting better - he's
learning from his mistakes, and seeing how I maneuver, handle myself
and my weapon.  At the same time, I'm learning from him - he tries
new things, takes chances, occasionally comes up with new moves that
I have to think fast to react to and learn how to counter.  He's
definitely getting the better learning experience out of our
practice sessions, but I'm not coming out empty handed either.

On the other hand, I have a friend who can beat me almost every
time.  By a far greater degree than myself and the friend mentioned
above.  This friend is just far faster and far more skilled than I
am.  He actually gets lazy when he fights me, because it takes him
comparatively little effort to beat me, and I'm not learning a whole
lot either, because I simply can't perform most of the maneuvers he
can, and I just can't seem to get an edge on him.  The only thing
going for me is that I'm slowly getting faster, up to his (honestly
amazing) speed.

Just the reality of practice.

>> 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.

> What the game doesn't realize is that golems rely on high-damage,
> close-range attacks--and a pair of smart wizards can "juggle" a
> golem between them, switching the monster's aggro to the other
> player whenever it approaches one.  While the golem does resist

> half their attack spells, they can skill kill it over the course
> of about five minutes--and the bonus xp handed out for the
> "difficult" fight makes it all worth while.

Fair point.  Which I why I advocated the second solution.  This
solution assumes, just as does the raw level solution does, that the
difficulty can be guessed ahead-of-time.

>> 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.

> Players will enthusiastically game an approach such as you
> describe here.  Fights where I finish with just 10% health
> remaining give out more xp?  Time for me to make certain that I
> don't finish the fight until I've taken enough damage.  Using
> healing potions increases xp gain?  Healing potions are now
> potions-of-xp--and there will be spreadsheets detailing the exact
> cost/benefit of earning money to spend on potions to use for xp.

Fine.  Let the players put _effort_ into gaining XP.  That's the
whole point.

Yes, they'll min/max the situation.  You can't get rid of that so
long as you have a game based on numbers.

There's also a case for balance.  If any player can easily get their
hands on tons of healing potions, then obviously damage taken during
a fight counts very little towards XP gain.  It's not like I'm
advocating some hard number like "for each damage point taken,
multiply XP earned by 2."  You obviously have to balance the
formulas based on the economics, rules, and so on of your game.

It's also worth noting that taking damage _and_ using potions isn't
going to award a whole lot of XP in the above system.  After all, if
the players keep healing themselves, the fight isn't actually taking
anything away from their health resource.  Just their potion
resource.  Losing health isn't an actual hardship for a player with
a lot of potions available.

> This also opens entire new worlds of potential player frustration.
> The active, aware healer who ensures that every member of the
> party is at full health all the time is suddenly
> unwelcome--because he's reducing the bonus "in danger" xp awards.
> The player who uses good tactics to obliterate a tough monster
> with carefully planned attacks receives a smaller award than the
> random button-masher who wastes have his energy on useless spells.

> This last point is one of the dangers of "perfect" balance,
> incidentally--there's a fine line between an exploit and good
> tactics.  Aggressively closing down unintended approaches to
> overcoming game obstacles can (will) make the overall game less
> interesting.

Here you have a great point.

I'm of the mind it's not insurmountable, but I'd have to put some
time into the specifics.  Namely, though, that it isn't impossible
to measure player stupidity.  ;-) for example, if the player keeps
casting useless spells on a monster when the player _knows_ they're
useless (because they've already failed on this or similar monsters
before), then obviously it's not a problem of the monster being
difficult - it's a problem of the player (or character) being a
moron.

There's also the note that pure point/skill power isn't all players
have.  A player that is clever and ingenuous is already more
powerful than a player who isn't.  The players are just relying on
two different things for their power - one on intelligent, one on
points.

>>> 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.

> This isn't true at all.

> I'm contrasting systems with fungible advancement with ones with
> modes of advancement may not be exchanged.

> Consider a small game which contains ten distinct tasks.  Each
> task has a difficulty from 1 - 5, with an ideal difficulty (not
> too easy, not too hard) of 3.

> Eight of the tasks are well-balanced with a difficulty of 3.  One
> is too easy, and has a difficulty of 1.  One is too hard, and has
> a difficulty of 5.

> Consider a small game with fungible advancement: There are ten
> tasks.  Every time you complete a task, you get one point.  You
> need five points to win.  Under this system, a player can perform
> the easiest task five times in a row to win; the average
> difficulty of the tasks required to win is 1.  The game is too
> easy.

> Consider the same game, but with non-exchangeable advancement.
> Every time you complete a task for the first time, you get one
> point.  You need five points to win.  The average difficulty of
> the tasks required to win is 2.6.  The game is slightly too easy,
> thanks to the one unbalanced task, but still very close to the
> ideal of 3.

> Systems where advancement is composed of many unrelated components
> are far more robust than ones where all forms of advancement may
> be swapped for one another, because balance failures in a single
> component are isolated.

All quite true from a "points to win" perspective; not a whole lot
to do with learning and advancement, like I said.  Just because I've
done a task once doesn't mean I can't learn something new the second
time I've done it.  Or the 100th.

In your system, you also have a problem of content limitation.  If
you must complete different tasks to advance, you eventually run out
of content.  The content has little replay value to many types of
users that won't bother with something that grants little benefit.

In a combat situation, fighting one type of monster the 100th time
can be just as difficult and challenging as the first time.  What
matters in that case is if you improve during the challenges.  If I
eventually learn that the monster's attacks always come in low, and
keeping my shield held low greatly reduces the amount of time I get
hit, then I have improved.

A computer game, based solely on numbers, can't really _measure_
that kind of improvement.  That kind of improvement is something you
find in the players themselves in an action game.  If the game lets
you position your shield and such, you (the actual real player)
learn to hold the shield low.  The game doesn't have any numeric way
of noting this.  (Well, it _could_ note player strategy and
behaviour, but then one has to ask what the purpose of doing so
would be - the player just "leveled up" by learning how to fight
better, there's no need to reward them twice for the same learning
effort.)

>> 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.

> The real world functions with currency because, as you say, it
> looks absolutely nothing like game economies.  In particular,
> money in the real world has no value other than what people
> ascribe to it.  There is no guarantee that you can take a dollar
> bill to the local fast food restaurant and exchange it for a
> hamburger.

The assumption that I can buy that hamburger is what makes one want
to obtain the money, though, same as in a game.  And games don't
have to have a guaranteed value attached to currency, either.  I've
seen a couple games that have fluctuating prices, shop owners that
refuse to server certain characters, fluctuating currency value,
supply and demand, etc.  What I haven't seen is a game where it's
impossible for every player to walk around with 10,000,000,000
platinum coins and somewhere there's still enough money left in the
rest of the world for everyone else.

>> 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.)

> This is the kind of thing that sounds great until you try to
> implement it.  Can you give any examples of functioning games
> using this form of economic model?

Admittedly, no.

I don't think it'd be _that_ difficult to implement, but you would
need a good set of GMs/story tellers to arbitrate.  If the local
population of monster gets wiped out because they have no more
resources, something new needs to come in.

It also isn't required to actually have _all_ transfer of goods
actually occur in-game.  Items decay in most games, for example -
those can go back into the pool.  Instead of tracking individual
items, simply values can be tracked; a long sword is someone
destroyed in game (decayed, player quit, whatever) so 50 coins worth
of value are returned to the world.  etc.

If some part of the game gets an excess amount of coin (say,
merchants), assume that coin trickles away - they have to pay their
suppliers, taxes, buy food and clothing, rent, etc.  That money is
going to trickle threw the hands of a lot of NPCs that don't
actually exist in the game, and (likewise) a lot of monsters are
going to have chances to take money from those non-existent NPCs.
So long as the total amount of goods remains fixed, or at least
increases at a steady, controlled pace, the system could work.

The total amount of currency in the system _does_ increase.  For
example, new ore is mined, and the value of the ore is generally
more than the miners are paid.

>> 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.

> The game economy is much harder to balance, because goods can be
> passed from player to player.  (Unlike personal advancement via xp
> or some other system.)

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