Quick answer: A game press release is a working document, not literature: the news in the first sentence (what, when, platforms), a tight description a journalist can lift verbatim, two or three quotable lines, links to trailer and presskit, and embed-ready assets. Most coverage is written from the release's first paragraph plus the trailer — optimize exactly those.
A game press release is a working document, not literature: the news in the first sentence (what, when, platforms), a tight description a journalist can lift verbatim, two or three quotable lines, links to trailer and presskit, and embed-ready assets. Most coverage is written from the release's first paragraph plus the trailer — optimize exactly those. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
Inverted pyramid, because nobody reads page two
Journalists triage dozens of pitches daily; yours gets seconds. First sentence: the complete news ('[Game], a [genre hook], launches [date] on [platforms]'). First paragraph: the elevator pitch with the distinctive angle. Then descending importance: features as experiences, context (team, history, accolades), quotes, and boilerplate. Anyone who stops reading at any point should still have the story.
Write the description paragraph knowing it will be copy-pasted — many small outlets publish lightly-edited releases. That paragraph appearing verbatim across twelve sites is the system working.
The package matters as much as the prose
Every release links: the trailer (YouTube, embeddable — it does more persuading than your text), the presskit (screenshots at full resolution, logos, key art, GIFs, fact sheet — the standard presskit format devs use exists for a reason), the store page, and contact info that gets answered fast. Missing assets are the most common reason coverage that almost happened didn't: an editor with a 20-minute slot writes the story they can illustrate now.
Include review-key information when relevant ('keys available on request' with the Curator Connect/distribution method), and an embargo time if you're coordinating one — clearly, at the top.
Timing and targeting beat blasting
Releases support beats: announcement, date reveal, demo/festival, launch, major update. Send 3-7 days ahead for launches (writers schedule), morning on a Tuesday-Thursday, and target a curated list — the writers who actually cover your genre, found by who covered comparable games — over thousand-address blasts. Personalize the top line for your best-fit dozen ('you covered X, this sits in the same space') and let the release carry the rest.
Expect silence as the median outcome and coverage as compounding luck: each beat re-introduces you, and the writer who ignored the announcement covers the launch. The release's job is making 'yes' effortless whenever the timing finally lands.
Marketing is a generosity game
The indie marketing that works rarely looks like advertising. It looks like sharing something genuinely interesting: a clip that makes people grin, a devlog that teaches something, a thread about a problem you solved. People share what makes them look good for sharing it.
So lead with the most interesting true thing about your game, not with the ask. 'Wishlist now' earns nothing by itself; a great 15-second clip earns the wishlist without asking twice.
Consistency compounds, virality doesn't
Every indie knows one game that blew up from a single tweet, and that story wrecks more marketing plans than it helps. Viral moments are lottery tickets. The reliable curve is slower: post regularly, get a little better each time, and let followers accumulate like interest.
Pick a cadence you can sustain on your worst week — one post, one clip, one devlog — and hold it for months. The audience you build that way actually shows up on launch day.
Plan for the bugs you won't see coming
Whatever else you take from this, build yourself a way to hear about problems. Once your game is on other people's machines, most failures happen out of sight: the crash on hardware you don't own, the save that corrupts once in fifty exits, the bug players mention in a review instead of a report.
A lightweight crash and bug reporting setup — even just Bugnet's free tier wired into your engine — turns that silence into a fixable list. The devs who look calm at launch aren't luckier; they just see their problems earlier.
Putting it to work
Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.
Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.
Show up where your players already are, lead with the interesting thing, and keep the cadence.