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 24, 2020
arrowPress Releases
February 24, 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 2 of 4 Next

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.

Article Start Previous Page 2 of 4 Next

Related Jobs

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
Futureplay — Helsinki, Finland

Senior Game Designer

Loading Comments

loader image