Multiplayer Level Design In-Depth, Part 3: Technical Constraints and Accessibility

Introduction

My first paper dedicated to multiplayer level design tackled the specific constraints imposed by the multiplayer game mode compared with that of single player. Later, my second paper detailed the level design rules that I consider to be the most important to respond to these constraints. Today, I will tackle another equally important aspect of the development, balancing.

Fine Tuning

Balancing consists of ensuring that no player or group of players can keep the advantage systematically throughout the game, by making the most of a game parameters (the power of a weapon for example) or of a weakness in the map. This problem is particularly seen in multiplayer games, because their users have plenty of time to discover the faults of the game and exploit them to their full effect. As maps are played for tens of thousands of sessions and players easily swap tricks among themselves.

A fault in a map could potentially kill the entire map by enabling a player or a group of players to reach a highly destabilizing advantage. That very problem was raised in one of the multiplayer maps we developed for Splinter Cell - Pandora Tomorrow's Warehouse. In this map, divided into three areas, the killed defenders spawn in a small room next to the first play area. This room is obviously reserved to the defenders and the attackers are not supposed to have access to it.

After a few weeks of use, we realized that attacking players had found a technique to enter this room by taking advantage of the moment when one of the defenders walked out of it. As soon as they were inside, they could easily kill the defenders as soon as they respawned! Such a fault could have made the map unplayable. Fortunately, this was not the case, thanks to the fact that the map was divided into areas, because as soon as the mission objective of the first area was reached, the players move on to the next area.

A poorly balanced game ends up making the players lose their interest, because nobody likes fighting against an opponent who benefits from an unbalanced advantage. Note that balancing isn't only about level design, but also the game system and the game design. Three directions must be considered to balance a multiplayer game: the level design itself the game design and the playtests.

Level Design

The first level design decision that is likely to affect the balancing of a game is the map's size and the number of players it can support. A small map generally makes balancing more difficult, because tiny details are amplified by the density and the speed of the action. Conversely, if the map is too large, the players will get bored because encounters will be rare. The choice of the ratio between the number of players and the size of the map is therefore very important. In most cases, opt for relatively large maps. They offer more tactical opportunities, and it will therefore are more difficult for the players to take advantage of the faults of the map.

The map layout itself can favor the balancing of the game. An open map (outdoors, for example) and the use of the third dimension (see my paper dedicated to map design) will make it difficult for bottlenecks, which could create destabilizing situations, to occur. Such maps offer more tactical opportunities than "flat" indoor maps.

Finally, the map should also offer various opportunities to use the game design features: weapons, equipment, moves, and so on. The maps of the multiplayer versions of Splinter Cell - Pandora Tomorrow and Chaos Theory include many places where an attacker can hide to prepare to ambush a defender, objects to hide behind, high footbridges to supervise a large area and accurately throw grenades, and pipes along the ceiling of rooms used by the defenders which allow the attackers to jump them.

The Game System, or The Balancing Of Opposing Forces

The idea is to provide the gamers with enough "tools" so they can find a counter-measure to a possible imbalance. The game designers who worked on the multiplayer versions of Splinter Cell - Pandora Tomorrow and Chaos Theory controlled this dimension of the game system very well. Each piece of equipment the players have at their disposal is characterized by the possibilities it offers to its user, but also by the opportunities it offers to the opponents. Here are a few examples: the defenders' laser enables them to inevitably find the opponents by scanning the surroundings, but it also allows attackers to spot the defender from a distance and to see what he is looking at. The attackers' camouflage clothing enables them to greatly reduce the risk of being spotted by the opponents, but it also restricts speed. The laser mine is discreet, but the attacker can easily spot its ray by activating electronic vision. This approach limits the risks of having any specific piece of equipment become too powerful.

Playtests, The Gameplay Quality Assurance

Regardless of the time you spend "planning" your game or level design in order to identify potential weaknesses, there is nothing like putting the game to the test in the hands of experienced gamers to see how badly they break it and take a malicious pleasure in exploiting its faults.

Generally, playtests are particularly useful during the development phase of a game. They have become essential for a multiplayer game. In fact, gamers - most often hardcore gamers - will spend hundreds of hours exploring every slight detail in the map, applying all the different tactics generally used in this type of game: testing all weapons and equipment, searching for any fault in the level design, and any bugs that will enable them to take advantage over their opponents. Consequently, the weaknesses in the game or level design are quickly revealed and the game soon becomes less interesting. Properly conducted playtests allow the detection of faults in the level design, or poor settings of the game parameters such as the power of weapons, health levels, and so on.

In addition to my responsibilities as the lead level designer of the multiplayer versions of Splinter Cell - Pandora Tomorrow and Chaos Theory, I also implemented and supervised the playtest structure of the Ubisoft's D'Annecy studio where these versions were being developed. The managers of the studio were so aware of the importance of playtesting that they wanted the testing to be done in the same building, so that the development team could be directly connected to the playtest team.

How did we use the playtests?

In Splinter Cell - Pandora Tomorrow, the setting of smoke grenades gave rise to lots of playtesting.

Conducting a playtest campaign is a particularly rewarding experience for a development team. To see how real gamers use the game and how they change the use an item from its original function (as I saw in the case of proximity mines that were often used as presence detectors by the defenders) to understand why they don't use certain equipment that seemed so cool at the design meetings. Playtests are the tool that separate what looked great on paper in a design meeting from what is more important: what the gamers will actually use.

Design Solutions to Respond to Technical Constraints

In the first part of my series, which tackled the issue of level design for multiplayer games, I introduced three technical constraints that have a particularly significant impact on the design:

Let's look at a few possible solutions to these constraints.

The Bandwidth Bottleneck

Previously, we saw that developers must maintain a balance between the number of players that can be supported during a session and the complexity of actions (animations, map events, special effects etc.) that can occur. Today, the general trend is to favor the number of players rather than the wealth of interactions in the map. I am convinced that this choice will evolve, because gamers want to have the same experience in multiplayer modes that they experienced in single player, such as map animations, destructible backgrounds, and physics management. Consequently, here are a few solutions for handling the bandwidth problem.

It is possible to hide a very complex animation by masking the animation behind a flash or a cloud of smoke, therefore avoiding overloading the bandwidth. We used this technique to its extreme in the Factory map that we developed for Splinter Cell - Chaos Theory, where a whole room can be destroyed following an explosion triggered by one of the defenders. The room is full of explosive barrels, which can go off if one of the defenders hits them with a bullet or launches a grenade towards them. It is obviously not in his interest to do that, because the room's layout would then be completely changed and the defenders' movement would be severely limited. Such a map event would have been impossible to carry out without sacrificing bandwidth. The level designer in charge of the map succeeded in handling this event as follows: when the room blows up, all those inside it are instantly killed. Consequently, they cannot see the explosion and if some sly gamer has the idea to fire from outside the room, the smoke prevents him from seeing the result of his action (see the screenshots below).

In this room of the Factory map (Splinter Cell - Chaos Theory), the defenders' movement is easy: there are few ground obstacles and the footbridge goes around the room on a higher level...

...but if one of the defenders triggers the explosion of the explosive barrels, the room changes completely. Movement on the ground is slowed down because of collapsed wall sections and the footbridge is a pile of scrap metal. Defending the room then becomes much more complicated.

A second solution consists in scattering bandwidth consuming elements around the map. In this way, no two complex elements will ever occur simultaneously. It is essential to ensure that they will never interact with each other.

Another option is to try to mask the movement of certain mobile objects such as elevators, whose movement may be obscured by opaque walls. Finally, remember to include the possibility for a player to throw a grenade in an elevator box while the latter gets ready for movement. The explosion should not interfere with the movement.

Finally, one last solution is to work on compressing the data exchanged between the game machines.

The Need for Event Synchronization

Synchronization problems account for most of the dissatisfaction among gamers. When a good player places the cursor on a moving target and pushes the trigger, he expects the bullet to reach the target immediately and exactly where he aimed at. If you are working on an FPS, this problem should be at the core of the development process. I see two possible solutions to this problem:

To develop a multiple server architecture. Traditionally, in a multiplayer session, one of the game machines acts as a server and synchronizes all the interactions resulting from the actions of the client machines. This architecture guarantees the synchronization among all machines, but slows down the data transfer, because the information related to an interaction between clients A and B must pass through the server first. With multiple server architecture, each machine acts as a server and a client at once. In this way if player A interacts with player B and the other players are not involved, data is exchanged directly between A and B. This solution was probably used in the Xbox version of Soldier of Fortune, a game appreciated by FPS "pros" for its precision. The multiple server architecture also offers another advantage compared with classical architecture, where a loss of connection with the server puts an end to the entire session. In case of multiple server architecture, players may start and end a session as desired.

A less elegant solution from a technical standpoint consists in using only weapons with an area effect, such as a shotgun, a rocket-launcher, or a grenade-launcher.

The Lack of Control over Players' Actions

The objective is to avoid that too many players find themselves in the same spot, so as to limit the number of interactions among them. Once again, the solutions are related both to the game and to the level design.

Increase the number of mission objectives and scatter them throughout the map. These two mechanisms were successfully implemented in Splinter Cell and Battlefield series of games. In the latter, players who select an engineer profile have access to many secondary objectives, such as the destruction of radar stations.

Another method to encourage the players to spread apart is to give them access to weapons that require them to preserve a certain distance from their foes. Battlefield also uses this mechanism by allowing the players to pilot a plane or control a turret.

Finally, my last recommendation is to avoid using small maps. However, the balancing between the size of the map and the number of players it can support is a delicate decision to make, because if the map is too large compared with the number of players, the player will soon get bored.

These "second best" solutions are far from being able to provide a long-lasting response to the multiplayer-specific technical problems. Other solutions exist. Essentially, my objective is to draw the attention to these problems so that they be taken into account very early in the development cycle of a game. I encourage my readers who have a solid technical experience to open a discussion thread and come up with additional solutions in the forum.

Getting Casual Gamers to Play

In my previous papers, I presented my suggestions to very specific challenges of multiplayer level design. I will end this series with what probably represents the main challenge: to make multiplayer games more accessible.

The very essence of a multiplayer game is to enable players of all levels to gather and play against each other. This is where the interest for this type of game lies, but this is also what makes it so difficult for the beginners. Playing against real human beings is intimidating, even if you are hiding behind a GamerTag. Yet, what happens when a casual gamer ventures into a multiplayer session is quite typical. Confronted with gamers who have mastered the game more than him, he repeatedly suffers humiliating defeat. It's therefore not surprising that multiplayer games are reserved for hardcore gamers. Nobody likes suffering defeat after defeat. If we want to make the multiplayer games accessible to the mass market, we have to handle this problem. The solutions lie both in the game and in the level design.

In my opinion, there are two solutions to this problem:

Features for Beginners

Let's begin by reviewing features that may be added to a traditional multiplayer game to make it more accessible. This is something that we tried to do with the multiplayer mode of Splinter Cell - Chaos Theory.

The first solution is simple and particularly effective. It simply consists in adding cooperative modes. Gamers will not play against other gamers in flesh and bones, but against opponents, bots controlled by the game AI. This solution allows gamers of all levels to play together without being humiliated by other gamers, as bots are rarely as unpredictable and dangerous as their human counterparts. It allows experienced gamers to show themselves to best advantage by sharing their experience with the beginners. Finally, the cooperative game may be an extraordinary source of joy, since working together to reach a common goal is one of the driving forces of the human adventure. A "coop" multiplayer mode was developed for Splinter Cell - Chaos Theory by the Canadian studio Ubisoft. This mode was a huge success.

The second solution is just as traditional. It consists in developing a mechanism for classifying the players according to their victories and giving them the freedom to choose to play only with other players of the same level. This mechanism is present in many multiplayer games, but its efficiency often leaves much to be desired. It is therefore not unusual to find yourself playing against much more experienced players, even of the same "level". In fact, playing on an unknown map is all it takes to ensure your defeat. To develop a classification system that is accurate enough to correctly evaluate a player's level is much more difficult than it seems. Aware of the problem, Microsoft has propose 'TrueRanking,' an innovative classification mechanism that takes into account a very large number of parameters to make a player's rank.

The third solution is to make the gamer learn the game by means of tutorials. Various types of tutorials may be created, outside the game and integrated in it. In the "versus" mode of Chaos Theory, we went deep into this matter, as we knew the game was hard to learn. Thus, the game includes a classic tutorial, made up of mini-sessions where the gamer learns how to handle his character. We added a mode that enabled the gamer to visit the game maps and discover the main features, in which all he had to do was follow a path marked by a light path and explanations (see the screenshot below). We added explanations to each element of equipment the gamers had at their disposal. We even made the player pass an examination map to make sure he understood the basics of the gameplay before giving him access to the multiplayer sessions.

The tutorial for map exploration in the multiplayer version of Splinter Cell - Chaos Theory. The path to follow is indicated by a light path and explanations are displayed at regular intervals.

What were the results of this abundance of help topics? The tutorials proved beneficial to get the new gamers started and prevent them from feeling completely lost in the map and in the game in general, but they were inadequate to give them a chance against the experienced gamers. After all, you cannot learn to drive just by reading a car's manual. A better solution can be seen in Battlefield 2, where certain help topics are contextual. Thus, when the player jumps off (or falls off?) a building or ejects himself from a plane, he can avoid a fatal fall by opening his parachute. But if the player fails to open it and dies, a message reminds him of the existence of the parachute and how to control it when the player resumes the game. This approach offers significant potential as far as tutorials are concerned.

A fourth solution may be to integrate a positive or negative handicap system. Thus, according to the gamer's classification, he can benefit from additional health points or from less ammunition. A mechanism such as this would allow a partial balance of the game among players of different levels. However, in order to be accepted by experienced gamers, the game would have to compensate them with new animations or new equipments. An intelligent system using this method is currently being designed for the multiplayer version of Crysis.

Finally, the last solution I propose is to provide a variable geometry controlled interface. Certain games, such as those of the Splinter Cell series, require the player to master a particularly complex interface. For such games one solution would be to offer two versions of the interface, a simple one for beginners and a full version for more experienced players. This idea cannot be applied to all games, but it may be worth trying.

Games Designed to Be Accessible to All

Adding features that are meant to help the beginner face hardcore gamers may be useful to a certain extent, but I think that if we want to make the multiplayer game accessible for the majority of gamers, we must develop it in this direction from the design stage. Here are the three issues the new gamer is confronted with when he enters a multiplayer game:

Let's see how we can address these three problems.

Let's begin with the interface. It should be designed around easy to access principles. We are all acquainted to controlling a character by means of the two analogue sticks on a pad, but is this mechanism easy to control by a beginner? Experimental playtests would probably provide a lot information on how the beginners comprehend and learn to use a game interface. One solution that should be tested is to develop an adaptive interface that would enable the beginners to carry out basic actions and which would provide them with new features as their level improves. The use of voice commands or of a controller such as the Wii-mote could revolutionize the way we interact with our games. And if these solutions seem too utopian, it is always possible to simplify the interface. The interface of Halo 2 is a great example of an intuitive one, because it is not overburdened with controls.

Let's go on to the maps. In a previous paper dedicated to level design, I described various solutions to facilitate the understanding of a map. let me repeat some of them: favor the large maps rather than the complex layouts, use easy to identify mission objectives, create a strong link between the mission objectives and the layout in such a way that by simply understanding the structure, players can locate their objectives, develop an easy to identify navigation network, enable the players to have a global view of the map or a part of it, or favor asymmetrical maps. Note that the games of the Battlefield series offer very large maps, but simple navigation and understanding of the objectives. The map size is not the enemy!

Long Run, a complex yet easily navigable map thanks to its asymmetrical design.

Finally, there are the tactics. It's the game dimension that is the most difficult to control. In a game such as Splinter Cell, it really is the one that makes the difference among gamers. In my view, there are two possible ways to approach this problem.

The first is of technical order. It lies in developing an intelligent agent who analyzes the player's game and makes recommendations accordingly. For instance, if a FPS gamer remains static for too long, the intelligent agent would remind him that he is too vulnerable to a sniper attack. The agent could also help the player discover new paths if it realizes that the player keeps using the same ones. Attractive as it may seem on paper, this approach would probably be complex to develop. However, the idea to provide the gamer with contextual information works, as we could see in Battlefield 2.

The second approach is conceptual. There are already multiplayer games that are relatively easy to pick up for casual gamers, such as Counter Strike and the games of the Battlefield series. This simplicity lies in several design choices: a game style that is known to almost all PC gamers, the FPS, easy to understand mission objectives, a layout that makes the map navigation easy (at least for Battlefield), large maps and sessions that are able to support many players.

I find the latter two factors particularly interesting from the perspective of making a multiplayer game accessible to everybody. The large map size provides the gamers with more opportunities to easily notice and avoid the remote attacks of the opponents. This can be seen in Battlefield, where gamers often lose their lives progressively, due to the lack of precision of the enemy fire. The second factor, the large number of players in a session, also seems favorable to integrate the casual gamers. Actually, when a gamer is part of a large group, he can join the team and just follow a team member who knows the map and the map's tactics.

Conclusion

I wanted this series of articles to be practical in showing that the design of multiplayer maps must follow its own specific structure, different to that of single player maps. The success of a map lies in the successful control of many parameters each equally important. Designers must be aware that their maps will be player hundreds of thousands of times (possibly by the same player), so the faults present will come out.

In closing I would like to remind you that there is no such thing as a perfect map, only those which follow certain points described here to their limits.