How to release a game on Steam: a plain checklist for indies

Releasing a game on Steam is less mysterious than it looks from the outside, and more paperwork than most developers expect. Nothing in the process is hard on its own. The trouble is that it is a long chain of small steps with waiting periods between them, and a missed step near the end can push your launch back by a week or more. This is the checklist I wish I had the first time: what the Steam Direct fee is, when to open your store page, what wishlists actually do for you, what builds and depots mean in plain words, how review works, and what to do in the last few days.

A caveat before we start. Valve changes details of its rules and tools over time. Everything here is the shape of the process. For exact requirements, the Steamworks documentation is the source of truth, and it is worth reading the relevant page each time rather than trusting memory (mine included).

Step one: the Steamworks account and the app fee

To publish on Steam you sign up as a Steamworks partner. That involves the usual identity checks, tax information and bank details for payouts. Do this early. The tax and identity forms are the kind of thing that sits half finished for a fortnight because you needed one document from a drawer at your parents' house.

Each game you put on Steam needs an app slot, paid for through Steam Direct. Valve publishes the app fee as 100 US dollars per game. It is not a subscription. Valve describes the fee as recoupable: once your game has earned enough revenue on Steam, as set out in their terms, the fee comes back to you in your payouts. Treat it as a deposit you might get back, not as money you can count on.

Paying the fee gives you an app ID, which is the number Steam uses to identify your game everywhere: store page, builds, achievements, the lot. Valve also applies a waiting period between paying for an app and being allowed to release it. Check the current length in the documentation and put it on your calendar, because it is a hard floor under your launch date.

Step two: the store page, earlier than feels comfortable

The most common mistake I see is opening the store page a few weeks before launch. The store page is not a launch announcement. It is a collection point. From the day it goes live as "Coming Soon", people can find the game, follow it and wishlist it.

Steam also requires a Coming Soon page to be public for a minimum period before release. Again, the exact figure lives in the documentation. Plan for much longer than the minimum. Many indie developers open the page as soon as they have a short trailer and a handful of screenshots that honestly represent the game, often many months before release.

What a store page needs before you submit it for review:

• A capsule image set in the required sizes (the small, main and header images that show up in lists and search).
• Several screenshots taken from the actual game.
• A short description, one or two sentences, that says what the player does.
• A longer description with a few paragraphs and maybe some animated images.
• Tags, genre, supported languages and system requirements.
• A trailer, ideally, even a short one.

The capsule art matters most, because it is what people see in lists before they ever click. It should read at a tiny size. If your game has a strong character, put the character on it. A clear silhouette carries further than a busy scene, and the advice in designing pixel art character sprites about readable shapes applies to capsules too.

Step three: wishlists, without the mythology

A wishlist is a player saying "tell me when this is out or on sale". When your game launches, Steam notifies people who wishlisted it. That is the practical value: a list of people who already said yes, reached at the moment it matters.

You will read a lot of confident rules about how many wishlists you need. I am not going to add another number to the pile, because nobody outside Valve can see how the store really ranks things, and every game is different. What is safe to say:

• More wishlists before launch is better than fewer.
• Wishlists come from people seeing the game: trailers, festivals, posts with short clips, press, streamers and friends sharing it.
• Steam runs festivals such as Steam Next Fest, where you can show a demo. A demo during one of these is one of the most reliable ways to get attention for a small game.
• The Steamworks dashboard shows your wishlist numbers over time, so you can see which of your posts or events actually moved anything.

A good habit is to post a short clip of the game every week or two, linking to the store page. Not a polished trailer each time. A five second loop of the best moment you built that week.

Step four: builds and depots in plain terms

This part scares people because the words are unfamiliar. Here is the plain version.

An app is your game, identified by the app ID. A depot is a container of files inside that app. You might have one depot for the Windows files, one for Linux and one for macOS, or one shared depot for assets plus small per-platform ones. A build is one upload of the contents of your depots at a moment in time. Each build gets its own build ID.

A branch is a named pointer to a build. The default branch is what normal players get. You can create other branches, for example a beta branch with a password, so testers can try a newer build without touching what everyone else plays. Releasing an update is mostly "upload a new build, then set the default branch to it".

Uploading happens through SteamPipe, Valve's content system, usually using the steamcmd command line tool and a small set of build scripts that say which local folder goes into which depot. You write those scripts once and reuse them. A typical flow looks like this:

1. Make a clean release build of the game.
2. Copy it into the folder each depot script points at.
3. Run the upload with steamcmd and your app build script.
4. In the Steamworks site, find the new build ID.
5. Set it live on a private test branch.
6. Install it through the Steam client and play it.
7. Only then set it live on the default branch.

That is pseudocode for the process, not exact commands. The Steamworks documentation has the current script format. Step six is the one people skip, and it is the one that catches a missing asset folder or a launch option pointing at the wrong executable.

Launch options are the other thing to set: which executable Steam runs for each platform, with which arguments. If you build a Rust game, make sure the binary name in the launch option matches the release build, and that any assets it loads at start sit relative to where Steam puts it. If your game also has a web version for a jam or a demo, keep the two builds separate in your head and in your folders. The notes on shipping a Rust game in the browser are about a quite different packaging job.

Step five: review

Valve reviews two things: the store page and the build. Both have to pass before you can release.

The store page review checks that the page is complete, the images are the right sizes, the content is described accurately and nothing breaks the rules. The build review checks that the game launches, runs, and matches what the page says. Reviewers will point out problems, and you fix and resubmit.

Review takes some days, and you cannot hurry it. My rule of thumb is to allow at least a week for each review, separately, and to submit the store page long before the build. If a review comes back with changes, that week buffer is what keeps your date. Submitting your build for review the weekend before launch is how launches slip.

A worked timeline

Here is a backwards plan for a small game. The gaps are my advice, built around the rules above, not Valve's figures. Put your real launch date at the bottom and fill upward.

The key idea is that the build is "done" a month before launch, and the last month is for fixing, testing and telling people. If that sounds like a lot of slack, you have not yet had a reviewer find that your game crashes on a machine without a controller plugged in.

The launch checklist

The night before and the day itself, work from a list. Mine looks like this:

• Default branch points at the final build, checked by installing through a clean Steam client.
• Launch options correct on every platform you support.
• Store page price set, regional prices checked, launch discount decided.
• System requirements honest, including the minimum graphics level you actually tested.
• Release announcement written as a Steam event, with a short clip or image.
• Community hub and discussion area ready, with a pinned post for bug reports.
• Press and creator emails scheduled or ready to send.
• Something to eat that is not crisps.
• A plan for the first patch: you will need one, so have the build scripts ready.

Then press the button. It is a strange moment. The game appears in the store, wishlisters get their notification, and the first reviews arrive surprisingly quickly. Answer bug reports politely and fix the urgent ones fast. A quick first patch shows players that someone is listening.

Questions people ask

Do I need a company to release on Steam?

No. Individuals can sign up as Steamworks partners. You still need to fill in the tax information that applies to you, and depending on where you live you may want advice from an accountant about how to report the income.

Can I release a game jam game on Steam?

You can, but it is usually worth growing it first. A jam game is a prototype. Use the jam to find out whether the idea is fun, then build it into something that justifies a store page. If you are still at the jam stage, scoping a jam game you can finish is the place to start.

Should I make a demo?

For most small games, yes. A demo lets people try before wishlisting, and it gives you a reason to take part in a Steam festival. Keep it short and end it on a high point.

What if I miss my launch date?

Move it. Setting a new date is far less painful than launching a broken build. Tell people early and honestly.

Before you pay the fee

Do one dry run. Make a release build of whatever you have, write a store description in a text file, mock up a capsule image at the small size and look at it from across the room. Write the steamcmd build scripts against an empty test folder. None of this needs Valve's approval, and every step you practise now is one you will not be learning for the first time in launch week.