Game patch notes: writing updates players actually read

Patch notes are the one corner of software where the audience shows up wanting to read. Nobody refreshes a spreadsheet app's changelog at midnight; players do exactly that on patch day. Communities screenshot notes, argue about them, make videos about them. That attention is a gift most studios squander — with vague lines, missing numbers, and changes that aren't in the notes at all. This guide is about honoring the one audience that reads.

Three readers, one document

Every patch note serves three players at once:

• The casual player wants the headline: what's new, what's fun, is my favorite thing different. They read the top and skim the rest.
• The invested player wants exact numbers. They know the current values by heart, they'll notice a 5% change in play, and they will compare your notes against what actually shipped.
• The player whose bug it was wants one line: the crash/exploit/glitch they personally hit, named by symptom, marked fixed. This is the symptom-first rule from ordinary changelog writing, and it matters more in games because players report bugs in community language ("the elevator eats you") — use their words, not your ticket titles.

The structure that serves all three: headline changes up top (new content, big reworks), then sections by game system — the map of the game as players experience it (Combat, Economy, UI, Performance, per-character or per-weapon blocks), never by internal team. "Engine team" is not a place in your game.

Balance changes: exact numbers, every time

The single biggest patch-note failure is the vague balance line:

- Slightly reduced the damage of the Volt Rifle

Write the numbers:

Volt Rifle
- Damage per shot: 34 → 30
- Reload time: 1.8s → 2.0s

Three reasons this is non-negotiable:

• Players get the numbers anyway. Within hours the community will have datamined, frame-counted, or tested the real values. If your notes say "slightly" and the truth is 12%, the story becomes the gap, not the change.
• "Slightly" is unfalsifiable and reads as either not knowing or hiding. Exact values read as a team in control of its own game.
• The before → after format carries the magnitude. "30 damage" means nothing without the 34 it used to be.

For changes players will hate, add a designer note — one or two sentences of why, in a visually distinct block. League of Legends made this style famous for a reason: "we're targeting her mid-game power spike, not her lane" turns a nerf from an insult into a decision you can disagree with intelligently. Rage scales with mystery.

The stealth-nerf rule

Whatever ships, goes in the notes. An undocumented nerf costs more trust than any documented nerf ever could — because when the community finds it (they will, in days), every future patch note becomes suspect, and your most invested players become auditors instead of advocates. If the list of tweaks is genuinely too long, "full list of minor tuning changes" can link to an appendix — but it has to exist. The only legitimate omission is exploit details that would teach the exploit before servers update, and even then you note that a fix shipped: "Fixed an exploit allowing item duplication."

Known issues: the trust section

A short Known issues block — what's still broken, what you're doing about it — is the cheapest trust you can buy. Players tolerate bugs remarkably well when they know you know; silence converts every open bug into "the devs don't care." It also cuts duplicate reports: forums police themselves with "it's in the known issues." Keep it honest and short; a 40-line known-issues section is a status problem, not a communication problem.

Voice: seasoning, not the meal

Games have license for personality that B2B software doesn't — Dwarf Fortress's bug-fix lines are community folklore ("cats no longer die of alcohol poisoning after walking through tavern spills" is a real fix, and perfect). Use it, with two rules. The joke rides on complete information — a funny line in place of the actual change is a broken promise to reader number two above. And never joke about pain: the save-corruption bug someone lost 60 hours to is not material.

Where patch notes live

One canonical page per patch, with a permanent URL and a date — the same one-URL, many-pointers rule as any launch. Then mirror to where players are:

• Steam/store event posts — many players' only feed. Post the full notes or the headline + link.
• Discord — the de-facto gaming channel. An automatic post in #patch-notes the moment notes publish beats a community manager pasting by hand an hour later.
• In-game news screen — the only channel that reaches players who never visit anything. Headline + link is enough.

Timing: notes go live when the patch does, not before, not the next morning. Patch day is a spike of exactly the attention notes exist to serve — and if datamining beats your notes to the community, you've handed the narrative to whoever unpacked the files first. For console cert or staged platform rollouts, the announce-when-usable rules apply: say which platforms have it now.

A skeleton that works

## Patch 1.4.2 — 2026-07-27

### Highlights
One short paragraph: the headline change and who it's for.

### New
- ...

### Balance
**Volt Rifle**
- Damage per shot: 34 → 30
> Designer note: one honest sentence of why.

### Fixes
- Fixed: [symptom, in players' words]

### Known issues
- [open bug] — [what you're doing about it]

More copy-paste variants in the release notes templates guide.

Anti-patterns

• "Various bug fixes and improvements." The app-store cop-out, worse in games: reader number three came looking for their bug and found nothing.
• Internal jargon. "Fixed a desync in the replication layer" — players experienced "other players teleporting." Say that.
• Notes as hype-only marketing. If the "notes" are three screenshots and a trailer link, the actual changes will be community-documented — without your framing.
• Skipping small-patch notes. A hotfix with no notes teaches players that the game changes silently, which is exactly the suspicion the stealth-nerf rule exists to prevent. Two lines is fine. A steady cadence of small honest notes beats occasional epics.

Where Wakelog fits

Wakelog is a free hosted changelog that fits the indie-studio patch-note loop: every patch gets a permanent dated URL (your canonical page), markdown bodies handle the skeleton above (headings, tables of numbers, designer-note blockquotes), and tags mark new vs fix vs announcement. The Discord webhook posts each patch to your server automatically the moment it publishes, scheduled publishing (--at) lets you write notes before the patch and have them go live with the deploy, and posting is one curl from your build pipeline. RSS and JSON feeds cover the players who subscribe to everything.

Start your patch notes free   Next: release notes templates →

Related guides

• Known issues: how to admit what’s broken (and why it pays)
  A release note is a claim that things work; the known issues section is what makes the claim believable. What qualifies, the symptom-first entry template, tracker vs curated list, where the section lives, and how to close the loop when the fix finally ships.
• Posting your changelog to Discord and Slack (without writing a bot)
  Chat is where your updates actually get seen. Webhooks over bots, pointer-not-archive, and how to keep #changelog from becoming mute-bait.
• Devlog vs changelog: the story of your game and the record of it
  The devlog is a story, the patch notes are a record, and the day strangers can run your build you need both. How to write a devlog people follow — and the handoff that starts at your first public build.

Last updated 2026-07-27 · All guides