Gamasutra is part of the Informa Tech Division of Informa PLC

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.

Gamasutra: The Art & Business of Making Gamesspacer
The Genre Blender: Experiments In Social Gameplay
View All     RSS
February 20, 2020
arrowPress Releases
February 20, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


The Genre Blender: Experiments In Social Gameplay

January 4, 2011 Article Start Previous Page 3 of 4 Next

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.


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.

Article Start Previous Page 3 of 4 Next

Related Jobs

Tenacious Entertainment
Tenacious Entertainment — Bellevue, Washington, United States

UI Artist / Designer
Purdue University
Purdue University — West Lafayette, Indiana, United States

Assistant Professor in Game Development and Design
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Gameplay Programmer
Airship Syndicate
Airship Syndicate — Austin, Texas, United States

Senior Systems Designer

Loading Comments

loader image