Chapter 39 Exercises

These exercises move the post-launch discipline from abstract to operational. By the end, you should have a launch-day playbook, a set of case-study-informed lessons, a three-month roadmap for your own game, and a carefully examined sunset note. Do them in order; each builds on the previous.

Practical: Write a Day-One Crisis Playbook

You are about to launch. Four days from now, your game goes live on itch.io and Steam simultaneously. Write a day-one crisis playbook that your team (even if the team is just you) will follow.

Your playbook must cover, in explicit detail, the following:

(1) Incident classification. Define three severity levels for post-launch issues. Write a one-paragraph definition for each. Example starting point — P0: game-breaking (crash on boot, save corruption, progression blocker, security exploit). P1: significant (a major system behaves wrong, a common path is broken, a large fraction of players affected). P2: minor (cosmetic, edge-case, low-impact). For each level, specify: the maximum time-to-first-response, the maximum time-to-fix, and who has authority to declare that an issue is at that level.

(2) Triage roles. List every role that needs to exist on day one and name the person who is filling it (for a solo dev, that name is yours, repeated — but write it out explicitly so the workload is visible). Minimum roles: Crash-Dashboard Watcher (who is looking at the telemetry and report aggregator), Community Reader (who is reading Discord, Reddit, Steam forums, Twitter replies), Bug Reproducer (who verifies that a reported bug is a real bug), Fixer (who writes the fix), QA Verifier (who confirms the fix works and does not break anything else), Deployer (who pushes the build), Communicator (who tells the public what just happened). Specify handoffs between roles — who escalates to whom when.

(3) Communication cadence. For the first forty-eight hours, write a schedule. When do you post a status update publicly? How often? What is the format? (Example format: two-sentence update, clear state — "We are investigating / we have identified the issue / a fix is in QA / a fix is rolling out / the issue is resolved." — with a timestamp.) Where do you post? Discord, Twitter/X, Steam news post, itch.io devlog? Specify each channel and who is responsible for each.

(4) Decision authority. Spell out, in writing, what decisions can be made without escalation and which require it. Who can push a hotfix? Who can promise a specific fix date to the community? Who can ban a user? Who can issue refunds (if that is within your purview)? Ambiguity here is where post-launch disasters are made.

(5) The first holiday. Put a date, in writing, for when the team gets its first day off after launch. If the answer is "whenever it gets quiet," that is wrong — set a concrete date, protect it, and if the post-launch work is not done by then, find someone else to cover. A team that never rests ships worse patches.

Your playbook should be three to five pages, formatted as a usable document — not an essay. The test of a good playbook is: can someone who has never seen it follow it in the middle of a crisis, at three in the morning, when they are panicked?

Research: Trace Three Post-Launch Recovery Arcs

Choose three games, each with a well-documented post-launch recovery. Suggested set: No Man's Sky (2016 launch disaster → 2024 praised), Final Fantasy XIV (1.0 disaster → A Realm Reborn → decade of growth), and Cyberpunk 2077 (2020 launch disaster → 2023 Phantom Liberty redemption). You may substitute one with another documented case — Sea of Thieves, Destiny 2, Rainbow Six Siege, Warframe, Path of Exile — but stick to titles with rich public post-mortems.

For each game, produce a written analysis (one to two pages each) that identifies and evaluates:

The launch state. What shipped? What was missing, broken, or misrepresented? How did critics receive it? How did players react? Pull at least two specific data points per game — concurrent player counts, review scores, refund rates — from public sources.

The turning-point decisions. Every recovery has a decision (or a small cluster of decisions) that redirected the trajectory. For No Man's Sky, it was the decision to ship free updates and rebuild rather than sunset. For FFXIV, it was Naoki Yoshida's decision — and Square Enix's decision to let him — to rebuild the game while running the broken one. For Cyberpunk, it was the commitment to multi-year patching plus the Phantom Liberty expansion. Identify the specific turning-point decisions; cite post-mortems, interviews, or GDC talks where you can.

The cost. What did the recovery cost, in years, in team morale, in scope of the original vision? Many recoveries succeed creatively while exhausting the team. Address this honestly.

The generalizable lesson. What would a different studio, in a different launch disaster, learn from this game's path? Be specific; avoid platitudes like "communicate honestly" (true but useless). Instead: "Ship free major updates on a published cadence, so even skeptics see continuous evidence of commitment." Or: "Separate the broken game from the rebuild — do not try to patch a version that is architecturally beyond repair."

Write the three analyses, then write a short (one-page) synthesis: what do the three recoveries have in common? Where do they differ? What would you, today, take from this research into your own post-launch planning?

Cite your sources. Death of a Game: Final Fantasy XIV (NerdSlayer, YouTube) is a thorough history of FFXIV's 1.0 era. Sean Murray's No Man's Sky talks and the various retrospectives in Eurogamer and IGN cover that recovery in depth. Cyberpunk 2077's patch cadence is documented in CDPR's own patch-notes archives plus the Phantom Liberty launch coverage.

Design: Propose a Three-Month Post-Launch Roadmap

Your progressive-project 2D action-adventure game is about to launch. Write a three-month post-launch roadmap for it. This is the roadmap you would show publicly (to community) and privately (to team). Write two versions of the document — the public version and the private version — because they serve different purposes and should contain different levels of detail.

Public roadmap. One page. Use rough time windows, not precise dates. Structure: "Month 1 — Stability and Polish," "Month 2 — Quality-of-Life and Small Content," "Month 3 — First Content Update."

For each month, commit to two or three specific deliverables, each phrased in a way the community can hold you to but not corner you with. Good: "Keybinding remap and controller rebinding, which have been our top community requests." Bad: "Full controller rebinding for Xbox, PlayStation, Switch Pro, and third-party gamepads, with support for chorded inputs and per-button deadzone adjustment." — too specific to a single feature; what if it ships shorter?

Include a section called "What we are not doing yet" — features the community has asked for that you have decided not to do in the first three months. Name two or three, explain briefly. This section is more important than the "what we are doing" section: it prevents the roadmap from becoming a pile of unacknowledged requests that the community thinks you ignored.

Private roadmap. Three to five pages. Includes everything the public roadmap does, plus:

• Specific tasks per week, with owners (even if the owner is always you).
• Estimated hours for each task and cumulative effort per week — so you can see when you are overcommitted.
• Risk list: which features might slip, which might need to be cut, which depend on things outside your control.
• A scope-reserve: at least twenty percent of your time budget reserved for "things we cannot predict" — bugs that surface, community emergencies, platform issues.
• A burn-down chart or equivalent for tracking progress week by week.
• A review checkpoint at the end of month one: what did we actually ship? How does that compare to plan? What are we adjusting for months two and three?

Submit both versions. Reflect, in a short paragraph, on how the public version and the private version differ — what you chose to hide, what you chose to show. The discipline of public roadmapping is largely the discipline of communicating uncertainty honestly.

Critical: Analyze a Goodbye

Choose a game that has been sunset and whose final developer note is publicly available. Examples: City of Heroes (2012 shutdown letter from NCSoft / Paragon Studios), The Matrix Online (2009), Star Wars Galaxies (2011), Club Penguin (2017), Landmark (2017), Hyper Scape (2022), MultiVersus's temporary shutdown (2023), or the various smaller live-service shutdowns documented in the Died by Ninja or similar video-essay channels.

Find the shutdown announcement. Read it carefully — the full text, not the summary. Then write a two-page analysis.

What does the note communicate? Identify: the reason given for the shutdown (commercial, technical, strategic); the timeline (how much notice the community is getting); what happens to players' investment (purchases, progression, social connections); whether an offline or preservation option is being provided; the tone (corporate, personal, apologetic, defiant).

What does the note conceal? Most sunset notes omit things — internal decisions, project dynamics, the fact that a team fought hard to save the game and lost. Read between the lines. What would you, as a practitioner, read in the silences?

What did the community do with it? Find responses — Reddit threads, news coverage, community efforts. Many sunset games generate fan-preservation efforts (private servers, reverse-engineering projects, tribute sites). City of Heroes famously returned years after shutdown via fan-run servers; the relationship between the original shutdown note and that afterlife is part of the story.

The practitioner takeaway. If you had to sunset your own game, what would you take from this note? What would you do the same? What would you do differently? Write a short imagined sunset note for your progressive-project game (assume you are shutting it down in 2028 because your two-person team is moving on to a new project). Two to three paragraphs. Be honest. This is an imagined exercise but treat it as the real document — because some day, for some game, you may be writing it.

Bonus Exercise: The Patch Notes Voice

Patch notes are among the most-read pieces of writing your studio will ever publish. A loyal community will read patch notes the way newspaper readers once read the obituaries — carefully, with real investment. The voice of your patch notes sets a tone that other studio communications will be measured against.

Study the patch notes voices of three games whose tones you find distinctive. Good candidates: Slay the Spire (whose patch notes are dry-funny and famously beloved), Hades (which treats patch notes as part of its voice and atmosphere), Destiny 2 (whose notes are long, technical, and serious), Hearthstone (whose notes are cheerful and designer-led), Apex Legends (whose notes are marketing-adjacent), Path of Exile (whose notes are exhaustive and technical).

Write a one-page comparative analysis: what is each game's patch-notes voice, what does it communicate about the studio's values, and what does the community appear to make of it? Are the notes written in first person, third person, or "studio voice"? Do they use humor, and if so, what kind? Do they credit specific team members or specific reporters of bugs? Do they acknowledge trade-offs explicitly ("we know this change is going to hurt; here is why we made it anyway") or do they present every change as a straightforward improvement?

Then write the patch notes for your own v1.1 patch — the one described in the progressive-project section of the chapter. Two versions: a formal version (suitable for a Steam news post, a studio blog, a press release) and a community-facing version (suitable for Discord or the itch.io devlog). Both versions should describe the same changes but in different voices. Pay attention to: how you credit player bug reports, how you describe known-outstanding issues (the bugs you have not fixed in this patch), how you handle community-requested features you declined to add, and how you sign off. The sign-off — the last paragraph — is where most patch notes fail; write a good one.

The point of this exercise is not the writing for its own sake; it is to internalize that patch notes are design communication. They tell the community what you value, what you prioritize, how you think. Over the course of a long-running game, the accumulated patch notes become a secondary document as important as any design document you ever wrote internally.

Bonus Exercise: The Community Pulse Check

Set up a structured process for reading your community weekly. This exercise is about building a practice, not producing a single artifact.

For two consecutive weeks, every Friday afternoon, spend ninety minutes reading your community (for the purposes of this exercise, imagine your progressive-project game has been on itch.io for three months; if that is not yet true, pick a real indie game whose Discord you can join). Cover at minimum: your Discord's general and feedback channels, your itch.io comment section (or Steam forum if applicable), the subreddit if one exists, and a Twitter/X search for your game's title.

Take notes in a structured format. Four columns: Signal (what was said), Frequency (how many people said it), Source (which channel), Category (bug, balance, feature request, praise, criticism, question). At the end of each week, compile the notes into a short report: the top five most-frequent signals, the top three most-interesting single pieces of feedback (regardless of frequency), and your proposed response — action, discussion, defer, or nothing.

After two weeks, write a short reflection. What did the process teach you about your community that the raw Discord experience did not? What signals repeated? Which loud individual complaints turned out to be non-representative? Which quieter signals turned out, on closer inspection, to be more significant than they initially seemed? What does this practice suggest about how often you should repeat the exercise if this were your actual long-term post-launch work?

The point here is discipline. Reading community is a muscle; without a structured process, you will read what is loudest rather than what is representative, and you will respond to what is emotional rather than to what is informative. Build the process before you need it.

Bonus Exercise: The Telemetry Dashboard Mock-Up

Design, on paper or in a spreadsheet or in a Figma mock, the telemetry dashboard you would want to look at every morning in the first thirty days after launch. This is the single screen — or at most two screens — that tells you whether the game is healthy, where the fires are, and what the next patch should prioritize.

Constraints: the dashboard must fit on one screen at a normal laptop resolution. Every metric must have a clear definition (what exactly is counted, over what window, with what filters). Every metric must also have a threshold — a number or condition that would trigger you to act. Without thresholds, a dashboard is decoration; it tells you numbers but not what to do with them.

At minimum, include the following sections, each with at least two metrics and clear thresholds:

Stability. Crash rate per session, percentage of sessions that end in crash versus normal exit, top-five crash signatures by frequency. Threshold example: a crash rate above two percent of sessions triggers a P0 incident review.

Engagement. Daily active users, average session length, day-1 retention, day-7 retention, and the change in each of these versus yesterday or versus the previous week. Threshold example: a twenty-percent week-over-week decline in DAU triggers a qualitative investigation of what changed.

Content consumption. Percentage of players who have reached each major story or progression checkpoint, ordered so you can see the cliffs. Threshold example: a drop-off greater than fifteen percent between two adjacent checkpoints triggers a content review for that segment.

Economy (if applicable). Currency flow — how much is being earned versus spent, by source and sink. Inflation or deflation indicators. Threshold example: a week-over-week change greater than twenty percent in either direction triggers a balance review.

Community signal. A count of bug reports by severity, a sentiment proxy from your community channels, a top-five list of most-requested features. This section is qualitative-flavored but still countable.

For each metric, write the specific SQL-like query or event-aggregation logic that would produce it. Do not write actual SQL unless you want to; write clear enough pseudocode that a data engineer could implement it.

Present the mock as a layout with fictional but realistic numbers for a hypothetical day fifteen of your post-launch. Add a "morning commentary" — the three sentences you would write at the top of the dashboard each day to interpret the numbers for your team. That morning commentary is where a good dashboard owner earns their keep; the numbers are inputs, the commentary is the signal.

Bonus Exercise: The Honest Letter to the Team

Write a one-page internal letter to your team that you would send on day thirty after launch.

This is not a public letter. It is internal. You may be brutally honest in it, or carefully encouraging, or both; the exercise is to find your own voice for the moment when the launch dust has settled and the real shape of what you shipped has become visible.

Cover, at minimum: what went well, what went badly, what surprised you, what the team should be proud of regardless of how the launch was received, what the next phase of work looks like, and what — if anything — you are asking the team to do differently. If the launch was a success, resist the temptation to triumph; successes breed their own blindnesses. If the launch was a failure, resist the temptation to despair; a thirty-day post-launch letter is not the place to decide the game's long-term fate.

Read your letter aloud. Does it sound like something you, specifically, would say? Or does it sound like a generic management letter any manager could have written? The test of a good internal letter is specificity — specific things you saw the team do, specific moments you want to remember, specific decisions you want to mark. Generic encouragement is worse than no letter.

This exercise is practice for the real one. Every game you ever ship will, at day thirty, deserve a letter like this. Learn to write it early.

Bonus Exercise: The Sunset Simulation

Imagine you are three years post-launch. Your progressive-project game has had a modest but loyal audience. You have shipped v1.1 through v1.8, a free holiday-themed content drop, and a paid expansion that added a new region. The game has never been a hit, but it has paid for itself, and you have a Discord of about eight hundred regulars who have stayed with you the whole time.

Your studio — you and one collaborator — has started work on your next project. The next project is larger, more ambitious, and will consume your full attention for the next two to three years. Supporting the current game at its current cadence is no longer sustainable; you have to decide what to do with it.

Write a three-part sunset plan:

Part one: the technical plan. What, specifically, do you do to the game's codebase, build pipeline, and server infrastructure (if any) over the next six months? List concrete tasks with rough time estimates. If your game has any always-online components, what is the offline-patch plan? If your game has cloud-saves, what happens to them? If your storefront pages need to remain maintained, who does that?

Part two: the community plan. How do you communicate the sunset to your eight-hundred-person Discord community? What is the timeline? What events, content, or moments do you offer as a farewell? What do you commit to continuing (bug fixes? storefront presence? community moderation?) and what do you stop doing? Be specific about the cadence of your final communications — how many posts, on what channels, spread across what period.

Part three: the creative plan. What, if anything, do you say publicly about the game's creative legacy? Do you release the source code? Do you publish a final design document or developer commentary? Do you leave a breadcrumb for the community to take over maintenance if they choose? Consider the Stop Killing Games argument in your answer: what obligations do you believe you owe to players who bought the game, and how do you discharge them?

Write it as if you were going to publish it as an internal document tomorrow, and then act on it six months later. The point is not to predict your actual future but to force yourself to think — in advance — about the end-of-life phase that every game eventually enters. Designers who have thought about the sunset from the first day of development make better architectural decisions along the way. They build games that can be sunset with grace because they have imagined the sunset.

Bonus Exercise: A Studio Tone Study

Compare the studio voices of three developers' post-launch communications over a six-month window. Good candidates: Supergiant Games (for Hades and Hades II), Larian (for Baldur's Gate 3), Mossmouth (for Spelunky 2), Motion Twin (for Dead Cells), Team Cherry (for Hollow Knight and Silksong), or ConcernedApe (for Stardew Valley).

Read every public post-launch communication — patch notes, blog posts, Twitter, Discord announcements — from these three studios over the six-month window you choose. Take notes on tone, frequency, specificity, humor, the degree to which individual team members are identified, and the way criticism is handled.

Write a two-page comparison. What do the three studio voices have in common? Where do they differ? Which voice most resonates with you as a designer, and why? What elements of each voice would you want to borrow for your own studio's communications, and what would you avoid?

Finally, draft a one-paragraph "studio voice guide" for your own work. Three to five sentences that describe how your studio communicates: formal or informal, frequent or occasional, first-person or third-person, humorous or earnest, technical or accessible. This is a document that, if you hire or collaborate with anyone in the future, you will want to have written down. Studios without a defined voice end up with whichever voice their most recent community manager happens to use, and the result is inconsistency that erodes trust.

Submit all eight exercises as a single portfolio. The playbook, roadmaps, patch notes, telemetry dashboard, and internal letter should be formatted as working documents; the research, critical analysis, and community reflection should be short essays. Together, they form a post-launch professional practice. Most developers never write any of these things explicitly, which is why most games handle post-launch worse than they could. Be the developer who wrote it down.