Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 1, 2014
arrowPress Releases
October 1, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Player 2, Press Start
by Robert Dieterich on 10/03/12 11:23:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

This is a cross-post from my blog, Game Dev Without a Cause.

Multiplayer in video games is almost as old as the medium itself. It's at least as old as Pong, right? As such an old institution in games, you'd think we'd have all the issues related to implementing multiplayer in games figured out by now. Of course, you'd be wrong. Otherwise, I'd have nothing to write about in this article.

In terms of handling multiplayer from a game design perspective, there are several issues that tend to slip through the cracks until they show up during actual implementation. In large teams, the late discovery of these issues can cause disproportionate amounts of time being spent to fix them as they wind their way from the discover's desk to the people responsible for game design decisions and back to the feature implementor.

So, in an effort to nip that sort of game development waste in the bud, here is a short list of common multiplayer oversights that I've seen crop up in the wild.

Whose Save Data is This Anyway?
In the past, most multiplayer modes had very little in the way of persistent data. Let alone data that may be saved per user. Nowadays, with player profiles and the like, it's quite likely for each player in the game to have their own save data. While it makes sense in terms of having each player save their own play records, things can get messy when we start talking about unlockable characters, options, and levels. Should multiple players be able to select from a union of characters unlocked by all the players? Should players only be able to select characters they themselves have unlocked? The best answers to these questions vary by the kind of game and have significant effects on the core design of menu UI.

In terms of playable levels, one must think about how a player's progression data is handled. Will a player be able to unlock levels by playing multiplayer? What happens if they unlock levels out-of-order by playing with someone who has progressed further in the game? This is one of the reasons that games with co-op campaigns tend of have player 2 as a sort of guest participant in player 1's host game (and save data). While player 2 may save some statistical data, the main progress data remains wedded to player 1.

Whose Story is This Anyway?
In games with a significant story element, handling of extra players in cutscenes can be a major issue. Because of the significant costs involved in creating cutscenes that could handle a variable number of stars (or co-stars), it's common for the cutscenes to simply focus on the main (player 1's) character while player 2's character simply shows up in the background (if at all.) Another common approach is to have player 2 take control of a normally AI-controlled character. This allows the "buddy" character to be available story-wise while also providing a vessel for player 2 to participate should they want to play.

Whose Menu is This Anyway?
Castle Crashers is not a good party game. Not if you have a mix of gamers and non-gamers anway. The main reason I say this is because of the map menu. Basically, because everyone could control the map simultaneously, we could never select the stage we wanted because someone was always fiddling with their controller for some reason or another. Someone might be moving the thumbstick idly while someone else is trying to select a stage. In the meantime someone else was always trying to compensate for stray inputs, further complicating the mess. Eventually, one of us had to yell out and tell everyone else to not touch their controllers while they selected a stage. The end result: the non-gamers were too intimidated to touch their controllers while the gamers would occasionally try to override each other's level decision.

Seemingly in an attempt to be "fair" to all players involved, Castle Crashers allowed them all to control the level select menu simultaneously. Unfortunately, this led to the above result. This is why most fighting games arbitrarily choose one player to pick the arena backgrounds during Versus mode. You want to the players to squabble over who is the better fighter, not over what the next stage should be. In the case of Castle Crashers, some explicit decision as to who would control the level map (essentially, a party leader) would have gone a long way to smooth the multiplayer experience with any disagreements about level choice ultimately being filtered through a human arbiter before being chosen in the game.

Multiplayer gaming is great, especially the local, on-the-couch kind. That being said, it can bring along with it a lot of seemingly minor issues that can deeply affect the core experience of a game. With a little bit of forethought, it's possible to address these issues before encountering them during implementation. In a project with any sort of significant budget on the line, this sort of forethought is crucial.


Related Jobs

Raven Software / Activision
Raven Software / Activision — Madison, Wisconsin, United States
[10.01.14]

UI Lead - Raven
DoubleDown Interactive
DoubleDown Interactive — Seattle, Washington, United States
[09.30.14]

Game Designer
Machine Zone
Machine Zone — Palo Alto, California, United States
[09.30.14]

Game Designer
Raven Software / Activision
Raven Software / Activision — Madison, Wisconsin, United States
[09.30.14]

Lead Engineer - Raven






Comments


Justin Lynch
profile image
Awesome article! You bring up some great points and I wonder if there are more things to delve into when talking about creating a multiplayer experience.

Another type of multiplayer that could cause headaches for developers is if they try to create a persistent world between a handful of players. The best example I can think of Animal Crossing where your actions not only affect you, they also affect the town (which in turn affects other players). It's an interesting concept that has to be balanced correctly or it could destroy the joys of having multiple players.

Robert Dieterich
profile image
Thanks! I'm glad you liked the article.

Multiplayer experiences are great, but they definitely bring lots of issues beyond the ones I mentioned. In general, I think we're pretty good at figuring out the "big" issues like how to multiple players are handled in a games rules, but we tend to forget the little ones. Like, how do we handle cases where some users have DLC but others don't but you expect them to play together? It's easy to not realize that those issues even exist until you run into them head-first.

That sort of shared state you're talking about can be really interesting but does bring up lots of issues. You might find yourself asking: "Okay, just how much should I allow a player to potentially screw up another players world?"


none
 
Comment: