Chapter 38 Exercises: Publishing, Marketing, and Finding Your Audience

These exercises move you from reading about marketing to doing marketing. Each one produces an artifact you will use for your actual game — not a throwaway academic deliverable. Do them in order. Each builds on the previous.

Practical: Build a Complete Press Kit for Your Game

Build a press kit for your progressive-project game (or, if you do not have one yet, for a hypothetical indie game you describe in enough detail to make the exercise real).

A complete press kit has nine required sections. Build each one in a single document (a Markdown file, a shared Google Doc, or a live presskit() page — your choice of format).

Section 1: Fact Sheet. One page or less. The fact sheet is the "above the fold" information. Include: game title, developer / studio name, publisher (or "Self-Published"), platforms (with launch platforms and post-launch platforms separated), release date (or "TBA"), price (or "TBA"), website URL, contact email, genre tags (five to eight), and a one-paragraph elevator pitch of three to five sentences.

The elevator pitch is the hardest piece. It must answer three questions: what kind of game is this, what makes it distinctive, and why should a player care? Write three versions. Show them to three friends who do not play games much. Ask which version makes the game sound most interesting. Use that one.

Section 2: Features List. Five to ten bullets. Each bullet is a specific claim about the game, not a mood. Bad: "Immersive atmosphere." Good: "Over forty hand-crafted rooms, each with a unique environmental puzzle." Bad: "Tight controls." Good: "Frame-perfect input buffer and twelve dash directions, built for speed-running." Specific claims become the bullets in any coverage your game gets. Vague claims become nothing.

Section 3: High-Resolution Screenshots. At least ten screenshots at 1920x1080 minimum, PNG format. Each screenshot should be taken at the most visually striking moment you can set up. For this exercise, pull screenshots from your actual game if it exists, or mock up ten frames using placeholder art and annotate them with what the final screenshots will show.

Section 4: Animated GIFs. Three GIFs of key gameplay moments. Each under five megabytes. If your game is not yet running, describe each GIF in text: "GIF 1: Player executes a three-hit combo into an air-juggle. Shows the combo system." "GIF 2: Fire spreads across grass, interacting with two enemies. Shows the emergent fire system." "GIF 3: The ending of the first boss fight, with the death-flash effect."

Section 5: Trailer. Link to your launch trailer (YouTube or Vimeo), plus a downloadable MP4 link for outlets who need it. If the trailer does not exist yet, write a 60-second trailer script with a shot list (this is the Design exercise below — you will produce it there and can attach it here).

Section 6: Logo Files. Your game's logo and studio logo, in SVG or transparent-PNG format. For this exercise, either attach your actual logos or sketch them and describe the color scheme, typography, and iconography.

Section 7: Development History. Two to four paragraphs. Who made the game. How long it took. What engine. What inspired it. What the development story is. This is the human-interest angle most coverage hooks onto — the "solo dev who worked for three years" angle, the "college project that became a commercial release" angle, the "team of three friends" angle. Find your angle and write it honestly.

Section 8: Awards and Recognition. Any festivals the game was accepted to, awards won, notable coverage, streamer playthroughs, press mentions. For a pre-launch game, this section may be empty at first — leave it as a placeholder for future fill-in.

Section 9: Review Copy Request Form. A form or email address at which journalists, streamers, and content creators can request keys. For an exercise version: include the email and describe what your policy is (e.g., "Keys available to creators with 1000+ followers, any platform, no coverage requirement").

Bundle all nine sections into one document or one presskit() page. Submit it to a real friend in the indie dev community for feedback. What questions do they still have after reading? Iterate.

Analysis: Tear Down Three Steam Store Pages in Your Genre

Pick three Steam store pages for games in your game's genre. Choose one successful game (five thousand or more reviews, mostly positive), one mid-tier game (five hundred to two thousand reviews), and one underperformer (under two hundred reviews or mixed-negative reception). All three must be in your genre — the same one your game targets.

Write a tear-down of each page. A tear-down is a structured critique — you are not summarizing, you are evaluating. For each page, answer the following:

The capsule art. Look at it at thumbnail size (Steam's main library size, about 231 by 87 pixels). Does it pass the swipe test — in three seconds of glance, do you understand what kind of game this is and whether you are interested? What does it do well? What does it do badly? If you had to recommend one change, what would it be?

The trailer. Watch the first video. Time it. How long is it? What happens in the first three seconds? Is there a hook, or does it open with a logo? At the midpoint, does the variety of gameplay come through? At the end, is there a clear call to action? If you had to cut the trailer to sixty seconds, what would you cut, and what would you keep?

The screenshots. Count them. Look at each in order. Does the sequence tell a story about the game — hero shot, gameplay clarity, variety, mood, systems? Or does it feel random? Are the screenshots high quality (crisp, composed, interesting) or raw (low-res, cluttered, generic)? Which screenshot would you replace first?

The description. Read the "About This Game" section. Is the first line a hook, or is it a generic "Welcome to the world of X"? Does it tell you what you actually do in the game, or does it describe a setting and vibe? Is the length appropriate (four hundred to a thousand words is a good range)? Are there subheads and bullet points, or is it a wall of text?

The features list. Count the bullets. Are they specific (good) or vague (bad)? Do they match the gameplay shown in the trailer? Do they promise things the screenshots do not back up?

The tags. Click through the tags. Are they correctly targeted (your metroidvania tagged "Metroidvania, Platformer, 2D, Indie, Action-Adventure")? Are there tags that seem wrong or aspirational?

Reviews pattern. Look at the review summary (Overwhelmingly Positive, Very Positive, Positive, Mostly Positive, Mixed, Mostly Negative, Negative, Overwhelmingly Negative) and the percent. Read the five most helpful positive reviews and the five most helpful negative reviews. What patterns emerge? What do players praise? What do they criticize?

After finishing all three tear-downs, write a synthesis: what are the three things the successful game's page does that the underperformer's does not? What are the three things the mid-tier game could learn from the successful one? What does your game's page need to do differently from all three, and what can it copy?

Deliverable: a four-to-six-page document with the three tear-downs and the synthesis. Share it with a peer in your genre for feedback.

Research: Compare Wishlist Trajectories of Three Indie Games Using SteamDB

SteamDB is a third-party tool that tracks Steam game metadata, price history, owner estimates (via a controversial but useful proxy), and player counts over time. While SteamDB does not directly expose wishlist counts (Steam hides those), it does expose release dates, player concurrency, and review accumulation — enough to reconstruct a launch narrative for almost any Steam game.

Pick three indie games that launched in the last two years. Choose one that is clearly a major success (top 100 indie games of its year), one that is a modest success (enough to sustain the developer but not a viral hit), and one that failed to find an audience despite decent production values. Again, aim for your genre or an adjacent one.

For each game, research and record:

Pre-launch timeline. When did the Steam page go live? When was the first trailer released? Did the game participate in Steam Next Fest? If so, which one(s)? When did the demo drop? When were there major showcase appearances (Wholesome Direct, Day of the Devs, etc.)? Construct a timeline of the game's visible pre-launch activity using a combination of SteamDB, the game's Twitter/Bluesky history, press archives, and YouTube trailer upload dates.

Launch and first-week performance. Launch date, launch price, launch discount percentage. First-week concurrent player peak (SteamDB records this). First-week review count. First-week review percentage positive. Compare the three games' launch weeks side by side.

Sustained performance. Three months after launch, six months after launch, one year after launch — what does the concurrent player chart look like? Did the game fade? Did it sustain? Did it have a second wave (a free weekend, a sale, a content update that drove a second peak)?

Visible marketing activity during launch window. Look at the developer's Twitter / Bluesky / YouTube during the launch window. How many posts per week in the month before launch? What was the tone? Did they do streamer outreach visibly? Any cross-promotion with other indies?

Apparent strategy. From the above, synthesize what the developer appears to have done. Was it a "slow burn" build with a Next Fest peak and steady launch? Was it a "big reveal" with a publisher-backed splash? Was it a "quiet launch" with minimal pre-marketing?

Write a three-to-five-page comparative analysis. The successful game did what the others did not — what was it? The underperformer missed what the successful game did — what was it? For your own game's launch plan, what specific practice will you borrow from the success story?

Note: SteamDB data is approximate for some metrics (owner estimates especially), and third-party sources should be cross-checked. Use it as a directional tool, not a source of precise numbers. Where you cite SteamDB in your analysis, note this.

Design: Write a 60-Second Trailer Script with Shot List

Writing a trailer is writing to a timeline. Every second is accounted for. Every shot has a purpose.

Write a full shot list for a sixty-second launch trailer for your progressive-project game. Use the following format:

Timecode | Shot description | Audio | Text/overlay

Each row is one shot. Each shot has a duration (show it in the timecode column — "0:00-0:03" means seconds zero to three). The total duration adds up to exactly sixty seconds.

Structure guidelines:

0:00-0:03 (the hook). The single most striking, genre-defining moment of gameplay. No logo. No title. Just the moment. This is what makes the viewer not scroll past.

0:03-0:12 (core gameplay). The viewer is shown doing the fundamental activity of the game. Multiple short shots, each 1-2 seconds. Music is driving; no voiceover. By the end of this section, the viewer should know the genre and core loop.

0:12-0:40 (variety). Show range. Different enemies, different environments, different moments. Cut faster — shots are 1-2 seconds each. Build energy. By the end, the viewer should feel the game has depth and does not repeat itself.

0:40-0:55 (emotional payoff). Slow down. One or two longer shots (3-5 seconds each) of an emotional or atmospheric moment. A boss reveal. A quiet landscape. A character in grief. A triumphant moment. Music should swell or drop. This is the moment the viewer connects with the game emotionally, not just mechanically.

0:55-0:58 (title reveal). The game's title, large, on screen. Held for about two seconds.

0:58-1:00 (call to action). Release date and "Wishlist on Steam" / "Available on itch.io" / platform logos. Two seconds.

Every row in your shot list must include what the viewer sees, what the viewer hears, and any text overlay. Example row:

| 0:03-0:05 | Player character executes a dash-attack through three enemies, camera shake on impact | Music: drum-kick at moment of impact | No text |

After writing the shot list, write a one-paragraph rationale for each of the four major sections (hook, core, variety, payoff) explaining why you chose those shots and what they communicate about the game.

Attach your music plan: what kind of music (genre, tempo, mood), what the beats are, when it swells or drops. If you are commissioning original music, this is the brief. If you are licensing, this describes what you are looking for on AudioJungle or Epidemic Sound.

Deliverable: a two-to-four-page document with the full shot list, section rationales, and music plan. Bring it to a peer and ask them to read it and tell you, in one sentence, what genre of game they think they just "watched." If their guess matches your game's actual genre, your trailer script is working. If not, revise.

Bonus challenge. Actually cut the trailer. Use your real in-game footage, or if the game is not yet playable, use placeholder footage (gameplay from similar games, with attribution for the exercise; never publish this publicly). The cut does not need to be polished — the exercise is the experience of turning a script into time-based media. You will learn how much gameplay you actually have, where your footage is weak, what kinds of music sell what kinds of shots, and how hard "hook in three seconds" really is. This is often the most educational exercise in this chapter.