Where Did "Content Locusts" Come From?

The term "content locusts" came up today in a Google+ post by Richard Bartle discussing the direction of "free-to-play" online games.

This term content locusts has come into use as a shorthand way to decribe the phenomenon that, when a new computer game (especially a multiplayer online game) is released, there is a sizable subset of players who will begin playing that new game as soon as it's available, try to experience its primary content as rapidly as possible, and then move to a new game. The notion is that these players are like locusts -- they swarm a new game, buzzsaw through its content, and then fly away (often complaining that the game was "too short" or "too easy").

I remember having mentioned a few years back that the Achiever Bartle Type was most closely related to this behavior, mostly because the behavior seems keyed directly to the Achiever motivation that "game" means a challenge to be beaten.

That got me thinking: what was the earliest use of this term?

There are several forms of the basic idea. The earliest mention I could find of "locusts" in the context of computer games was a comment by "Wolfshead" (saved by Google on May 29, 2004) describing player guilds in EQ: "The EQ Devs were caught off guard by the tenacity of the uberguild phenomena. These guilds consumed content like locusts and in many cases actually tested major encounters."

The next mention showing up is by Mike Sellers at Terra Nova on June 13, 2005: "As far as I know instancing has been introduced to reduce the immersion-shattering practice of camping, lining up for spawn points, and seeing popular dungeons or hunting grounds having been essentially clear-cut by roving locust-like bands of players."

The first reference I can find that specifically links content, locusts, and Achievers was my "Will The Real Explorers Please Stand Up?" blog entry (inspired by the Terra Nova discussion of the same name from January through July of 2005): "Achievers tend to become bored quickly -- like locusts, they swarm to a new game, burn through anything resembling "content," then zoom off again to consume the Next Big Game."

According to Google, the first use of the specific term "content locusts" is in the "Time flies when you're having fun" post by Isabelle Parsley (AKA Ysharros) at the Stylish Corpse blog on November 24, 2009: "It takes work to provide a smorgasbord of content that the content locusts can NOM NOM NOM their blind hungry way through, but that the … let’s call them content slugs can enjoy much more slowly and completely."

Finally, the use of the term "content locusts" that ignited its widespread usage appears to have been the "Content Locusts Killed My MMO" article by the very same Isabelle Parsley at MMORPG.com on January 27, 2012: "I like to blame the content locusts for this, at least to a large extent – that small percentage of players whose goal isn’t to experience content but to consume it as fast as possible as they race inexorably through a game."

Following that article, 2012 was littered with uses of the phrase "content locusts." And the design of SWTOR seems to have been directly related to how quickly the term entered general usage -- it's what most people who used the term were talking about.

Assuming anyone else is intrigued by this kind of linguistic archeology, can anyone else find earlier expressions of this idea?

Storybricks + DikuMUD = Balance in MMORPGs

To follow my previous comments about Storybricks, this time I'd like to get into the nuts and bolts of how Storybricks works. (Note that this is based on what has been revealed of Storybricks at this time -- things can and will change as Namaste continues to develop the concepts and implementation.)

Nearly all MMORPGs today are descendants of an early text-based multi-user dungeon (MUD) called DikuMUD. There are three interrelated reasons why DikuMUD proved to be genetically superior to other MUDs, and why it became the progenitor for nearly all modern graphical MMORPGs:

• it emphasized easy-to-understand and action-oriented combat over other forms of interaction
• it simplified interactions down to easily-trackable, table-driven statistics, and
• it was designed to be easy to modify and install by gameworld creators.

These elements combined to catapult DikuMUD and its successors to prominence in the world of computer-based roleplaying games. As other forms of MUDs became less visible, and as new gamers arrived and saw only DikuMUD-derived MMORPGs, eventually only DikuMUD-descended MMORPGs remained.

This wasn't inherently wrong. Obviously a lot of people enjoy the focus on simple fighting, and DikuMUD-derived MMORPGs have prospered because they satisfy that desire. It's also easier for developers to manage table-driven, numbers-oriented content than features that highlight emotional interactions or logical exploration, so that's the kind of game they tend to make and the kind of features they prefer to add to existing games.

But I think it's also true -- and there seem to be at least a few other gamers who agree -- that something important has been lost in the Cataclysm that is World of Warcraft and its close MMORPG siblings. In particular, and as I noted previously, these stat-driven games have dehumanized roleplaying. While there are some dedicated souls who try to enjoy what little roleplaying and exploration content exists in today's MMORPGs, for the most part you're only as useful as whatever combat capabilities your character brings to a group. You're not a person with an interesting history, living in a richly detailed world filled with fascinating people -- you're the equivalent of a car with a gun strapped to the hood, useful only for how much destruction your character can help the group do per second.

In the DikuMUD-based MMORPGs available today, story is dead. (Again, with respect to BioWare and the story emphasis they're trying to offer in Star Wars: The Old Republic, while I'm glad to see that they're trying to inject some story into the combat, in the end it's still going to be about the numbers-driven combat. I expect that over this this will be what gets the most developer attention in SW:TOR, just like in every other MMORPG.)

What's so refreshing about Namaste's Storybricks is that it restores the power of character creation -- thus reviving the power of human-oriented storytelling -- to roleplaying games and to the gamers who enjoy them.

Most content creation tools for computer games are created by developers for developers. Sometimes, versions of these tools are released to gamers. Examples include the Neverwinter Nights story creation tool, the GECK tool for Fallout 3, and the quest creation toolkits in the Champions Online/Star Trek Online MMORPGs. Standalone content creation systems such as Unity and RPG Maker are also becoming more widely available. And support for user-made modications ("mods") such as Notch is adding for Minecraft is also provided occasionally.

Having these tools available has been exciting for gamers who enjoy creating their own content, and I salute the developers who have taken this step. But all these tools been limited in some way -- either by creating content that can only be used locally, or by tightly limiting multiplayer content, or by exposing so much power that the would-be content creator is overwhelmed.

Storybricks -- by design -- addresses all of these impediments to user content generation by including players as creators of game content right from the very start and by making the content creation interface simple but expressive.

Of course it's natural to try to understand new technologies in terms of what can be done using today's tools. This has led some, hearing about Storybricks for the first time, to wonder whether it's simply another iteration on the content creation tools currently available. So it's worth taking a moment to try to address some of these questions and concerns.

First, the current plan (as I understand it) is that when you create characters and place them in the gameworld, other players can play with them as well. This way you can build your own stories and then allow others to join you in discovering where those stories lead. This ability of players to create content for each other appears to be a central goal of Storybricks.

As for being just an improvement on quest creation tools like those for Neverwinter Nights or Champions Online/Star Trek Online, there are some mechanical similarities in that all these allow the content creator to establish connections between characters and objects. But Storybricks is more focused on creating and expressing personal relationships among multiple characters (PCs and NPCs alike) than on associating experience points with object-based player actions. The core of Storybricks is not so much a system for detecting the completion of certain player actions (although it must do that, too) as an AI engine for storing and reflecting personal drives and multi-character relationships.

And unlike powerful quest-generation tools like the NWN toolset or general content builders such as Unity, Storybricks is very simple to use while being extremely expressive. You simply drag nouns and verbs and adverbs from a context-sensitive list and snap them together. In the same way that a few natural-language sentences can express powerful thoughts, the linguistic construction model for relationships in Storybricks is capable of defining a remarkable amount of communication with just a few clicks.

By design, however, the real power of this system is encapsulated in the AI engine that carries the load of emotional interpretation. The building system that is exposed to the player is really simple to use, and Namaste seem determined to keep it that way even as they add useful new features.

Another concern I've heard is that in a Storybricks gameworld, you'll be forced to make your own content or somehow pushed into giving developers "free labor." I think I'm safe in asserting that no one will ever be forced to participate in content creation in a Storybricks gameworld. All the details of how user-generated story material gets used and distributed have not been worked out yet, but the developers of Storybricks have made it absolutely clear that their goal is creative freedom for players, not player control. I'm confident that adding your own story material will be completely optional; those who only want to play in a story-friendly game world will be free to do so.

Finally, it's important to bear in mind that the Storybricks system is not at this time being developed as some kind of external engine-plus-user-interface that can be plugged into an existing MMORPG like World of Warcraft or EVE Online. The degree to which the relationship AI has to be keyed to everything -- objects, places, factional states, movement animations, available interactions with other characters -- means that you pretty much have to build the entire gameworld around this relationship engine. Playing with Storybricks will mean playing in a Storybricks gameworld.

That's admittedly a limitation of the Storybricks idea. To have immediate impact, it would need to be easily implementable in existing gameworlds. But the association of emotional states with character animations and interaction options, not to mention character awareness of objects and places, is so pervasive in Storybricks that it would be extremely difficult to retrofit to an existing gameworld. Such an extensive web of connections basically has to be baked into a game from the very start.

This doesn't mean that the Storybricks idea can't have wide consequences, however. It only means it will take time for elements of the Storybricks approach to character design -- once the kinks are ironed out in practice -- to be integrated into new MMORPGs.

Not every new MMORPG will need or want emotionally plausible NPCs. Some will continue to implement NPCs as quest dispensers and mobile targets. There's nothing wrong with that in itself; it's fine and even desirable for there to be games that follow the path laid down by DikuMUD and its descendants.

But to do well over the long term, I think MMORPGs can't afford to neglect the storytelling and world-discovering interests that gamers also have. And that's why I'm excited about Storybricks.

For the MMORPGs that aspire to being narratively rich places, whose creators care about letting gamers create and interact with interesting characters who are capable of driving stories of intrigue and passion and revenge and all the rest of Georges Polti's 36 plots, I believe that Storybricks truly does have the potential to give the MMORPG evolutionary tree the strong new branch it needs as a counterbalance to the old stats-and-combat-focused DikuMUD branch.

Storybricks: The Rehumanization of Roleplaying Games

Anyone who has followed this blog for any length of time will know that I tend to look at game design (like everything else) from a fairly high-level perspective.

Other people are good at speaking to the mechanics of specific games, or at advocating for concrete gameplay content. My interest is usually directed toward the design of core gameplay systems that could help make interactive worlds more engaging for people who enjoy simulation and narrative -- that is, for the Explorer and Socializer gamers among us.

This is why I've developed numerous ideas and criticisms around the goal of helping gameworlds feel more "alive." In particular, I've criticized the practice of building Non-Player Characters (NPCs) as nothing more than loot piñatas (pop them for goodies!) or static props handing out quests and dispensing pellets of experience points. They look like people, but they don't act like people. Their inhuman behavior leaves a gameworld feeling more like a wind-up toy than a world filled with interesting people -- once you've seen its limited repertoire of behaviors, you're done with it.

This is radically different than -- and a serious step back from -- interacting with the complex, fascinating, frustrating, dangerous, and lovable non-player characters found in tabletop roleplaying games. In these games, where NPCs are played by humans, characters have character.

The roleplaying part of tabletop roleplaying games was a remarkably humanizing play activity. Pretending to be a person with abilities and desires other than your own could reveal unexpected abilities and motivations in yourself. How many areas of human experience can say that?

But in translating roleplaying games to computers, much of the human touch was lost. With so many other systems to develop (especially the systems for character leveling and combat), the developers of most computer-based RPGs somehow never got around to recreating what was arguably the most important part of a roleplaying game: interacting in interesting ways with interesting characters.

(BioWare deserves credit for trying to bring interesting characters to life in their computer RPGs. No one forgets Minsc. But massively multiplayer online role-playing games -- called MMORPGs for the obvious reason -- have not yet given anywhere near the same level of attention to NPCs, and BioWare's Star Wars: The Old Republic took years to fill with hand-developed content.)

In a way, many of the concepts I've suggested over the past decade have been attempts to address this problem of characterless characters. A couple of notions in particular are specifically meant to help NPCs feel more interesting by building into them a greater range of perceptive and expressive capabilities.

One thought was to enhance gameworlds with specific environmental effects, such as day/night cycles and sound propagation, while also allowing NPCs to perceive these environmental effects and respond to them in reasonable ways. An NPC who can realize that some meaningful event is happening and respond to it is a much more interesting character than one who just stands there oblivious to local reality.

The other key suggestion in this area is something I called "multifaction." In today's MMORPGs, when you do something for a particular NPC, that character may be able to "remember" that your action helped the one group to which that NPC belongs. This notion of "faction" is good for creating a very limited social fabric -- members of the Rebel Alliance love me, but I'm shoot-on-sight to Imperial stormtroopers -- but it's inexplicably underused.

Why can't I have faction with individuals rather than just groups? Why can't individuals and groups have factional standings with each other so that when I do something nice for Person A, who is disliked by Person B but loved by Person C, Person B likes me less while Person C likes me more? Why isn't faction used to enable persistent-world computer RPGs to store and express the complex webs of social relationships that give human existence its emotional richness?

There are plenty of games that emphasize points-gathering and loot-collecting and level-raising. And it's good that there are such games.

But where are the games that support internally complex and logically consistent worlds filled with characters who act like people because they can perceive their environment and can form and attempt to satisfy emotional goals?

Well, I have some good news to report on one of these fronts. If the folks at Namaste have their way, NPCs who can express emotionally plausible behaviors may be standing just around the corner, waiting to meet us.

I was recently given the opportunity to see an early build of Namaste's "Storybricks" system in action. If any of what I've said so far is of interest to you, you should visit Namaste's Web site to see for yourself what they're doing.

In the meantime, here's a brief description: Storybricks is a set of systems integrated into a gameplay environment that allows NPCs to have emotional goals and states and to act on those goals and states in plausible ways through their relationships with players and with each other. (Note: this statement and all that follows here are purely my personal interpretation of Storybricks. For the official facts about Storybricks as it is developed, please refer to Namaste's site.)

Initially, Storybricks allows players to create characters who have particular motivations and goals ("drives"), some of which may come from a role-based template (Peasant, Shopkeeper, Guard, etc.), and others which are added to particular characters by their creator. All drives implemented in a Storybricks gameworld have in-game actions through which they can be expressed, as actions (along with objects and places) are all linked through the central AI system at the heart of a Storybricks gameworld. This allows characters to have plausible emotional goals and states based on their role, but also to have unique sets of interior motivations, some of which may actually oppose each other.

Cuthbert the Guard Captain, for example, may be designed to be motivated by duty and honor, but also by avarice and impatience. Under normal circumstances, all that a player may see of Cuthbert is his upholding the law... but what might happen if the player presents Cuthbert with a bribe?

Another possibility: Cuthbert the Guard Captain believes that order is important, and that it is necessary to defend the king in order to maintain order. But Cuthbert hates Baldwin the Noble... so how does Cuthbert behave when Baldwin usurps the throne and becomes king?

This ability for NPCs to have conflicting internal states immediately makes Storybrick's NPCs vastly more interesting as characters than the people-shaped automatons standing in for NPCs in today's MMORPGs.

Storybricks also allows NPCs, like player characters, to have relationships with multiple NPCs. By "relationships" I don't mean romantic alliances (in, say, the Mass Effect/Dragon Age sense). I mean relationships in the sense of holding various kinds of feelings in differing degrees toward players and other NPCs. Alfgar the Citizen may like you, while Edward the Brigand may despise you, and these NPCs would be able to act on these relationships in appropriate ways.

Further -- and approaching the "multifaction" concept -- perhaps Baldwin the Noble likes you, while Ethelred the Peasant likes Baldwin. If Ethelred observes that you have done some harm to Baldwin, this may change your relationship with Ethelred even if you don't directly do anything to Ethelred.

Taken to its full extent in a gameworld, this capability for second-order effects instantly propels MMORPGs toward becoming games that can tell interactive stories as good as those of their tabletop progenitors. Instead of forming (and farming) isolated factional standings with faceless groups, players in a gameworld designed around the Storybricks system swim in a chaotic sea of ever-shifting personal alliances and emnities, where actions over time can lead to consequences that are hard to predict. At last, computer-based NPCs may soon have what characters in tabletop RPGs have always had: the power to surprise.

People yield interesting stories not when they do what we expect of them, but when they shock us by revealing hitherto unknown aspects of themselves. We expect Sarah Connor to protect her child, but we don't expect her to do it by aggressively hunting down those whom she considers threats. We expect Sam Gamgee to care for his friend Frodo, but we don't expect him to become an action hero in taking on the horrible spider Shelob. The twist is plausible but unexpected, the result of putting a person with complex internal emotions in a stressful situation that reveals something of the character's true nature. And that depth of character is the engine behind every great story.

Storybricks is important -- perhaps the most important new technology in MMORPG development in many years -- because it provides the technological foundation for creating characters with emotional depth in computer-mediated gameworlds. This enables the crafting and emergence of captivating stories, a vital source of gameplay that's been absent from online persistent-world computer RPGs (including the few now allowing players to create quests).

It's always tempting to try to understand new things in terms of what we currently have. But there really hasn't been anything like Storybricks before. The possibilities it offers for experiencing a gameworld in which NPCs feel like people instead of quest pellet dispensers is tremendous.

Not everyone will want this, and that's fine. There are games available today for those who prefer to always know where to go and what to do, as there should be. But for those who have been wanting NPCs to play a more compelling role in building gameworlds as satisfying secondary realities, Namaste's Storybricks is by far the most exciting concept in a very long time.

I'll have more to say about the mechanics and internals of the Storybricks system in a later blog entry.

For now... here's looking forward to the rehumanization of roleplaying games.

The Prisoner's Dilemma and Multiplayer Game Design

One of the most fascinating things about massively multiplayer online roleplaying games (MMORPGs) is that, although these games are for the most part designed to promote competitive behavior, cooperation among players frequently emerges.

These games do usually provide some mechanism for four or five players to work together as a temporary "pick-up group," or for up to 100-200 players to form a somewhat longer-lasting organization as a "guild" or "corp." But these forms of cooperative play are always subsidiary to competitive behavior -- ultimately winning means doing better than the other guy.

And yet, in these games there can be remarkable examples of cooperative behavior, which seem to emerge despite the rules of the game that clearly favor looking out mostly for oneself. How does this happen? What are the features of these gameworlds that enable islands of cooperation to emerge out of a sea of advantage-taking?

Understanding this means taking a look at a simple game that allows two players to choose whether to cooperate with each other or to "defect" and take advantage of the other player. From this simple game -- with some tweaks -- it's possible to see how people behave, and from that behavior identify the factors that allow cooperation to become a viable strategy.

What follows is an essay on this game -- the "Prisoner's Dilemma" -- that I wrote in 1998. The principles haven't changed, though, so I thought I'd add that essay to this blog since it offers some useful insights into certain core game design concepts that are interesting to think about.

We begin with the surprising (if you think about it) observation: sometimes people choose to cooperate with each other.

THE EMERGENCE OF COOPERATION

Why do we cooperate with one another?

Don't we do better personally when we take advantage of someone who tries to cooperate with us?

How can we justify cooperating when others don't?

It would seem that cooperation is for suckers. And yet there are examples of cooperation all around us: no single person could build a skyscraper, or fight a war, or agree to an international treaty. For all of these things (and many others) to happen, sufficient numbers of self-interested individual human beings must agree to cooperate even when cheating is easy. But why does this happen?

In the late 1970s a researcher named Robert Axelrod was studying the question of how cooperation can emerge in an uncooperative world. Given that in many real-world situations the payoff for taking advantage of others is greater than the reward for cooperation, how can the observed prevalence of cooperative behavior be explained?

THE PRISONER'S DILEMMA

Axelrod began by considering the "Prisoner's Dilemma" experiment. This is a kind of thought game which examines the rewards and punishments for either cooperating or not. The story usually given runs like this:

Suppose you and an accomplice (whom you barely know) in some crime are arrested. The chief detective visits you. He says, "We know you and your pal did it. And you're both going to jail for it. But we always like to make sure, so you've got a choice. You can tell us what your pal did, or you can keep quiet. (And by the way, we're giving him this same choice you're getting.)"

"If you give us evidence against him, and he keeps quiet about you, then you get one year, and he spends six behind bars. If you keep quiet and he gives us the goods on you, you stay for six and he's out in one. If you both keep quiet, you both get three years; if you both turn each other in, you both get five years. So what'll it be?"

You must select one of two options -- you can either cooperate with your fellow prisoner (by keeping quiet) or defect (by providing evidence). You have no way of passing information between you, and you don't know him well enough to predict what he'll choose based on his personality. So which will you choose?

The table below describes what is called the "payoff matrix" of this classic formulation of the Prisoner's Dilemma:

Classic Prisoner's Dilemma

	Accomplice Cooperates	Accomplice Defects
You Cooperate	R = -3	S = -6
You Defect	T = -1	P = -5

Note: In this table the results are the payoffs to you. They are categorized as follows:

T: Temptation for defecting when the other party cooperates

S: "Sucker's payoff" for cooperating when the other party defects

R: Reward to both players for both cooperating

P: Punishment to both players for both defecting

Try it for yourself. Here's a link to an on-line version of the Prisoner's Dilemma.

Looking at the table in a purely rational way, it would seem that your best choice is to defect. The two possible results of your defection mean a chance for jail time of either 1 year (if your compatriot cooperates by keeping quiet about you) or 5 years (if he talks), for an average risk of 3 years. On the other hand, if you cooperate with your accomplice, you get 3 years if he cooperates too and 6 years if he defects, for an average risk of 4.5 years.

What's more, you have to assume that your accomplice is capable of thinking about this just like you did. Since he -- just like you -- is likely to conclude that defection is less risky, he'll probably defect... in which case you have even less incentive to cooperate.

And so you defect. And so does your accomplice. And so you both come away worse off than if you had cooperated with each other.

It appears that as long as the temptation to defect is greater than the reward for cooperating, there's no reason to cooperate. Yet it's clear that in the real world we do cooperate. So could there be some other factor at work, the addition of which to the Prisoner's Dilemma might make its outcomes more realistic?

THE ITERATED PRISONER'S DILEMMA

This is where Robert Axelrod enters the story. He considered a possibility others had suggested: What if instead of a single chance to cooperate or defect, you and an ally had numerous opportunities on an ongoing basis? Would that affect your choice on any single interaction?

Suppose you arrange to sell to a fence some stolen goods you regularly receive. To protect you both, it is agreed that while you are leaving the goods in one place, he will leave the payment in another place. At each exchange, each of you will have to decide whether to cooperate by leaving the goods or the money, or to defect by picking up the goods or the money without leaving anything of your own. Furthermore, each of you knows that this arrangement will continue until some unspecified time; neither of you knows when or if at some future date the exchanges will cease.

Assume that the payoff values remain the same as in the basic Prisoner's Dilemma. Does your strategy of defection in the earlier one-shot Prisoner's Dilemma change in an environment of repeated interactions with the same individual?

In 1979, Axelrod devised an ingenious way of testing this possibility (known as the "iterated" Prisoner's Dilemma). He contacted a number of persons in various fields -- mathematicians, experts in conflict resolution, philosophers -- explained the payoffs, and asked each of them to come up with a strategy for a player in an interated Prisoner's Dilemma tournament that could be encoded in a computer program.

No limitation was placed on strategy length. One strategy might be as simple as "always defect." Others might take into account their memory of what the other player had done on previous turns. "Always cooperate but with a random ten percent chance each encounter of defecting" would be still another strategy, and so on.

Axelrod collected 13 such strategies and encoded each of them in the form of a computer program. (He also added one strategy of his own, which randomly chose cooperation or defection on each turn.) He then began to pit each of the 14 strategies against every other strategy over 200 iterations. This would determine if any one strategy would prove to do well against all other strategies (as measured by average payoffs to that strategy).

The winner was the shortest strategy submitted. It consisted of four lines of BASIC code submitted by psychology and philosophy professor Anatol Rapaport of the University of Toronto in Ontario, Canada. In its entirety it consisted of the following: Cooperate on the first turn, then in all subsequent turns do whatever the other player did on its previous turn. This strategy was dubbed "Tit for Tat".

THE "ECOLOGICAL" PRISONER'S DILEMMA

After deriving some preliminary conclusions about this result, Axelrod tried an even more interesting innovation. In this new round, for which Axelrod publicly requested submissions from any source, there were 62 entrants plus one (RANDOM, from Axelrod) for a total of 63. All these strategies were then pitted against one another in a giant free-for-all tournament.

The winner was Tit for Tat, submitted again by Rapaport. (But, oddly, by no one else.) Again, it had the highest average score of payoffs.

Axelrod scored the results of the tournament as a 63x63 matrix which showed how each strategy had fared against every other strategy. An analysis of the strategies played revealed that there were six strategies that best represented all the others. Since the 63x63 matrix showed how each strategy played against all others, Axelrod was able to calculate the results of six hypothetical "replays" in which one of the six representative strategies was initially dominant.

Tit for Tat scored first in five of the six replays, and scored second in the sixth.

Then came the cleverest innovation yet. Suppose, Axelrod's notion had it, we performed a hypothetical replay in which all strategies were pitted against each other, and in each turn the "loser" was replaced by a copy of the "winning" strategy, thus altering the population of players? Each strategy's score -- already known from the 63x63 matrix -- could treated as a measure of "fitness" against other strategies in a kind of "ecological" tournament.

The results left no doubt. The lowest-ranked strategies, which tended to be "not-nice" (in other words, which tried to defect occasionally to see what they could get away with), were extinct within 200 rounds. Only one not-nice strategy (which had been ranked eighth in the original 63x63 competition) lasted past 400 rounds, but by then the population of surviving strategies consisted only of those which replied to defections with immediate retaliation. Because the not-nice strategy had no more strategies which could be taken advantage of, it began a precipitous decline. By the thousandth round, it too was virtually eliminated.

And the winning strategy? Once again it was Tit for Tat, which was not only the most prevalent strategy at the end of 1000 rounds, but the strategy with the highest rate of growth. Tit for Tat was not merely successful, it was robust -- it did well in all kinds of environments.

Why did Tit for Tat do so well? How could such a simple strategy perform so capably in such a broad mix of more complex strategies? More to the essential point, how could Tit for Tat do so well even when surrounded by strategies which depended on defecting and so would supposedly tend to earn better payoffs? It appeared that a strategy which cooperated by default was able to not only survive but actually thrive amidst a sea of defectors.

In other words, cooperation evolved over time in a world dominated by uncooperative players. If this simulation bore any relation to the real world of humans, there could be some important lessons in it for us.

HOW COOPERATION WORKS

What actual, emotion-driven human beings do with individual choices of cooperation or defection is, of course, unpredictable. But in general, rational players will tend to make similar choices. This allows those interested in human behavior to work out some mathematical predictions of behavior.

In this case, it turns out that a careful choice of the four payoffs for cooperation or defection results in being able to say that there exists a rational choice of cooperation, even in the midst of a majority of defectors. Specifically, Axelrod found that if just four conditions were met, cooperation can be the most rational choice -- even in a population consisting almost entirely of defectors. These are the "world" conditions that affect whether a gameworld such as a MMORPG will tend to encourage cooperative behavior to emerge or not.

First, the players must be able to recognize one another. Anonymity, becauses it decreases the penalty for defection in an environment of iterated interactions, tends to work against the evolution of a population of cooperators. This has a direct impact on MMORPGs, in which players are somewhat recognizable by the names they choose for their characters, but because they can play multiple characters on multiple servers, players are for the most part anonymous to each other. (This is why the recent attempt by Blizzard to switch to a "Real Names" system in their online game forum had a chance of promoting more cooperative behaviors there, instead of the flaming and hyperemotional verbal abuse -- "defection" behavior -- that characterizes game forums currently. It's unfortunate that Blizzard's concept was shouted down and not given a chance to be implemented; it would have been useful to see whether changing the rules of the "world" to minimize anonymity would, as suggested here, have encouraged more cooperative discussion.)

Second, the total number of potential opportunities for interaction must be unknown to each player. It is the uncertainty preventing players from calculating just how much defection they can get away with that decreases the long-term reward for defection. If you don't know when your final interaction will be, and thus can't plan to defect on that turn, you must take into your calculations the fact that what you do on this interaction will affect the response to you on the next interaction. This creates an incentive to cooperate.

Third, the payoff for mutual cooperation (that is, both players cooperate with each other) in each interaction must be greater than the average payoff of a cooperation-defection (the payoff to the defector plus the sucker's payoff divided by 2). In mathematical terms, this is the condition in which R > (P + S) / 2.

Fourth and last, there must be a certain minimum proportion of cooperating players in the population... and here was one of the greatest surprises. Axelrod calculated that -- amazingly -- if all the preceding conditions are met, and there is a high probability that players which have interacted before will do so again (specifically, ninety percent), then cooperation can eventually evolve to include the entire population if only five percent of the total initial population consists of cooperators. It's reasonable to expect that there must be enough cooperators so that they can create a sort of island of trust in a sea of defection. What's surprising is that so few are necessary.

HOW TIT FOR TAT WORKS

Axelrod concluded that Tit for Tat succeeded not by trying to do the absolute best for itself in every transaction, but by trying to maximize the sum of its own and the other player's reward in all transactions combined. In other words, Tit for Tat did well for itself because the effect of its strategy was to allow every player with whom it interacted to do well.

An intriguing aspect of this is found in the raw scores of the various Prisoner's Dilemma tournaments. Looking at the numbers, it quickly becomes obvious that in individual encounters Tit for Tat never did better than strategies which were more "aggressive" (i.e., defected more often) or -- interestingly -- strategies which were more "forgiving" (i.e., didn't always respond immediately to a defection with a defection of its own). In individual transactions, Tit for Tat's numbers were solidly middle-of-the-road.

But over iterated transactions the consequences of defection began to outweigh the benefits. As more players started to resemble Tit for Tat, which always retaliated immediately to a defection but was always open to cooperation, the long-term payoff for defection dropped. Soon there were no players who could be taken advantage of by a defecting strategy. Meanwhile, the Tit for Tat-like cooperating strategies were busy cooperating. Their long-term payoffs were never outstanding... just better than those of the defectors.

THE PRINCIPLES OF TIT FOR TAT

Axelrod distilled several principles from his observation of how well Tit for Tat did against various defecting and cooperating players. Not only do these explain how Tit for Tat did better than even other cooperating players, they have useful implications for real world human interactions.

Be Nice
Don't be the first to defect. Assume cooperativeness on the part of others. If you go into an interaction assuming that you're going to get ripped off, then you might as well try to take advantage of the other person. But if instead the other person turns out to have been willing to cooperate with you, you've just missed a chance for both of you to do well.

Be Forgiving
Don't overreact. When taken advantage of, retaliate once, then stop. Meeting one defection with a harsh response can create a series of echoing mutual defections that prevent cooperation from ever occurring.

Be Provocable
When a defection occurs, always respond in kind. Don't be too forgiving. In the instructions for the second tournament, Axelrod included the two lessons ("be nice" and "be forgiving") that he had drawn from the first tournament. Several of those who submitted second tournament strategies concluded that being forgiving was essential to the evolution of cooperation. Their strategies tended to let a few defections slide. In effect, these strategies tried to elicit cooperation by allowing not-nice players to take advantage of them without penalty. But the actual result was to encourage not-nice strategies to keep defecting. A lesser penalty for defecting made that lack of cooperation more valuable, so cooperation became less valuable. A better choice is to always defect when provoked.

Be Clear
Respond in kind immediately. Strategies that tried to be clever tended to appear unresponsive, which elicited defection. (If your attempts to cooperate are ignored, then you might as well defect to get as much as you can while you can.) Cooperation should meet with immediate cooperation, and a defection should be met with an immediate defection.

THE IMPLICATIONS OF TIT FOR TAT

What if anything does this mean for actual human interactions? There is a strong suggestion that the behaviors that elicit cooperation in this restricted world of the Prisoner's Dilemma do indeed carry over to our real world.

One finding particularly worthy of note was the evidence that too much forgiveness actually works against the evolution of cooperation. The notion of "tolerance" so trendy today turns out to be an invitation to defection, rather than the means to a better society as its proponents claim. While being "nice" is necessary to evoke cooperation in others, it's not enough. Bad behavior requires a proportionate response, or the result will be more bad behavior.

This applies as well to criminal justice. There is a vocal minority today calling for a reduced emphasis on incarceration as societal retribution, and a commensurate greater attention given to rehabilitation. Without disputing the goodness of the impulse, the success of Tit for Tat suggests that it's a bad idea. If an individual member of a society defects (commits a crime), that defection should provoke an immediate retaliation from society. Not an overreaction, but some equivalent reaction nonetheless appears necessary in order to elicit future cooperation from that individual, and to demonstrate to other players the value of cooperation and the price of defection.

The ancient policy of lex talionis -- "an eye for an eye, and a tooth for a tooth" -- may be the wisest policy after all.

THE FUTURE OF COOPERATION

For cooperation to evolve, there have to be enough cooperators who interact with one another on a sufficiently regular basis. Such "islands of cooperation," once established, can grow... but too small an island will sink beneath the waves of defectors.

One critical factor not addressed by any other commentator on Axelrod's work I've seen concerns being able to recognize other players. The Tit for Tat strategy depends on remembering what another player did on the immediately previous turn. But if the other player is anonymous, or is encountered only once, it's impossible to associate a history with that player. This leads either to cooperating with an unknown (and possibly being taken advantage of repeatedly) or defecting from lack of trust (and possibly missing an opportunity to create an environment of cooperation).

This takes on added relevance today. Not only are the streets and highways filled with persons whom we'll never see again -- and who thus have no qualms about defecting (in other words, driving like jerks) -- we are spending more time surfing the Web as anonymous entities than we once did sitting in the back yard talking with our neighbors. Our contacts with other players in the game of trust/don't-trust are more likely to be brief encounters with strangers: ephemeral and anonymous. Under such conditions, not only is it unlikely that new clusters of cooperative behavior will evolve, but even the maintenance of what cooperation there is becomes difficult. Trust breaks down.

How long can such a state of affairs last?

Can we find a way to balance legitimate privacy interests with the guaranteed recognition required for cooperation to emerge? Or is anonymity and the Hobbesian, everyone-out-for-himself world imposed by anonymity inevitable?

---

". . . perhaps the chief thesis of the book on The Fatal Conceit . . . is that the basic morals of property and honesty, which created our civilization and the modern numbers of mankind, was the outcome of a process of selective evolution, in the course of which always those practices prevailed, which allowed the groups which adopted them to multiply most rapidly (mostly at their periphery among people who already profited from them without yet having fully adopted them)."
-- letter from Friedrich A. Hayek to Julian Simon, Nov. 6, 1981.

MMORPGs: The Evolutionary Dead End

Brian "Psychochild" Green, in a thoughtful post (MMOs Change Over Time) on his blog, asks the question: Do you enjoy your favorite MMORPG more or less because of the changes that have been applied to it?

Unhappily, my MMORPG experiences since EQ have led me to precisely the opposite conclusion: as a gamer, I’m just not interested in playing any of these games any more because my perception is that they have ceased to change in any meaningful way.

I find it terrifically frustrating to consider the fact that these games, as forms of virtual worlds, could be about anything... and yet the best that their designers today can do is to copy the mechanics that have become conventions of the genre. I recently helped beta test an online game based on a well-known IP, and I was shocked to see that many of the mechanics, far from being designed fresh to fit the IP, were not merely copied from existing MMORPGs -- they were actually called by exactly the same names: root, buff, aggro. But this game’s designers are not alone in seeming to believe that these arbitrary mechanics have become non-negotiable requirements that simply have to be copied wholesale into the core design. So does everyone else.

Even at the next level up, every MMORPG designer seems obsessively fixated on delivering only one kind of entertainment experience: kill mobs and take their stuff. Ask today’s typical MMORPG player to define “MMORPG,” and that’s how they’ll describe the whole genre: combat and loot.

Change? What change?

When I see game after game aping their predecessors (while ads proclaim them to be “revolutionary”), and then think about the possibilities of MMORPG play that are bounded only by human imagination... yes. It’s infuriating.

Why are so many designers willing to put up with such limits to creative expression?

Why are so many gamers willing to tolerate such an unnecessary lack of choice in entertainment experiences?

From my perspective, the problem with MMORPGs is not that there is too much change -- it’s that the genre has already gone into creative rigor mortis long before its time. Whatever changes we perceive are merely various stages of decay and rot.

At this point I’m about ready to declare that monolithic MMORPGs are the shambling dead, and that social games on networks like FaceBook will soon rule the Earth as our new overlords.

Is there any cause to think I’m wrong in that forecast? Is there any hope for the MMORPG?

An Alternative to Aggro

I'm on record as opposing the mindless cloning of the "aggro" mechanic into new MMORPGs.

The expense of real-time collision detection was why the aggro hack was invented. Without it, NPCs could simply walk through burly front-line player characters in order to get at the chewy nougat center of the weaker characters behind them. So "aggro" was created as a quick and dirty gameplay mechanic that would allow front-line players to get NPCs to focus on them. It solved a problem by adding active gameplay content -- what could go wrong?

What went wrong was that the concept of the "fighter" was transmogrified into the tank role. Once that decision was made, it seemed perfectly natural to convert mages into damage-dealers and clerics into healers with crowd-control and buff/debuff support abilities.

And then other developers copied this mechanic for their games. They even "improved" on it to the point that aggro management has come to dominate not only character class/ability designs, it's now the default model for the combat play experience. A PvE fight in one of today's MMORPGs is not about smart tactical use of the local gameworld environment; it's about using character skills (like /taunt) that were explicitly created to "manage aggro."

So how does implementing this system in every new MMORPG make sense now that the technical limitations that led to that mechanic no longer exist? I believe it doesn't. With today's technology, proper collision detection and, more importantly, better combat AI can be implemented. The aggro mechanic survives now only through cargo cult game design, copying it because other developers have copies it, then rationalizing that decision by pointing to gamers who -- because they've been offered nothing else -- now believe and assert (loudly) that it's mandatory.

It's not. It's a convention, nothing more.

All that said, opposing something is easy. If I'm against aggro, what am I for? If I favor getting rid of it, what should replace it?

Until now I haven't really taken the time to suggest an alternative, which I think is a necessary element of constructive criticism. So this essay is an attempt to draft such an alternative. I don't think it's a complete solution, and I know it's not perfect. It's just one possible starting point.

AGGRO MANAGEMENT IS NOT COMBAT

"Aggro," for those new to this issue, is a combat AI mechanic used in most online games (MMORPGs in particular) to allow non-player characters (NPCs) to decide which player character to attack.

Aggro (defined as "hate" on Wikipedia) works basically like this: when an NPC needs to choose which character should be attacked next from a group of player characters, it consults an internal list of "aggression" values. For each player character in the group, the attacking NPC calculates an aggression value based on various qualities of and/or actions by that PC. It then aims its next attack at the PC with the highest aggression value. That player character is then said to have "aggro'ed" the attacking NPC.

The natural outgrowth of this aggro concept is that players will want to be able to do things to "manage" the aggro of attacking NPCs. The "tank" role comes first, because it's obvious that if players can control who gets aggro'ed, they'll want that aggro to stick to the character with the best defenses, leaving weaker characters unharmed and free to do other things like apply damage to the NPC or heal the tank. Group combat, then, gets defined in terms of role-based aggro management -- carefully choosing and timing actions to do as much harm to the enemy or as much help to one's group as possible without shifting aggro away from the tank PC.

My question is: when did people start confusing "managing aggro" with having an interesting tactical combat experience?

What in the world does "managing aggro" have to do with letting a group of players make intelligent and cooperative use of a rich set of environmental phenomena to achieve tactical superiority? How does the artificial and arbitrary gameplay of "aggro management" make any use whatsoever of the IP, the setting, on which a MMORPG is based? How is "performing actions intended to control the internal aggro calculation of an NPC" anything like "combat?"

If people think they like the aggro game, that's fine. People are free to like what they like. But the fact that some people like one particular solution to a game design question does not imply that it's the only possible solution. As gamers, we should be expecting game developers to look for more enjoyable solutions to game design questions, to try to create new and better solutions, not to merely clone mechanics that might work for some other gameworld. Importing the "aggro" mechanic from ground-based fantasy combat games into new games -- including even science fiction games -- presents the appearance of laziness.

So instead of aggro, I'd like to propose an alternative approach to NPC combat decision-making, which for lack of a better name I'm calling "cultural tactics."

CULTURAL TACTICS

Cultural tactics assumes the existence of a story. When there's a background story providing opportunities for narrative development, that story can and should be used to inform the behaviors of intelligent NPCs.

This is done by assigning cultural qualities to every non-player aggressor (NPA), such a non-player character or a tank or a spaceship. All individual NPAs will be defined as belonging to a primary culture. While some individual variation may be possible, those cultural qualities will tend to determine the choices that an individual NPA makes in any situation. Those choices may be about combat actions, or they may be about diplomatic actions or anything else the NPA is able to do. All possible forms of interaction with player characters would be produced by a goal-generating system whose rules would take as inputs the cultural attributes of the decision-making NPA, unique (probably randomized) attributes of the NPA, relevant aspects of the local environment (including perceptions of player character resources), and a desired goal state.

What's important to see here is what's not listed as an input to this decision-making system: player character actions. Getting good combat behavior out of an NPA actor does not require allowing players to directly manipulate that decision-making process. It might benefit from it in extended interactions, such as strategic-level conflict, but the typical short tactical fight does not require NPAs to use player actions as decision-making inputs.

As for offering that capability because it provides gameplay (e.g., aggro management), that's true, it does... but when that gameplay takes over, completely shifting the attention of players from interacting with elements of the gameworld to the manipulation of arbitrary rules that have nothing whatsoever to do with combat, then if that mechanic isn't required, it does not need to be implemented.

Cultural tactics would allow NPAs to have an appropriate and interesting degree of autonomy. Instead of being the pawns of players in gameplay that distracts from the gameworld, NPAs whose actions are based on attributes of the story-based culture to which they belong would choose combat targets in a way that tells us something interesting about who they are.

In a space game, for example, an NPA from a mindlessly aggressive culture might simply target the nearest ship. (Maneuvering into and out of an NPA enemy's range would thus be a viable combat tactic for groups of player characters up against ships commanded by members of such cultures.) An NPA honor culture might always try to target and destroy the strongest (however that's defined) player ship; a ship commanded by an NPA from a victory-at-any-cost culture might seek to destroy the weakest ships first.

A nasty pirate might go after the ship that appears to have the most/best weapons. A daring privateer could be culturally inclined to attack the ship that might carry the most interesting advanced technology. Members of a cybernetically enhanced culture that shares a hive-mind (you know who you are!) might simply attack randomly -- they're big enough not to care what the typical opponent looks like -- or they might look for whichever ship acted like the leader in order to disable the target group's command hierarchy.

LIFE AFTER AGGRO

The point behind all these examples is to show that aggro is irrelevant. Aggro is not necessary for non-player aggressors to be able to make interesting choices about whom to target. And getting rid of aggro serves the useful function of eliminating the bizarre focus of players on withholding their gameplay actions in order to avoid being noticed by a vastly stronger NPA foe, who then hammers their characters into pulp most instantly.

Without being forced to play the Aggro Management Game, players are free to engage in actual combat-relevant tactical decision-making: should I try to maneuver to my target's rear facing, or would it be better to try an alpha strike now? Can I use the particles in the nearby nebula in some interesting way? Is there something cool I can do with one of my weapons right now instead of having to hold my fire because it might make an NPA mad at me?

In summary, if the aggro mechanic works for other games, fine, but it is not required for every game. It can be discarded with no loss, and with considerable gain, since not having to withhold one's combat actions for fear of attracting damage-dealing attention allows more players to participate more frequently in the fun.

It also means they don't have to have all of their actions squeezed into the subset considered appropriate by some developer for a particular and narrowly-defined combat role like "tank" or "crowd control." That permits players much more freedom to play the combat game in the way that's most enjoyable to them.

Roles are still possible; the beauty of getting rid of aggro is that those roles can then be defined in ways that make more sense for the setting of a particular MMORPG. And even without aggro, NPAs are fully capable of selecting their targets in fun and meaningful ways.

If all that is accepted, then yes, I find it disappointing that MMORPG designers continue to clone the aggro mechanic for their games. If they really believe it's necessary, that's a shame. If they don't, it's a wasted opportunity to do something better. Either way, the concept of "aggro" is long overdue for retirement.

CONCLUSION

I'm under no illusion at this point that the producers/designers of any MMORPG under development will read this and think, "Say, you know, he has a point -- right, everybody stop what you're doing; we're going to re-do combat even if it means shipping four months later than planned!" I assume that the aggro mechanic and its tank/DPS/support handmaidens will be the default choice for the core combat model of every new MMORPG for years to come.

The point of proposing and explaining this alternative is therefore not to try to change the minds of big-studio game designers who clone MMORPG conventions as a risk-reduction technique, but to suggest to the newcomers that there's room for innovation here. By all means, look closely at the aggro management model of combat, analyze it, consider its first-order features and second-order effects within the context of your other game design choices, and use it if it makes sense for you... but also feel free to go with something else if aggro management doesn't feel right for your game.

Big-budget games that try to play it safe don't always succeed. So why not take a few carefully-considered risks and try something different, such as deep-sixing aggro in favor of a combat model that's actually related to combat? It's not like your odds of success will be much worse than those of the play-it-safe developer. :)

In fact, given the wealth of conventional MMORPGs available currently, this might be exactly the right time to break away from the pack in a few key areas of design.

Why not start with aggro?

The Archetypal Origins of MMORPG Group-Combat Roles

In thinking about designing character classes in a MMORPG around the group-combat roles of tank/DPS/support, one of the things that's been lost is the relationship of these roles to distinct playstyles.

Each of these "holy trinity" roles is based on one of the basic functional classes of the original Dungeons & Dragons: fighter, mage, and cleric (healer) respectively. But we've forgotten that all of these roles were distilled from archetypes in fantasy fiction and heroic myths... and those archetypes were used to dramatize real differences between how people see the world.

So I'd like to take a look back at D&D to show how its classes, on which the roles and classes of most modern MMORPGs are based, are actually derived from mythical archetypes which recognize that people have distinctively different worldviews. And I'll then show how that understanding of gameplay roles as archetypes points the way toward designing better gameplay around those roles.

Back to the Past

The effectiveness of each of D&D's four basic types was determined in large part by one character attribute -- a different attribute for each type. I contend that this attribute was in fact a gameplay-driven abstraction of an archetypal pattern of behavior of characters in fantasy literature, which was based on heroic mythology, which in turn was a way of highlighting the behavioral styles of real people and their distinctively different ways of understanding and living in the world.

The correspondences between the four fundamental character classes and their controlling attributes are as follows:

Fighter	--	Strength
Mage	--	Intelligence
Cleric	--	Wisdom
Thief	--	Dexterity

(Constitution and Charisma were the two other primary attributes of characters in D&D, but they were not used as defining/controlling attributes for any class.)

It's easy to see how representing each of these four attributes with a number leads immediately to gameplay. But it's important to also see that each of these four attributes is an abstraction of a different personality style, and that part of the fun of playing a character whose abilities are determined by their "class" is playing with the stereotypical (but fundamentally realistic) patterns of behavior we all recognize in those styles.

A Question of Style

Strength, Intelligence, Wisdom, and Dexterity each signify a different way of understanding -- and thus interacting with -- the world.

Strength represents the preference for attacking problems head-on, for directly pitting force against force. The archetypal Fighter prefers to keep things simple -- follow the rules, do your job, be compensated fairly, enjoy the rewards of success.

Intelligence is the hallmark of the Mage, whose prefers to solve problems by understanding them and applying the correct tool in the correct way to their resolution. Knowledge and understanding, represented in fantasy literature by mastery of the arcane arts, are the mage's preferred way of approaching the world.

Wisdom is the Cleric's goal. Wisdom, perhaps best understood as intuitively living in harmony with the world, wants all the beings in that world to live in harmony with their nature and with the overarching principles of rightness. The ability to heal others in both body and soul is a natural interest of this archetype.

Dexterity in any situation is the distinguishing feature of characters representing the Thief. Not only does this permit them to use tools with surpassing skill, it also defines a particular kind of worldview in which plans and rules are unnecessary. They're not nearly as much fun as making things up as you go and counting on your nimbleness and adaptability to get you out of any trouble.

By closely keying each of the abilities associated with a class to the archetypal features of the character attribute that defines that class, D&D accomplished two things.

First, it made roleplaying easy and fun. In a purely utilitarian sense, having characters with distinctively different kinds of abilities made the whole group better able to deal with different kinds of problems that could be encountered in the gameworld. But perhaps more importantly for a roleplaying game, when you played a mage character, the abilities of that class encouraged you and helped you to play that character in a way that "felt" like pretending to be an exemplar of that kind of personality style. Recognizing the distinct personal style that was represented by the class helped one to enjoy playing a character of that class.

Where We Are Now

That brings us back to today. In the decades-long process of transitioning from Strength/Intelligence/Wisdom/Dexterity to Fighter/Mage/Cleric/Thief, and thence to tank/DPS/support, we've lost several important things.

Most obvious is the loss of the Thief class, which represents the Rogue archetype. While letting players express this kind of "loose cannon" archetypal behavior through their character abilities might appear to be problematic in a PvP setting, eliminating it means losing access to both the fun of playing this risk-taking kind of character as well as dexterity-focused problem-solving techniques that can get your group out of a jam when nothing else will. What would Star Wars have been without Han Solo?

There is a more important loss, however, which is the understanding that these roles were once archetypal. Without that understanding, the implementations of these roles no longer link as strongly to the mythic archetypes. They can still be fun in a surface-level, number-crunching, mechanical kind of way -- tank attracts aggro, mage does damage, support class provides healing and crowd-control. But the deep joy of playing a "role" in the artistic, literary sense of expressing the behavior patterns of an archetypal pattern represented over several millennia of human mythology, is gone.

Into the Future

MMORPG developers can retrieve some of this fun by recognizing the human archetypes on which roles and classes are based, and by consciously designing the character abilities and gameplay content of their gameworld to once again express those archetypal styles of understanding and interacting with the world.

Tank/Fighter types and the game content associated with that style can be focused on the direct application of force, on collecting loot and badges, on simple leveling, and generally on the enjoyment of knowing the basic rules of play and following them for profit.

DPS/Mage characters and the content created for them can be developed to apply knowledge and perception to solving problems. The character's level of capability should be affected by how much the character knows about the gameworld and how well they're able to integrate that knowledge to respond to novel situations.

Support/Cleric characters and their content can be designed to highlight the importance to this archetype of wisdom in resolving problems of body and soul. Beyond healing and crowd control, this role could be much more interesting to play with the restoration of the understanding that it's based on an archetypal representation of the personality style that cares about other people.

And bring back the Rogue role! :)

Conclusion

The mythological bases of the tank/DPS/support roles prominent in today's MMORPGs appear to have been forgotten by their designers. While this is fine for a purely mechanical, numbers-based, follow-the-arbitrary-rules kind of game, it should be understood that the price tag for this approach to MMORPG design is high: players lose the joy of expressing their in-game actions as heroically distinctive characters. It's just about doing a job.

Archetypes link player behaviors to the heroic myths and legends of human history. The archetypes (along, of course, with the game's setting) should drive the abilities created, rather than abilities being generated without thought for consistency with playstyles. Recognizable patterns of behavior and diversity of problem-solving modes are directly connected to perceiving differences among playstyles as reflections of archetypal preferences. When roles aren't understood as reflecting distinctive playstyles, the abilities created for those roles feel generic; they're not as much fun.

Abilities should instead be designed to help players express archetypal behaviors. By returning to the roots of character ability design, in which the things that characters can be good at are structured around the fundamentally distinct attributes of legendary heroes, MMORPG designers can restore to players the pleasure of heroic play beyond mere number-crunching.

And once character abilities are focused on playstyles, the roles derived from those abilities will feel vastly more satisfying. The better that game designers can tap into those fundamental heroic archetypes, which haven't changed since the days of Homer's Iliad, the better their game will resonate with gamers looking for a heroic experience.

Breeding Better NPC Opponents

During the course of a discussion on specific gameplay mechanics that could be used to define the challenge level of NPC opponents in a space combat game, one of the ideas involved eliminating NPC ships that don't perform well.

That got me thinking -- how interesting would it be to work out a more-or-less evolutionary model for letting NPC opponents get better over time? What if NPC ships themselves could get better by repeated interactions?

What follows is a first cut at a system for letting NPC ships "breed" themselves into combat excellence. It's not intended to be The Perfect Solution -- it's just some starter ideas to beat up on to see if the notion might have some merit.

It's In Your Genes

The first step is to define the "genes" of NPC ships. According to my naïve understanding, these would be fields enumerating the kinds of decisions that an NPC ship could make, where each decision mode could have several possible values corresponding to decisions of each kind.

So here's one possible set of NPC ship genes:

• maneuver
• 1 = maintain close range
• 2 = kite (circle opponent at medium range)
• 3 = maintain long range
• 4 = hide behind cover between attacks
• 5 = randomly jink
• offense
• 1 = fire any weapon as soon as it's ready
• 2 = fire when 2 or more weapons are ready
• 3 = fire when 3 or more weapons are ready
• 4 = fire only when facing opponent's weakest shield
• 5 = fire only when facing opponent's strongest shield
• aggressiveness
• 1 = maximize power to life support
• 2 = maximize power to auxiliary systems
• 3 = maximize power to engines
• 4 = maximize power to shields
• 5 = maximize power to weapons
• mercy
• 1 = allow opponent to run away
• 2 = allow opponent to surrender
• 3 = no quarter asked or given - maneuver to remain engaged while checking self_preservation
• defensive_maneuver
• 1 = turn to keep all shields evenly charged
• 2 = turn to keep forward shield overcharged and facing strongest opponent
• 3 = turn to keep weakest shield away from strongest opponent
• targeting_focus
• 1 = personal_targeting only
• 2 = if grouped and internal damage = 0%, group_targeting, else personal_targeting
• 3 = if grouped and internal damage < 75%, group_targeting, else personal_targeting
• 4 = group_targeting only
• personal_targeting
• 1 = target strongest opponent
• 2 = target weakest opponent
• 3 = target nearest opponent
• group_targeting
• 1 = target same shield of same opponent targeted by nearest allied ship
• 2 = target weakest opponent firing at weakest group member
• 3 = target strongest opponent firing at weakest group member
• 4 = target nearest opponent firing at weakest group member
• targeting_focus_updates
• 1 = review targeting every ten seconds
• 2 = review targeting every thirty seconds
• 3 = review targeting every minute
• 4 = review targeting if internal damage > 25%
• 5 = never change active target
• self_preservation
• 1 = fight until internal damage > 25%, then take defensive_action
• 2 = fight until internal damage > 75%, then take defensive_action
• 3 = fight until victory or destruction
• defensive_action
• 1 = run
• 2 = surrender
• crew_morale (not really a gene... exactly)
• 1 = 25% bonus to effectiveness
• 2 = 50% bonus to effectiveness
• 3 = 75% bonus to effectiveness
• 4 = 100% bonus to effectiveness

What other genes would be appropriate/useful/fun?

Code Is Law

The next step is to define the code that uses these genes to select the "fittest" NPC ships for future generations.

Since NPC ships of different kinds will always need to actively exist in the gameworld, it's not possible to follow the usual GA approach of performing all genetic actions on the entire current population in clear-cut "generations." Instead, breeding new ships will have to occur in an asynchronous way, and the only way to determine the population's characteristics will be to take a snapshot at some arbitrary moment in time.

Some quick sample pseudocode:

#POOL = 10000 
#MUTATION_RATE = 95

fight():
  // do combat stuff according to genetic predispositions with some random variance as appropriate
  // for example, "close in" maneuvering would move ship randomly to remain near the target ship

  if NPC ship survived the fight
    increment "winner" field in ship table for this ship

  if crew_morale gene < 4
    increment crew_morale gene by 1
  else if crew_morale gene > 1
    decrement crew_morale gene by 1

spawn_new_ship(type, tier):
  select into temp table the #POOL ships from the desired type/tier table with the largest "winner" field value
  randomly select first_ship from temp table

  if random > #MUTATION_RATE%
    new_ship = mutation(first_ship)
  else
    randomly select second_ship from temp table

  new_ship = crossover(first_ship, second_ship)
  add new_ship to NPC ship table with "winner" field value set to 0

  spawn new_ship

mutation(ship):
  create newship

  randomly pick one gene of "ship"
  randomly change the selected gene's current value to a different value

  return(newship)

crossover(ship1, ship2):
  create newship, newship1, newship2

  randomly select number of genes to swap (any number from 1 to 1/2 [rounded down] of total number of genes)
  randomly select specific genes to swap

  newship1 = selected genes from ship1 + selected genes from ship2
  newship2 = unselected genes from ship1 + unselected genes from ship2
  newship = randomly pick either newship1 or newship2 return(newship)

Questions On Genetics

Naturally there'll be questions about this. :)

I have some myself. For example, how would the usual "culling" function work in an asynchronous breeding model? Would it happen naturally as a side-effect of allowing only the most successful #POOL of ships to "breed" new ships? (I suspect so, but I'm open to other opinions.)

Is 10,000 ships too small a number for a breeding pool given the number of fights with NPC ships that are likely in a normal gameplay session? What's the right number to create a fitness metric that leads to a satisfying rate for breeding better (not just different) ships? Should this number be one thing when the game starts, then change to something else later?

Is a 5% mutation rate too high or too low? Should this number be one thing when a new game is started and change later?

Would this system eventually lead to too few different types of ships? How long would it take to reach that point? How could this system be tweaked to avoid this problem?

At what point should the breeding process be stopped? When will opponent ships be "good enough?" Could they ever become "too good?"

Application of an NPC Opponent Breeding Program

Having considered just the core mechanics of an "opponent breeding program," it's also true that while a gameplay mechanic might be cool on its own merits, in an actual game it needs to be fun for anyone who's likely to experience it. So let's consider now some of the meta-level design possibilities for how to make a "ship-breeder" mechanic fun for most players who engage in ship combat.

One way could be to impose a rule that new kinds of ships get created through breeding only 5% of the time. In other words, most of the time when the game needs to spawn a new hostile NPC ship, it can randomly instance a pre-defined ship of the appropriate tier, win/loss ratio, and (perhaps) type from the current table of ships.

This would satisfy the usual "appropriate for your ability level" requirement for spawning opponents. Note, however, that this is still pretty simplistic. For one thing, it assumes that only one opponent is being spawned, rather than considering how multiple opponents could produce a desired challenge level. And it doesn't address at all the issue that spawning a new kind of ship through breeding might sometimes produce a ship that's either bizarrely stupid or unexpectedly clever -- that's a problem if one of the high-level design goals for challenges is that they always be close to the ability level of the player for whom those challenges are being spawned.

Another possible issue with the ship-breeding mechanic is that it might be too good. Over a long time the population of "successful" ships currently stored in the ships table might become much larger than the number of average- or poor-performing ships. At that point the only "dumb" ships (i.e., really easy challenges) that players ever see would be the 5% spawned by genetic chance (and a small number of those might turn out to be really smart). So if most ships at various tiers/types are generally "smart" (in other words, good opponents at any challenge level), would that be a problem? Or a win?

What other issues should be considered when thinking about how to actually include a genetic mechanic for breeding better opponents?

In My Ideal Star Trek MMORPG....

The question came up on the official Star Trek Online forum of what our "ideal Star Trek Online experience" would look like.

After some thought, I realized that I did, in fact, have some fairly specific items on my wish list for this particular online gameworld. This essay is an enhanced version of the items I noted in that original list.

Before I go any further, it's important for those reading this to understand that the things I ask for describe only the gameplay experience I consider personally optimal. They're not necessarily what I think the play experience should be for all players... though I do believe -- and numerous comments on the STO forum confirm -- that I'm not the only person who'd enjoy playing the Star Trek MMORPG whose key features are outlined below.

So, that being said: in my ideal Star Trek MMORPG, I'd like to be able to log in and enjoy gameplay that engages my head and my heart as much as my hands.

In my ideal Star Trek MMORPG, the iconic elements of Star Trek would be the starting point for developing gameplay. Conventional MMORPG mechanics (such as the class/level model of character advancement or the combat-centric tank/DPS/support+aggro roles) would under no circumstances be mindlessly cloned from other games and simply renamed with Star Trek terms. Let the mechanics of this game be inspired by what's uniquely fun about Star Trek. If it's fun gameplay, then it's fun gameplay regardless of whether other games do it or not.

In my ideal Star Trek MMORPG, the game would launch with a balance of combat and non-combat content, and the developers would commit to sustaining that balance throughout the lifespan of the game in all of the patches and expansions released. The gameworld would be designed to be experienced through the functional disciplines of Science/Medical, Tactical/Security, Engineering/Ops, and Command/Helm (and their non-Starfleet faction equivalents). There would always be roughly equal amounts of content available for every one of these four distinctively Star Trek modes of play throughout the entire advancement path of a character.

In my ideal Star Trek MMORPG, the rules of play for Starfleet-faction characters would actively promote the emergence of cooperative, creative, perceptive, thoughtful, and supportive behaviors in my fellow players. I'm tired of games that are nothing but nonstop killing and mindless chest-thumping competition; the gameplay in my ideal Star Trek Online would reward Starfleet characters in proportion to the degree to which they work with each other to defend and promote their factional values of reason, tolerance, curiosity and cooperation.

In my ideal Star Trek MMORPG, Starfleet is the primary faction, and the core principles of the Federation (including tolerance and respect for the individual person and for other cultures) are unreservedly and unapologetically presented as the "right" principles when they are forced to come into conflict with competing principles. Non-Starfleet factions, beginning with the Klingon Defense Force, will be presented as having their own distinctive and consistent internal logic, and faction-related content will be created to be fun for those players who create characters in those factions. But Star Trek always focused on Starfleet, and my ideal Star Trek MMORPG would do likewise.

In my ideal Star Trek MMORPG, exploration would be the primary gameplay motivator for Starfleet characters. Physical exploration would be supported by a large or semi-infinite number of star systems and worlds (whether pregenerated or generated on the fly). Intellectual and emotional discovery would be provided by a profusion of lifeforms and civilizations that can be discovered on new worlds and in space, all of which have highly varied characteristics, and the process of cataloguing these characteristics would be implemented as enjoyable gameplay. These variations would also be used to spark story-based gameplay in the Star Trek mode. The quest to expand knowledge would be valued as fun in and of itself, and not solely for its value in economic competition.

In my ideal Star Trek MMORPG, many of the places and objects, lifeforms and cultures, and looks and sounds from Star Trek episodes will be replicated with reasonable fidelity and respect. The art and the lore -- the "feel" of Star Trek -- would be treated as though it was important to get it right. The "worldiness" of a MMORPG is no less important to me than the rules-based play set within that world, and in my ideal Star Trek MMORPG world content will not always be the loser in any conflict between the needs of "live in" and "play in."

In my ideal Star Trek MMORPG, both space and planetary surfaces would be rich in environmental phenomena. These phenomena would be the particles, energies and other natural and artificial effects mentioned in the many episodes of Star Trek, most or all of which would have specific action-oriented functional effects on the characters and objects in the gameworld. Making these phenomena an active part of all environments in a Star Trek MMORPG would provide outstanding support for multiple forms of play: visual beauty, surveying and cataloguing, storytelling, puzzle-solving, and tactical combat.

In my ideal Star Trek MMORPG, the characters matter as people. Understanding them as people, discovering their similarities to us as well as their differences, would be recognized as being both good Star Trek and good gameplay. Accordingly, this game would allow me to explore those similarities and differences through emotionally engaging stories. The stories in my ideal Star Trek MMORPG would be about things that matter. They would never be didactic, telling players what to think or feel, nor would the NPCs through whom these stories are told ever be used as mouthpieces for some developer's personal political opinions. The storytelling in my ideal Star Trek MMORPG would treat players as adults who are capable of feeling and thinking like adults, and giving us opportunities to do so through interacting with well-characterized NPCs in storylines that resonate with all of us as human beings.

In my ideal Star Trek MMORPG, science and engineering in particular would be treated with respect and appreciation. Gameplay involving the Science and Engineering divisions of Starfleet (and their non-Starfleet counterparts) would be created by people who understand science and engineering and appreciate their importance in the Star Trek universe. The developers assigned the task of designing and building gameplay around the Science and Engineering divisions would be enthusiastic about the opportunity to create constructive, creative, logic- and technology-based gameplay in a massively multiplayer persistent-world environment.

In my ideal Star Trek MMORPG, the starship is the central mechanism through which the content of the gameworld is accessed and experienced. Starships would be implemented with some key locations rendered as interiors; players would experience shipboard activities as an avatar interacting with other avatars in 1st- or 3rd-person perspective; and while no player would be forced into a support role on someone else's ship, friends who want to play together on one ship in specific roles would be able to do so. Away team missions would let players enjoy highly varied environments as a way to break up the shipboard play experience, but one's starship (of which there should be only three or perhaps four during a character's lifespan) should always feel like "home."

In my ideal Star Trek MMORPG, starships would be implemented as complex systems. That doesn't mean complicated interfaces, nor does it imply constant micromanagement -- it means that there would be depth in the functional behaviors of the subsystems and interconnections between subsystems that comprise the incredible artifact of advanced technology that is a working starship. Implementing starships as complex functional systems would create opportunities to solve problems in thoughtful and clever ways through the perceptive and creative use of those technological systems.

In my ideal Star Trek MMORPG, the high-level design of all combat systems would be assigned to someone who actually understands the military arts, preferably in both personal and theoretical settings. "Combat" would be understood to be not merely the artificial one-versus-one duels or small-group "boss fights" of other MMORPGs, but as tactical, operational, and strategic levels of lethal conflict in which each level requires and rewards very different playstyle interests. Combat in my ideal Star Trek MMORPG would be designed from the ground up to distinguish between these styles of conflict resolution and make each one a distinct area of gameplay that supports and enhances the others.

In my ideal Star Trek MMORPG, operational gameplay (helping to lead groups and player fleets) and strategic gameplay (long-term, wide-area management of resources valuable to one's faction) would be gameplay modes that are consciously designed to be distinct from tactical gameplay. The ranks in each faction would be keyed to each of these three gameplay modes, with the rank of Captain being the normal endpoint for advanced tactical play. Players would never be forced to accept promotion beyond Captain, which would shift them out of tactical play and into operational or strategic play, but those players who wished to take on greater levels of responsibility for the fun of other players would be supported by the rank structure and the overall design of conflict-based gameplay.

In my ideal Star Trek MMORPG, starship combat would be designed to play out over a span of several minutes, with many opportunities for true tactical gameplay through applying the various technological systems and crew capabilities of a mighty starship to the environmental phenomena that exist in a particular location. Engagements would last long enough for smart decision-making to play a much more meaningful role in resolving combat situations than just who's got the bigger stick (as in current MMORPGs).

In my ideal Star Trek MMORPG, crafting would be implemented as a game of constructive creativity that is fun in and of itself, not as a game of manufacturing and sales where your gameplay products only have whatever value other players give them. While it can make perfect sense for other games, in my ideal Star Trek MMORPG crafting would absolutely not be a game of using fleet resources to crank out thousands of identical products to try to "win" some economic competition. Instead, there would be a limited game economy in which players are encouraged to use their personal creativity and the skills of their characters to individually handcraft new things for trade to other player characters.

In my ideal Star Trek MMORPG, all of these things would be designed and implemented to create a total gameplay experience that is highly satisfying to people with different playstyles. Those who enjoy the simple competition/accumulation-oriented play so prominent in current MMORPGs would definitely be able to enjoy that kind of content in my ideal Star Trek MMORPG. Competition and the (limited) accumulation of value items are important aspects of the human condition and deserve a place in a well-developed gameworld. But in my ideal Star Trek MMORPG, competitive/destructive gameplay will never be allowed to dominate the gameworld to the exclusion of cooperative/constructive content. Both are fun; and in the game I'd like to play, both would be energetically supported with a long-lasting balance of enjoyable content.

Those are the main things I personally would like to see in Star Trek Online.

Am I going to be disappointed to some degree when the Star Trek MMORPG that Cryptic is making finally ships? Sure. But I expect there'll also be plenty of things from this list that do appear in their game.

Hey, I can take "yes" for an answer. :)

Engineering Crafting Modes in a Star Trek MMORPG 2

As a result of some discussions, I've updated my design concepts for Engineering-oriented crafting in Star Trek Online.

REVISIONS

There are two key changes:

• added Fabrication mode -- how do devices get created in the first place?
• changed Maintenance mode to Optimization mdoe -- "maintenance" implied "recover from item decay"

To help keep these modes clear, I turned to my industry experience -- I came with an acronym. :)

Fabrication
Optimization
Repair
Enhancement

FORE!

So the overall model for how Engineering crafting might work in a MMORPG based on Star Trek is as follows:

Fabrication: create a device with standard capabilities using standard components
Optimization: modify the internal connections between components to improve the numeric performance of a device's or system's current capabilities
Repair: fix or replace damaged or destroyed components to restore basic functionality of a device or system
Enhancement: replace standard components with exotics or add optional components to give a device or system non-standard capabilities

PRESENTATION

To allow the player to easily learn and perform all of these gameplay functions, a single presentation system would be used.

The main window would display an aesthetic dark gray representation of the type of device being created or device/system being modified. This representation would be surrounded by numerous slots for the components of which that device or system is comprised. Any fully functional components already placed into component slots would be displayed with a green background; damaged components would be shown in yellow; and destroyed components would appear with a red background.

A side window would display a tree-structured hierarchy of device types and components, which can be double-clicked or dragged into the main window to be displayed there. Existing components in the character's personal inventory will be visually distinguished from standard components that can be replicated.

The main window would also display connections between components. (It will be useful if every device/system always requires at least two or three connections so that the player will understand that they exist.) Players will be able to click on the ends of connections between components to move those ends to different components.

Finally, there should also be two display-only subwindows. One would present a graphical depiction of the device as it will look when the crafting process is complete, and the other will display textual and numeric information describing the device's functional characteristics.

GAMEPLAY

In practice, several of the Engineering crafting modes would interlace. A character wanting to create, modify or repair a device would bring up the crafting interface, which would consist of four subwindows within one overall window.

For example, maybe your character, who has specialized in Engineering, is asked to provide to a newly-encountered culture a genetic sequencing analyzer for medical research that is capable of an 93% level of codon discrimination. If you weren't an Engineer, you could look to buy or contract for the creation of such a device. But since you're an Engineer, you figure you'll try to create such a device yourself.

You check your manifest and find that you don't have an existing analyzer that you could Enhance or Optimize to a 93% discrimination level. So you decide to Fabricate one from scratch. You pull the schematic from the Federation Engineering database, and replicate the standard components you need... but the resulting analyzer provides only an 89% level of codon discrimination.

So you start Optimizing the device by tweaking the internal connections between the components of the analyzer, trying to find a combination that improves the codon discrimination level (preferably without degrading any other feature too badly). Eventually you're able to see the pattern, and your analyzer develops a 95% discrimination level. Now you can give the analyzer to the appropriate NPC.

Alternately, you might have chosen to try to Enhance a standard genetic analyzer with non-standard components, some of which could provide a bonus to codon discrimination (though possibly to the detriment of some other operational capability).

Should the analyzer break for some reason, a character could attempt to Repair it. The player would right-click on the device and select "crafting" (or a more Star Trek-y term) to bring up the crafting window. The standard window would appear, and any damaged or destroyed components would be easily visible through the color-coding described above. The player would then be able to attempt to repair damaged components (perhaps via some minigame). Alternately, the player could choose to replace damaged or destroyed components by replicating standard components and dragging them into the appropriate component slots, or to replace damaged or destroyed components with non-standard components from the character's personal inventory. (Another way to look at this is as Fabrication or Enhancement mode gameplay, just on an existing device or system rather than a new device.)

Note: in this system, I'm assuming that players would be able to Fabricate new devices, but not new systems. I'm thinking of "systems" as large fixed installations, either on the ground, in a starbase, or mounted on a starship. Players would be able to Optimize, Enhance, and Repair such systems, but creating large systems from scratch should probably not be part of player crafting -- new systems should, I think, come from a different gameplay interface. For ships, this would be a "ship customization" interface. Once a ship system is installed, a character would then be able to attempt to Optimize, Enhance, or (when necessary) Repair it.

DESIGN NOTES

"Surprise"

One of the goals of this design is to support both the reliable crafting of specific objects as well as "creative" crafting.

Reliability depends on the same inputs, connected in the same ways, always producing the same output -- that is, devices that always have the same functional characteristics. Since there's nothing random about this model of Engineering crafting, reliability is guaranteed. The internal rules by which specific inputs lead to specific outputs may be quite complex, but they would be invariant.

At the same time, the complexity -- or "depth" -- of those internal transformation rules would, in combination with having a very wide range of input components and component characteristics, allow for the possibility of surprise. Trying a new component or a new way of connecting components should produce new results (that is, new functional capabilities or new levels of performance of specific capabilities). These things should be comprehensible. Certain types of components should usually lead to certain recognizable kinds of capabilities in the devices constructed from those components, and connecting certain types of components together should generally lead to roughly consistent optimization results.

So there would be some level of predictability in a player's crafting choices. It's OK for a system to appear complex as long as it doesn't appear to be random. But that internal transformational complexity coupled with the large number of possible inputs would still allow for surprise, which should keep the crafting system fresh and interesting while still allowing reliable production.

It would be possible using this system to intentionally make a specific device to achieve a specific purpose. But those gamers who enjoy tinkering would also be able to use this system to explore creative possibilities.

...

More to come on this subject, I suspect. :)