Living in the Living World Game

Back in June of 2008, I published a blog post describing a game design concept that fascinated me: the Living World game.

Since then I've remained fascinated by the idea of a game that models social dynamics at both a very high and a personal level, and that runs constantly like an online game (simulating changes while the game is turned off). I would still love to see a game consciously developed as a gameworld, where the fun comes not from following some game developer's linear story to a predetermined conclusion but from being a part of and exploring an truly enormous and dynamic open world.

One of the possibilities in my original work-up of this concept was that players would create their own characters who, in typical role-playing game fashion, the player would mold and "level up." Lately, however, I've been thinking it could be much more interesting to eliminate level-based character advancement entirely.

Rather than the standard RPG model of creating a new character out of thin air and then leveling up that character through progressively more difficult challenges, a Living World might not need to copy that model. Instead, the primary gameplay system really ought to be designed to highlight the scope and dynamic features that make the Living World unique.

And what comes most strongly to mind is not giving the player a new character at all, but instead making gameplay about "jumping into" existing NPCs. (Credit Where Credit Is Due Dept.: this line of thinking was inspired in part by some comments made by Owain abArawn to the Gamasutra version of the original Living World essay.)

In this model (which, yes, now that I think about it does somewhat resemble the notion behind "Quantum Leap"), players starting the game would first experience the gameworld from a disembodied perspective. They would be shown the Living World from a great distance; the camera would then zoom in to various regions and then to individual NPCs going about their lives. The player would be shown how to take control of two different NPCs as a tutorial. After returning to the big picture view of the world (to impress on the player the scope of the Living World), they would then be free to begin exploring the world by inhabiting the NPCs of their choice.

This is where the core gameplay of the Living World would be found. Every NPC would be defined to have a particular role. (Role definition would be part of the toolset for building the content of the Living World.) Players would be able to observe or inspect an NPC to see the role he or she has, and then choose whether or not to inhabit that NPC.

Inhabiting an NPC immediately gives the player access to all the skills -- defined as gameplay activities -- that are associated with the role to which that NPC was assigned. So if you want to fight monsters, inhabit a Ranger; if you want to chase thieves, jump into a City Guard NPC; if you want to practice crafting, inhabit a Blacksmith or Baker; if you're looking for economic gameplay, inhabit a Merchant; and if you feel like trying your hand at the very difficult game of city or kingdom management, you would be able to inhabit a town's Mayor or even the King of an entire nation.

As noted above, in each case the kinds of gameplay available to you would depend on the role of the character you choose to inhabit. These gameplay activities would need to be predefined by the developer as selectable actions which use and/or affect objects inside the gameworld. The "Ranger" role, for example, might be defined to optimize skills (gameplay actions) such as Shortbow, Shortsword, Tracking, Herbal Medicine, and Stealth. Meanwhile, the "City Guard" role could be defined as having special training in Shortsword, Tracking, Negotiation, Perception, and the Guard badge which allows that character to summon other Guards. Other roles would have their own appropriate skill optimizations.

In addition to roles having particular skill optimizations, roles would also be keyed to preconstructed gameplay content. In other words, the role of the NPC you choose determines the kind of prescripted gameplay content offered to you. If you choose to inhabit a Ranger, you would not only be free to explore the gameworld while doing Ranger-y things, the act of inhabiting that NPC would also activate any number of world events (either automatically or at the player's discretion) in which Ranger skills could be particularly useful -- say, a monster invasion, or finding a lost child for some villagers. The same would be true for every role. Even highly mundane roles such as Baker would have gameplay events (e.g., baking challenges) scripted for them that would be fun for someone who voluntarily chose to be a Baker. (Note that this design integrates into the "epic storylines" feature of a Living World game.)

The assignment of NPCs to particular roles would need to be integrated into the social dynamics of the gameworld. Because the Living World models the birth, growth, and death of individual NPCs (possibly only at a statistical level except where the player has traveled or currently exists), the mechanism of children maturing into adults would need to be fitted into the role system. For example, a village experiencing dynamic growth would encourage children to fill high-priority roles as openings (due to death, injury, retirement, or possession by the player) occur, then useful roles, then expansion-oriented or support roles as the group's resources and rules permit. A village or social group that can't or doesn't care to continue, on the other hand, would probably find most of its children emigrating to cities or taking on "solo/loner" roles. In other words, the Living World needs to be designed so that role assignments to juveniles are made dynamically based on a determination of whether to maintain/enhance the existing social group or to break it up in favor of forming new groups elsewhere.

One other note on the gameplay design approach of "inhabiting" NPCs: Because the Living World would simulate not just large-scale social movements but personal social structures as well, in many cases the NPC whom the player chooses to inhabit would be part of a social group -- a member of the city guards, or the blacksmith for a village, or a husband or wife who is the parent to some children. This raises the question: should those NPCs realize when someone who is part of their social group is "inhabited" by an entity with the unique power of possessing people's bodies and minds?

I very much like the idea that these NPCs would definitely know when someone in their group is inhabited by the player, and that they would be able to react toward the player according to their beliefs and fears. It seems reasonable that stories of this kind of possession, occurring for thousands of years, would be part of the legends and histories of all the peoples of the Living World. Would you be considered a god? or a demon? or perhaps just a very talented sorceror? If you choose to inhabit an NPC who, in addition to her gameplay role, is a wife and mother, how might her husband and children react to you when they realize that she no longer exists as herself and that you might do anything at all to her, from taking her across the wilderness to getting her killed? These relationships, I think, would also be an excellent opportunity for prescripted gameplay activities to be activated, with the twist that they could have more than the usual amount of emotional resonance -- would you choose to risk the life of an NPC whose children are begging you not to take her away?

I'll be thinking more about this approach to character-based gameplay within the Living World concept. For now, the more I think about it, the better I like it as a system that supports and improves the overall design of the Living World game.

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.

Types of Character Power in a Star Trek MMORPG +

Originally Posted by Daedelus:
Everyone would have a basic skill but the more research/study and points you put into your knowledge of that skill would enhance or slightly alter the effect of a given ability.

I'm liking this idea a lot, Daedelus. Skill-enhancing discoveries... slick. Let's call them SEDs for short.

In fact, I'd like this idea even more as gameplay if you'll allow me to make the following tweaks to it:

• Characters have only a limited number of slots for SEDs. (Maybe higher department level [not higher rank!] allows more slots?)


• There are many more SEDs possible than slots.


• SEDs will need to be balanced very carefully so that none are clearly better than all the others in most situations.

The value of defining skill-enhancing discoveries this way is that it creates opportunities for interesting choices, and it helps players distinguish their character from someone else's character. (That makes the gameplay a bit harder to balance, but it's very important for roleplaying.)

Suppose you and I both have Level 30 Engineers. (Rank should be irrelevant to this, but for the sake of discussion let's say we're both Lieutenant Commanders.) This means we both have (just picking a number out of the air) four slots available for skill-enhancing discoveries.

Let's further say that I choose to enhance my Engineer character's skills by making four discoveries related to Power Systems, while you focus on making your four discoveries in the field of Sensors. In this case, we're both going to be more valuable Engineers than someone with fewer skills or fewer enhancements. But we'll also be different from each other, giving us different play experiences that are a better fit for what we enjoy doing in these games.

There is a potential downside to this, which is that by no longer having characters with exactly identical gameplay capabilities, we're no longer "plug-and-play" for groups who want an Engineer. Now that we have specializations (from the SEDs), and those specializations can vary between characters, maybe we each become a perfect fit for one group but not quite as good a fit for some other group. And we're both not precisely right for some group that just wants a generic Engineer as a kind of Gear-Healer.

Maybe so. OTOH, I don't know about you, but I have zip point zero interest in being a generic anything.

So I find the notion of having a limited number of slots for making skill-enhancing discoveries (through solving puzzles of some complex kind) to be a pretty interesting possibility for how Skill power and Knowledge power can be combined in a game like Star Trek Online.

Tanks, Nukers, and Healers in a Star Trek MMORPG +

Originally Posted by Ereiid:
I would offer that class systems exist predominantly for balance purposes, the tradeoff is in player diversification and freedom. I can only surmise from the precedent of other games that class-based systems are substantially less difficult to adaptively balance, in contrast to skill or profession-based systems. Their prevalence in MMOs is a conceit of the developers' and designers' desire to make their own jobs as easy as possible.

That is precisely my feeling as well.

I'm sensitive to the practical necessities of meeting budget limits and schedule milestones. Making a triple-A MMORPG is such a vast undertaking that I absolutely can understand the desire to simplify a core system like character abilities.

But it's the fact that character abilities are a core system -- possibly the core system in any RPG -- that makes me think it's critical for this part of the game to be designed with the player in mind, not the developer. I think players of a Star Trek RPG are going to want more freedom to define their characters than allowed by the restrictive class-based ability model of conventional fantasy MMORPGs. If that means a character ability system that's somewhat harder to balance than a simple class system that stuffs every player into the round holes of the usual combat roles, then so be it -- if this part of the code is somewhat harder to write and maintain, that is a price worth paying to get a character ability system that makes every other gameplay design decision more consistent with the license.

Finally, I'd point out that nowhere is it written than developers can't offer both individual skills for the players who like creative freedom and preconstructed templates of skill clusters for those players who prefer the simplicity of filling a specific role. If a lot of players choose the templates, that makes it easier for developers to balance character abilities while still allowing other players to create the unique characters that are important for their gameplay satisfaction.

Finally, I'd ask developers to think about something: What does "balance" mean for non-combat grouped content, anyway?

Tanks, Nukers and Healers in a Star Trek MMORPG +

Regarding designing character classes (if we must restrict ourselves to thinking in terms of "classes" -- sigh) around roles, the bottom line for me with respect to a Star Trek MMORPG is that those roles do not need to be and should not be combat-specific roles. That, IMO, would be dead wrong for a Star Trek Online.

The simplest, easiest approach would be to conceive of ST:O as another combat-focused game, designing Tactical, Engineering, and Science as mere classes optimized for killing stuff, perhaps with specializations to serve in the usual "combat support" functions. Crafting would merely be implemented as a few "tradeskills" that anyone could level up in.

Does this really sound like the right way to go for a MMORPG based on Star Trek? It doesn't to me.

So, if we simply must have classes, I see the more reasonable alternative as letting Tactical/Security and Engineering and Science/Medical be their own roles around which class-appropriate skills can be designed. It simply is not necessary for these roles to align perfectly with tank/nuker/healer -- as long as there are clear roles, so that those kinds of players who like knowing what they're supposed to do can have that information, I think most gamers will have zero difficulty with those roles not being the conventional combat roles.

Let Star Trek Online be its own game. As long as it's internally consistent, deep, and polished, it will have a fair chance to succeed.

Tanks, Nukers and Healers in a Star Trek MMORPG +

My feeling is that while damage-dealing and healing do go back to pre-computer RPG designs, the notion of a "tank" role is something unique to computer-based RPGs.

Tanking is a gameplay concept that flows from an earlier design choice not to implement collision detection between NPCs and PCs. Once you've made that decision, NPCs are easily able to attack the characters playing the typically weak healer and caster roles. And once they're down, a total party wipe usually follows. Not fun. So as a quick-and-dirty "solution" to that problem, MMORPG developers came up with the notion of "aggro"... and poof, the tank role was born.

The point here is that collision detection is purely a problem for computer RPGs. In a non-computer roleplaying game (e.g., tabletop or LARP) where the live players are expected to know and follow the rules of play, you can simply say, "I attack Darg the Evil with my broadsword," or plop down a die-cast figure on a scale map of a dungeon, and that's that -- you get to soak up damage. Any physical damage-dealer is also automatically a "tank," so no one ever thinks of them primarily as fulfilling that combat role.

Explicitly designing character classes to satisfy a perceived need for a tank role thus shows up only in computer-based RPGs -- specifically, in MMORPGs where the rules which tell attacking NPCs what they can and cannot do physically must be implemented in code, and where one of those coded rules is that characters can pass through each other without colliding. (This may actually be a result of the developers choosing not to implement collision detection -- same result.)

If there's no need to code an "aggro" workaround because physically tougher player characters can physically get between attackers and weaker player characters, then there's no need to design player character classes around a tank role for attracting and holding aggro. More broadly, designing Tactical and Science and Engineering department-based abilities around tank/nuker/healer roles -- for no other reason than because other MMORPGs decided to implement those roles -- would be to embrace precisely the kind of foolish consistency that Emerson warned us against.

Aligning character abilities to certain preconceived gameplay roles isn't wrong in and of itself. It's only wrong if those roles are adopted as conventions, if they're merely copied from other games without asking whether they help communicate the overall conception of this game set in this unique universe.

Which returns me to my overall point, which is that if the action in Star Trek Online should be something more than non-stop destruction, why design character abilities around purely combat roles at all?

There will be more than enough challenge in balancing character abilities specifically designed to support Tactical/Security and Science/Medical and Engineering (and Command) gameplay without also having to try to shoehorn them into the tank/nuker/healer roles copied by other MMORPGs.

Tanks, Nukers and Healers in a Star Trek MMORPG

Originally Posted by Brian_Starr:
From what I have read, the three available classes include most of what you are talking about. True, most MMO's use a Tank, Healer and DPS, but what is a [Tactical] officer? A Tank, what is a Science officer? A Healer. Who makes the Phasers fire? The Engineer/DPS.

Not only do I disagree that the associations you describe exist naturally, I have to say I would strongly oppose any suggestion that the developer of Star Trek Online should try to force such associations when designing Tactical/Security, Science/Medical, and Engineering gameplay. If this game is deliberately designed to stuff those three Starfleet departments into the conventional tank/healer/DPS roles, my interest in playing such a game goes way, way down. (If there's so little imagination applied to something so core to gameplay, what hope is there for thoughtful design in the rest of the game?)

Gameplay for those who choose to specialize in the Tactical department should be about effectively operating offensive and defensive systems for any kind of hostile encounter or environment. If the Big Three roles factor into departmental gameplay design at all, then I think we'd have to say that Tactical officers in a Star Trek RPG are both tank and nuker, and in addition to those roles have capabilities (that aren't part of any typical MMORPG) for surviving purely environmental challenges. ("Captain, we're encountering an area of severe gravimetric distortion." "Shields up, Mr. Tactical Officer! Divert power to structural integrity!")

Gameplay for those who specialize in the Medical subdepartment of Science should be about healing, yes, but as a scientific discipline it also ought to be about discovery, and about creating new processes, and about understanding biological and physical systems, and about the exploration of unknown worlds and phenomena and cultures. Reducing Science/Medical gameplay to the "healer" role (or the even less appropriate "crowd control" role) would lobotomize it.

As for those who specialize in Engineering, their gameplay ought to be about constructing and maintaining and repairing complex technologies. Sure, they can make phasers work... and transporters... and warp engines... and communicators, etc., etc. In a way, Engineers ought to be thought of as the middle way between the theoretical Science officers and the aggressively hands-on Tactical officers -- a good Engineer will be highly competent at the intersection between "thinking" and "doing." Engineering gameplay in a Star Trek MMORPG ought to be designed to support that kind of fun, regardless of how other MMORPGs slice things up.

Overall, I understand the value of roles in MMORPGs. I know there are gamers who like to know exactly where to go and what to do, and that having very simple and distinct roles makes filling positions in combat groups trivially simple. If some MMORPGs want to satisfy those well-worn roles by design, fine.

But there is no requirement that Star Trek Online's character advancement model and content must or should be designed around those particular roles. Even if ST:O has plenty of combat action, there is no good reason to design either its character ability system or its ship classes solely to satisfy the needs of combat gameplay as other MMORPGs do. For an online game wrapped around the Star Trek license, the usual three combat roles are inappropriate.

Tactical/Security, Science/Medical, Engineering/Ops, and Command/Helm are the correct roles for Starfleet characters (and ship classes) in a MMORPG based on Star Trek. The gameplay should be designed around those roles.