The Melancholy of Lost Civilizations in RPGs

Gamasutra recently reported on a presentation by veteran RPG designer Ken Rolston, in which he noted that world-building often means creating objects and settings from days gone by:

Often, that melancholy comes when exploring the remains of long-dead civilizations, seemingly something of a preoccupation of Rolston, and one that frequently makes its way into his games by way of in-game artifacts.

"Melancholy, I think, is the underlying tone in most of the role-playing games I've done," Rolston said, adding, "I know games are all about fun, but there's an underlying tone I'm always trying to speak to."

That aspect of RPGs never struck me before... but how appropriate that a sense of melancholy is consciously integrated into the design of most RPGs!

By its nature, the typical RPG conventionally contains several things, among which are a relatively well-developed world and characters roaming that world killing each other. Well, what does it say about these worlds that it's considered normal for people to go around killing each other without being clapped in irons immediately as a danger to society?

As worlds in which the player character can run around killing people, that naturally suggests some kind of breakdown of order. This makes it almost inevitable that the created history of the world of a computer-based roleplaying game must include lost civilizations, in which a Golden Age of the past was more civilized than the Hobbesian present.

It's virtually commonplace to see cultural and architectural fragments of former civilizations in a fantasy milieu. Michael Moorcock's Elric, last emperor of languid Melniboné, is regularly described as melancholic. In computer RPGs, there were the Ayleid Empire of The Elder Scrolls and the Tevinter Imperium of BioWare's new Dragon Age. But a more aesthetically advanced past is almost always part of other well-developed RPG settings as well -- the mythically idyllic pre-invasion past of the Fallout series, for example, or the Republic before Palpatine corrupted it, or the pre-catastrophe world before The Computer took over Alpha Complex in Paranoia (another game Ken Rolston worked on).

In such worlds, where you can't swing a sword or fire a bullet without hitting some burnt-out ruin, any character capable of thinking beyond moment-to-moment survival must feel some sense of melancholy for a life that might have been. It's a natural way of lending some emotional depth to what otherwise could have been a simple action-oriented killfest.

Consider the choices and placement of objects in Bethesda's Fallout 3. The use of artifacts in Fallout 3 are a graduate-level course in how the objects placed in a gameworld can define the narrative of that world.

Fallout 3 was filled with what might be called "microstories." Open a door to a bathroom and see a skeleton in a bathtub, surrounded by empty bottles of booze and a pistol. Look into a small bedroom and find an array of children's toys, seemingly abandoned in the moment of play. Peer into a closet in a tunnel and discover a rat's-nest of useful items guarded by a lone teddy bear. (And let's not forget the "plunger room" or the Rube Goldberg-style trapped grocery store....)

In every place where people lived, there are artifacts posed in ways that tell a small story of the moments just before The Big One... or the grim and hopeless days after. I can't imagine even the most hardcore gamer, who cares only for how many Super Mutants he can kill, being insensitive to the pathos of the little stories and the overall sense of lives meaninglessly snuffed out that they tell.

Is that "fun" in and of itself? I suppose not. "Experience feelings of loss!" will probably never be part of the advertising materials for a game. But did the care that went into telling those sad microstories make Fallout 3 more memorable -- more fun -- for me?

Absolutely yes. More generally, I would say they contributed to making Fallout 3 a more satisfying game for many gamers.

But should that sense of melancholy be a part of every RPG with aspirations of worldiness?

The question for RPG designers is, do they want to continue to create worlds in which emotional heft is supplied by an elegiac regret over the remnants of lost civilizations?

Or is it possible to build a deep RPG world that includes all the lethal conflict that gamers seem to want, but that takes its emotional depth from some place other than comparison to "a more civilized age?"

What Kind of Team Player Are You?

As a software project manager, I frequently have to interact with people filling different roles in the development process.

Over the years I've often been in the position of needing to work with these people to accomplish some goal. Usually they possess information I have to have in order to determine whether something can be done, or what specific steps need to be taken in order to get the job done right.

A few people have been helpful. Most are... less so.

In fact, I was eventually able to categorize the kinds of answers I can expect to get when I ask a "can I do X?" kind of question:

• "Yes."
  Translation: "You can do whatever you want, but you'll have to figure it out yourself; I'm clearly too busy/important to help you. Oh, and don't get it wrong, or else."
• "No."
  Translation: "I am a human roadblock. You will follow my required process. I will not tell you what that process is. If you ask, I will assume the attitude that it's something you should (somehow) already know."
• "Yes, but."
  Translation: "Progress is dangerous. Do you not realize just how many things might go wrong? It's my job to object continuously to every little thing you will ever propose, and to write emails to your manager disclaiming all responsibility if anything bad ever happens."
• "No, but."
  Translation: "No, that won't work, but here's some information that might help you find another way to accomplish your goal."

I love the "no, but" people. The "no, but" people understand that we all play for the same team, and that by taking a few extra seconds to help me be productive, they help themselves, too.

The only bad thing about the "no, but" people is that there aren't nearly enough of them.

Which kind are you?

Casually Hardcore

Two terms that consistently show up when talking about playstyles are "Hardcore" and "Casual." But what do these words mean?

Lewis Pulsipher, in a blog post on Gamasutra, provided a list of examples of how Hardcore gameplay (and gamers) differ from a Casual style. Many of these examples are frequently cited when this Hardcore/Casual split is discussed. "Plays a long time" versus "prefers quick play sessions" is often mentioned, as is preferring challenging (Hardcore) over easy (Casual) games.

Chris Bateman has proposed some interesting definitions as well. For example, Hardcore = "gamer hobbyists" while Casual = "mass market," or Hardcore = "prefers a 'punishing' game" while Casual = "prefers a 'forgiving' game."

For my part, the one word I keep finding myself using in discussing Hardcore/Casual is "investment." The typical Hardcore player (as I see it) invests personally in the gameworld, while the classic Casual player is mostly or fully divested.

The Hardcore gamer is willing and able to talk about the gameworld as though it matters, and doesn't mind being seen as caring about the characters and places and internal rules of the gameworld. By contrast, it's almost always a Casual gamer who declares "it's just a game" and prefers to be perceived as holding it at (emotional) arms-length.

I suspect this notion of "investment" is one of the fundamental motivations that drive the actual behaviors of play that we see. It would explain why different gamers spend more or less playing time per session, and why they prefer deeper and more challenging games or simpler and easier-to-put-down games.

The Very Model of a Good Game Designer

So what makes someone a good game designer?

Is it innate? Or can it be taught? What makes one game designer more effective than another? What the heck is "game design," anyway? What distinguishes it from, say, simulation design or bridge design or graphic design?

Here's my one-line definition of game design: game design is high-level systems design in an entertainment context.

To put it another way, a good game designer is someone who's good at creating core designs for systems intended to entertain people. And if that's true, then by implication the way to become a better game designer is to become better at high-level systems design.

A systems designer surrounds himself with knowledge about systems -- how they work, and how they fail to work. Because people love to create systems, that means studying human systems: economics, philosophy, history, politics, psychology. What enables a government to function, and under what conditions will it cease to function? What are the fundamental motivators of human behavior? Why do we call the notion of supply and demand a "law?" Are there patterns to the emergence, growth, and extinction of civilizations? Unlike most people, the systems designer never gets bored studying these things because all of them help to explain how systems satisfy their intended purpose(s) and how they fail to do so.

The good systems designer also studies science in order to understand the greatest of all creators of systems: nature.

Look at the head of a sunflower, and consider: why do the number of spirals of pips correspond specifically to numbers on the Fibonacci sequence? How do ecosystems maintain equilibrium? How do the strong nuclear force and gravity produce stable dynamic systems in a chaotic universe? I think what relates all these and other natural phenomena is simple to express: when you've got millions and billions of years to experiment, and you're not emotionally attached to any solution, eventually the systems you wind up with are going to be extremely efficient at satisfying their purpose because all the less efficient solutions were discarded.

The good systems designer is thus a student of natural science because nature is all about highly functional systems. They also study human organizational systems precisely because they are far less functional most of the time than natural systems -- human-designed systems provide powerful lessons on what doesn't work.

That's most of what a good game designer needs, I think. But the entertainment context matters, too. So I'd specify that a good game designer is a good systems designer who's played enough different kinds of games to understand "play" at a systemic level.

A couple of the best resources I've encountered on practical systems design are The Design of Everyday Things by Don Norman and Systemantics by John Gall. Again, the true game designer, as a systems designer, studies all systems. They'll have read hundreds of books to try to glean practical rules of effective systems design. But anyone who thoroughly groks these two works in particular and has played enough games to perceive most of the patterns within the "game" context is probably as ready to be a successful game designer as anyone can be.

Ultimately, then, to find a good game designer, first find someone who understands systems at a deep level and who's familiar with game design patterns.

And then give that person a clear high-level vision document that says "what" but not "how," a list of resource constraints, and all the caffeinated beverages they can drink, and say to that person, "Yeah, I don't know, all the experts say it can't be done...."

Bartle, Keirsey, and Chris Bateman's DGD1 Gamer Demographic Model

Introduction

On the advice of Richard Bartle, I picked up the book 21st-Century Game Design edited by Chris Bateman.

This book, in addition to later chapters on general game design, begins with a section that discusses playstyles. More specifically, it explores a "demographic game design" model (DGD1) of gameplay preferences and suggests how this model relates not only to the original four Bartle Types, but to Myers-Briggs personality types and Keirseian temperaments as well.

After working through the concepts, I believe I've been able to how the DGD1 model of play fits into the Myers-Briggs/Keirsey model of general personality. And if my notion that the Bartle types are an alternative formulation of the playstyle theories and models of Caillois, Lazzaro, and Edwards (among others), then the DGD1 model can be seen to integrate with those explanatory systems as well.

Before I go any further with this, I should note that I'm not forcibly wedging the DGD1 model into my own current articles of faith regarding a sort of One True Model of playstyles. Chris Bateman himself has provided the Myers-Briggs types and Keirseian temperament associations with the four proposed DGD1 playstyles -- in what follows, I am simply providing a visual representation of those claims.

Later on I'll have some comments that might fall into the category of original research; when that happens I'll clearly flag them as such.

The Demographic Game Design (DGD1) Model

Chris Bateman's DGD1 model begins by noting that certain Myers-Briggs types seem to cluster with respect to the behavior of players in games -- certain kinds of people like certain kinds of gameplay.

Based on demographic research, combined with the research of game publishers, Bateman's model starts with Hardcore and Casual players. From there, his model is expanded to recognize the existence of a second axis of play interests between freedom and what he calls "structure," and which he associates with the FP and TJ Myers-Briggs type combinations respectively. Finally, Bateman infers the existence of two additional styles associated with the FJ and TP type combinations.

The result of this data reduction is a model consisting of four playstyles, along with two general modes of play (Hardcore and Casual). Each of the four DGD1 playstyles is associated with four of the sixteen Myers-Briggs types, as well as with combinations of the four general temperaments defined by Keirsey. (Actually, Bateman uses the terms Tactical, Logistical, Strategic, and Diplomatic, each of which is treated by Bateman as an expression of playstyle associated with one of the four Keirsey temperaments.) And the Hardcore and Casual play modes are said to be associated with the Intuitive and Sensing preferences defined by Carl Jung, from whose work the Myers-Briggs types were developed.

In tabular form, the DGD1 model can be rendered as follows:

DGD1 STYLE	MYERS-BRIGGS TYPE	KEIRSEY "PLAYSTYLES"	KEIRSEY TEMPERAMENTS
1. Conqueror	INTJ, ENTJ, ISTJ, ESTJ	Strategic-Logistical	Rational (NT) - Guardian (SJ)
2. Manager	INTP, ENTP, ISTP, ESTP	Strategic-Tactical	Rational (NT) - Artisan (SP)
3. Wanderer	INFP, ENFP, ISFP, ESFP	Diplomatic-Tactical	Idealist (NF) - Artisan (SP)
4. Participant	INFJ, ENFJ, ISFJ, ESFJ	Diplomatic-Logistical	Idealist (NF) - Guardian (SJ)

The DGD1 Model Meets The "Big Model"

Based on these associations, it is possible to construct a diagram showing all of the elements that Bateman defined for his four playstyles as well as for the Hardcore and Casual modes. As I'll explain, the DGD1 elements fit naturally into the diagram of the four Keirseian temperaments as mapped onto the four Bartle types that I've been exploring, which (because I think the models of play developed by Roger Caillois, Nicole Lazzaro, and Ron Edwards are alternative versions of the same larger model of human personality) I've taken to calling the "big model":



The brief description of the DGD1 model, then, is that it neatly provides descriptions for the six possible modes of play formed by the six intersections among the four Keirsey temperaments -- or the four Bartle types and the other associated models of play if you accept my theory that all these models are analogous.

To say this another way, I believe the DGD1 model maps with extremely high fidelity onto my own four-quadrant "big model" that associates the four-quadrant original Bartle types with the four-quadrant general temperament model of David Keirsey (although my version of the four-quadrant temperament model is modified from Keirsey's version). In particular, I find it highly supportive of the suggested mapping of DGD1 onto the "big model" that the bottommost line on my diagram, which corresponds with the TJ Myers-Briggs type combination, is explicitly called "structure" by Bateman -- and that is precisely how I refer to that end of the vertical axis on my four-quadrant model. Similarly, the other end of that axis I refer to as "freedom," and Bateman seems to think of it in the same way, thus the DGD1 player "Wanderer" player type most closely associated with that FP type combination.

In a broader sense, the value of the DGD1 model (beyond any specific utility it can be shown to have in and of itself) is that it provides a direct response to one of the most common criticisms of the Bartle types model, which is that "no one is ever just one 'type' of player."

Without going into the details of why that charge is somewhat true and yet misleading (I favor a theory that most of us have one primary preference, two secondary preferences, and one avoided preference), the DGD1 model fills in the gaps between Bartle types. A player who knows that their preferred style of play is balanced between exploration and achievement, who was told they "didn't fit" the Bartle model, can now understand themselves to be representative of the Conqueror playstyle as described by the interstitial DGD1 model. Rather than invalidating the Bartle types, the DGD1 model helps to refine that model.

How the Hardcore/Casual Preferences Fit Into the "Big Model"

One final note regarding the DGD1 model (and this is where I get into my own interpretation of Chris Bateman's work, rather just giving an enhanced representation of what he provided in 21st-Century Game Design) concerns the Hardcore and Casual modes of play.

One of the most important distinctions in temperament theory is the difference between the preference for Intuition or Sensing. This preference describes whether a person prefers to check inside themselves (Intuition) or outside in the world (Sensing) for what really matters. So if the other elements of the DGD1 model are valid, then the assignment of the "Hardcore" players to the purely Intuition-oriented preference and "Casual" players to the purely Sensing-oriented preference can actually be read as relatively pure cases of Intuition-expressed gameplay or Sensing-expressed gameplay.

To test this, let's first consider the Casual gamer. These gamers, with their Sensing preference for what the world says, are likely to have world-oriented interests -- not only will their gameplay tend to be in shorter bursts because they have less time for games (because they're busy doing world-oriented things), when the conventions of society say that "playing games" is childish, Sensing persons are likely to accept that convention. Not surprisingly, then, Casual gamers take a casual attitude toward playing games out of concern that someone might discover their childish pleasure. Dipping only casually into games provides Sensing-oriented players with plausible deniability; they can claim that they never invested any real time or care in the game. Of all types, this is the one most likely to declare with utter conviction, "It's just a game."

By contrast, "investment" is precisely the word that best characterizes the Hardcore gamer. Where the Casual gamer is willing to "play in" a gameworld, the Hardcore gamer is eager to "live in" the gameworld. Where the Casual gamer objects to complex rules because it means they have to put in more time to learn the dynamics of game systems, the Hardcore gamer rejoices in complex game systems because they are interesting and feel more like a living environment. However, while Hardcore players may be willing to accept minor changes to the world of the game, they are much more likely to object strongly to major changes in the gameworld. Hardcore players put down roots; they come to understand a gameworld as a kind of home and invest in it as a familiar place... so if that sense of place is uprooted, the Hardcore player will never forgive those responsible, while the Casual player can shrug and move on to the next game.

One complicating factor here is that according to Myers-Briggs research, about 70% of the general population prefer Sensing. While this also supports the observation that the marketplace of Casual gamers is considerably larger than that of Hardcore gamers, this also means that the number of each kind of gamer is likely to be well-represented in online forums dedicated to particular games. This frequently leads to intense debates between Hardcore gamers who assume that their style of play will be respected by the game's designers and who expect the game to make intellectual and emotional sense, and Casual gamers who are equally certain that, because there are many more of them, the game's designers must cater to their interests which revolve around pure rules-based play: "it's just a game." Again, though, these arguments so often observed in game forums can be taken as supporting evidence for the existence of a Sensing/Intuition split among gamer attitudes that manifests as Casual or Hardcore expectations respectively.

Wait... Achievers Are Casual Gamers?

Having pointed out the apparent goodness of fit of the Hardcore/Casual divide with the Intuition/Sensing preference, there's one apparently glaring contradiction here: how can anyone say that an Achiever -- who usually has a strong preference for Sensing over Intuition -- is in any way a "Casual" gamer? Aren't these the people who will play a game for hours, weeks, months, until they've beaten it? Isn't that a form of investment?

I would say that it is... but it's not Hardcore investment in the gameworld, it's "beat the game" investment in generic competitive activity. In much the same way that Sensing-preferring individuals are more likely to enjoy playing team sports for the competitive challenge, while those who prefer Intuition -- if they enjoy sports at all -- are more likely to enjoy challenges that test their mettle as individuals. For example, while an Intuitive is more likely to enjoy climbing a mountain to enjoy the view from the summit, the Sensor is more likely to view the climb either as a race to see who can reach the top the fastest, or to see who can climb the most mountains.

In a gameplay context, this means that the Achiever who spends many hours every week playing the same game is not doing it in a Hardcore way because he feels a need to savor the experience internally -- he's doing it to beat the game, at which point (as a Casual gamer who doesn't invest in a game as a place) he's done with it. "Beating the game" may come in several forms for the Killers/Manipulators and Achievers on the Casual end of the spectrum. It may be literally reaching the end of a story-based game, or the end-game of a persistent-world game such as a massively multiplayer online roleplaying game (MMORPG). It may also be expressed through smaller competitive challenges, such as being the first player to obtain a particular rare item or to collect a certain number of such items; it may be to collect more of some item than any other player (such as currency); it may be to have the top entry on a leaderboard; it may be to "kill" new player characters until doing so no longer offers a sufficient adrenaline rush. In all these and similar cases, however, once the Casually competitive player's dominance has been accepted -- once the game of choice has been "won" -- the Casual player begins to lose interest and (unlike the Hardcore gamer) will rapidly disengage with that game, often without a backward glance.

Conclusion

In summary, then, while it bears repeating that no model of human behavior can ever be considered perfect, the real question is only whether a given model provides sufficient explanatory and predictive power to allow game designers to communicate usefully about what gamers in the aggregate want and why. Under that measure, I believe the combination of the Bartle/Lazzaro/Edwards+Keirsey model I've suggested with the DGD1 model of Chris Bateman produces an overall model of gamer preferences that does offer good explanatory and predictive power. The model adequately explains why different kinds of gamers consistently demonstrate specific kinds of preferences for certain gameplay forms. Although less evidence exists to support this conclusion, I believe this model can also reliably predict which large groups of gamers (not necessarily individual gamers) are likely to be attracted to particular gameplay forms.

Bearing always in mind that no model is perfect (and thus that perfect explanation or prediction are not reasonable standards against which to hold any model of gameplay preferences), this one seems sufficiently effective to me to warrant continued exploration. But as Richard Bartle says, if some other model can be shown to have better explanatory and predictive power, then I'll enthusiastically set this one aside in favor of the new model. What matters is not that I'm personally "right," but that all of us who are interested in making better games (and making games better) have the best possible tools at hand for that task. If someone can come up with a better model of gamer preferences, we all win.

Until then... this one seems to work.

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.

Game Development as Customer Satisfaction

The Philosophy of Customer Retention

The creative side of game development is fun to talk about. A commercial game, however, whether a one-time product or a service like a MMORPG, has additional needs. In particular, it has to persuade people to choose to part with their money. And a development studio for commercial games, or for an online game, needs to make this persuasive case not just once, but repeatedly.

When it comes to repeat sales, I think successful non-game businesses may have something useful to offer game developers, and that's the concept of customer satisfaction as a conscious focus of daily business practices.

For commercial games, it's easy to think that "customer satisfaction" is some financial metric that can be left to the bean-counters: if a lot of units changed hands, if it made a lot of money, then customers must be satisfied. Making a game is just about doing your job of creating functional gameplay or art or audio; it's not about interacting with customers... right? Isn't that Marketing's job?

That might work. You could get lucky and wind up with a hit game, bringing you to the attention of many new customers. But what happens when you try to sell those customers another game product, or when you ask them to continue subscribing to (or microtransacting with) your game service?

What are you doing to keep customers once you get them so that your game development studio achieves a long-lasting state of continuous success instead of being remembered as a one-hit wonder?

Customer Satisfaction Defined

That's where customer satisfaction comes in. Far from being an after-the-fact affair, customer satisfaction works best when it's like water to a fish, when attention to satisfying customers is such an integral part of the organization's culture that no one even notices it any more.

So what does "customer satisfaction" mean? There's a simple functional definition: setting and meeting expectations.

Customers are satisfied when they understand what to expect from you, and when they get what they expected. An effective business, then, will take pains to define customer expectations properly, and then to meet those expectations consistently.

The Andy Unedited blog suggests four expectations that are common to all customers. I found them particularly interesting because each of them has direct application within the context of game development:

Customers expect accuracy. Visible bugs are the fastest and easiest excuse for rejecting your product. Don't give a potential customer that excuse.

Customers expect availability. For online games especially, you're providing a service in a competitive marketplace. If people can't access your service when it's convenient for them, they'll turn to someone else's. But even new single-player games need to become available on a regular basis from you so that customers can trust that you intend to meet their gaming interests over the long term.

Customers expect partnerships. Customers who sign up for a service want you to value their experience and listen to their opinions regarding that service. Customers know they have choices, and they expect you to remind them occasionally why you're still their best choice.

Customers expect advice. Gamers tend to object to feeling "forced" to do anything in a game, but they do expect you to guideposts that help them find the content that matters most to them.

So which of these expectations are being met where you work, and which aren't? Which of these things are you treating as a personal responsibility to increase customer satisfaction? Before you say, "that's not my job," are you sure there's nothing you can do to contribute to it?

In short, what have you added that communicates to everyone who spends their hard-earned money on your game that you value them as a customer and you want their business in the future?

On the Virtues of Plussing

A "thank you" screen at the end of a credit sequence (especially the ones that are twenty minutes long) is not sufficient. Focusing on making functional gameplay or art or audio is not enough. All your competitors are doing those things.

A memorable product -- a product whose creators, from bizops to programming, were consciously focused on customer satisfaction -- is one that has been made just a little bit better in every single feature. There's even a term for this, which comes from Walt Disney and has been picked up by such successful creative houses as Industrial Light & Magic and Pixar: "plussing." Everything gets created to meet its functional requirements... and then everything gets plussed in some way.

This isn't just some feel-good, buzzword-bingo "quality" statement that everyone just winks at. It's a proven tool for achieving customer satisfaction because it doesn't take the customer for granted. Plussing as a corporate policy is an understanding that customers will notice and appreciate extra effort.

When plussing is practiced by everyone in a creative shop, when it's so deeply embedded in the corporate culture that people actually compete to see who can most effectively plus their contributions to every product, customers notice. They may not recognize individual contributions, but the product as a whole will shine... and that, they do notice. Assuming the product meets their functional expectations, customers will remember that developer positively when considering whose future games are likely to meet their expectations of getting value for their money.

Summary

To sum up, the ultimate responsibility of everyone making a commercial game is to customer satisfaction. And everyone in the group can contribute to that goal by committing to making everything they do just a little bit better than it has to be.

Given the choice between a game whose developers did only what was necessary, and a game whose developers took personal responsibility for making everything they did a little better, which do you think you'd be likely to find more satisfying?

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?

Timmy, Johnny, and Spike Meet the Bartle Types

I recently noticed an article by Mark Rosewater for Magic: The Gathering in which he discussed player types (or, as Rosewater calls them, psychographic profiles).

This was a December 2006 expansion of a previous article, which proposed three types of playing styles -- that is, three player types -- for Magic: The Gathering: Timmy, Johnny, and Spike. As Rosewater describes these types in the updated article:

Timmy wants to experience something. Timmy plays Magic because he enjoys the feeling he gets when he plays. What that feeling is will vary from Timmy to Timmy, but what all Timmies have in common is that they enjoy the visceral experience of playing.

... Johnny wants to express something. To Johnny, Magic is an opportunity to show the world something about himself, be it how creative he is or how clever he is or how offbeat he is. As such, Johnny is very focused on the customizability of the game. Deck building isn't an aspect of the game to Johnny; it's the aspect.

Spike plays to prove something, primarily to prove how good he is. You see, Spike sees the game as a mental challenge by which he can define and demonstrate his abilities. Spike gets his greatest joy from winning because his motivation is using the game to show what he is capable of. Anything less than success is a failure because that is the yardstick he is judging himself against.

In the update, Rosewater goes on to further break down each of these three styles into four subgroups:

Timmy: Adrenaline Gamers, Power Gamers, Diversity Gamers, Social Gamers

Johnny: Uber Johnnies, Combo Players, Offbeat Designers, Deck Artists

Spike: Analysts, Tuners, Innovators, Nuts & Bolts

Reading the names and descriptions of these subgroups, I had that very familiar feeling of seeing another iteration on the four original player types proposed by Richard Bartle. Each of the four subgroups for all three MtG styles sounded very much like one of the Bartle types, simply zoomed in a bit to be specific to each of the MtG styles.

Based on Rosewater's effectively characterized descriptions of all twelve subgroups, it was surprisingly easy to see each one aligned with one of the Bartle types. (Naturally, that's "Bartle types as I understand them." None of this has been endorsed by Richard; all interpretations and extensions of his player types model described in this blog are my own and should not be blamed on anyone else.)

Bartle	Timmy	Johnny	Spike	Goal of Play
Killer [Manipulator]	Adrenaline Gamers	Uber Johnnies	Analysts	plays for the sensation
Achiever	Power Gamers	Combo Players	Tuners	plays for the win
Explorer	Diversity Gamers	Offbeat Designers	Innovators	plays for mastery
Socializer	Social Gamers	Deck Artists	Nuts & Bolts	plays for self-expression

(Note that this chart should be considered an extension of Styles of Play: The Full Chart showing the deep correspondences I believe exist between several theories of personality and player styles.)

As always, it's possible that I'm seeing just what I want to see here. But considering how very neatly each of the four subgroups for the Timmy, Johnny and Spike styles matched up with the four Bartle types (at least to my perception), I have to wonder whether Rosewater deliberately drew from the Bartle types to create the various subgroups.

Whether he consciously adapted the Bartle types to his three-style psychographic model or not, I thought the juxtaposition of these models was interesting enough to be worth mentioning. There are many styles of play for many kinds of games and gamers; I'm fascinated by the possibility that there might be some utility in recognizing four deep patterns of play in particular.

Is Mark Rosewater's assessment of styles of play in Magic: The Gathering yet another confirming instance for this theory?

Is There Now a Language of Game Design?

In "Analysis: The 5 Major Trends of GDC 2009," Gamasutra editor Chris Remo mentions a particular exchange between veteran game creators Will Wright and Warren Spector:

Warren Spector and Will Wright observed that indie developers are exploring design avenues that are nearly impossible for older designers to have conceived, because younger indies are building on a lifelong fluency.

"It’s like we developed this language we had to learn as non-native speakers," said Wright of his generation of designers. "They grew up with that language."

"They're almost like commentary on the games that have come before," Spector offered.

As I read it, this is the notion that today's game designers are inheriting (and fluently speaking as natives) an immediately usable language of gameplay mechanics that until now has had to be invented on the fly.

That's a wonderfully provocative comment. (Actually, I suspect it explains not only a good deal about the success of W.W. and W.S., but also why it's great to have them on conference panels!)

Some random reflections:

1. The "language" W.W. mentions seems to be more at the level of design patterns than the atomic-level game grammar that Raph Koster, among others, has been exploring. That's not to undercut the potential value of being able to reduce gameplay to low-level factors; it's more a recognition that the working language of a designer may usually be at the higher chunking level of patterns.

2. In terms of expressive capability and maturity, how does this game design language compare to the language of film direction? After a hundred years of movie-making, film directors today have a rich, specific, and broadly-understood vocabulary of verbs and nouns to work with -- how near or distant to that standard is today's language of game design?

3. How dependent on the computing, networking, and presentation technologies is the language of game design? Do non-computer games (such as tabletop RPGs) have useful "words" that today's computer game designers might not be aware of? Or is most of the utility of computer game design patterns driven by what the technology allows, in which case, what happens to a language of game design when the technology changes radically (as OnLive may do, which W.S. noted)?

4. As the flip side of the previous question, do some words in the language of game design ever die? That is, are there some game design patterns that are permanently abandoned? If so, why and how does that happen?

5. What's left to invent? Considered solely on its own merits, how complete is the current language of game design? Are there any obvious gaps; are there useful intentions and directions that are currently hard to communicate even between experienced designers?

6. Can new words in the functional language of game design simply be made up through conversation or general writing? Or must each new word prove its utility by being implemented in a game or games? Does the popularity of a game have anything to do with whether a new game design word is perceived to have enough value to enter the lexicon? Should it?

7. To put the above question in a different context, who invents new words in the language of game design? Game designers? Or non-designing game players?

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

Does Every Gamer Really Want WoW's "Directed Gameplay?"

In a presentation at GDC 2009 [note: this links to some salty language], Wrath of the Lich King gameplay director Jeffrey Kaplan discussed a number of issues in quest design that the Lich King team considered to be problems. Kaplan says that all of these issues are things that Blizzard will be actively avoiding in all future quest designs.

Examples of these perceived quest design defects are:

The Christmas tree effect: quest hubs activate lots of quests, which players take in any order that they like.

Too long, didn't read: most WoW players skip even the 511 characters Blizzard allows for quest text, so why bother?

Medium Envy: "Art, literature, drama, film, song have all embraced story" but gamers don't care about any of that artsy stuff.

Mystery: "[E]ven if you're on a mystery story, we should never going to put you on quest where we say 'Something's wrong in [the forest]. Go figure it out.' At the end of the day it needs to say 'go kill this dude, go get this item.'"

Why am I collecting this [stuff]? "You never want the player to even think somebody made the game. You want the player to think only of himself."

My reaction is that all the things Kaplan describes as problems probably make sense for Blizzard. Blizzard has enthusiastically embraced the "directed gameplay" notion of game design, in which no player at any time ever lacks a blindingly obvious answer to the question, "What do I do next?" All of Blizzard's new content, including quests, is being designed to be consistent with that assumption that everyone who plays World of Warcraft needs their moment-to-moment gameplay to be strongly directed by Blizzard.

Is that really a good assumption for all other MMORPGs?

Should all of the quests and other content of every MMORPG be designed so that no player at any moment in time is ever in any doubt about what they're "supposed" to do next?

Or is there room in the MMORPG industry for games that provide guidance and assistance but not constant direction?

For my part, I think of these two service models as similar to those of the late Circuit City and Ikea, respectively. Forget for a moment about the products sold: think about the shopping experience.

I used to hate going into a Circuit City, so much so that I simply stopped going there years ago, because I detested being swarmed by vulture-like "sales associates" who wanted to direct my consumer experience. They treated everyone as uninformed, and they pushed their ideas of what was desirable on every consumer. No sale, thanks.

By contrast, I love the Ikea shopping experience -- there is an incredible wealth of products to explore, each of which is clearly described. On the rare occasion when a customer needs assistance, it's easy to find the centrally-located customer service area. When I shopped at Ikea, the low-pressure environment allowed me to find specific things that I wanted in my own time, and through exploration I often found (and bought) things I didn't even know I wanted.

I'm not suggesting that following the "we'll tell you what you really want" Circuit City approach will cause WoW to fold like Circuit City did. Obviously there are a lot of gamers who are perfectly happy being told one place to go and one thing to do at a time.

What about the gamers who value choice and freedom and the ability to explore a gameworld in their own way and at their own speed?

WoW already exists for the gamers who like lots of direction.

Why should every MMORPG try to compete with that service delivery model when there's an alternative model that can satisfy gamers who are willing and able to direct themselves?

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