Welcome to Raph Koster's personal website: MMOs, gaming, writing, art, music, books.
Game talk

Use-based systems

July 18th, 2006

Recently, there’s been some chatter on the [ultima] Yahoogroup about macroing. Lots of talk about how the fixes for detecting macroing software are coming years too late. But we waged a silent war against macroing from very early on — not because of the gold farmers, as that was much less of a concern back then, but because of the basic mechanics of a use-based system.

These days, use-based systems are most familiar to everyone because of Oblivion, probably. And sure enough, there’s plenty of tales of how amusing it is that the use-based system there encourages strange behaviors that do not fit the expected behavior in the game: people jumping everywhere in order to improve the stats and skills related to dodging, that sort of thing.

The basic definition of a use-based skill system is one where you have a chance of improvement every time you use the skill. So everyone has access to every skill from the beginning (or, in a variant, access may be unlocked by other means, such as being taught), and as you exercise the skill, your chance of success goes up.

The attraction is that it leads to a more freeform game experience. Instead of tracking arbitrary “experience points” that can be applied to anything, leading to oddities like getting better at crafting because you have slain a lot of orcs, you can get better at crafting by, well, crafting. The downside, of course, is that it lets you sit there and do something repetitively in order to get better at it.

In the real world, this is called “practice,” and we don’t regard it as a bad thing. We force kids to sit and do scales on their piano or violin; we tell them to do a billion math problems; and we send them to sports camp so they can keep honing skills. “Practice” isn’t a dirty word at all, and generations have bemoaned the repetitive nature of it. However, the logic seems to be that in game, repetitive action like that has no place.

Elements required for fun:
(from A Grammar of Gameplay)

Do you have to prepare for the challenge?
…where prep includes prior moves?
…and you can prep in multiple ways?

Does the topology of the space matter?
…does the topology change?

Is there a core verb for the challenge?
…can it be modified by content?

Can you use different abilities on it?
…will you have to to succeed?

Is there skill to using the ability?
…or is this a basic UI action?

Are there multiple success states?
…with no bottomfeeding?
…and a cost to failure?

That’s balderdash. The issue isn’t the repetitiveness. Many games allow repetitiveness within their framework even if they don’t require it. You can practice headshots in an FPS, or jumps in a platform game. In fact, you pretty much have to. So it’s not practicing that is the issue — it’s that, in classic “theory of fun” style, practice that isn’t challenging your skills and helping you learn is boring. In the headshot example, you probably start out not able to hit headshots reliably — as you practice, you take on tougher and tougher shots, and keep challenging yourself. In the musical instrument example, new pieces and new techniques open up, much like new levels in a game. (There’s a reason we say you “play” a piece of music!)

But in use-based systems, at least how they are structured today, this isn’t the case. There’s no challenge in jumping off a hill in Oblivion, and therefore, the grind rears its ugly head.

Now, the biggest barrier here isn’t mechanical, it’s psychological. Players are bottomfeeding the system (fun checklist item again!). There’s no cost to failure. The topolgy of the space is irrelevant. There are no differing abilities. No skill required. All of these can be avoided if players simply quit doing unfun stuff. But that particular psychological barrier isn’t one that is going to fall; humans seek advantage, and just because it may be more challenging to forage for one’s own food in the winter, it’s smarter to instead hit the grocery store even though it’s distinctly less challenging.

So the systems must adapt to the psychology. Some players will “play it straight,” but even many of those will succumb to temptation once they see other players gaining advantage over them by using the bottomfeeding method.

UO used a straight-up use-based system. Each time you used a skill, it had a chance of going up. In fact, originally, it had a chance of going up if you observed someone else using it. There was no difficulty rating on the task, so there was no way to say “you won’t learn from this because it’s beneath your skill threshold. What’s more, skills that you didn’t use originally decayed away. A player was allowed only 700 skill points total — when you hit that threshold, and gained a point, a point was automatically lost from somewhere else — not even the least used skill, as I recall, but any of them, on the grounds that ify ou used something occasionally, it’d counteract a bit of the loss.

The first big problem that we ran into with use-based systems was that every skill was used at a different rate. Swords were swung quickly. Talking to the dead was done rarely. If every skill had the same chance of advancing and the same amount by which it advanced, then swords would be mastered incredibly quickly, and skills that could not physically be performed as often because of the lack of opportunity would advance more slowly.

The solution to this was to dynamically track the frequency of use of all skills. That way we could look at swords, see that skill checks for it happened ten times more often than our baseline, and that spirit speak usage happened ten times less than our baseline. We could then make the chance of swords advancing when used to be 1/10th the chance of the baseline, and the chance of spirit speak advancing to be ten times the baseline. If skills became more popular (lets say, a whole bunch of spirit speakers started to play the game) then spirit speak would be checked more frequently, and then it would move closer to the baseline chance of advancing. It would be a self-balancing mechanism for when payers rushed to skills because they were “easier to advance.”

It didn’t work. For one, I don’t think there was a baseline in place; instead, everything started getting slower and slower to advance. As things got slower, players responded by macroing the skills, chasing after the one time in a thousand that they would go up. This meant that now the chance became one in ten thousand. The thing players had an infinite amount of was time — it didn’t matter to them whether they macroed for an hour or overnight. What broke was the feedback mechanism — the reward of advancement came so incredibly infrequently that playing “the right way” no longer had any incentives.

A few thing could have fixed this, in theory. Only advancing for taking on actual challenges, rather than doing something you already know how to do, such as swinging at a practice dummy. Soon people started trapping powerful monsters in their houses to macro on instead. Ooops. Next solution?

One such solution was 8×8. I’ve mentioned before how UO internally divided up the map into “chunks” of 64 tiles, 8×8 square, and stored the invisible resources on a “chunk egg,” an invisible object that represented the amount of wood, grass, and os on to be found there. This also meant that the chunk egg was a unique object with an id.

A feature of how random numbers work on computers is that they aren’t actually random. They are seeded by a value. If you give a random number generator a given seed number, say 1234, then it will always spit out the same result. With a use-based system, we were rolling dice to see when people were going to advance. The inputs were things like what skill they were using, what skill level they were currently at, and a random seed.

I had already moved off the team by this point, but Sunsword came to ask me for advice. I suggested that instead of seeding the random number generator with the system clock (so that it would always spit out different numbers) we instead should seed it with the id of the chunk egg. This meant that you’d get a predictable result for a given person, skill, and skill level. If a guy who was standing at a forge started forging, and failed, he’d be guaranteed to fail there until the heat death of the universe. The only way to get it to succeed would be to change the random seed number. This could be accomplished by putting different inputs into the seed: a different skill level (by, say, going elsewhere and managing to advance) or a different location (by just going elsewhere).

The intent was to get people to move about — two or three moves would carry you a whole screen away from where you were previously.

Players still managed to figure out, via pure scientific experimentation, as far I know, that if they regularly moved 8 tiles away, they would have an improved chance of advancemrnt. And thus was born the phenomenon called “8×8 macroing,” which involved moving 8 tiles via an automated macro, after a given failed attempt. I regard the player discovery of this as a great example of one of the Laws:

No matter what you do, players will decode every formula, statistic, and algorithm in your world via experimentation.

Runesabre never liked the skill table, and once UO was under his domain, he removed it in favor of a hand-coded table. A hand-coded advancement rate table will always need to be updated as players discover exploits that drive them towards one skill or another, so I strongly recommend that anyone dealing with a use-based system maintain metrics of rate of use anyway; whether they then manually copy those values into their advancement table, or do it automatically is to my mind largely irrelevant. The challenge is fixing the feedback loop.

Once the table was removed, a series of increasingly outré systems such as “guaranteed gain” and “power hour” started becoming required, as rates were adjusted to try to bring some semblance of balance to things. I was gone by then, so I don’t know what the logic behind those were.

How to make use-based systems work? Well, one way is to move to “results-based” logic. This is the philosophy that it isn’t using the system that should grant you advancement, but instead, getting a concrete result. This is what leads to experience points; in SWG, we said that you could have results classified by what sort of result, thus giving us multiple types of experience.

The sorts of results we wanted, however, weren’t solely the act of building something (because that could still be done in a closed room making crap nobody wants) but instead results that were somehow socially valid. From this wan born the notion of crafting XP being granted when someone else actually used something you crafted: a validation that what you made actually worth something to someone. Alas, this system was marginalized in favor of themore direct feedback of getting XP when you made something; to really work, it would have needed to account for all of the XP, or else bottomfeeding would once again ensue (as it did).

In the long run, we ended up tracking the rate of usage during beta, and setting static XP requirements per skill box based on the rate of usage of skills, just like that table in UO. We also added the dfifficulty rating to each challenge that users were overcoming (be it a monster or something they were crafting) so that we could adjust the XP gain accordingly.

A fun little story for those who think SWG was still too grindy: three days before the game launched, the designer in charge of advancement rates went through them and made them all ten times slower. His concern was that players would max out the game in a matter of weeks, and then quit. This actually hit the live beta servers, and I reverted it back out as soon as I saw how excruciatingly slow it was: making literally thousands of blaster bolts to advance one skill box. I felt that I’d rather people exit the game having had fun, than stay and not have fun, or quit because it was too grindy.

Of course, it was still too grindy.

So, how to make use-based systems work? Well, I think you’d have to run down the checklist, and try to fix each of those problems. The result might not look much like a use-based system once you were done.

One system that we were planning with the cancelled Privateer Online was to drop this advancement metaphor altogether. Instead, you were certified to do things. You earned certification by doing a minimal amount of training, defeating a challenge of some sort, and then most critically, paying your dues. Dues would be currency paid to the NPC guilds in the game. If you couldn’t pay the dues, then you’d lose the certification.

The instant reaction to this system was, “but people could buy their way up to the top!” And my reply was, “so what?” It’s not it’s regular skills — instead, think of it as a mechanism for people to play the way they want to. If you want to set up a merchant empire, find a sponsor, and try to get going. And if you can’t cut it, you’ll lose all your money on expensive dues, and slip back down to the level of gameplay you can actually handle. For a game about commerce, this sounded fine to me.

At the heart of all this, though, is the problem that skills, levels, abilities — these are properly regarded as enablers, and not as the point. A skill is supposed to be a tool you use to defeat a challenge. If the game becomes getting the tool, then you have a nice little rat race going that is inevitably going to be a grind. You need to make the skills something you pick up in order to do something else. At that point, whether you make people earn them or just let people pick up any they want becomes much less important, because you’ve placed the burden for fun where it should be: on the game, and not on the advancement.

*

You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.

Meta

Recent Comments

Categories

Tags

Recent Trackbacks

Archives



A Theory of Fun
for Game Design

Book cover for A Theory of Fun for Game Design, by Raph Koster

Press
Excerpts

Buy from Amazon

Twitter @raphkoster



The whole Web

Raph's Website

See popular posts »



After the Flood

After the Flood CD Cover

Available as MP3 download
$14.99


More stuff to buy

ORPG Rorschach Test T-Shirt

ORPG Rorschach Test
Organic Cotton T-Shirt

$18.99


LegendMUD

click here to visit the Legend website

"The world the way they thought it was..."