Friday, June 30, 2006

Inside-Out Design

I started programming back in the early 80s when "structured programming" was still going to save programmers from themselves. One of the components of this model was "top-down programming."

Through experience I learned that neither top-down programming nor its bottom-up predecessor worked well for me. Both approaches missed important things. So I worked out my own approach to design, which I naively called "inside-out" design. Rather than starting either at the top or the bottom, I would start from the middle, seeing the whole system as a skeleton of core systems branching out into reusable subsystems.

Another way of putting it is that I learned to "flatten" the map of systems. Looking at either the top or the bottom hid necessary information -- by exposing systems from the middle outward, I could see all the key system relationships at once. (A key here for me was encountering John Gall's remarkable book Systemantics, which for its exploration of both theory and practice remains one of the most useful works on systems design I've ever read.)

Later on I discovered that although I personally was more comfortable with this systems-oriented approach to design, there were some people who still preferred top-down design... but there were even more people for whom bottom-up is simply the only way they are capable of thinking.

In the group of developers I manage, for example, there's one who regularly misses things because she "chunks" systems. Her code usually accomplishes what the customer really needs, and fits well with the rest of the system, and gets done in a timely fashion. But there's almost always some little piece that doesn't work, causing me to have to budget more time for testing her code than that of other developers.

But then there's the other developer who is constitutionally incapable of thinking in any way other than details-first. He is superb at collecting requirements, and at insuring that no requirement is missed in implementation... but his stuff takes forever to write, it often duplicates existing subroutines, and it doesn't always integrate well with existing code. Worst of all, it sometimes has to be substantially rewritten later because it didn't question what the customer asked for versus what they actually needed. So I have to allocate time to providing high-level organization for this developer's work.

No amount of direction or assistance from me has changed these behaviors. These are simply the ways their minds work, and the best I can do is find tasks for them that fit their styles.

All of which is an excessively long preface to my agreeing enthusiastically with the observation in the Situational Awareness thread on Terra Nova that "[d]esired is a form that reflects the priority of the player (and implicitly the world/game design)." This fits precisely what I've come to believe about MMORPG design, which is that in too many cases it's not player-centric enough. Or, more accurately, that features and interfaces are designed for only one type of person, that being the detail-oriented kind of person. If you're not that kind of person, sorry, you don't get a game.

Many people think in terms of concrete, external details. These folks want interfaces that let them interact directly and reliably with tangible elements of the game. They like the "radar"; they like having the numbers of the RPG exposed; they like seeing information about a potential target (either floating over its head or detailed in a pop-up window, or both). They like things that can be held, owned, possessed -- weapons, armor, tools, clothing, houses, furnishings, decorations -- and they want to be able to control the appearance, positioning, usage, and stats of all these things. Oh, and they want all of that Right Now. Like the jet fighter pilot, they value constant situational awareness. Clearly most MMORPGs are designed to satisfy people with this worldview.

But not all gamers see the world that way. Some of them naturally have top-down minds. They prefer not to see the nuts-and-bolts details; to expose that information breaks the illusion of being in a coherent, dynamic world-story. These gamers prefer surprise over certainty; they enjoy realizing how systems fit within systems to create a coherent whole; they like stories-within-stories that unfold over time; they want "ecological" AI rather than farmable loot bags; they prefer reading layerable maps over following magic lines; and by a large margin they want tools to build their own objects and stories instead of just taking whatever they're given. (If it's hard to provide examples of top-down game features and interfaces, that's because few MMORPGs offer those kinds of things!)

So where are the virtual worlds that consider both of these ways of looking at the (game)world to be valid? What MMORPGs support both top-down and bottom-up thinking in the design of both gameplay features and user interfaces?

Is such a thing even possible?

Thursday, June 29, 2006

Playing a Jack-of-All-Trades in MMORPGs

"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly."

Specialization is for insects.

-- from Time Enough for Love by Robert A. Heinlein
That concept of action has been with me pretty much since the first time I read it lo, these many years ago. And it's how I prefer to play MMORPGs. I like being a jack-of-all-trades.

Note that when I say "jack-of-all-trades" I do not mean a support class like Healer. That's not a jack-of-all-trades character; it's a class role character who is directly aimed at satisfying some developer's role requirement. When I say jack-of-all-trades, I mean a character who is capable of doing a lot of completely different things in a game. Maybe not perfectly, maybe not even well, but to be able to do many things at all is satisfying enough.

I'm just not interested in spending all my waking hours in some futile attempt to be the "best" at something in a game. I prefer to go my own way, do my own thing in my own time. Specialization would box me into a particular set of content -- why would I want to do that?

By having a jack-of-all-trades character, I not only improve my chances of being able to survive most basic problems the game flings at me, I'm also able to experience many of the different types of content available in the game. I can never master any of them -- in fact, being a generalist in a MMORPG pretty much insures that there's some content (the so-called "high end" or "endgame" content) that I will never be able to enjoy.

So? If it's that intense, I'm not interested. I get enough "intensity" in my life outside of games; I play games to get away from intense stuff. (Note that this doesn't mean I don't enjoy playing FPS games. It's just what I get out of them is different: I tend to play snipers because I like the chess match; I don't play them for the sensation/excitement of an intense firefight... and I absolutely hate being put on a countdown timer. That's too much like work.)

The jack-of-all-trades approach lets me enjoy a game on my own terms... unless of course the game insists on stuffing every player into a neat, tidy little class to fill some developer-determined role, rather offering a rich array of player-selectable skills so that players can write their own stories. A class-based game is the mortal enemy of the generalist.

So why don't developers respect gamers who prefer to be a jack-of-all-trades by designing content specifically for them?

Wednesday, June 28, 2006

Improving NPC AI +

The bottom line problem with non-player mob (that is, NPC and creature) AI is that it's reactive, not active. NPCs and critters are either loot bags waiting to be popped or mindless quest dispensers. They don't act; they exist only to be acted upon.

To some degree, that's how it has to be. Those are functions players want NPCs/critters to have, so that's what developers give them. Except that developers stop there. But why stop there?

Well, partly it's because there are only so many hours in a day, even if you work programmers like galley slaves. (Something that courts are beginning to take a dim view of.) Stop for a second and ask yourself: How many important systems are there in a major MMORPG?

Go ahead, come up with a number.

Now multiply that number by 10, and you'll start to be in the ballpark of how many systems there really are that somebody has to design, implement, and test. (And you can easily double or triple that number if you also take into account server code, behind-the-scenes "helper" systems, and tool development.)

With so much to do that absolutely has to get done, I'm sympathetic to not implementing super-AI. "Minimally plausible" starts looking like a more appropriate goal.

It's also the case that you don't necessarily want your mobs doing things when there's not a player there to be affected by those behaviors -- that can be perceived as a waste of processor cycles. (Do you want more lag?)

Finally, there's the argument that despite what some of them may say, most players don't actually want mobs that are smart enough to wipe the floor with them. The highly gameplay-oriented players -- to whom most MMORPG developers cater slavishly -- want mobs they can beat so that they can take their stuff. (Actually, that applies to PvP as well, but that's another thread.) Making mobs smart enough to run away or gang up on a player might wind up being very unpopular with many of today's gamers.

And yet... what a waste of good mobs. If a MMORPG is a game world, then shouldn't "world" be roughly as important as "game?" In which case, shouldn't mobs be designed to support the goal of making the gameworld feel like a living, breathing, dynamic place?

Bearing in mind all the objections, I think the answer to that (as the editorialist said) has to be "yes." To make the gameworld as dynamic as it should be to make it feel "alive," mobs need to be more than loot bags and quest dispensers. Instead of just existing to be acted upon, they need (to some degree) to be independent actors themselves.

I believe that accomplishing this will require non-player mob AI to improve in at least four specific categories: agenda, environment, communication, and ecology.


Agenda is easy to describe, but hard to implement: mobs need to have goals and desires and interests, and then (according to their level of intelligence) should be able to devise and carry out plans that will plausibly allow them to achieve their goals.

In some cases, that will mean that they do exactly what they do right now: stand around and wait to be activated by a player. Maybe they're in "guard" mode, which means patrolling a certain area to protect something (shops if they're NPCs, babies if they're critters). Maybe they're just lazy and don't have a job. Maybe they're injured, or lost. There are plenty of reasons why some mobs could do exactly what they do now; the differences would be that there's a plausible reason why they're doing it, and other mobs are capable of doing something else because now they have a reason for that.

Being able to form and carry out plans -- in other words, having an agenda -- along with the subsidiary capability of being able to describe this agenda to players who ask would tell players that they are part of a world that has a life of its own. Creatures would seek to feed and breed. NPCs would have player-like aspirations that they, like players, would attempt to fulfill.

Not being at the center of the universe could be a shock to some players... but there are, I think, a lot of other players who would feel much more satisfied to be playing in a gameworld where even the mobs have interesting stories to tell.


Why is it that I can unleash electric death on an NPC and another NPC who is three feet away -- who belongs to the same faction as the first NPC -- will simply continue lounging against the wall?

How can that some creature can detect me from a hundred feet away when I'm behind a tree, at night, wearing all black, downwind and masking my scent, and not moving?

I cannot think of a single MMORPG that implements the gameworld as a place where the various emissions of the electromagnetic spectrum are used to any serious degree. Most games let their mobs do simple A* pathfinding around collidable obstacles. Some games give you line-of-sight. A few games allow terrain or character position (standing/crouching/prone) to matter. But how many really incorporate sound? Smell? Environmentally-appropriate camouflage? Reduction in visibility due to darkness/rain/dust/fog/smoke? UV or IR detection/masking? Heat or power signature detection/masking? Weight/mass detection (as for pressure-sensitive switches)?

Can you imagine a game where mobs could detect and recognize other mobs (including players) through all these environmental cues, and could incorporate that information into their agendas?

Creatures could stalk their prey, and prey could use various means (natural, technological, magical, whatever) to avoid or break detection by predators. NPCs could see or hear when their allies are being attacked and run to the rescue. Mobs in general would become able to interact with each other and with players in a vastly more plausible way because they would finally have access to the same kind of environmental information that we as players take for granted when we’re deciding what to do.


Some mobs are social. While individuals, they are also members of a group or groups. Accordingly, these mobs ought to be able to communicate information to and among each other.

A mob who enters a "danger" or "opportunity" state ought to be able to transmit that information to other mobs who could benefit from the knowledge.

When a creature makes a kill, why can't he alert his packmates to come share in the bounty when doing so helps to insure the group's survival? When an NPC sees an enemy force coming over the town walls, why can't she race to the watchtower to ring the warning bell, then run through the town calling for all allied NPCs (and players!) to help repel the invaders?

A decent level of communication capability would allow mobs to share these kinds of useful information. Rather than acting purely independently, they would be able to act together as a group. And that would finally allow mobs to effectively match the ability of players to act in a coordinated way.

Which brings me to:


Why is it that I can whack the same mob eight zillion times, and he will respawn in roughly the same place to allow himself to be whacked for eight zillion more times? Why is it that I can wipe out an entire zoneful of orcs, and they'll just reform in the same place as soon as I turn my back so I can wipe them out again? How come I and other players can all take the same quest from the same NPC for weeks at a time and he never learns to recognize us?

Here's an answer: Player actions have no long-term consequences because mobs have no long-term memory or social decision-making capability. There's no ecological response to repeated external stimuli.

(The larger answer is of course "to make the game fair for all players." But there has to be a way to do this that doesn't turn the gameworld into a bizarrely static place! When it comes to gameplay challenges, is "equivalent" good enough? Or is "identical" required? Right, back to mob ecology.)

The last major component of a full, integrated mob AI system would be to allow groups of mobs to change their behaviors over time. Creatures (as less intelligent mobs) would simply react to player incursions by migrating elsewhere from their hunting or feeding grounds. (Unless of course they happen to regard players as tasty snacks, in which case maybe breeding rates go up to take advantage of the unexpected bounty.)

NPC mob groups would have even more types of long-term behavioral choices available to them. Maybe when you wipe out an orc encampment several times, the orcs move somewhere else. Now they're someone else's problem (or opportunity.) But perhaps instead you've stumbled across a particularly warlike band of orcs, and they don't take kindly to your depredations. So they've dispatched a runner to invite some of their friends over to hide in the woods around their encampment. The next time you show up to casually mete out destruction, you discover that you're facing not five orcs, but fifty. Surprise!

Or suppose a group of NPCs realize that a lot of players have been asking them for a particular type of quest. What if the rewards for that quest become less valuable to reflect an increased supply in reaction to demand? Conversely, what if those NPCs decided to offer more quests like that one, since obviously it's very popular? Why shouldn’t NPCs be able to change their behaviors in response to the ways that players interact with them?

As a final example, what if an entire faction of NPCs decides that players have been beating up on them a little too much, and coordinates a massive assault (maybe physical, maybe economic) on some player resource or location? Isn't that exactly the kind of large-scale action many players say they'd love to see in a MMORPG?

An ecological AI capability could enable precisely that sort of event.


Agenda, environment, communication, and ecology. Design your mob AI to incorporate those capabilities, and you will have a gameworld that players will remember with pleasure for years to come.

Tuesday, June 27, 2006

Crafting as a Process in MMORPGs

I've sort of started to wonder whether a lot of developers have a funny idea of what "crafting" is... or maybe I'm the one with the funny idea. Either way, there's a gap.

I can understand designers thinking of crafting as being about servicing the game economy. In other words, designers design a crafting system as an economic support system -- its purpose is to insure that other players can have the stuff they need/want to play the game.

Well, yes, that's a useful function of a crafting system... but what does that offer the people who like to make things?

My problem with crafting systems in nearly all current and discussed MMORPGs is that they're not focused on satisfying the people who craft because they actually enjoy crafting. "Crafters" aren't all automatons who thrill to the opportunity to grind out gazillions of copies of some uber weapon, nor are they all hypercompetitive economic PvPers who see crafting as a sales game -- they are creative people who enjoy imagining new things and bringing them into the (game) world. It's the enjoyment of making new things in and of itself that appeals to the crafter personality, not the utility of the end product.

Accordingly, my one great interest in any MMORPG's crafting system is that it be more about process than product.

Don't worry about whether crafters will crank out enough units of Product X to satisfy demand. Make the process of crafting so much fun in and of itself that lots of people want to do it and (assuming you also implement a free-market player economy) the results will take care of themselves.

So how can this be accomplished? I believe the three keys to enabling a fun crafting process are:

1. Great variation in resource and configuration inputs is possible.
2. The attributes of outputs mirror the attributes of their inputs. (a nod there to the Doctrine of Signatures)
3. Players can choose to trade quality for quantity in outputs.
In a little more detail:

1. By variation of inputs I mean two things. First, there should be a vast number of resources/components needed to make things, and all those resources and components should have multiple attributes of varying degrees. And second, there should be a appropriate number of ways to connect each of those resources and components to each other.

Variation of inputs allows players to experiment with inputs to see what works best for a given purpose. It supports treating crafting as an exploratory process.

2. Allowing outputs to derive their attributes from their inputs gives structure to crafting exploration. If through crafting some test items I can learn that using a certain kind of wood or a resource with a high level of copper turns my finished product green, that's information I can use later if I ever want to make something that's green.

Similarly, letting crafters experiment with how resources and components are connected to each other (in more complex crafting procedures) should also have some plausible effect on the final product. Perhaps connecting a flywheel to an engine through a gear will make the complete device more efficient, though perhaps also resulting in a higher maintenance cost due to more parts....

3. Letting players decide whether to optimize an individual crafting process for quality or quantity is a way to support both creative crafters as well as those current players who regard crafting as a competitive economic game. If you want to try to corner the market on widgets, OK, but optimizing your crafting process for quantity will mean that you can't make the "best" widget possible. Likewise, if you want to try to make the most perfect widget possible, you're only going to be able to make a very small number of them, and the cost in failed experiments will probably be pretty high.


A crafting system designed to incorporate these principles for focusing on process would, I think, be one that satisfies everyone's needs. The artistic crafter can create; the exploratory crafter can tinker; the sales crafter can meet market demands; and the developers can all buy Ferraris with the revenue from the subscriptions from happy gamers.

Cooperative Play in MMORPGs

These MMORPG things need more cooperative play options.

Of course that's a tricky thing to do. What the heck do we mean by "cooperative" play, anyway? Everybody knows what competitive play is like, but how do you implement the alternative? Worse, how does a designer offer cooperative play if doing so will be used by two players just to level each other up or gain money or loot rewards by playing like bots?

First, I think it's important to recognize that just as there are different levels of competition -- tactical, operational, strategic -- there are different levels of cooperation.

Combo moves are one type of tactical cooperation that's starting to get some attention. (The MMORPG Hero's Journey from Simutronics, for example, will be offering this feature.) Something similar could probably be designed for crafting by a clever designer, or even for socializing.

But what about operational and strategic cooperation? I can't think of any MMORPG that has even considered such features, much less implemented them. That would be a game that would definitely get my attention.

Second, regarding how to encourage cooperation generally, I feel pretty strongly that the ubercompetitive nature of most MMORPGs is driven by their fundamental design as zero-sum games.

Most MMORPGs are built as "lands" on some individual world, or as a few planets... and that's all there is. Those are the only places you can be. Which means that any game that allows players to compete for places are zero-sum games -- you just fight over the same patch of ground over and over and over again because that's all you can do.

A non-zero sum game takes that pressure off by offering an alternative. Instead of competing for scarce resources, players can choose to add to the total number of resources through exploration and discovery. In effect, they can compete by cooperating to see who can add more resources to the game world the fastest.

Very few gameworlds offer a non-zero-sum game. The only such game I can think of that's actually running currently is EVE Online. It's still highly competitive, however. Because the number of star systems, while relatively large (~5000), is still fairly low compared to the number of players, and because maintaining security in these player-run systems is a full-time job, players compete fiercely to keep what they've been able to wrest from tough NPCs.

An even more non-zero-sum game is currently being developed, called Infinity: The Quest for Earth. Although I disagree with some of the design decisions being made, there's one that I agree with wholeheartedly. (In fact, it's something I wanted to do myself before I ever even heard of Infinity.) Namely, Infinity's playing field will consist of literally billions of procedurally-generated worlds.

With that many worlds, it will take years before players are able to explore (much less exploit) even a fraction of them. And that should be enough to take the pressure off players to compete over every square inch of known ground, enabling cooperation as a viable way to play the game.

So where are the other persistent online games that offer both strategic and non-zero-sum play? Why expect cooperative play to emerge if the game isn't designed to encourage and reward such play?

Friday, June 23, 2006

The Passage of Time in MMORPGs

Let's consider the question of how time passes (or not) in online worlds. It takes us into multiple game systems, and winds up having some deep connections to how different people experience a game world.

The first question that has to be asked is, should time pass at all?

It's not a requirement for a game. You could simply make time in the game an eternal "now," and eliminate all questions related to the passage of time.

For some game worlds, that might be desirable. Social worlds, for example, probably don't need to create their own local time format. It's also possible to imagine game worlds that are more like tone poems; they're not about gameplay so much as experiencing a particular feeling or event.

It's when we consider larger and more complex game worlds in which players can, to some degree, tell their own stories that marking time in the game world becomes useful. For these worlds that try to balance gameplay and immersiveness, the next question is whether time should pass with reference to physical or social phenomena (or both).

Examples of physical phenomena related to time are things like the day/night cycle, circadian rhythms, tides, seasons (temperature, weather), erosion, plant and animal responses to long-term temperature changes (as during the "Little Ice Age"), and continental drift.

And examples of social phenomena related to time are interest on loans, labor organization, traffic patterns, housing styles, city growth, and migration routes.

To explore these possibilities for features in a gameworld, let's look at the most common ways in which time is measured.

The measurement of seconds only gains importance when you can measure them accurately. That means you need the ability to build clocks/watches. So does the technology in your game (whether mechanical or magical) support that?

And from a game perspective, do players need to know exactly what second something happened or will happen?

See "seconds."

Hours are primarily a social measure of time. As civilizations become more complex, they tend to develop labor specializations. To support people of different professions working together, it's useful to be able to coordinate times at which exchanges can be made.

Is this really necessary in your game? Is there gameplay value in players knowing exactly what hour (within some larger measure of time, usually a day) it is?

Is your game set in a location on a planet that rotates near a star, revolves around that star, and whose rotation period does not match its revolution period? If so, then logically it would have a day/night cycle. (Some orbital bodies are what's called "tidally-locked" -- from the perspective of someone on the body they revolve around, such a satellite always presents basically the same face. Our Moon is like that.)

And do you want to spend time developing the graphics and code to dynamically change both the ambient lighting and the sky textures?

If both of these conditions are true, if you implement a day/night cycle, then you'll probably want to define the "day" of your game to be shorter than a real-world day. All of the MMORPGs I know of with day/night cycles do this; it just seems to be perceived as more fun by most players -- probably a function of variety/novelty.

Another socially-generated measure of time that your game probably doesn't need.

Yet another primarily social measure of time. Because months are usually named, they're potentially interesting as lore flavoring if your game also implements days and years.

Seasons -- cyclically recurring periods of global temperature and weather variation -- are sometimes thought to be caused by a planet's orbit being elliptical, but that's not correct... at least not for Earth, whose orbit is not very elliptical. (A planet in a more elliptical orbit, such as Mars, does have orbitally-induced seasons.)

Earth's seasons are caused by its axis being tilted (rather than perpendicular) with respect to the plane of its orbit around the Sun. Because of its tilt and average distance from the Sun, both of the northern and southern hemispheres get roughly four seasons. (Except for Minnesota, which has only two seasons: Winter and Construction.)

So if you set your game world on a planet, is that planet tilted on its axis? And will you implement weather in your game?

If so, then it's conceivable that weather patterns could change over the year according to seasons. Knowing when a season was about to start was incredibly important when survival depended on predicting when the local delta would flood. That permitted sufficient crops to be irrigated to feed a growing city. But as technology improved, and agriculture became less critical, seasons became mostly a mildly interesting way to break up the passage of a year -- basically they allow some variation in the local weather.

So are seasons worth the development time?

To put it another way: If weather is implemented at all in your game, will it have any practical effect? Or will it just be pretty?

If it has some actual effect, then seasons might be worthwhile. Otherwise, probably not.

The period of a planetary body's revolution around a star is its year. It's a good measure of the passage of time compared to a human's lifespan.

If characters in your game are effectively immortal, years might not be worth implementing.

On the other hand, if nothing else ever changes cyclically in the game, then there's no real downside to implementing years as an accumulation of some number of days (other than the time to write and maintain the code). If players can know that they started playing in the year 3371 and it's now the year 3402, what are the benefits of that, and do they outweigh the cost in terms of the time it took to code that capability?

What about if instead of numbering years, you named them (as in the "Year of the Fruit Bat")?

Decades and Longer Periods
It would be fascinating to see an online game world that tried to deepen its immersiveness by reflecting some of the phenomena related to multi-year spans of time. These could be physical, such as changes in tree types or animal migrations; or they could be social, as in organizing periods of years according to who's in charge politically ("the 12th year of the glorious reign of Planodigitus Maximus").

Perhaps someone will give this kind of thing a shot someday.

Friday, June 16, 2006

Price Stability in MMORPGs

The subject of how to keep game economies stable -- that is, to prevent both inflation and deflation -- keeps coming up over and over again. Price maintenance is about keeping the game's level of challenge balanced, especially for new and casual players. If prices rise too high, new and casual players can’t afford goods, making the game too hard. If prices fall too low, everyone can afford anything and the game gets too easy.

So, in a game where players can essentially create money and items, how can prices be kept stable?

The key to price stability is to hold the inputs equal to the outputs: the total amount of wealth entering the game should over time be roughly equal to the total amount of wealth exiting the game world. Some games have tried to do this with "closed" economies -- outputs are cycled back into the game as inputs. This approach has the advantage of insuring price stability, and resembles a simulation of a real-world economy, but it has the serious disadvantage of being very difficult to maintain.

Instead, most MMORPGs use an open economy model. Wealth enters the game world by simply being created out of nothing, and exits by simply being destroyed. In this "faucet/drain" economic model (originally developed for Ultima Online after the closed economic model proved too hard to manage), items are easy to create, but finding ways to remove money from the game economy becomes crucial. Compounding the difficulty is that some kinds of money drains are more palatable to players than other kinds. You can't just impose any kind of drain, because some kinds will make players so unhappy that they will quit the game.

So here are some ideas for MMORPG money drains. To reflect the point that not all ideas are equal, they're listed in rough order of popularity with players, from most acceptable to least acceptable. (It's important to realize that this is intended to be a descriptive list, not prescriptive. This is just an attempt to develop a reasonably comprehensive list of possibilities; I'm not saying that every game should offer all these drains.)

  • recognition for having the most money: (hoarding removes currency from the game economy) (Note: This isn't a true drain since money is not "physically" removed from the economy. But it's still a drain in that it does prevent money from having any practical effect on the game economy.)
  • purchase of system-created items: (Note: This isn't a perfect drain because players receive items for their currency.)
    • tradable commodity items:
      • "required" items (e.g., class-based basic gear not crafted/craftable by players)
      • consumables
    • unfarmable/untradeable luxury items:
      • house decorations
      • special clothing
    • one-to-a-customer benefits (such as a sign for a shop)
  • purchase of system-created non-items as status markers (titles, memberships, temporary appearance changes, etc.)
  • system-run games of chance (gambling):
    • lottery (someone will win big, but more will lose)
    • "house" games
    • NPC gamblers
  • fees:
    • public services:
      • transportation
      • skill training by NPCs
      • protection (city guards)
      • space for a player-operated public vendor
      • rental of public housing
    • maintenance:
      • structures -- usage/upkeep cost
      • objects -- damage repair cost (decay)
  • taxes:
    • on stored money
    • on each intermediated transaction ("auction house," Bazaar, etc.)
  • removal within the gameworld context (stolen by NPC thief, natural disaster, etc.)
  • outright removal by the developers
Note that this list refers only to money drains, to ways to remove currency from a game economy. But currency isn't the only form of wealth in an economy -- wealth also enters a game world in the form of items such as loot drops and crafted goods.

If your interest is to maintain price stability (that is, to avoid both inflation and deflation), then there can't just be currency drains. You’ll almost certainly also want item drains. This gives you another tool for keeping the total amount of wealth (money + items) entering the game world roughly equal over time to the amount of wealth leaving the game world.

Here are some possible item drains, again in rough order of popularity with players, from most acceptable to least acceptable:

  • selling items to NPC vendors (Note: this isn't a perfect drain because players receive currency for their items.)
  • recycling (e.g., junk dealer who takes multiple items and returns one item or some nominal amount of money)
  • consumables:
    • ammunition (bullets, arrows, etc.)
    • components (spell reagents, crafting subassemblies, etc.)
  • deliberate destruction by players
  • maintenance destruction (item is destroyed when condition falls to 0% through either usage or damage)
  • failure destruction (item is destroyed through some critical failure, as in combat or crafting)
  • destruction within the gameworld context (theft, story-based disaster, etc.)
  • outright destruction by the developers

One particularly good discussion of the factors involved in MMORPG economies is Zachary Simpson's analysis of the Ultima Online economy, "The In-game Economics of Ultima Online." Despite being written in 1999, a surprising number of the observations made by Simpson are still relevant to today's MMORPGs.

I strongly encourage anyone who's interested in this kind of stuff to review Simpson's essay. (Note: This is a Word document.)

In considering what might be effective money and item drains, it's useful to bear in mind what ideas actually don't constitute drains. (Not being a drain doesn't make something a bad idea; it just means it won't help to take stuff out of the game economy.)

For example, there's my Player Contracts idea (condensed version here). (I find it interesting to note that Simpson also proposes this idea as "enforceable contracts." One important difference is that he assumes that a third player would be required to enforce a contract, where I believe the game itself can and should fill that role.)

I think a player contract feature would be a valuable addition to any MMORPG that wants a meaningful player economy. For one thing, it would create a new reason for players to want to interact socially -- a Good Thing in a "massively multiplayer" game. But in a purely economic sense, a player contract feature would also help to level out the Pareto effect that concentrates the majority of wealth in a few hands. Instead of a few players hoarding cash, they'd be able to spread it around more by hiring other players to do things for them.

What's important to realize about this is that while it would be socially and economically useful, it would have absolutely zero effect on inflation/deflation because it would not alter the total amount of wealth within the entire economy. Letting players trade with each other wouldn't actually constitute any kind of drain -- rather than removing currency, it would simply shift currency from one player to another.

The same can be said about other proposals for ways to allow players to trade with each other. Player-to-player trades don't actually remove anything from the game world, so they can't be considered true drains. Only player-to-system interactions can be true drains.

Side note: There's an important difference between tangible wealth in MMORPGs and in the real world. In most MMORPGs, players generally aren't permitted to own or create two very important kinds of real-world property: land (real property, AKA "real estate") and ideas (intellectual property). (Side side note: property that is not real property is actually recognized legally: it's called "personal property," or "moveable property," or even "chattel property," and it's treated differently than real property in several ways under most modern legal systems.)

Concerning land, although players in some games can occupy land with a house or other object, few games allow player characters to actually "own" that land. (Second Life appears to be an exception to this, but SL is much more a social world than a game world.)

As for intellectual property, few game worlds allow players to create truly new kinds of objects or processes within the game world, either. The most you can do (if you're lucky and the game even has a decent crafting system) is make instances of predefined item types. So it's not possible to create original IP that either a character or player could own. (SL is again exceptional in legally acknowledging a right of players to own the scripts they can write to create new objects in SL. But again, SL isn't a game world.)

My question: What would a game economy look like that did allow ownership of real (virtual) property, creation of intellectual property, and the trading of both?

For example, suppose some MMORPG decided to allow characters to own land in the game world... would this require the game to have "eminent domain" rules? How would they be enforced? And what if players themselves could constitute the governments that applied eminent domain to some player character's land? Could this work, or would it only bog down in appeals to the developer?