At the Office

Home

On the Couch

At the Office

In the Library

Mailbox

Neighborhood

Why Co-op Is Harder Than It Looks

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.

Home

On the Couch

At the Office

In the Library

Through the Mirror

Mailbox

Neighborhood