Chapter 28: Multiplayer Design — Cooperation, Competition, and the Social Layer

There is a moment in every multiplayer match that single-player games can never produce. Someone — a stranger on the other side of the country, a friend on the couch beside you, a teammate you have played with a hundred times — does something you did not expect. They throw the ball you did not know they saw. They betray you on the last round. They revive you at the edge of the map while both of you are laughing and cursing. They leave the match without saying goodbye. Whatever it is, you did not write it, your design team did not script it, your playtesters never produced it. Another human being did. And that fact — that the content of the moment was generated by a person who is not you — is the entire reason multiplayer exists as a discipline.

Single-player design asks: how do I make the system compelling? Multiplayer design asks: how do I make the table around which people gather compelling? You are no longer writing the content. You are writing the conditions under which people write the content for each other. Your levels are conversation topics. Your mechanics are the grammar of a language the players will speak. Your economy is the loot that two humans will argue over. Your matchmaking is the introduction. Your moderation is the bouncer. You are running a small social institution, not shipping a product, and the entire discipline changes accordingly.

This chapter is the practitioner's guide to thinking about that institution. We will not teach you to write netcode — that is an engineering specialty and the books that do it well (Glenn Fiedler's Gaffer on Games is where you start) would triple the length of this book. We will teach you to think like a multiplayer designer: to see the gap between what your rules say and what your players will do with them, to understand which design decisions foreclose possibilities three years into a live service, to recognize when you have accidentally built a toxicity farm, and to know when not to ship multiplayer at all. Multiplayer is the most expensive thing you can add to a game. It is also, when it works, the most durable — the games that stay with a community for a decade are almost never single-player. Counter-Strike is older than most of the people playing it. Team Fortress 2 released in 2007. EVE Online launched in 2003 and is still adding features. Single-player games are consumed. Multiplayer games are inhabited.

The chapter is largely theoretical because the progressive project for this textbook is a single-player 2D action-adventure. Your project will not ship with multiplayer. You should not, at this stage of your career, try to build a multiplayer game from scratch. But you will, eventually, be asked to think about multiplayer — to evaluate whether a mode could be added, to read a design document with a multiplayer component, to have an opinion about matchmaking or voice chat or asymmetric co-op. This chapter arms you for that moment. The project deliverable at the end is a one-page multiplayer design spec — a hypothetical future version of your game with a multiplayer mode grafted in. It is a thought experiment. Do the thought experiment seriously. The habits of multiplayer thinking are learned by design reps, not by reading.

Why Multiplayer Is a Different Discipline

A single-player game is a conversation between the designer and the player. You wrote the enemies. You chose the pacing. You decided when the player would feel frustrated and when they would feel capable. The AI you built in Chapter 27 is your voice in the room. Everything the player encounters was authored, by you, for the experience you intended. You can playtest it. You can tune it. You can know, to within a small error, what the player is going to do and how they will feel about it.

A multiplayer game is a conversation between players, which you merely host. You do not author the moments. You author the preconditions for moments. Two players fight over a health pack in Team Fortress 2 because you, the designer, put the health pack in a spot where fighting is incentivized. But you did not design their fight. They designed their fight. The feint, the panic shot, the taunt after the kill — those were not in your document. The document just created the clearing in which the players wrote it.

This shift has enormous practical consequences. The first is that you cannot test a multiplayer game by playing through it yourself. You can play through a single-player game once and know, roughly, what the player will experience. You cannot play through a multiplayer game at all — it only exists when multiple players are in it, and their behavior is what you are testing. This is why multiplayer games require playtest infrastructure that single-player games do not need: closed alphas, large-scale betas, stress tests, server-load tests, meta-observation weeks where designers watch the community and do not ship anything. Valve has famously used internal "Gauntlet" playtests where employees play the same build for weeks before public release. Bungie's Destiny raid design includes a dedicated team whose entire job is to playtest the raid repeatedly with different group compositions before public launch. You cannot shortcut this. The multiplayer content does not exist until you put a crowd in the room.

The second consequence is that your players become your content creators, whether you intended that or not. The speedrunner who shaves a frame off a trick, the support main who invents a new role, the guild that discovers an exploit and publishes a YouTube video about it, the streamer who finds a comic niche in a corner of your game — these people are now, functionally, part of your design team, and you did not hire them. You can make them miserable by patching them out, or you can make them powerful by elevating their discoveries into official features. The Dota 2 hero Anti-Mage's mana-burn became a central strategic archetype because competitive players discovered what it could do; the original Dota mod within Warcraft III was itself a player-designed thing that eventually became one of the most successful games of its decade.

The third consequence — and this is the one that surprises designers making their first multiplayer game — is that the player is the content. Not the level. Not the weapon. The other player. The story of the match, told afterward in the group chat, is almost never "the map was cool" or "the gun felt good." It is "remember when Dave flanked us from the catwalk and got the quad kill?" Dave is the story. The catwalk is just where it happened. Your job is to make catwalks where Daves can happen.

💡 Intuition: In single-player, you design against the player — you are the dungeon master and they are the party. In multiplayer, you design the table that the players sit at together. Your job stops being "make the game hard enough" and starts being "make the conversation interesting." The dungeon master has moved to the bar across the street. You are running the bar.

This reframing is harder than it sounds. Designers with single-player instincts will keep reaching for single-player tools. They will balance a PvP weapon the way they would balance a PvE weapon — "this rifle does 35 damage, and that kills the enemy in three hits" — without accounting for the fact that every buff to one weapon is simultaneously a nerf to every player who chose another. They will design a cooperative mission with scripted beats, forgetting that a team of four will blitz past scripted beats at three times the speed of one player. They will write dialogue intended to land emotionally, forgetting that the second player is standing on the NPC's head spamming the dance emote. The single-player instinct fails because the single-player instinct assumes you have the player's attention. In multiplayer, you share the player's attention with three other people, four teammates, ninety-nine opponents, and a Discord call where someone is telling a joke about last weekend.

Cooperation vs. Competition vs. Hybrid

The first decision, and the one that shapes every subsequent decision, is the social-emotional shape of the game. Are the players aligned or opposed? Cooperation and competition are not two points on a spectrum — they are two different design problems with two different emotional palettes, and the hybrid forms in the middle are not compromises but a third category with its own rules.

Pure cooperation — all players allied against the system — produces a specific emotional shape. The highs are shared. The lows are shared. The victory belongs to the team; the loss belongs to the team. The design challenge is to make the teamwork legible — to make each player feel that their contribution mattered, that the outcome was not just the sum of four independent performances but a thing the group achieved together. It Takes Two is the purest recent example, explicitly designed for exactly two players where the mechanics require the two to complement each other at every moment; you cannot solo a puzzle because the solution requires two different movesets. Portal 2's co-op campaign did something similar, with puzzles designed so that one player's portal is useless without the other's. Left 4 Dead forced cooperation through enemy design — the Smoker grabs you and drags you; you die unless a teammate shoots the tongue; the game is teaching you, at the mechanical level, that you cannot survive alone.

Cooperative design has a specific failure mode: the solo-carry. When one player is far stronger than the others, the cooperative experience collapses. Everyone stands behind the carry and watches. The game becomes single-player with spectators. Preventing this requires mechanical constraints that force distribution of contribution — hard-locked roles (a healer cannot tank), positional requirements (two buttons on opposite sides of the room), resource economies where each player's actions consume resources only they have. Deep Rock Galactic solves this by class-locking key mobility tools: the Driller makes tunnels, the Engineer makes platforms, the Scout grapples, the Gunner drops ziplines. Without all four classes, some terrain becomes unreachable. The game is telling you, through its geometry, that every player matters.

Pure competition — all players opposed to each other — produces a different emotional shape. The highs are personal. The lows are personal. The victory is a statement about you; the defeat is a statement about you. This is a sharper, more volatile emotional contract, and it is the one that produces the most toxicity, because when you lose, the cause of your loss is a specific human being who is currently typing "gg ez" in the chat. Counter-Strike is the canonical example — five against five, no AI, no environmental enemies, the only threat is the humans on the other side. StarCraft II one-on-one is a more intense version of the same contract: one winner, one loser, the loser cannot even blame a teammate. Fighting games — Street Fighter, Tekken, Guilty Gear — are the compressed pure form; a best-of-three is three minutes of direct confrontation with no intermediaries.

Competitive design's failure modes are different from cooperative ones. The dominant failure is imbalance — when the space of viable strategies narrows to one dominant strategy and all matches become the same match. The other failure is the skill cliff — when the game is sufficiently punishing that new players cannot get a foothold, and the population collapses into an increasingly thin top layer. Competitive designers spend their careers fighting both of these. A game with good balance has what designers call a healthy meta: three to five dominant strategies, each with counters, each requiring different skills, rotating as the patches evolve. A game with a bad meta has one strategy that beats everything, or three strategies locked in rock-paper-scissors with no skill expression available inside the choice.

Hybrid multiplayer is cooperation and competition operating in the same design space. This is the most common shape in the contemporary live-service landscape because it captures the social virtues of cooperation (your teammates are your friends) with the structural drama of competition (there are winners and losers). Team shooters — Overwatch, Valorant, Rainbow Six Siege — are coops of five against five, internally cooperative but externally competitive, a format that produces the most active matchmaking populations in the industry. Destiny 2 is cooperative PvE (raids, strikes) wrapped around competitive PvP (Crucible, Trials), with a shared economy and progression bridging both. Sea of Thieves is cooperative crews — you and three friends running a ship — competing with other cooperative crews on an open sea, producing emergent drama no designer at Rare scripted.

Hybrid design is the hardest of the three because the two logics — cooperation and competition — have opposite demands. Cooperation wants you to help your teammates. Competition wants you to not help your opponents. The boundary between "teammates" and "opponents" becomes a design variable. Sea of Thieves deliberately made ships small — four players maximum — so the coop group is intimate; it deliberately made the server large and the sea vast, so the competitive encounters are rare and memorable. Destiny 2's strikes are designed for three players because three is the sweet spot for felt-importance without matchmaking fragility. Every choice about player count, about team size, about zone density, is shaping which of the two logics dominates at which moment.

🎮 Case Study: Sea of Thieves shipped in 2018 as a game with almost no content by AAA standards — a handful of enemy types, a small number of mission structures, a tiny loot table. Critics panned it. But the hybrid multiplayer framing produced stories no content team could have designed: the five-hour chase, the alliance that broke into a betrayal, the ghost ship that swooped in to steal your hard-won chest at the last moment. Six years later, Sea of Thieves has a thriving community and has added enormous content — but the content was always secondary. The ocean was the content. The crews were the content. Rare built a table, not a game.

Synchronous vs. Asynchronous

Multiplayer can happen in real time or across time. These are genuinely different genres and the design constraints are almost non-overlapping.

Synchronous multiplayer means all players are present in the same match at the same moment. Fortnite, Counter-Strike, Overwatch, Rocket League, League of Legends — all synchronous. The players gather (via matchmaking), the match happens, it ends, they disperse. Time is the master constraint: every action happens now relative to the other players' now, and any drift in that synchronization is a bug. Synchronous multiplayer requires low-latency networking, careful tickrates, prediction and rollback, and a design that respects the short temporal budget of human reaction (about 200-300 milliseconds for reflex actions).

Asynchronous multiplayer means players interact across time, not within it. Turn-based games (Words With Friends, Chess.com correspondence, mobile strategy games where you "raid" when the other player is offline) are the purest form. Leaderboard games (Trials series, time-attack modes, daily-challenge puzzle games) are an asynchronous form where the competition is mediated by a score rather than a co-presence. Asynchronous multiplayer removes the latency constraint (a move can take five seconds or five days) and removes the co-presence constraint (your opponent does not need to be online, which solves half of the matchmaking problem at a stroke).

The design affordances are different. Synchronous games can use reaction-based mechanics — a parry that must be timed to the frame, a dodge that must be executed before the hit lands. Asynchronous games cannot; all action must be decision-based, because the decision is being made in one player's hour of reflection, not the other player's moment of reflex. Chess is the perfect asynchronous design because every move is a decision rather than a reaction; the game still functions correctly played by email across six months. Street Fighter would not function at all — the whole point is the millisecond mind-game, and a player who takes twelve hours to respond has broken the medium.

Asynchronous multiplayer has a huge practical virtue: it solves the population problem at small scales. A synchronous match-three-mobile-game needs a large, live playerbase to produce fair matchmaking. A turn-based version can let players send moves to friends at any time, so the matchmaking is social (you pick your friend) rather than algorithmic (the server picks a stranger). Mobile gaming has disproportionately gone asynchronous because of this — Clash Royale's laddered PvP is synchronous, but Clash of Clans's "raid your opponent's base while they're offline" framing is asynchronous, and the second model scales to enormous player counts with no matchmaking queue.

There is a middle ground: semi-synchronous games, where the match is technically synchronous but the temporal pressure is loose enough that a player can step away. Browser-based tactics games often work this way — turns happen in real time but turns can be several minutes long. Some mobile shooters use five-minute matches with per-round pauses. The design trade here is that semi-synchronous games feel more casual (which expands the audience) but produce less intense moment-to-moment play (which cuts against competitive depth).

Async-leaderboard is a specific subtype that deserves its own mention because it is underused. Trials Rising has no synchronous multiplayer in its core experience — every rider plays alone — but the game frames the experience socially through a rich leaderboard, ghost replays of friends' runs, and "beat your rival" daily challenges. You are playing against ghosts. The social pressure is real; the latency is zero; the population problem is solved; and you can pause the game without consequence. More games should consider this design space. Most competitive games do not need to be real-time. They need to feel competitive. An asynchronous ghost system does that for a fraction of the engineering cost.

🛠️ Practitioner Tip: If you think you need synchronous multiplayer, first ask whether an asynchronous framing would achieve 80% of the social goal at 20% of the engineering cost. Leaderboards, ghosts, async turns, and "your friends also played this level" framings are under-explored and vastly cheaper than a live-service multiplayer deployment.

Local vs. Online

The second axis is where the players are. Same couch? Same LAN? Same internet? Same planet? Each configuration implies different design affordances.

Local multiplayer — two or more players on the same screen, same machine — is the oldest multiplayer form and in 2026 is enjoying a quiet renaissance. The design affordances of couch co-op are specific and valuable: you can use split-screen (or single-screen), you can use face-to-face communication (no voice chat bug has ever ruined a game of Mario Party), you can use the social friction of being physically present (trash talk is funnier in person), you do not need servers, you do not need matchmaking, you do not need anti-cheat. Overcooked, Lovers in a Dangerous Spacetime, Towerfall, Gang Beasts, It Takes Two — all of these games work because the other player is three feet away. Many of them would not work online, and the developers know this. It Takes Two shipped with a pandemic-era "Friend Pass" that let a second player join online with only one copy of the game, but the experience is manifestly designed for the couch first.

Local multiplayer's design window is smaller than online. The player count is bounded by screen real estate and controller count — typically 2 or 4, occasionally 8 for party games with simplified per-player interfaces. The session length must accommodate the social context of people physically in the room — usually 15-90 minutes, rarely longer. But within those constraints, the experience is richer per minute than any online multiplayer, because the communication channel is bandwidth-unlimited (you can point at each other's screens, laugh, hand each other food) and the trust context is unambiguous (these are your friends).

LAN multiplayer is the forgotten middle. Once the dominant form of competitive multiplayer — the Quake LAN parties, the early Counter-Strike leagues, the StarCraft tournaments — LAN has nearly vanished as a consumer format because broadband replaced it. But LAN remains an enormously underrated design context. Zero latency. Zero matchmaking. Trusted players. Simple anti-cheat (you can see if someone is cheating). Some games still support LAN as a formal feature (Minecraft, Factorio, Age of Empires IV, most Valve games) and find that a vocal minority of players use it constantly. If you are making a game where LAN support costs little — i.e., your netcode does not fundamentally require a cloud server — ship LAN support. It is almost free and it earns the deep loyalty of a specific kind of player.

Online multiplayer is the default for contemporary games, and it is the most expensive. Server infrastructure, matchmaking systems, anti-cheat, moderation, patching pipelines, player-support operations — all of these are required and all of them are ongoing. The ongoing nature is what makes online multiplayer a different business as well as a different design, which we will address in the chapter on live service (Chapter 34). For this chapter, the design-relevant point is that online multiplayer surfaces its own set of problems that local and LAN multiplayer simply do not have: toxicity, cheating, network variance, matchmaking fairness, server outages, and the long multi-year maintenance tail.

The platform matters. Console players do not communicate the same way PC players do (text chat is harder on a controller). Mobile players cannot play 30-minute matches (they get interrupted). VR players have richer body-language channels than flat-screen players. Any multiplayer design that ships across platforms needs to reason about what each platform affords.

Player Counts and Their Effect on Design

The number of players per match is not a cosmetic choice. It is a design variable that determines the entire structure of the game.

Two players. The chess-like configuration. Head-to-head, one-on-one, every decision is read against one other mind. Two-player games produce the deepest strategic reads because every action is fully attributable to one person. Fighting games, strategy games, classic-style card games, Hearthstone, Pokémon-style monster-battlers. The design challenge is that two-player games are the most skill-exposing of all formats — there is nowhere to hide, no teammate to carry you, no crowd chaos to obscure a bad moment. They also have the hardest matchmaking problem (perfect pairing) and the most brutal social failure mode (when you lose, you lost to a specific person, with no team to spread the emotional weight).

Three to four players. The party-game sweet spot. Four players is the number around which most cooperative design clusters — it is large enough to allow roles, small enough that every player has an audible voice in the group. Left 4 Dead, Vermintide, Deep Rock Galactic, Overcooked, Mario Party, Monster Hunter (four players), Back 4 Blood, Helldivers 2 — all four-player. Destiny's strikes use three. The pattern repeats because of social psychology: groups of four can conduct a single conversation, can divide into pairs, can collectively attend to a shared task. Groups larger than four fracture into subgroups; groups smaller than three feel sparse.

Five to eight players. Team shooter territory. The five-versus-five shape (Counter-Strike, Valorant, League of Legends, Dota 2, Overwatch) is a dominant form in the competitive space for a specific reason: five is large enough to require role specialization (you cannot play five of the same role effectively) but small enough that teammates are identifiable individuals rather than interchangeable faces. Six versus six (Team Fortress 2, some Overwatch modes) shifts the balance slightly; seven or eight per side starts to feel crowd-like. The three-versus-three shape (Rocket League, Valorant gunfight modes, some MOBA experiments) compresses the team dynamic into a tighter space with more action density per player.

Sixteen to thirty-two players. Large-scale team formats. Battlefield franchise, PlanetSide 2, Squad, Hell Let Loose, Battlefield 2042. These games are no longer about one team versus one team at a tactical level — they are about squads of four inside larger forces, with emergent chaos at the whole-server level. The design challenge is providing structure at multiple scales — the individual player, the squad, the team — without overwhelming any layer.

One hundred players. The battle royale. Fortnite, PUBG, Apex Legends, Warzone. This is the chaos-as-feature configuration: you accept that at a scale of 100, you cannot give every player meaningful agency in the whole-match narrative; what you give them instead is moment-to-moment drama punctuated by a narrowing arena that forces encounters. The shrinking circle is the engine. Without it, battle royale is just a large deathmatch. With it, every fight is a high-stakes fight because the alternative is the storm, and the final fights are forced regardless of how passively you played.

One thousand or more. MMO territory. World of Warcraft, Final Fantasy XIV, EVE Online, Old School RuneScape, Guild Wars 2. At this scale, the individual match is no longer the unit — the persistent world is. Players are not in a bounded match that starts and ends; they are inhabiting a shared space that persists across sessions. The design logic shifts from match-design to world-design; a huge portion of the work is social infrastructure (guilds, chat, economy, housing) rather than mechanics.

💡 Intuition: Player count is the most consequential multiplayer decision because it determines almost everything else. You cannot retrofit a 2-player design into a 100-player game; the architecture of one is hostile to the architecture of the other. Choose your player count deliberately, at the start of design, and let the rest flow from it.

Matchmaking

Matchmaking is the bouncer at the door of your game. It decides who plays with whom, and the quality of that decision shapes every subsequent match.

The canonical formulation of matchmaking as a problem: given a pool of players with different skill levels, different network conditions, and different ping times to the various servers, assemble matches of the requested size such that the matches are (a) fair, (b) fast, and (c) technically functional. The three goals conflict.

Skill-based matchmaking (SBMM) uses a rating system — Elo, Glicko, TrueSkill, or a studio's proprietary variant — to estimate each player's skill and match players of similar skill against one another. Chess has used Elo since the 1960s; Microsoft's TrueSkill (developed for Halo 3) extended it to team games; most modern competitive games use some variant. The advantage is that a fair match is more satisfying than a one-sided match; the disadvantage is that casual players hate SBMM because it removes their occasional easy match against a low-skilled opponent. Call of Duty has been the target of endless community debate about how aggressive its SBMM is, and every franchise faces the same tradeoff.

Connection-quality matchmaking prioritizes low ping to the server over skill matching. This is the right choice for competitive games where latency variance is a fairness problem in its own right. Counter-Strike's competitive system prioritizes regional servers with sub-30ms ping; if that means slightly wider skill brackets, the tradeoff is accepted. The technical term is ping-locked matchmaking, and it is nearly universal for shooters.

Lobby-based matchmaking lets players form a group before matchmaking — "parties" in most contemporary systems — and then matches the entire party against another party of similar composition. This preserves the social unit (you play with your friends) at the cost of matchmaking complexity (a party of five unequal-skill players is a different problem than five equal-skill solo players). Modern systems usually apply a per-party handicap.

The fairness vs. queue time tradeoff is the matchmaker's fundamental dilemma. A perfectly fair match — exactly equal skills, exactly equal pings, exactly complementary team compositions — is rare, and searching for it exhaustively produces long queues. A fast queue accepts looser matches. Every matchmaker tunes this tradeoff, and the tuning is usually regional and time-of-day dependent (primetime in a dense region can afford tighter matches; 4am in a sparse region cannot).

Smurfing and alt accounts are the chronic failure mode of skill-based systems. A smurf is a high-skilled player on a new, low-rated account; they are matched against genuine new players and destroy them. Most systems now apply some form of new-account calibration — a few initial matches against a wide range of skills to find the true rating — but smurfing remains the thing that ruins the experience of low-ranked players in virtually every competitive game. If you are designing matchmaking, you must have a smurf plan. Behavioral heuristics (playing too well for a new account), hardware fingerprinting, IP-based limits — all of these are used, and none work perfectly. The defensive move most games eventually make is harsher account linkage (phone verification, ID verification, paid-account requirements).

A related consideration: queue bots and reserve systems. When the live population of players is thin, the matchmaker either waits (long queue) or fills the match with bots. Call of Duty was caught in 2023 filling early matches with bots without disclosing it, producing community outrage when players discovered they had been matched against AI opponents they thought were human. The lesson: if you use bots, tell the players you are using bots. Trust in the matchmaker is trust in the game.

⚠️ Pitfall: The single most common matchmaking failure in recent years is hidden rating vs. visible rank. If your matchmaker uses a hidden MMR to match players, but shows the player a different visible rank, the player experiences unexplained variance — "I won five matches but my rank did not go up" — and interprets it as the game cheating them. Either make the visible rank match the matchmaking rating, or communicate clearly to players that their displayed rank is not what drives matchmaking. Opacity breeds paranoia.

Toxicity, Communication, and Moderation

Online multiplayer will be toxic. This is not a moral failing of your players. It is a predictable output of the social conditions you created when you made a competitive game played by strangers over anonymous text and voice channels. Treating toxicity as "a problem that will emerge" rather than "a design consequence of our channel choices" is the first mistake.

Every multiplayer game's toxicity profile is shaped primarily by its communication affordances. Consider a spectrum.

No communication. Some games simply do not let players talk to each other. Journey is the most famous example — two players can meet on the sand but cannot voice-chat, cannot text-chat, can only sing a musical chirp at each other. Death Stranding's asynchronous player interaction is even more minimal: you leave objects in the world that other players might find. The effect in both cases is remarkable: the community reports these games as among the most positive multiplayer experiences they have had. Without a channel for harassment, harassment does not happen. The cost is that coordination becomes hard, strategy becomes limited, and the game style is narrowed.

Limited communication — pings only. Apex Legends popularized a middle path: a rich non-verbal ping system that lets players mark enemies, call for loot, request regroups, and celebrate kills without ever speaking. The ping system is expressive enough to coordinate a squad effectively and constrained enough that harassment cannot happen through it. Rocket League's "quick chat" system uses a similar principle: a small pool of pre-written phrases ("Nice shot!", "I got it!", "Take the shot!") that cannot be used to insult a teammate. You can still harass by spam-repeating "What a save!" after a goal against you, but the harassment bandwidth is radically compressed.

Text chat, default-on. The legacy configuration of most PC multiplayer games. Text chat is infinitely expressive, which is the problem — if you can say anything, players will say anything, and the distribution of what players say includes slurs and harassment. Default-on text chat without moderation tooling produces the worst toxicity outcomes of any channel configuration. If you ship text chat, ship chat filters, a report system, and a team behind the report system. If you do not have the team, default text chat to off.

Voice chat, default-on. The most expressive channel and the most toxic. Voice chat can transmit emotional nuance, convey humor, enable tight coordination — and also convey verbal abuse, reveal identity markers (voice, gender, age, accent) that become targets of harassment. Women, children, and non-native English speakers all report voice chat as a channel where harassment is disproportionate. Every multiplayer game that defaults voice chat on without moderation has built a harassment delivery system. Some games have pivoted — Overwatch 2 removed voice chat from its reporting-heavy casual queue, Valorant has introduced voice moderation using Riot's Vanguard listening during matches (controversially). The honest answer is that voice chat is a powerful feature with enormous social cost and should be a conscious design decision, not an assumed default.

Voice chat with post-match-only chat. A compromise. Players can text-chat during the match but voice-chat only after in a post-game lobby where moderation tools are active. Loses in-game coordination but preserves social connection and funnels abuse into a moderated window.

The report system. Whatever communication affordances you ship, ship a report system. And have a team behind it. Overwatch's report system was praised in early years because reported players received feedback — a pop-up after login saying "one of your reported players was penalized for abusive chat" — that signaled the reports went somewhere. Players who believe the system works report more. Players who believe the system does not work stop reporting and start quitting. League of Legends's "Tribunal" system went further, letting community members review cases and vote on penalties; it was discontinued in 2014, but the underlying idea — community moderation at scale — is being revived in various forms.

Moderation is operations, not engineering. The common mistake is to think of moderation as a one-time feature build. It is not. It is an ongoing operations function. You need people reading reports, people tuning the automated filters, people managing appeal processes, people dealing with edge cases. Most indie studios cannot afford a 24/7 moderation team, which is a powerful argument for shipping games with limited communication affordances in the first place. You cannot moderate voice chat at indie scale. If you ship voice chat at indie scale, you are shipping an un-moderated voice channel, whether you meant to or not.

Among Us illustrates the power of constrained communication. The game's core design decision — text chat only during meetings, no in-game voice, short meeting windows — was made partly for technical reasons and partly because the game relies on social deduction that requires the tight communication budget. Players who stream with voice chat on are playing a different game than players using only in-game text, and the in-game text version is arguably the more interesting social deduction experience. The lo-fi communication became the game.

🎮 Case Study: Apex Legends's ping-only approach was not just a quality-of-life feature. It was a market-access strategy. Respawn knew that a significant fraction of console players and casual PC players will not voice-chat with strangers — because voice chat is uncomfortable, because their mic is broken, because they are playing in a room where they cannot speak, because they are new to the genre and do not want to be judged. Pings let all of those players coordinate as if they had voice. The game's audience expanded accordingly. Design that removes friction for reluctant players is design that expands the market.

Net Code Basics for Designers

You, the designer, will not write netcode. That is an engineering specialty, and good netcode engineers are among the most valuable people at any multiplayer studio. But you must understand the constraints netcode imposes on design, because those constraints determine which mechanics are shippable.

Client-prediction vs. server-authoritative. In a client-predicted game, the player's input produces immediate visual feedback on their local machine — the character starts moving the frame they press the button — and the server later arbitrates whether that movement was valid. The player feels responsive. The designer gets a snappy game. The risk is that the server sometimes disagrees with the client and "rubber-bands" the character back. In a server-authoritative game, nothing happens until the server confirms it — the player presses the button, the input is sent, the server processes it, the server's response is drawn. The player feels laggy. The designer gets correctness. Almost all modern online games use some mix: client-side prediction for the local player's own movement (for feel), server authority for everything else (for fairness).

Lag compensation. When you shoot at an enemy in a game like Counter-Strike, your shot is evaluated on the server against where that enemy was when you pulled the trigger — not where they are by the time your shot arrives at the server. The server rewinds the game state by your ping and checks the hit against that past moment. This is called lag compensation or "favor-the-shooter" netcode, and it is the reason you can play a shooter at 80ms ping without feeling broken. But it has a strange consequence: the enemy, from their local perspective, may have already rounded a corner when the shot registered. They died "behind cover." This is not a bug; it is lag compensation working as designed. The question the designer must answer is which player you favor — the shooter or the target. Favor-the-shooter feels good to the person shooting; favor-the-target feels good to the person running. There is no neutral choice.

Tickrate. The server simulates the game at a fixed rate — Counter-Strike 2 runs at 64 ticks per second with sub-tick input handling; Valorant runs at 128 ticks on competitive servers; many cheaper games run at 20-30 ticks to save server costs. The tickrate determines the temporal resolution of the game. At 64 tick, an event can happen 64 times per second; at 20 tick, only 20. Low tickrate causes inconsistent hit registration, unreliable fast-action sequences, and general "feel bad" moments that players will blame on latency even when latency is fine. If your game has quick aim-based mechanics, you need at least 60 tick. If your design involves parries, counters, or precise millisecond reads, you need 128.

Rollback netcode. A specific technique pioneered in fighting games and increasingly used in other genres. Each client runs a full simulation of the game locally and predicts what opponents are doing. When actual opponent input arrives, the client rolls back the simulation to when the input was supposed to happen and replays forward with the corrected inputs. The result is that local inputs feel latency-free while the game stays perfectly synchronized. Street Fighter 6 uses rollback. Killer Instinct (2013) was one of the first mainstream examples. Skullgirls and the 2020s wave of Arc System Works games run on rollback. The tradeoff is CPU cost (you are effectively running the simulation multiple times per frame) and a specific visual artifact (characters briefly "teleport" when a bad prediction is corrected). For twitch-competitive games, rollback is now the gold standard.

Designers do not need to implement these, but designers must know which their game has, because it determines what is possible. You cannot design a parry window of three frames in a 30-tick game — the network noise exceeds the window. You cannot design cover-based shooting if your netcode is client-authoritative for hit-reg — cheaters will walk through your design. You cannot design a rhythm-based co-op if your netcode has 80ms of jitter — the timing windows collapse. The netcode is the floor beneath the design.

🛠️ Practitioner Tip: Sit with your network engineer before you design the combat system. Ask them three questions: (1) What tickrate are we budgeting for? (2) What is our lag compensation strategy? (3) What is the budget for the worst-case client's ping? Their answers determine what you can design, and learning them a year in saves nothing; learning them in month one saves the project.

Cheating and Anti-Cheat

In a competitive online game, someone is going to cheat. Accept this. The question is how you respond.

Types of cheating. Wallhacks (see through walls). Aimbots (the game aims for you). Triggerbots (fire automatically on visible enemies). ESP (extra-sensory perception — highlight enemies, items, resources). Speedhacks (move faster than legal). Exploits (use a bug to gain an advantage). Account boosting (a higher-skilled player plays on your account). Each has different detection signatures and different damage profiles.

Detection approaches. At the most basic level, heuristic detection looks at the player's in-game behavior — aim patterns, reaction times, win/loss patterns — and flags implausible profiles for review. This is the approach taken by most casual competitive games, because it runs server-side and does not require the player to install invasive software. The downside is false positives: a genuinely very-skilled player can trip the detection.

At the other end, kernel-level anti-cheat runs at operating-system ring 0 — deeper than any normal program — and scans the machine for cheats. Riot's Vanguard (used in Valorant) is the most controversial example; it runs from system boot, requires a restart to disable, and has full system access. The cheating community finds kernel-level anti-cheat harder to circumvent, so it is effective. The privacy community, the Linux community, and the anti-DRM community find it concerning because a kernel-level driver is, functionally, a rootkit that Riot pinky-promises to use only for anti-cheat. When BattlEye, Easy Anti-Cheat, and Vanguard crashed systems in 2023-2024, the argument about kernel-level anti-cheat's cost-benefit intensified.

Counter-Strike's VAC (Valve Anti-Cheat) takes a middle path: run in userspace, collect signatures of known cheats, ban in waves rather than immediately. Wave-bans disguise the detection heuristics from cheat developers, extending the time before a new cheat is detected. This is game theory applied to anti-cheat.

The cat and mouse. The history of anti-cheat is an arms race. Every detection method gets countered by new cheats. Every new cheat gets detected eventually. The metric that matters is not "is anyone cheating?" — someone is always cheating — but "what fraction of matches have a cheater in them?" A healthy multiplayer game keeps that fraction low enough that players do not feel their matches are routinely ruined. This requires ongoing investment. It is not a shippable feature. It is a permanent operations function.

Cheating is a trust problem as much as a technical problem. Players do not need your game to be cheater-proof. They need to believe your game is fair. If the players believe cheaters are being caught and banned, they tolerate occasional cheaters. If they believe the studio does not care, they stop playing. The visible aspects of anti-cheat — public ban announcements, streamer accounts caught cheating and punished, clear communication about detection improvements — are as important as the technical detection. Studios that stay quiet about anti-cheat lose their playerbase's trust; studios that publish quarterly ban numbers (Blizzard for Overwatch, Riot for Valorant) keep it.

Design implications. If your game cannot be reasonably protected against cheating, do not make it primarily competitive. Cooperative PvE tolerates cheating better than PvP — a player running a damage mod in Monster Hunter is mostly ruining their own game — but PvP is poisoned by even rare cheating. This is one of the arguments for local competitive multiplayer over online: at the LAN party, you can see if someone is cheating.

Game Design for Replay

Single-player games are played, finished, and shelved. Multiplayer games are played forever, and the replay structure is part of the design.

Randomization. Every match must feel different. Map rotation, procedural generation, random starting conditions, random loot tables, weather variance — anything that makes match-to-match variation exceed tactical repetition. PUBG drops you in a randomized loot environment on a fixed map; Spelunky 2 (single-player, but same principle applies to its daily challenge) gives everyone the exact same seed so the competition is on execution, not randomness. The choice matters.

Asymmetry. If every player plays the same character with the same tools, match structure becomes repetitive quickly. Asymmetric roles — classes in team shooters, heroes in MOBAs, character-specific movesets in fighters — multiply the match space. Team Fortress 2's nine classes mean the 9-class-composition problem is substantially different each match. Overwatch's 30-plus heroes, League of Legends's 160-plus champions, Dota 2's 120-plus heroes — each addition to the roster is not just content, it is a multiplier on the strategic space.

Deep mechanics. The game must reward extended investment. A shallow mechanic is mastered in ten hours. A deep mechanic keeps producing new patterns at 100, 1000, 10000 hours. Fighting games invest enormously in frame-data depth: every move has frame-level properties (startup, active, recovery, hit advantage, block advantage) that interact with every other move to produce a combinatorial explosion of situations. Counter-Strike's recoil patterns, grenade arcs, and spray-control techniques are another form of depth. The test: is a 1000-hour player still learning the game? If yes, the mechanic is deep.

Meta-evolution. The dominant strategies in a competitive game must rotate, or the game dies. This is not organic — it requires active design work. Every patch should adjust the balance enough that the top strategies shift. League of Legends's semi-monthly patches, Magic: The Gathering's quarterly banned-and-restricted lists, Valorant's half-yearly agent reworks — all of these are meta-shaping work. A balance pass that does not move the meta has failed at its primary job.

The meta is the game. This is the deepest insight of competitive design. You do not balance the game against the rules; you balance it against the meta. A weapon's damage number is irrelevant; what matters is whether, in the current competitive environment with the current best players using the current best strategies, that weapon produces the right outcomes. This means the designer's primary data input is not the theoretical balance sheet — it is the observed competitive scene. If your patch's damage numbers are objectively balanced but the pro scene is playing one composition every match, you have failed.

🎮 Case Study: Team Fortress 2's class balance, as Valve shipped the original 2007 game, proved to be remarkably durable — but only after years of patching reshaped which classes dominated at which levels of play. Update-by-update, the competitive meta has shifted between Scout-heavy, Demoman-heavy, and Medic-coordinated compositions. No patch has produced the "finished" balance; every patch is understood to be a move in an ongoing game, where players and designers are both playing the meta.

Asymmetric Multiplayer

Asymmetric multiplayer means players are not playing the same game as each other. One or more players have a fundamentally different role — different controls, different objectives, different win conditions, different information.

One versus many. Dead by Daylight — one killer vs. four survivors. Evolve — one monster vs. four hunters. The killer sees and plays differently; the survivors see and play differently. The design challenge is enormous: you are balancing two nearly-disjoint experiences against each other. Dead by Daylight has shipped over 35 killers and 40 survivors since 2016 and each addition is effectively a small new game that must be balanced against the entire existing roster. Arrowhead's Helldivers (the original) and Turtle Rock's Evolve are examples of how hard this gets — Evolve in particular was so hard to balance that the game launched with unfixable problems and collapsed within a year.

The impostor framing. Among Us uses asymmetry of information, not ability. Impostors and crewmates have the same controls and similar tasks — but impostors know they are impostors, and crewmates do not. The asymmetric information produces the entire social-deduction game. This is a cheap form of asymmetry because it does not require balancing two different movesets; it requires balancing the information flow. Secret Hitler, Werewolf, Throne of Lies, Project Winter all work on the same principle.

Cooperative asymmetry. Keep Talking and Nobody Explodes is cooperative asymmetry — one player defuses a bomb, the other reads the manual — and both must communicate. Artemis Spaceship Bridge Simulator assigns each player a different ship role (helm, weapons, engineering). Left 4 Dead's Versus mode shifts between infected and survivors each round, letting each player experience both sides and removing the "I always play the monster" burden.

Raid-style asymmetry. MMO raids in World of Warcraft, Final Fantasy XIV, and Destiny 2 typically have asymmetric role distribution — tanks, healers, DPS — but not asymmetric mechanics at the match level. Within an encounter, though, individual players may have different responsibilities (one player carries the bomb, one player stands on the plate, one player watches the door). This is asymmetry-of-moment inside a shared role-structure, and it is what makes MMO raids feel like choreography rather than a fight.

Designing asymmetric games is the hardest of all multiplayer disciplines because your balancing problem is now multi-dimensional — you are balancing across role, map, team composition, and player count simultaneously. A studio's first multiplayer game probably should not be asymmetric. Your second or third might be.

Persistent Worlds and MMO Design (Brief)

Massively multiplayer online games deserve an entire book rather than a section; we will settle for an orientation.

The sandbox. EVE Online is the extreme example. CCP Games built a single-shard universe (one server; every player shares the same world) with minimal scripted content and near-total player-driven economy, politics, and warfare. The resulting world has produced battles with tens of thousands of real players, real-money-equivalent damages in the millions of dollars, and a sociology literature about itself. The design choice: give players tools, not narratives. The consequence: the narratives are made of player wars.

The themepark. World of Warcraft is the opposite — a densely scripted world with designer-authored quest lines, raid encounters, and expansion narratives. Players follow a content treadmill: reach max level, run the new raid, acquire gear, wait for the next patch. The design choice: give players content, updated continuously. The consequence: the studio is permanently on a content-production treadmill and burnout is endemic.

Recovery. Final Fantasy XIV famously launched disastrously in 2010, was pulled down, redesigned, and relaunched in 2013 as A Realm Reborn. The recovery is held up as a rare case of a publicly failing MMO coming back. The Naoki Yoshida-led relaunch is worth studying as a design document — the original was overdesigned, over-specific, and hostile to casual play; the relaunch was architecturally humble, narratively generous, and open to the audience the original had alienated.

Community-voted updates. Old School RuneScape takes polls of its players on proposed updates; updates that do not pass the player vote are not shipped. Jagex has effectively given its community a veto on design direction. This produces an extremely specific kind of game: changes come slowly, the community remains attached, and design innovations come at the pace the players tolerate.

The social weight of persistence. The defining feature of MMOs is that the world persists when you log off, and your community is still there when you come back. This is social weight that instance-based multiplayer does not have. Your guild is a thing that exists whether you play tonight or not. Your character's gear is a thing you earned through hours of play. Quitting the game means leaving a community behind, which is much harder than quitting a deathmatch. This is the commercial virtue of MMOs — they retain players for years — and the ethical concern (the commitment can be exploitative; the exit cost can be enormous; time-vampire design can be rationalized by the very social weight that makes the game good). We will return to the ethics in Chapter 33.

The Multiplayer Lifecycle

An online multiplayer game has a lifecycle that single-player games do not have. Understanding its phases is essential for the studio that is committing to live service.

Launch and honeymoon. The game launches. Player counts are high, press is high, community excitement is high. Everything is going well, and the studio is exhausted from launch. This is usually months one through three.

Death of the honeymoon. Around month three to six, a predictable thing happens. The initial audience has finished whatever "content" the launch provided and is asking "what's next?". The social meta has stabilized into a few dominant strategies, and players are either mastering them or tiring of them. Player counts start to drop. Reviews shift from "I love this game" to "this game has potential." This is the critical moment. Studios that invested in post-launch content early, and have the next update ready, retain players through this dip. Studios that are still patching their launch bugs and have no update ready lose their population to the next game.

The long tail. If the game survives the honeymoon, it enters a long, slow arc. Seasonal content, balance patches, new modes, new characters, new maps. Player count plateaus or slowly declines over years. The community crystallizes into a dedicated core that stays for a long time. This is where the profitable live-service games live — Counter-Strike, Fortnite, Destiny 2, Apex Legends, Warzone — and it is where studios earn their ongoing revenue.

The sunset. Eventually the game ends. Either the population drops below viability, the studio moves on to a sequel, or the publisher pulls the plug. Shutdown is a design challenge in its own right: how do you say goodbye to a community that has been playing for years? Some studios have handled it well (Knockout City open-sourced its server; Landmark refunded players), others have handled it badly (many free-to-play mobile games simply vanish overnight with in-app purchases still loaded).

Cautionary tales. For Honor launched in 2017 with a broken matchmaking system and a narrow playerbase; Ubisoft fought hard to recover and did, but the launch arc is the textbook case of "could not pass the death of the honeymoon." Hyper Scape (2020) from Ubisoft never had a honeymoon — the game released into a saturated battle-royale market and folded within 18 months. Anthem (BioWare, 2019) had a decent launch but collapsed under the weight of shipped bugs and an "Anthem Next" revamp that EA eventually canceled, leaving the game in maintenance limbo. Evolve (2015) released with controversial monetization and never recovered its audience. All of these games teach the same lesson: the lifecycle does not forgive, and your launch plan is the bare beginning of the work, not the end of it.

⚠️ Pitfall: Shipping a multiplayer game without a roadmap is shipping a dying game. Players can feel, within the first month, whether a studio is committed to its live service or whether the multiplayer was a marketing add-on. If there is no "Season 1" scheduled by launch, the community reads "no future" and leaves accordingly.

GDScript / Godot Multiplayer (Brief)

Godot 4.x has a reasonably mature high-level multiplayer API. For small prototypes — and only for small prototypes; scaling to dozens of players requires significant engineering beyond the basic API — the built-in MultiplayerAPI gives you enough to demonstrate the concepts.

The core idea: you set up a network peer (one player is the "server", others are "clients"), you attach a MultiplayerAPI to the scene tree, and you annotate functions with @rpc so they can be called remotely. The engine handles serialization and replication.

Here is a small worked example: a NetworkedPlayer.gd that synchronizes position across a session.

# NetworkedPlayer.gd
# Minimal Godot 4.x networked player. Each client runs this; one is the host.
# The local authority owns movement; peers replicate position.

extends CharacterBody2D

const SPEED := 200.0
@export var player_id: int = 1

func _ready() -> void:
    # The network authority decides whose input controls this instance.
    set_multiplayer_authority(player_id)

func _physics_process(delta: float) -> void:
    if is_multiplayer_authority():
        # Only the owning peer reads input and moves the character.
        var input_dir := Input.get_vector("left", "right", "up", "down")
        velocity = input_dir * SPEED
        move_and_slide()
        # Broadcast position to other peers each tick.
        _sync_position.rpc(global_position)

@rpc("authority", "call_remote", "unreliable_ordered")
func _sync_position(pos: Vector2) -> void:
    # Runs on remote peers; authority calls it on them.
    global_position = pos

# Example of a reliable RPC for one-shot events.
@rpc("any_peer", "call_local", "reliable")
func take_damage(amount: int) -> void:
    # Runs on everyone including the sender.
    # Health resolution should still be server-validated in a real game.
    print("Player %d took %d damage" % [player_id, amount])

A minimal host-setup script, for completeness:

# NetworkManager.gd
# Handles host/join for a LAN or loopback session.

extends Node

const PORT := 27015
const MAX_PEERS := 4

func host_game() -> void:
    var peer := ENetMultiplayerPeer.new()
    peer.create_server(PORT, MAX_PEERS)
    multiplayer.multiplayer_peer = peer
    print("Hosting on port %d" % PORT)

func join_game(address: String) -> void:
    var peer := ENetMultiplayerPeer.new()
    peer.create_client(address, PORT)
    multiplayer.multiplayer_peer = peer
    print("Joining %s" % address)

Three things to notice. First, the @rpc annotations specify who can call the function (authority vs. any_peer) and how the packet is delivered (unreliable_ordered for per-frame state, reliable for one-shot events). These match the general netcode vocabulary: unreliable-ordered for continuous state that will be overwritten next tick, reliable for events that must arrive.

Second, position is being naively broadcast every physics tick. This is fine for a four-player LAN prototype and terrible for a production game. A real game interpolates between snapshots on the receiving side, compresses the position to fewer bits, and often uses a MultiplayerSynchronizer node (Godot has one built in) to handle state replication declaratively.

Third, the game is client-authoritative — each peer is the authority for its own player. This is an acceptable model for cooperative games with trusted players; it is wide open to cheating for competitive games. A competitive version would run the game logic on the server, with clients sending inputs and receiving state, which is substantially more engineering.

The point of the example is not that you can build Fortnite with it. The point is that the design vocabulary — authority, RPC, tickrate, reliable vs. unreliable — translates into a small, readable script that you can extend and experiment with. If you ever do decide to prototype a multiplayer mode, this is the skeleton.

Progressive Project Update — Ch 28: The Multiplayer Design Spec

Your action-adventure is single-player. It should stay single-player. Building a real multiplayer mode during this textbook would blow the scope budget by a factor of ten.

But a thought experiment is free. For this chapter's project deliverable, write a one-page multiplayer design spec for a hypothetical future version of your game. Not "the multiplayer mode we are shipping" — the multiplayer mode you would build if you had the budget, three more years, and a netcode engineer.

The spec should answer, concretely:

1. Cooperative, competitive, or hybrid? And why does your answer fit the feel of the game you have built?
2. Synchronous or asynchronous? And on what platform?
3. Player count? And why that number?
4. What is the shared fiction? Are you playing as two protagonists in the same world? Rival adventurers racing through dungeons? A dungeon master vs. a party? The framing matters.
5. What is the mechanical hook? What does this multiplayer mode let players do that the single-player does not? (If the answer is "nothing, it is just multiplayer," your mode is not worth building.)
6. What is the communication affordance? Voice, text, pings, emotes, nothing?
7. What is the multiplayer lifecycle plan? Is this a one-and-done mode or an evolving live service?
8. What are the three biggest risks? Balance? Toxicity? Population size? Netcode complexity?

Keep it to one page. A spec that fits on a page has been thought through; a spec that sprawls to five pages has not. When you have drafted it, stress-test it against the pitfalls section below. Revise.

Common Pitfalls

Designing PvP balance like single-player balance. In single-player, you tune an enemy to produce a target difficulty — the boss should kill the player two or three times before victory. In PvP, every buff to one option is a nerf to every player who chose another option, and your numerical target is not "difficulty" but "meta-rotation." Designers who carry single-player instincts into PvP produce games where one loadout dominates and the community migrates away from it every patch because the studio nerfs the current best thing in a cycle that never ends. Competitive balance is an ecosystem, not a number.

No anti-cheat plan. You shipped a PvP game. You did not plan for cheating. Month four, a cheat provider posts a YouTube video showing a wallhack running in your game. You have no engineer who knows anti-cheat and no vendor relationships. Your population begins to leave. You cannot staff up an anti-cheat team in weeks. The time to plan for cheating was pre-launch; the time you actually did it was post-mortem.

Voice chat without moderation. You shipped voice chat because "everyone does." You did not ship a moderation team. Your community becomes a harassment delivery service. Women and queer players leave first, then the audience broadens as word spreads. By the time you realize voice chat is a product decision rather than a technical feature, you have a reputation that will outlive the game.

Balance changes that ignore the meta. You produce a patch with "balanced" numerical changes — every weapon adjusted toward the mean damage. The competitive community, two weeks later, has found that the patch accidentally buffed a specific combo that was previously marginal. Your "balanced" patch produced a less balanced meta than the one you patched. This is why professional balance designers play the game at the highest competitive level; the numbers do not speak for themselves.

No plan for the player count drop. You did not plan for month three. Your matchmaking queues are now 90 seconds long at off-peak hours. Players who log in at 11 pm experience a different game than those who log in at 6 pm, and they share that frustration on social media. Meanwhile, your "Season 1" roadmap does not start until month six, because production did not allocate time to it during launch crunch. You are bleeding players into the gap.

Assuming online works the same everywhere. You tested in your office in California. You shipped globally. Players in Southeast Asia, Latin America, and the Middle East have 200-300ms pings to your US-West servers. Your reactive combat system has a 150ms parry window. Entire regions cannot play your game. Regional server infrastructure is expensive. It is also non-optional if you want a global audience.

Summary

Multiplayer design is not an extension of single-player design. It is a different discipline that happens to share a game engine. Single-player design authors content; multiplayer design authors the conditions under which players make content for each other. The player is the content.

Every multiplayer game chooses among a small set of core shapes. Cooperation, competition, or hybrid. Synchronous or asynchronous. Local, LAN, or online. Small, medium, large, or massive player counts. These choices, taken together, determine the entire genre and nearly the entire design space of the game. Choose them deliberately.

Matchmaking is a tradeoff machine, not a solved problem. Fairness, queue time, and connection quality cannot all be optimized; you pick two and accept the cost of the third. The choice is usually invisible to players but shapes every match they ever play.

Toxicity is a design output, not a community failing. The communication affordances you ship are harassment channels if you do not invest in moderation. Treat voice chat, in particular, as a product decision with operational consequences, not a feature you add.

Netcode is the floor beneath the design. What your engineers can ship — client-prediction, server-authoritative, tickrate, lag compensation, rollback — determines which mechanics are possible. Learn their vocabulary; respect their constraints; design within the envelope they build.

The lifecycle is the thing most teams underestimate. A multiplayer game is not a product; it is a service. Launch is the start, not the end. The honeymoon ends on month three and the community either stays or leaves based on what you have ready for them. Plan for the lifecycle the way you plan for the launch.

And if your progressive-project game is a single-player action-adventure — which, for this textbook, it is — stay single-player. Do not ship multiplayer you cannot support. Think about multiplayer. Read this chapter. Write the one-page spec. File it under "future work." Ship the single-player game.

Chapter 27 gave you an AI opponent that plays against your player. This chapter asked you to imagine a human opponent instead. Chapter 33 returns to the multiplayer questions from an ethics angle — toxicity's consequences, matchmaking's fairness, monetization's edge cases. Chapter 34 takes them from the business angle — the economics of live service, the revenue models that sustain multiplayer games over years. Together, those chapters give you the full picture: what multiplayer is (here), what its ethical commitments are (Ch 33), and what its business shape looks like (Ch 34). For now, the takeaway is simple. Build the table. Think about who sits at it. Think about what they can say to each other. Think about what happens when the conversation goes wrong. That is the whole job.