At the Office

Co-operative multiplayer is one of those features that can be really tricky
to get into a game. There's a relatively small, but dedicated, fanbase
that likes to play games co-operatively. Because they often play on
local networks, it's difficult to get an accurate measure of how many people
use this game mode, as opposed to adversarial, which gamers are more likely
to play against strangers, i.e. over the internet. Playing co-op over
a network, gamers will often use the same copy on multiple machines, which
means that you can't necessarily translate numbers of players into numbers
of copies sold. On top of that, co-op play has a number of technical
and design implications that can be particularly tricky to handle. From
the player's perspective, though, it seems like a given that if you can support
single-player and adversarial multiplayer, co-operative should be possible.
This article lays out a few of the reasons why you don't see co-op
in as many games, or with as much robustness, as you might expect.

Co-op certainly can be done, and with large numbers of players. It's
important to plan for it early in the project, like anything else, because
it has some wide-reaching implications for how you build things, and it can
certainly be difficult to put in at the end of a project--difficult enough
to be cost-prohibitive in terms of time if not money. What people
actually mean when they say co-op can't be done is "We didn't plan to support
it and we have no intention of changing the plan now", "We'd have to pull
resources out of other parts of the game to make that happen, and we don't
feel it's worth it", or "We don't think it would work well with the gameplay
dynamic we're going for". Usually, it comes down to some kind of a mix of
those.

For example, Halo on the Xbox had co-op, but the PC version did not. A
lot of players looked at that with disbelief: why couldn't the PC product
support a feature that worked on the Xbox? My understanding of why
co-op didn't make it in for Halo (and be warned: I have no
actual insider information on this) is that co-op on the Xbox relied on the
fact that the simulation didn't have to network any information. Since both
players were on the same box, adding a second player didn't really change
the load of the world simulation. Co-op meant that they did have to
account for new rendering situations, because of split-screen, and there
was probably some overhead in needing to process the second controller's
inputs, but both players were constrained to a small slice of the overall
world, so there was no additional AI or memory bandwidth needed.

Now, the PC doesn't have any way to easily support plugging a second controller
in, and that wasn't what the players wanted anyway. They wanted co-op
over the internet, which means that everything suddenly needs to be propagated
and synchronized over a network, whereas before, all of that data was already
resident on the box. Given the nature of the game, they would have
had to update and synchronize literally dozens of AI characters, and each
additional player needs their own copy of the data, making it an exponential
progression rather than arithmetic (you're not just updating each client
from the host; each client has to be updated with every other client's data
as well as the host's). In a shooter, you've got to keep the latency
(the delay of sending everything over the network) low because slight differences
in position can create wildly different outcomes (a hit becomes a miss; a
body-shot becomes a head-shot).

So, Gearbox has a contract that says they've got to get the game out in X
number of months, and they've got Y number of dollars, and they'd have to
build the whole networking system for the co-op part of the game from scratch.
All of the adversarial multiplayer networking stuff was already built, and
built specifically around not having any kind of AI (Halo MP doesn't support
bots), so that was relatively easy to port. Obviously, they would have
loved to have this cool new feature to push their product, so the fact that
they didn't suggests that they couldn't make it work with the time and money
they had to work with.

That's just the technical side. From the design side, maybe I can illustrate
some of the difficulties of translating a single player experience into co-op
by using some examples.

Let's say we're talking FPS, and you've got maps that are not completely
linear, and you've got an AI that's fairly sophisticated--shares information
among itself, tries to react tactically to situations, etc., in short all
of the kinds of behaviors that players today expect in single-player games.

In single player, you can save CPU time dropping--either completely or partially--AI
that is not in range of the player. If the player can't see or otherwise
interact with them, you can minimize or eliminate that data because it's
not really important. This is called affinity filtering, and it lets
the game work much more efficiently by narrowing the scope of what it has
to handle at any given moment.

In co-op, that range is not just relative to one player but to many. With
four players, you may be trying to simulate four times as many AI as you
would be in single player. You can't rely on players to do things one way;
if they can split up and run to four corners of the map, your game had better
be prepared to handle that, because someone's going to do it sometime, and
if the game crashes, then you're an illiterate moron who can't do the simplest
things right--even if they had to use cheat codes or other exploits to get
that far apart.

In single player, you can script events to happen whenever the player is
in an appropriate position--guys spawn around the corner, or the bridge blows
up right after he crosses it, whatever. Centering all of the events
on the player character allows you to cut all kinds of corners while still
preserving the illusion that the world is responding dynamically to the player.

In co-op, you can't rely on the notion of a single player character, so that
perfectly hidden spawn location may not be hidden to another player in another
location, even though it's triggered from the same spot. Players see enemies
spawn in, and again you're suddenly a moron. Or, the bridge blows up
right after the player crosses it, but his buddy hasn't crossed it yet, and
now he can't get to the rest of the level. Next thing you know, that guy's
on the forums telling everybody how stupid you are. Or, the bridge
blows up, but the guy out in front has already triggered that massive rush
spawn, so now you've got to track both the debris from the explosion and
all the enemies, which you didn't have to do in single player, because only
one or the other could be going on at once. Now your network code sucks because
you have these lag spots, even though the network code is doing just fine
and it's the simulation or the rendering or the sound system or something
else entirely.

I could go on for days about all the types of game situations that can break
co-op play, but it's really irrelevant to the guy at the store who's looking
at a box and going "wow, this would be so much better with co-op". Ideas
like that are easy, turning those ideas into designs that actually work is
hard.

Games are all about tradeoffs. You've only got so much CPU, so much screen
real estate, so much bandwidth, so many audio channels, etc. If you're trying
to build a AAA single player game, you've got to use every trick you can
come up with to maximize the experience while respecting those limits. So,
you end up doing things like making sure that your scripted VO doesn't fire
when you're in the middle of a firefight, or that the AI doesn't fire more
than X number of bullets per second, or that only one guy can throw a grenade
at a time, or that there aren't three guys firing shotguns simultaneously.
When you replace AI with players, they can break all of those rules.

Then, beyond that, you've got to deal with the realities of production, that
you've only got so much manpower, so much time, and so much money to build
the game with. You can push on any two of those, but the third one's going
to have to give. At the end of a development cycle, you have to take
a hard look at everything that's left to build and test, and pretty much
every time, you're going to have to make cuts to get the game out on time.
If you've planned for co-op from the very beginning and built it into
all of your systems, then it will probably make it into the final game; however,
if you're looking at a lot of programming and testing and re-scripting to
get co-op to work, it's an easy cut to make. The single-player campaign
is going to be used by pretty much everyone who buys the game; adversarial
multiplayer produces measurable benefits--competitive multiplayer gamers
are going to spread the game by getting the people they already play with
involved; co-op doesn't have as clear or as tangible of a benefit, but the
complexity (and time involved) makes it a significant savings if it's cut.

More and more games these days are supporting co-op play, which is a testament
to the fact that both players and developers recognize its value as a feature.
This is also due to the fact that more developers have experienced
the difficulties of getting co-op into a finished product, so the practices
necessary to make it happen are better known and more commonly adopted. However,
you shouldn't be surprised to see more games in the future that seem like
they could have incorporated co-op fail to do so. After all, it is
harder than it looks.