This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
[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.
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.