|
 Features
Multiplayer Level Design In-Depth, Part 3: Technical Constraints and Accessibility
 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:
- The bandwidth bottleneck
- The need for event synchronization
- The lack of control over the players' actions
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.
|
|
|
|
|
Previous