The Science of Multiplayer Mapping

Exploring how to make a great multiplayer map.

Every multiplayer gamer has a favourite map they like to play on. Mine is "Facing Worlds" from the original Unreal Tournament. It's a Capture The Flag map on which two colossal towers stand at either end of a diamond-shaped asteroid. It's only a short, straight run to get the flag from one tower to the other, but to do so successfully you have to run a gauntlet of sniper-fire from the opposing team's defence, and avoid the occasional, devastating nuclear blast of UT's most powerful weapon: the Redeemer.

Facing Worlds

Facing Worlds is simply designed, easy to learn, and beautifully balanced. That's why it's my favourite map. But perhaps your heart lies with classics such as Counter Strike's DE_Dust, or Goldeneye's Facility. Or maybe you're of a more modern taste, something along the lines of Modern Warfare's Vacant or Battlefield 3's Caspian Border. But what does it take to create a truly memorable multiplayer map? How does the concept of "mapping" differ from single-player level design? And does mapping have a future in the days of MMOs, open-world games and procedural generation? To find out, we're going to go right back to the beginning of mapping as a phenomenon, and speak to the designers of some of the most famous multiplayer maps around.

One of the early examples of a multiplayer shooter with truly memorable maps is GoldenEye 007. Mention words like "Temple", "Facility", and "Archives" to any gamer who was vaguely in the proximity of a Nintendo 64 during the late 90s and they will know immediately what you are referring to. Prior to GoldenEye, the main focus of multiplayer games was simply getting the "multiplayer" bit to work. Right up to the development of classic shooters like Doom and Quake, simply having two or more players competing in the same game space was the priority over and above whether the level design was particularly suited to the experience.

GoldenEye's Facility.

Interestingly, this was initially also the case for GoldenEye. This classic multiplayer experience - the first multiplayer FPS to really work on a console, was actually a last-minute addition to the game that the team had almost no idea how to approach.

"There wasn't a lot of reference, so we were really making it up on the fly," says Steve Ellis, 2nd Unit Director on GoldenEye and the man largely responsible for programming the multiplayer side of the game. "We had a game that had been completely coded as a single-player game, and the first step was a tedious trawl through every line of code to correct all of the assumptions that there would only ever be one player."

We had a game that had been completely coded as a single-player game, and the first step was a tedious trawl through every line of code to correct all of the assumptions that there would only ever be one player."

Working with very limited hardware, the team began to methodically play through the single-player game to figure out which levels would actually function with four players running around them. "Some levels were eliminated because the increased memory requirements for split-screen meant that they simply wouldn't load," Ellis explains. "More were eliminated due to the frame rate not being high enough when rendering them 2-4 times."

The remaining levels were what ultimately formed the multiplayer component, at which point Ellis and the team began making slight changes to make them better suited to multiplayer based on their playing experiences. "The alterations for multiplayer were to simply place start points, health, armour, guns, etc. and maybe lock a few doors to block off some areas."

Altering level design based on playtasting is one of the most, if not the most, crucial aspects of game design, especially in multiplayer mapping. Known as iterative design, its importance is highlighted by the fact that Ellis believes those particularly memorable GoldenEye maps are the ones the team played more than the others. "They're probably the levels that we spent most time playing and iterating on the layout and setup," he states.

This process of testing, elimination, addition and refinement is particularly vital in building a successful free-for-all style map. Predicting how players will use the game-space is virtually impossible, so the only way to ensure the experience is fair and enjoyable at every point in the map is to test it extensively. Simple things like a particularly powerful weapon being too close to a particular spawn point can unbalance a map. Because GoldenEye's multiplayer started out with a basic framework of levels, it meant they could focus entirely on testing and refining, rather than designing and building.

Counter Strike's DE_Dust.

While designing Free-For-All maps is largely about testing and responding to how players fight on the map, it isn't quite the same for team-based shooters like Team Fortress and Counter Strike. "In many ways, it's easier," says David Johnston, creator of Counter Strike's DE_Dust and Dust 2, "as you can quite easily determine where each team is going to meet, and can time your map accordingly."

Ironically the more restrictive these rules there are, the better, since they encourage greater levels of creativity."

Now working for Splash Damage, Johnston became involved in map design much the same way as Rare created GoldenEye's multiplayer: by taking existing maps and changing them, working out how he could make them more enjoyable. Dust itself was based on map designs for the original prototype of Team Fortress 2, although the actual map was built from scratch. As with GoldenEye, there were no specific plans for the structural layout. Rather, Johnston used the theme of a desert town to base the construction of his map around.

"It's the theme that dominates your thinking and defines the exact aesthetics, structure and flow of the world," he explains. "Ironically the more restrictive these rules there are, the better, since they encourage greater levels of creativity."

Similarly, building a team-based multiplayer map imposes its own set of rules and restrictions. A designer will always encounter the same basic problems. The first is ensuring the map is balanced. The most obvious way to do this would seemingly to make the map symmetric, like Unreal Tournament's Facing Worlds, but according to Johnston this isn't the case. "Even perfect symmetry can't guarantee a map is balanced, especially in objective-based games such as Counter-Strike where each team has very different, conflicting aims. Here, the skill is to visualise how you expect the map to play out and ask questions such as ‘if an attacker stands right here, what can a defender do?’"

Even perfect symmetry can't guarantee a map is balanced, especially in objective-based games."

But such tit-for-tat design causes an issue in itself: it can lead to the entire game grinding to a halt. These choke-points are a common problem in team-based maps. "The key is to give players options, and their opponents options to counter them,” says Johnston. “You want to ensure one team can always surprise the other. At some point one team will get the jump on the other and the map will progress." In the case of DE_Dust, the map features a tunnel in the centre of the map with various entry and exit points, enabling both teams to flank their opponents' position.

Creating a successful team-based multiplayer map, then, involves constantly thinking one step ahead of yourself, and ensuring that no matter how well a team can build up their defence, there is always a way the other team can get around it. Yet while such theorising is all well and good, Johnston emphasises that playtesting and iteration are still massively important in creating good maps. "Gameplay issues need to be found and resolved as early as possible, as they can be hard or costly to resolve once a map is further down the production pipeline. Additionally, the complexity of modern maps creates a far wider opportunity for bugs and exploits."

Indeed, multiplayer maps seem to be getting bigger and more ambitious all the time. Halo introduced wide-open maps and vehicles to multiplayer combat in 2001, and the likes of Call of Duty and Battlefield have taken things even further, the former adding persistence to your play in the form of upgrades and unlocks, and the latter featuring maps big enough to play entire military campaigns on, scaling right from the individual soldier right up to massive, coordinated assaults including tanks, helicopters and jets.

But by far the most ambitious, most complex multiplayer maps are to be found in Planetside 2. Sony Online's MMOFPS has hundreds, even thousands of players fighting simultaneously; entire virtual armies battling on maps so big that in-game they're known as continents. How do you create a game of that scale, while retaining the immediacy and delicately balanced environments of a more confined multiplayer shooter? Is it even possible?

"Balancing good flow vs. player movement freedom on a massive scale, while keeping the areas within performance limits, has proved to be incredibly difficult," says Matt Higby, Creative Director on Planetside 2. "We try to keep our levels varied. If we have a barren location that is good for large scale armor fights, it will be punctuated by areas of more dense cover where Infantry can set up traps to catch vehicles. Once you get into facilities or outposts we have a lot of guidelines we follow to make sure that the level provides a good balance of flow, safety, and navigability."

As if the sheer size of the game wasn't enough of a challenge, Planetside 2 features three teams fighting over continents rather than the traditional two, meaning the game has an additional layer of unpredictability. However, Higby states that having three teams is actually advantageous to a game of this size. "If one empire is overpopulated, the other two can work together to help balance the advantage out," he says. "In terms of designing the levels, it’s certainly a factor. We expect certain bases to be contested by two empires more often, and others to be three-way fights more often, but the level flow and outpost design reinforces those expectations as much as possible."

The size and complexity of Planetside 2 also means the traditional method of playtesting a map to ensure balance and flow is not really a possibility. Instead, Planetside 2 relies on its players for playtesting through the Public Beta server, used for introducing new features, and also to generally shape their own experience, how the maps are balanced, and where the choke-points are. "If an area is particularly well defended and players want to bash themselves against the defenders, they can do so for hours," Higby points out.  "It’s really up to players to decide they can’t breach a base and move to another attack vector or not. There’s very little in the game that forces players to attack a specific location or move from a defensive position, except their own decisions."

Planetside 2 feels like the zenith of the multiplayer FPS, certainly in terms of map design. It's difficult to see how it could possibly go further, innovate over and above what has already been done. Titanfall is promising mech-based combat and a more storied approach to multiplayer, but neither of those things are precisely new. Then again, many of the most popular multiplayer games, and the memorable maps that go along with them, have emerged as an unexpected consequence of something else. "Multiplayer maps for single-player games especially have always about pushing game boundaries, inventing new gimmicks and trying out wacky ideas well beyond the scope of the original game," David Johnston says, "And that's what makes many of them so much fun."