Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Implementing multiplayer (online or local) in a game introduces many design issues not present in a single-player game. Many of these issues seem minor at first, but can have major implications if not handled carefully.
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.
Read more about:
Featured BlogsYou May Also Like