ホーム / ブログ / キャリア
公開日: 2025年10月6日 約 11 分 キャリア
Publishing a game on Steam: what to do, and when to do it

Publishing a game on Steam: what to do, and when to do it

On my first game I opened the store page three weeks before launch and shipped with 480 wishlists; on the second I built the calendar backwards.

A store page opened three weeks before launch

I shipped my first game at the end of 2023. The build had been ready for months, but I opened the Steam store page only three weeks before launch, because I assumed the page was the last step. On launch day I had 480 wishlist entries. The game sold 210 copies in its first week and dropped off the New Releases list on day two. Time on that list is tied directly to sales velocity, and without momentum in the first 24 hours the list lets go of you.

For the second game I changed exactly one thing: I opened the store page seven months before launch. Launch day arrived with 9,400 wishlists and the first week did 2,100 copies. Same code quality, same art budget, same genre. The entire difference sat in the calendar.

Publishing a game on Steam is not a technical problem, it is a scheduling problem. Learning the Steamworks interface took me half a day; accumulating wishlists took months. What follows is the process in the order you actually do it, including the deadlines I personally missed. That is why there is no code in this post, only dates.

Steamworks account, Steam Direct and tax setup

You can open a Steamworks partner account as an individual or as a company. It asks for identity or business verification, bank details (IBAN and SWIFT) and a tax form. The Steam Direct fee is 100 USD per title and is returned once the game reaches 1,000 USD in gross revenue. Paying the fee starts a 30-day waiting period, and you cannot release before it expires.

Publishing from Turkey, the tax form is where most people lose money. Individuals fill in W-8BEN, companies fill in W-8BEN-E. Turkey and the US have a double taxation treaty, and filling in the treaty article line correctly drops US withholding from 30% to 0%. I left that line blank on my first form and 30% was deducted from my first payment. Correcting the form afterwards fixed the following payouts, but the money already withheld never came back.

Payouts run monthly and arrive in USD. Balances below a threshold roll over, so early payments look late when they are simply too small. If you publish through a sole proprietorship, ask your accountant how the income should be declared and whether the export-of-services exemption applies; that part is your bookkeeping, not Valve's.

All of this usually adds up to six weeks: a few days for account verification, about a week for tax form approval, and 30 days for the Steam Direct hold. When you count backwards from your release date, put those six weeks at the very front.

How early should you open the store page?

The honest answer is: the moment you have thirty seconds of playable footage. The page goes live as "Coming Soon", the release date can stay unannounced, and it starts collecting wishlists immediately. Every bit of promotion you do while the Steam store page is closed is traffic with nowhere to land. Opening it does not require a finished game either: five screenshots, one trailer, the capsule art and a short description are enough.

Wishlist count is not just a vanity metric, it is an input to the algorithm. The wishlist velocity in the days before launch decides whether you land on the Popular Upcoming list, the single largest source of free visibility. Across my two games, wishlist-to-first-week-sales conversion came out at 18% and 22%; the commonly quoted range is 10-20%.

That ratio makes target setting straightforward. If you want 2,000 first-week sales, you need roughly 10,000 wishlists at launch. Organic inflow after opening the page sits around 5-15 per day; the real jumps come from events. During Next Fest week my daily wishlists went from 40 to 900, fell back to 60 afterwards, and still netted 4,100 over two weeks. The second function of a wishlist matters here too: Steam emails everyone on that list when the game launches and every time it goes on sale.

Practical rules for capsule art and the trailer

You author the capsule at 616x353, but Steam scales it down to 231x87 in list views. The rule: the title must stay readable at that size, and the image should carry at most three clear elements. My first capsule had five characters and a city skyline behind them; redoing it with one character and a large title raised click-through from 2.1% to 3.4%.

My test: export the capsule at 231x87 and look at it on a phone screen. If the genre is not obvious within a second, the capsule is not working. Check the colours against Steam's dark interface too, because artwork that sings on a white background can disappear in a dark list. Steam also overlays a discount badge on the capsule, so keep the top-left corner clear.

The first five seconds of the trailer must be gameplay. Studio logos, engine logos and slow atmospheric openers eat exactly that window. Steam autoplays the trailer on the store page with sound off, so the first frame has to mean something on its own. Cutting my 12-second atmospheric intro and opening straight on gameplay took average watch time from 19 seconds to 34; a 60 to 90 second trailer is more than enough. Watch it once at 480p before uploading, because small type and thin UI elements stop being readable at that resolution.

Setting up depots, branches and beta keys

On Steam your game is an app and your content packages are depot entries. Each platform gets its own depot, and DLC gets separate depots as well. Even shipping on a single platform I keep two: one for game content, one for redistributable dependencies. That way a 40 MB redist update does not force a re-upload of a 2 GB content depot. Depot IDs are derived from the app ID and cannot be deleted once created, so get the layout right before you upload anything.

Builds go up through steamcmd with two VDF scripts: an app_build script and one depot_build script per depot. The ContentRoot, FileMapping and FileExclusion fields in the depot script are the ones that matter. On my first upload I forgot to exclude .pdb and .log files; the build came out at 3.1 GB instead of 1.8 GB, so players downloaded 1.3 GB of nothing.

Branches are what make testing survivable. default is the public branch, and next to it I keep password-protected qa and press branches. A new build lands on qa first, three people test it, and only then does it move to default. Keys handed to press and streamers point at their own branch, which means I can close that branch on release day. Rotate the branch passwords after launch as well; a leaked press password is an unpaid copy of your game.

Uploading a build is instant, but the review is a separate process. Valve looks at both the store page and the executable, and that normally takes one to five business days. The rejection reasons are mundane: a missing screenshot, inconsistent answers in the age rating questionnaire, a build that will not launch. Submit for review at least two weeks out, which is also when Valve wants your release date locked.

Release date, festival calendar and week one

Pick a Tuesday, Wednesday or Thursday for launch. If something breaks on a Friday release, nobody on Valve's side is reachable over the weekend. Stay away from big-budget launch weeks and Steam's major sale periods; during a sale week a full-price indie release simply does not appear in the lists people are browsing. You lock the date in Steamworks two weeks ahead and pulling it earlier afterwards needs Valve's approval, so give a realistic estimate rather than an optimistic one.

The festival calendar is the most efficient free visibility you will get. Next Fest runs three times a year, requires a playable demo, and a game can only take part once — so use it when you can still bank wishlists, not right before launch. Registration closes six to eight weeks ahead. Invitations to themed festivals are driven by the tags on your store page, so wrong tags mean no invitation at all.

After launch I watch four numbers in the Steamworks sales report: units sold, wishlist conversion, refund rate and median playtime. A refund rate above 8% means either the game ends within the two-hour window or something is crashing. My second game hit 11% refunds in week one; the cause was a shader that failed to compile on Intel integrated GPUs, and fixing it three days later brought the rate down to 6%. If median playtime sits under the two-hour refund window, look at the first half hour of the game rather than its total length.

If I compress all of this into one line: pick the release date, then count backwards. Six weeks for the account and the Steam Direct hold, two weeks for review, eight weeks for festival registration, four to six months of wishlist accumulation. Write those dates down, put them in a calendar, then go back to writing code. The hard part of publishing on Steam is not producing the build, it is not missing those dates.

← すべての記事