[A team at Carnegie Mellon's Entertainment Technology Center launched a project to determine how to get multiple game genres -- racing, first person shooter, and puzzle -- to blend into one socially competitive experience, and here present the results of that experiment.]

As gaming becomes more social and more widely accepted, the division between game genres increasingly frustrates social groups such as friends and families. People want to share social gaming experiences, but their different tastes in games leads them to be forced to compromise in order to play together.

Asymmetrical Cooperative Gaming (ACG) is a semester-long project at Carnegie Mellon's Entertainment Technology Center aimed at solving this problem by merging multiple game genres into a single game, allowing players to play together while still using mechanics that are appealing to them.

This article will discuss the successes and failures of the project in order to inform and encourage similar designs in the future.

We will first cover the guiding design philosophy behind our game, Fusion, and then move on to specific design choices and their results. Our hope is to show that this sort of design is both highly enjoyable to players and not overly difficult to develop.

ACG started from the belief that nearly any genre of game could be integrated into a shared gaming experience. Throughout this paper, we will refer extensively to "modes", which in Fusion refer to the way in which a player enters the game for a match.

Essentially, a mode is Fusion's representation of a genre inside the larger game. In order to prove that a Fusion-style game could work, we set down four specific design goals that we felt were integral to a successful proof of concept.

For the purposes of our proof of concept, ACG chose three game genres: first person shooter, racing, and puzzle. We chose these because they are very different and the potential interactions between them are not obvious. If we can merge these three genres, it should be clear that other games and genres such as RTS, tower defense, Cooking Mama, and RPGs will also be able to be incorporated.

Inside Fusion, Soldiers have FPS mechanics, Pilots are modeled after racing games, and Hackers play puzzle games. Given our limited time, we used the mechanics of Bejeweled for the puzzle game, but the Hacker design could be applied to a wide range of puzzle games.

Level Design: Merging Spaces

If different game modes are truly going to play together, they must have a space in which to play. Passing information and resources back and forth is not enough; they have to share a space in order for players to really feel like they are playing together, rather than only playing related games.

If each mode has its own "space", then two problems arise. The first is that it's much harder to share moments, those specific events which everyone will be talking about after the game. In order to create those experiences, each player in the game needs to see the same event and understand it in similar ways.

Second, while it may be possible to have players in different places feel like they're supporting each other, it's extremely difficult to let them feel like they are opposing each other. In fact, the failings of the Hacker mode in the current design largely exist because they aren't as integrated into the shared space as they need to be, an issue discussed at greater length in the Feedback section.

This shared space is a key challenge in any Fusion-like design, because the game spaces of different games are different for a reason. Arenas in first person shooters tend to be small and compact, emphasizing conflict over travel. Racing levels tend to be much larger so that there can be a significant amount of track. And puzzle games rarely deal directly with any sort of 3D world. Designing levels to accommodate these different games is difficult; we didn't find any general rules to make the process easier.

There were three solutions we applied to the problem of scale difference between an FPS level and a racetrack. The first was to loop the track across itself into a figure eight. In this way, we fit more racetrack into a relatively compact space. This concept could certainly be further taken advantage of with an engine more specifically developed to allow for interesting racing physics, such as those seen in F-Zero.

Second, we made use of jump pads and could considered teleporters. Using these requires careful consideration, because it would be unfortunate if Soldiers could essentially move as fast as Pilots. The level needs to be satisfying for all modes, but it's important not to strip different play styles of their natural advantages. In our case, we used jump pads to allow faster access to key areas, creating points of conflict and interest where the FPS terrain and racetrack intersected.

Third, important areas for each mode should be combined so that all modes are encouraged to be in the same place as much as possible. In Fusion's case, there are parts of the race track that are difficult or impossible to reach for Soldiers, but those locations don't allow Pilots to earn points directly. All modes earn points at the same locations, making those places conflict zones where all modes must interact in order to achieve victory. Each mode can have areas that only they can access so long as the goals and mechanics of the game make it necessary to enter shared space.

Playtesting has shown that most of this design works as intended. The only flaw is that the racetrack has areas with no incentive for Soldiers to go. We thought that have points on conflict would be sufficient, but we're finding that Soldiers quickly stop caring about Pilot positions because the time that they can interact for is so short. If we were to redesign the level, we would make greater use of jump pads and place more important points for Soldiers around all parts of the racetrack to allow much more of the game space to be shared between those two modes.

The puzzle player presented the unique problem of merging a game that normally does not deal with 3D space into a 3D world. It was important that the Hacker have a physical presence in order to feel like they were a part of the same game. It would be strange for Soldiers to know that they were being opposed by an enemy, but for that enemy to not have a physical manifestation to attack.

At the same time, puzzle players generally don't navigate 3D space and given ACG's goals, we did not want puzzle players to deal with such unfamiliar mechanics. Our solution was Hacker Nodes; physical locations that Hackers could log in and out of without directly navigating the level.

While logged into a node, Hackers have specific options dealing with the world around that Node, without having to directly interact with it. The other modes can see that a Hacker is in a Node and attack it accordingly. While logging in and out of nodes is somewhat new to puzzle players, it is an easy mechanic to learn and doesn't take any time away from the main focus of playing the puzzle game.

A final challenge regarding level design in Fusion was symmetry. Having a symmetrical level that favors neither team is important in many games, but symmetry is dealt with differently in different genres. Specifically, racing games don't have to worry about symmetry because all players are racing down the same track.

What this meant for Fusion was that given that each team had a base and the race track had to move through the same space, if Pilots started at a shared start line then they would move into one team's territory first.

There were two potential fixes to this. The first would be to remove the concepts of bases or team territories, such that the disconnect between the symmetry of the world and the asymmetry of the racetrack would become irrelevant because each team would be equally affected. The second possibility would be to start Pilots for each team at different parts of the track. This option balances the level, but removes much of the feel of a traditional racing game.

We opted for the second choice because having territories made creating shared goals for all modes much easier. This solution did cause the Pilot design to drift slightly away from a traditional racing feel. The solution was not perfect and the problem should be further explored. With further development, it's likely that a track configuration where Pilots from either team can begin at the same starting line without either team having an advantage could be found.

Help and Harm: Translating Intent and Skill between Modes

Creating a social experience in multiplayer games relies on each player understanding two things about each other player; their intent and their skill. Game specifics like weapons and health matter much less than knowing what your allies and enemies are trying to do, and how good they are at it.

At its core, the goal of ACG is to remove the element of personal taste from the game while allowing intent and skill to remain, such that each player can show off their talent and strategy without having to fit those things into a genre that other people prefer.

As such, translating intent and skill between modes is absolutely essential to making a Fusion-style game. The game's framework must allow players to express their intent and their skill at their own mode in a way that is easily recognizable and has a large effect on each other mode.

The clearest example of this in Fusion is translating aggression in and out of the Hacker mode. When an FPS player fires a weapon at someone, their intent is to kill that player. Their ability to do this quickly without getting killed themselves is the measure of their skill.

Normally this mechanic involves a health meter of some sort. Gunfire can generally be avoided by actions like dodging. But health is a concept rarely used in puzzle games and forcing that concept into the Hacker design would have created a disconnect between the Hacker mode and the puzzle genre that inspired it.

What is important is that the Hacker knows that he is being attacked and that he has a way to respond. As such, when a Hacker Node is fired upon, the puzzle gets correspondingly harder. If the Hacker fails the puzzle while this is happening, then the hacker is booted, which has a similar effect to being killed or destroyed in the other modes.

If the hacker responds to the damage by successfully completing the puzzle despite the increased difficulty, then the Hacker escapes unharmed, essentially having 'dodged.' In this way, Soldiers attack in their traditional way and Hackers defend by doing well at the puzzle game. Their skills are being tested against one another without either needing to concern themselves with unfamiliar mechanics.

Hackers need a way to not only endure attacks, but also retaliate or start attacks of their own. Soldiers and Pilots understand aggression in the form of weapons fire or, in the Pilot's case, obstacles appearing on the road. Puzzle players shouldn't be forced to aim or otherwise deal with the 3D world, so having them deal directly with those sorts of attacks wouldn't work. There should be a way for their puzzling prowess to directly translate into effective attacks. We accomplished this through the use of automated turrets.

Hackers have the ability to spawn turrets near their nodes, which automatically attack nearby enemies. How often Hackers can create turrets is item-based, meaning that a Hacker creating a lot of turrets could be the result of good teammates, rather than skill on their part.

But the Hacker chooses what node to be at when they create turrets, putting the strategic element in their hands. More importantly, the effectiveness of the turrets depends on how well the Hacker is puzzling, so if turrets appear and begin decimating the opposing team, it is clear that the Hacker responsible must be quite good.

This specific aspect of Fusion's design illustrates the importance to translating both a player's intent and a player's skill between modes, so that the player on the receiving end can understand both aspects inside the context of their own game. This is important for game balance and cohesion, but also necessary in order for players in different modes to respect each other's the strategy and skill.

Intuitive Common Goals

How victory is defined needs to be easily understood within the context of each game mode. While not absolutely necessary, we recommend that some form of abstract point system be used, although specific goals can be designed around it. Actions like killing, solving problems, or completing laps can sometimes be hard to tie together into an understandable team goal and it's important that each player understand how each other mode is succeeding so that they can either help or stop them.

If the way of succeeding in a traditional genre can be incorporated into a shared point system, then each player can strive for success in familiar ways, while seeing the success of players in other modes being reflected through the same system.

For Fusion, we kept this system very abstract as a matter of scope. We considered making a number of smaller goals that worked towards victory which could each be accomplished by any mode. For instance, a sealed door could be destroyed by Soldiers, bypassed by Pilots, or forced to open by Hackers, allowing that team that much closer to their opponents' base.

Due to scope issues, we abandoned those ideas in favor of simpler design, but we believe that a more complicated level with smaller shared goals could do a lot increase the variety and cooperative elements of a Fusion-style game.

Game Balance

A feature of Fusion's design that people were generally skeptical of was the ability to balance teams regardless of configuration. Making the three modes balanced within a team seemed like enough of a challenge without trying to make a team of three Hackers equal to a team of one of each mode.

While it is certainly true that balance is a difficult aspect of any design and is particularly challenging in a Fusion-style game, it is not insurmountable by any means. Balance can be tested and adjusted in a similar way to any design as long as the actions available to each mode are thought of in general terms. In other words, we strove to make each mode equally good at the three roles of attacking, defending, and supporting. As long as each mode is equally good at each of these three areas, then the mix of modes on a team becomes a much less significant factor.

This in itself can be fairly difficult, as fully explained in the next section. In addition to the problem of different modes having different strengths, there are two other factors that make balance difficult. The first is that interesting mode interactions have to be carefully considered and sometimes thrown out if there are not equivalent opportunities for other modes.

For instance, if Pilots have the ability to take Soldiers to an area not reachable on foot, then Hackers also need a way to provide that assistance, or alternatively Hackers need an option for helping Soldiers that is equally as powerful and as interesting as the Pilot option. This gets back to our original design philosophy of no player being pressured into a particular mode.

If options exist only for specific team configurations, then groups of players will feel pressured to use those configurations. This constraint can be difficult to work around and results in the abandonment of many potentially exciting interactions.

This was the result of our aim to create a situation where no player is pressured to choose any particular mode. A Fusion-style game could certainly be designed where the emphasis is on complex strategy, rather than ACG's goals. In that instance, designing elements that require or encourage specific team configurations would certainly be an option.

Similarly, we refrained from design options that would have added interest to modes, but also would have taken them further from the genre that inspires them. For instance, Hackers could be given the ability to specifically place their turrets, which adds a lot more tactical control. That mechanic is very reminiscent of Tower Defense rather than Puzzle, however, and so we didn't put it in.

The one aspect of balance we have found most difficult has come from creating interactions within a single mode. We want each mode to be able to help each other mode, but if a Soldier can help another Soldier, it becomes much trickier to make it so that a single Soldier is encouraged to work in a team instead of using those game elements to simply help themselves. Designing mechanics where a player in one mode can help other players in the same mode, but not themselves is certainly possible, but it's generally more awkward and would take more time to develop.

For instance, the racetrack could have a trigger that when driven over open a better track for Pilots, but if this track was behind the trigger than the triggering Pilot wouldn't be able to use it themselves. This sort of mechanic that specifically aims to keep the benefits of an action from the player initiating it has the potential to be confusing to players. As a result, teams in the current iteration of Fusion generally benefit from having at least two modes represented.

Not All Modes Are Created Equal

Our design principle of having each role be equally good at attacking, defending, or supporting was the first to principle to be reconsidered in response to design challenges. Everything about a first person shooter is designed to be aggressive, and putting that level of aggression in a racing game is very difficult, largely because racers have less ability to hunt down other players.

While attempting to solve this problem, we realized that we also need to take into account different mindsets. Not only is it mechanically more difficult to have racers be as aggressive is shooters, it also isn't something that players who gravitate towards racing games are looking for.

As a result, we are amending our principle to state that each genre should be as equal as possible in the roles of attack, defense, and support, and that when it comes to balance the designers need to make sure that the strengths and weaknesses of each mode are balanced.

In Fusion, Pilots are not as good at being aggressive as Soldiers, but they are significantly faster and more able to earn points than Soldiers unless they're being attacked.

As a result, a Soldier-heavy team will be more aggressive than a Pilot-heavy team, but will also have to use that aggression well to counter the benefits afforded by a Pilot-heavy team.

Finding Weaknesses

The key to finding good ways for one mode to help another is to find the other mode's weaknesses. It is useless to design cooperative elements that no one is inclined to use. A player has to be thinking, “I wish my mode was better at...” and then provide a way for another mode to solve the problem.

The Soldier-Pilot passenger mechanic in Fusion is based on the idea that Soldiers feel slow and will want to take advantage of a Pilot's speed. At the same time, Pilots feel vulnerable and want to take advantage of a Soldier's firepower. Creating these interactions with Hackers was more difficult because Bejeweled doesn't lend itself to these kinds of opportunities for assistance. We created some weaknesses for Hackers in the overall framework of the game, but because those weaknesses aren't a part of Bejeweled itself, Hackers weren't inclined to worry about them.

We finally decided that what Bejeweled players want is the ability to destroy more gems and earn levels faster. To aid in that, the other modes can unlock additional Hacker Nodes across the level for their team, which give these sorts of bonuses to their Hackers when logged in.

Cooperation Should be Obvious

One of the overarching systems that applies to every mode in Fusion is the team inventory. We created a shared inventory and the ability for team members to collect items for any mode as a way to allow any player to quickly and intuitively help any other. This has worked to an extent, but it fails to create a real sense of teamwork because it isn't easily noticeable.

Having the items you need when you need them is rewarding and creates a sense that there's some help among the team, but because the system is external to the game world and because messages concerning who is earning and using items are largely ignored, it doesn't create any real direct connection between players.

In contrast, the ability for Pilots to pick up Soldiers is significantly more rewarding because it's directly apparent what the benefits are and who's helping who. General systems like the inventory are still useful and provide a low-cost way to begin integrating new genres, but in order to create real shared moments between players in different modes, there must be mechanics that allow both players to directly see the effects of the teamwork.

Constraints on Genre-Selection

What genres can be merged into a Fusion-style game? Our only constraint when creating Fusion was that it be real-time. Merging real-time genres with non-real-time genres would be an additional challenge. True cooperative gaming would be hampered by the very nature of turn-based or play-whenever games, but a system could be devised where support could flow in and out of real-time.

Mechanics Should Be Shared

To make Fusion approachable to a large variety of gamers, it is important that our design not require a player in one mode to understand exactly how the other modes work. We ran into a problem where this was taken too far and some players didn't understand how to thwart the other modes.

Specifically, Hackers rely on a level system and initially the other modes didn't. Preventing Hackers from accruing too many levels is key to stopping them from winning, but since Soldiers and Pilots had no parallel system, that was never an easy thing to remember or respond to. We wanted to keep the level system for Hackers, and so we created parallel level systems for Pilots and Soldiers using elements already prevalent inside their own experience. Soldiers earned levels with kills and Pilots earned them with laps.

All three modes earn more points at higher level and lose levels for being destroyed. By making the mechanic universal instead of mode-specific and by publicly displaying the current level of all players, we created an awareness in all players of how to use the system to their advantage and overly-leveled Hackers became far less of a problem.

Feedback

Giving players feedback is important in any game, but especially so in something like Fusion. Because a player in one mode may not understand how the other modes work, it's important that they get feedback telling them how teams and individuals are doing. Specifically, they may not intuitively know when one of their allies needs help or when one of their enemies has become a significant threat and needs to be dealt with. Explicit messages alerting them to dangerous and important situations clear up a lot of the confusion in the game.

Earlier it was described how intent has to be translated between game modes. The actual translation can be behind the scenes, but the results sometimes need to be made explicit. In the Soldier-Hacker example, a Soldier needs feedback on how much damage they are dealing to a Hacker Node since a Hacker's form of "dodging" isn't apparent in the world.

And Hackers need explicit messages telling them when their turrets have killed an enemy since they're focused on their game board, rather than the turrets. Whenever a player is given the chance to affect another mode, the design needs to take into account how apparent it will be to them if they're successful or not and how to make it more obvious if need be.

Integration

The way that puzzle gaming was integrated into Fusion succeeded in several aspects, but failed to some degree in making the Hacker truly feel like they were a part of the shared experienced. The reason for this was the disconnect between the actual puzzle mechanics and the larger world.

All of the Soldier and Pilot's potential actions had some effect on the shared space, but the actual puzzle mechanics did not. Fusion's design made strong ties between success in the puzzle game and effects on the larger game, but the puzzle itself had no connection. We believed that the ties would be enough, but because puzzle games tend to make players myopicly focused on the task at hand, the disconnect between that task and what their allies and enemies were doing resulted in Hackers feeling more isolated than the other modes.

The lesson learned here is that the mechanics of any mode in a Fusion-style game should relate directly to the larger world as much as possible. Ideally, a puzzle game would relate directly to the terrain around the Hacker node and things like other players moving through that space would directly affect the puzzle.

With the current set-up, feedback about the world was helpful to Hackers, but it was often ignored because of how far removed it was from what Hackers were trying to accomplish from moment to moment.

Unintended Benefits

With Fusion, our hope was to allow each player to play a mode familiar to them, without needing to understand much about the other styles of play. Not only did that work well, we discovered an interesting aspect of Fusion that we had not expected.

In most of our play tests most players played a mode for three or so games and then switched to one of the others. Although they generally preferred their initial mode, seeing the other game types in the same world made them want to see how those modes worked as well.

In this way, many players explored game genres they otherwise have little interest in and in some cases enjoyed them more than expected. Although this is secondary to our intended goals, it's exciting that a Fusion-style game could allow players to not only play together, but also to share their own tastes with each other.

Conclusions

The purpose of the ACGproject was to explore the difficulties and potential of merging genres into a single game experience. What we found is that the design of such games is difficult and presents unique challenges, but more importantly that these challenges are managaeble and well worth the effort. With more development time, we believe that a game like Fusion would not only be possible, but also very well received.

Merging the mechanics of multiple genres is not especially difficult. A well thought-out framework that translates player intent and skill between modes is an essential first step. This framework must provide a clear goal for the team of players independent of the specific modes. Once developed, this framework makes the process of integrating the games no different from any other design process. Then the development of specific interactions and features can progress just like any other design.

Merging audiences is similarly possible. The premise we worked from was that these different people already want to play together; they just do not have an enjoyable way to do so. That turned out to be largely true, and testing shows that a wide variety of gamers do enjoy Fusion and the opportunity it provides for shared play. It also provided a way for players of different genres to show each other their own skill in a context that would earn respect from each other. The main difficulty is in allowing different play styles.

Different audiences will enjoy different levels of conflict and strategy and it's important that players in each mode have an ability to play the game in such a way that it appeals to their tastes. We also recommend that in an asymmetrical cooperative game, different skins be available such that players have some control over the artistic style they experience. If players could control aspects such as the sound effects to the level of gore, they would be able to custom-tailor the experience to better suit their tastes.

The end result of our design, development, and testing is that we are confident that merged-genre games are possible and enjoyable. Within the scope of this project, we discovered particular difficulties with aspects such as keeping a genre's feel intact while affording it the same basic options as each other mode inside the game.

The changes we made in response to these discoveries have created improvement to the player experience even within our limited time frame and we have no doubt that such obstacles can be overcome without much more difficulty than design challenges in traditional single-genre games.

As a final note, we leave you with these general design principles that we hope can serve as guides in the design of this style of game:

We hope that you have found this useful and that other developers will see the potential of Fusion-style games. You can take a peek at some of the gameplay of Fusion at http://www.youtube.com/user/ACGFusion. If you have any additional comments or questions, please mail them to [email protected]. You can visit the Fusion website at: http://www.etc.cmu.edu/projects/acg/.