Chapter 28 — Exercises

These exercises are designed to build multiplayer design instincts even though the progressive project in this textbook is single-player. Do them as thought experiments, but do them seriously — the reps build the muscle. Most of the exercises require only a notebook, pen, and two or three multiplayer games you actually play. The coding exercise at the end is optional and Godot-specific.

Work through them in order. Later exercises assume you have done earlier ones. Save your outputs — the Progressive Project deliverable (the one-page multiplayer spec for your action-adventure) will be stronger if you have done the analytical and design exercises first.

A note on difficulty markers: Introductory exercises require only observation and comparison of games you already play; Intermediate exercises require original design work that you should share for feedback; Advanced exercises require research, outside reading, and the willingness to be wrong in public. Do at least one from each tier. If you find the Introductory exercises unhelpful because you already think about these questions reflexively, do them anyway — writing forces specificity that thinking does not, and your design reps are at their best when you cannot hide behind hand-waving.

A note on format: almost all deliverables in this chapter are written (memos, briefs, spec documents). This is not accidental. Multiplayer designers spend most of their time writing. Proposals to engineering. Balance-change notes to community managers. Incident reviews after server outages. Internal design reviews before feature sign-off. You will write more as a multiplayer designer than as a single-player designer, because every decision affects many more people and must be communicated to more stakeholders. The exercises here are as much writing practice as design practice.

Part A — Analysis (Introductory)

Exercise 28.1 — Matchmaking Comparison (Introductory)

Pick two competitive multiplayer games that you actively play, or have actively played. They should be from different genres if possible — e.g., a shooter and a fighting game, a MOBA and a battle royale. Play at least three ranked matches in each, or consult your match history from the past month.

Write a 600-800 word comparison addressing:

  1. Skill metric. How does each game rate player skill? Visible rank (tier/division), hidden MMR, performance score within a match, something else? How transparent is the system to the player?
  2. Queue time vs. match quality. How long were your queues at peak vs. off-peak times? Did off-peak queues produce worse (more lopsided) matches? How did the game handle the tradeoff?
  3. Party play. How does each game handle parties (groups) vs. solo queuers? Are parties matched only against parties, or mixed with solos? Did this produce any mismatch experiences?
  4. Smurfs and new-account handling. How obvious were smurfs in your low-rank matches? Did the game seem to have a calibration phase for new accounts? What clues would let you identify a smurf?
  5. Ranked vs. casual. Do both games have separate ranked and casual queues? How do the matchmaking rules differ between them? Which feels better to play, and why?

The goal of this exercise is to notice matchmaking as a design decision. Before this chapter, most players experience matchmaking as invisible plumbing. After this exercise, you should see it as a series of consequential choices made by the studio.

Exercise 28.2 — Communication Audit (Introductory)

For each of three multiplayer games you have played recently, fill out the following table:

Game In-game voice chat Text chat Ping system Emotes Post-match chat Report system Moderation feedback

For each cell, describe what is available and any notable design choices. After filling the table, write a 400-600 word analysis of:

  • Which game's communication design you think best serves its gameplay, and why.
  • Which game's communication design you think creates the most toxicity risk, and whether you have observed that risk materializing in your own matches.
  • Whether any of the three games has communication features you would remove, and what you think the studio was trying to solve with the features you would remove.

Exercise 28.2a — Toxicity Observation Journal (Introductory)

For one week, keep a toxicity journal covering two online multiplayer games you play regularly. Each session, note:

  • Game and session length.
  • Number of teammates and opponents encountered. (If stranger-matchmade.)
  • Count of toxic incidents observed. (Slur, personal attack, deliberate griefing, rage quit, harassment via voice, harassment via text, harassment via emote or ping spam.)
  • What channel the toxicity used. (Voice, text, in-game emote, report-system-abuse, after-match-lobby.)
  • How you responded. (Muted, reported, argued back, ignored, left the match.)
  • How the game supported or failed your response. (Was the mute instant? Could you report? Was there feedback?)

At the end of the week, tabulate your journal. Compare the two games. Which produced more toxicity per session? Which produced higher-bandwidth toxicity (voice vs. text)? Which had better tools for response? Write a 400-600 word reflection on what your data tells you about the communication-design choices of the two games, and what one concrete change to each game you would propose to reduce the toxicity you observed.

The point of this exercise is empirical rather than theoretical. Design discussions of toxicity often stay at the level of "games should do better." Your data grounds the discussion in what you specifically experienced — which, in aggregate across a class of designers doing this exercise, becomes a reasonably honest picture of the current state of multiplayer hostility.

Part B — Design (Intermediate)

Exercise 28.3 — Four-Player Asymmetric Co-op Concept (Intermediate)

Design, on paper, a 4-player asymmetric cooperative game concept. The core premise: the four players have four different roles, with different controls, different views, and different responsibilities. The team succeeds only if all four perform their role.

Deliverable: a 3-4 page design brief containing:

  1. The one-sentence pitch. (Example: "Crew is a 4-player asymmetric co-op in which one player pilots a damaged spaceship while the three others manage engineering, navigation, and weapons from different stations.")
  2. The four roles. For each role: a name, a one-paragraph description of what this player does, a bulleted list of their unique controls or abilities, and a single sentence describing what makes the role enjoyable.
  3. The shared objective. What is the team trying to do? How does success get measured?
  4. The interdependence map. Draw or describe the links between roles: what each role produces that another role consumes. A pilot needs navigation data; navigation needs to know where weapons are pointing; weapons need power from engineering; engineering needs the pilot to avoid taking hits.
  5. The failure mode analysis. What happens if one player is bad? What happens if one player disconnects? Can the game continue? Should it?
  6. Balance risks. Which role is likely to be unpopular? Which role might dominate the match narrative? How would you compensate?

Grade yourself against the asymmetric design pitfalls from the chapter. If the game would only work with four coordinated friends on voice chat, that is probably not a shippable product — what could you change to make it playable with randoms?

Exercise 28.3a — Matchmaking Algorithm Sketch (Intermediate)

You are the matchmaking lead on a new 5v5 team shooter launching globally. Your design constraints:

  • Target average queue time: 90 seconds at peak, 180 seconds off-peak.
  • Target skill fairness: matches where both teams have a projected win probability within 45-55%.
  • Regional servers: North America East, North America West, Europe West, Europe East, South America, Asia Pacific, Middle East, Oceania. You may not cross regional boundaries because latency would exceed 120ms.
  • Party sizes: solo through 5-player parties.
  • New accounts: first 10 matches are "calibration" with wider skill brackets.

Write a 800-1200 word design memo sketching:

  1. The rating system. What mathematical model do you use (Elo, Glicko, TrueSkill, proprietary)? Why?
  2. The queue algorithm. How does the matchmaker select candidates and form teams?
  3. The fairness-vs-queue-time fallback schedule. After 60 seconds, do you loosen? After 120? What exactly loosens — skill bracket, party composition constraints, something else?
  4. How you handle the solo-vs-party problem (a 5-stack queueing against 5 solo players).
  5. How you detect and handle smurfs.
  6. How regional populations of different sizes affect your decisions (Oceania has 1/20 the players of Europe West; the same algorithm does not serve both well).

Include a "known-limitations" section: three things about your proposed algorithm that you believe could produce player complaints, and how you would tune them post-launch.

Exercise 28.4 — Battle Royale Alternative (Intermediate)

The battle royale genre is dominant but follows a specific formula: large map, 100 players, shrinking circle, last-player-standing wins. Imagine that the dominant formula does not exist. Design an alternative 100-player format from scratch.

Write a 1000-1500 word proposal covering:

  • The match objective. If not "last player standing," what? Team capture-the-flag? Cooperative race? Asymmetric roles? Concentric objectives?
  • The "contraction mechanic." Battle royale uses the shrinking circle to force encounters. What does your alternative use? Scarcity of resources? Objective rotation? A timer with escalating penalties?
  • The starting conditions. Where do players begin? Do they have equipment? Do they pick roles?
  • The end condition. When does the match end? Is it possible for a "team" to win without eliminating everyone else? What does second place feel like?
  • Why this is not battle royale. Explicitly: what design problems with battle royale are you trying to solve? What problems from battle royale does your design inherit anyway?

This is a design exercise in counterfactual thinking. The formula is not the only formula. Designers who can propose alternatives are designers who are not trapped by the current genre.

Part C — Theory (Intermediate-to-Advanced)

Exercise 28.5 — Moderation System for a Voice-Enabled Team Game (Intermediate-Advanced)

You are the lead designer on a new 5v5 competitive team shooter with mandatory voice chat in ranked matches (the team communication is essential to the design). Your studio has committed to shipping a moderation system that minimizes toxicity without compromising the tactical communication the game requires.

Design the moderation system. Your design brief (1500-2000 words) should cover:

  1. Voice transmission architecture. Push-to-talk vs. open-mic? Team-only vs. all-chat? Does the game record audio, and if so, for how long?
  2. In-match controls. What can a player do during a match if a teammate is being abusive? Mute? Report? Kick? How is the kicking (if allowed) prevented from being weaponized against specific teammates?
  3. Reporting workflow. What happens when a report is filed? Is any automated action taken, or is everything routed to human review? What is the expected review time?
  4. AI/ML detection. Are you using voice-transcription with keyword detection? Pattern matching on speech rhythm? Only human-verified reports? What are the false-positive costs of each?
  5. Escalation ladder. What penalties exist, and how are they applied? Chat mutes, ranked queue bans, account suspensions, permanent bans? How do repeat offenders climb the ladder?
  6. Appeals. Can a banned player appeal? What is the evidence standard? Who reviews appeals?
  7. Transparency. What do reporters see after filing a report? Do you tell them if their report led to action? Do you publish aggregate ban statistics?
  8. Regional and language considerations. English-speaking moderation is easier than Portuguese; Portuguese is easier than Arabic. How do you handle underserved languages and regions?
  9. The staffing model. How many moderators do you need? Full-time vs. contract? In-house vs. outsourced? What is your per-month budget?
  10. The failure mode. What is the scenario in which your system breaks? A coordinated griefing campaign? A false-report bot? A streamer who weaponizes the report system against rivals? How do you detect and respond?

End the brief with a self-critique: which parts of your own design are you least confident in, and why?

Exercise 28.6 — Netcode-Constrained Mechanic Design (Advanced)

You are the lead combat designer on a new online fighting game. Your network engineer gives you the following constraints:

  • Rollback netcode, 60fps simulation.
  • Target worst-case ping: 120ms one-way.
  • Input poll rate: 60Hz, no sub-tick.
  • Maximum rollback window: 8 frames.

Design three mechanics that are made possible by rollback and would not work on delay-based netcode, and three mechanics that are foreclosed by the 8-frame rollback window and the 120ms ping assumption — mechanics you would not attempt to ship. Provide 100-150 words of reasoning for each of the six mechanics.

Then, for one of your possible mechanics, write a 300-500 word detailed design spec: frame data, inputs, countermeasures, what a high-skill execution looks like. Treat it as a proposal you would hand to a prototyper.

Part D — Critical (Advanced)

Exercise 28.7 — Autopsy of a Dead Multiplayer Game (Advanced)

Choose a multiplayer game that launched with significant press and budget and is now shut down, in maintenance mode, or has a critically reduced playerbase. Candidates: Hyper Scape, Anthem, Evolve, Battleborn, LawBreakers, Concord, Radical Heights, The Culling 2, Rumbleverse, Knockout City (before open-source resurrection), Bleeding Edge. You may choose another if you have stronger personal knowledge.

Write a 2000-2500 word critical autopsy addressing:

  1. The pitch. What was the game at launch? What were the developers selling? Read contemporary press coverage from launch week.
  2. The launch. What actually shipped? How did the launch numbers compare to target? Look for CCU (concurrent user) statistics from SteamDB, tracker sites, or the studio's public statements.
  3. The honeymoon curve. How did the playerbase trend over weeks 1-12? Where was the steepest drop? When did the CCU fall below viability for matchmaking?
  4. The diagnosis. What went wrong? Construct a causal story. Was the matchmaking broken? Was the genre oversaturated? Was the monetization hostile? Were there netcode problems? Was the marketing off-target? Almost always multiple factors compound — identify at least three.
  5. The studio's response. How did the studio react? Patches, pivots, pulled monetization, added content, eventual shutdown? Was the response timely or too late?
  6. Counterfactuals. What design decisions, if made differently at launch, would plausibly have saved the game? Consider: matchmaking, communication, player count, mode variety, progression, monetization, regional server rollout, marketing cadence.
  7. Lessons for your own work. If you were making a game in an adjacent space, which specific choices would this autopsy make you reconsider?

Cite sources. You should be drawing on press coverage, developer post-mortems (GDC talks, Medium posts, Twitter threads), and player community discussions. This is not a creative-writing exercise; it is a forensic exercise. Get the facts right.

Exercise 28.8 — The Ethics Preview (Advanced, Optional)

This exercise foreshadows Chapter 33 (Game Design Ethics). Pick one of the following three scenarios and write a 1000-1500 word position paper:

A. Predatory matchmaking. You are the matchmaking lead on a free-to-play PvP game with a cosmetics shop. Your data scientist proposes an experiment: match spenders against non-spenders at slightly favorable skill ratios, increasing spender win rates by 3-5%. The hypothesis is that spenders who win more will spend more. The experiment's effect on retention and revenue is projected to be substantial. What do you do?

B. Voice chat in a youth-facing game. Your game is rated T for Teen and has a substantial under-18 audience. Voice chat data consistently shows harassment of minors by adults. Removing voice chat will cost you approximately 8% of daily active users and significant competitive community goodwill. What is your recommendation to leadership?

C. Shutting down a community. You are the product director on a six-year-old multiplayer game with 30,000 monthly active users, a dedicated but declining community, and revenue that just went below the break-even line. Sunsetting is financially rational. The community's most committed members — some of whom have played for 5000+ hours — will lose access to a social world. How do you design the sunset? Is there anything you can do to soften the loss that would also be economically viable? At what point does "business necessity" become "abandoning the people who kept your game alive"?

Part E — Implementation (Optional, Godot)

Exercise 28.9 — Networked Movement Prototype (Optional, Advanced)

If you want to experiment with Godot 4.x multiplayer, build a minimal networked movement prototype based on the NetworkedPlayer.gd example from the chapter.

Requirements:

  1. Host-join over localhost or LAN. Two players should be able to connect.
  2. Each player controls their own character; both characters are visible to both clients.
  3. Add interpolation on the receiving side so remote players do not jitter when packets arrive. Do not just snap to the latest position.
  4. Add a simple take_damage RPC that a player can trigger by pressing a key while touching another player. Display each player's health on their own HUD.
  5. (Stretch) Add latency simulation to test what the game feels like at 100ms and 250ms simulated ping. Godot's MultiplayerAPI has built-in latency simulation via multiplayer_peer.set_target_peer and timed delays, or you can insert your own artificial delay on RPC calls.

Deliverable: the Godot project, plus a 400-600 word write-up on what you learned. Specifically: did client prediction feel necessary for the local player? Did remote player movement feel acceptable without interpolation? What happens at 250ms ping that does not happen at 0ms?

Do not attempt to extend this into a competitive PvP game. The client-authoritative model is wide open to cheating and is only appropriate for LAN/friend-group play. A server-authoritative version is substantially more engineering.

Exercise 28.10 — The Progressive Project Deliverable (All Levels)

This is the chapter's primary deliverable. Write a one-page multiplayer design spec for a hypothetical future version of your single-player action-adventure progressive project.

The spec must fit on a single printed page. One page is a discipline; a longer spec is a less thought-through spec. Use dense, specific language — no throat-clearing, no marketing copy, no "we would like to potentially explore the possibility of." Direct declarative statements.

Address, in this order:

  1. One-sentence pitch. What is this multiplayer mode?
  2. Shape. Cooperative, competitive, or hybrid? Synchronous or async? Local or online?
  3. Player count and match length. A specific number and a specific range.
  4. The mechanical hook. What can players do in this mode that the single-player cannot offer? If your answer is "play with a friend," try again.
  5. Communication affordance. Voice, text, pings, emotes, nothing? Why that choice?
  6. Matchmaking approach. Skill-based, lobby-based, friend-invite, random drop-in? What is your regional strategy?
  7. Anti-cheat posture. What is your plan? (If the answer is "none because it is cooperative with friends," say so — that is a valid answer for cooperative contexts.)
  8. The lifecycle plan. Is this a one-and-done mode, a seasonal mode, or a permanent live service? What does the first six months look like?
  9. The three biggest risks. Specific risks, ranked.
  10. Cost estimate. Rough engineering months and team composition required. Be honest.

Constraints on the exercise:

  • The spec must be plausible given a hypothetical future version of your project. It cannot invent new mechanics that fundamentally contradict your single-player design.
  • The spec must be defensible — you must be able to argue, for each of the ten points, why the choice fits the game and your studio's capacity.
  • The spec must be specific. "Four players" is better than "a small group." "90-second queue target at peak" is better than "fast queues."

When complete, hand your spec to another designer (a classmate, a friend, a community member) and have them perform a critical review. Specifically ask them: which of the ten points do you think is weakest? If they had to veto one decision in the spec, which would it be?

Revise based on their feedback. Keep both drafts. Six months from now, when you are starting a different project, look back at your spec and note which of your assumptions about multiplayer design have shifted.

This is the chapter's Progressive Project checkpoint. File the spec in your design-document folder. Do not build the multiplayer mode. You are a single-player action-adventure team. The spec is the discipline of having considered multiplayer seriously enough to reject it for this project — or, if you revisit this in the future, a starting point from which another version of your game might grow.

Submission. For the course this textbook accompanies, submit your written exercises as a single PDF and any Godot projects as a linked repository. Grading rubrics for these exercises are in the Instructor Guide. For self-study readers, share your drafts on the book's community Discord or the subreddit for feedback — multiplayer design improves fastest through conversation with other designers, which is, after all, what this chapter has been about.