What It's Like to Release a Game on Steam

A transparent development project can show a lot: learning an engine, making prototypes, running feedback sessions, wrestling with design problems, hiring help, launching on Steam, and supporting the game after release.

But some launch stories come with an obvious caveat. A developer with a large existing audience, a ready-made community, easy access to playtesters, and unusual visibility does not represent the average first-time indie release.

That does not make the numbers useless. It just means they need context. If a modest 2D puzzle platformer sells well after very little external marketing, part of that success may come from audience trust and prior attention rather than the game alone.

The game went live on Steam at 5pm on launch day. The first instinct was to stare at the live player count, watching it jump from a dozen people to fifty, then one hundred, then two hundred, then back down again.

That number is not sales. It is simply how many people are playing at that moment. But Steam's backend also gives a near-real-time sales readout, and that quickly turned the evening into a blur.

The game sold about 800 copies in the first couple of hours, then 1,000, then 2,000. It reached Steam's New & Trending section, appeared high on the top sellers list, received prominent Steam Deck visibility, and even appeared in the large front-page carousel.

By the end of launch day, the game had sold about 5,000 copies. That was roughly 10 percent of its 50,000 wishlists.

By the end of the first week, it had sold around 10,000 copies, or about 20 percent of those wishlists. A few weeks after launch, the total was 12,446 units.

Those are excellent results for a small first commercial game. They are also unusual results, which is why the audience caveat matters so much. A strong launch can be real and still not be a clean benchmark for an unknown developer.

It is tempting to multiply units sold by price and assume that number is the developer's income. Steam revenue does not work that way.

If the game earns 100 units of gross revenue, a chunk disappears immediately into sales taxes, payment fees, chargebacks, and refunds. In this launch, that was roughly 10 percent.

Then Valve takes its platform cut, around 30 percent of remaining revenue. After that come development costs: contractors, soundtrack work, promotional art, assets, tools, and other production expenses. Then tax arrives. In a simple 100-unit model, the final retained amount was closer to 43 units.

The lesson is not that a successful launch makes no money. The retained amount was still meaningful. The lesson is that a game's visible price and visible sales count do not describe the full business.

Refunds, platform fees, taxes, contractors, tools, and localization or compliance costs can all change the real outcome. A launch discount and future seasonal sales also need to be built into the pricing plan from the start.

A first-time developer should do this math before assuming a headline sales number can pay for months of life, future development, or a celebratory holiday.

A public launch brings a kind of QA that no private test period can fully simulate. Once thousands of people start playing on different machines, controllers, operating systems, play styles, and expectations, the bug reports arrive quickly.

The launch window produced no catastrophic game-breaking issue across the player base, but there were still plenty of problems. Achievements failed on the Mac version. Around twenty levels had issues, mostly cheese, unintended solutions, or small layout problems. One level was redesigned because a fresh look revealed a better puzzle.

Controller glyph detection also needed work, so an explicit option was added to let players choose the button prompts they wanted. Another update replaced the world-select flow with a level-select screen after completion, making it easier to replay any level directly.

Some bugs were left alone because speedrunners had already turned them into techniques. These were physics quirks and movement exploits that most players would never notice, but expert runners could use to move faster, jump higher, bypass puzzles, or skip sections.

Fixing those bugs might have made the game cleaner in a narrow technical sense, but it would have made a small community less interesting. The better choice was to preserve them.

Steam's branch tools also made it possible to keep the original launch version available. That helps speedrunners, and it also preserves a record of what the game was like on release day.

The game landed at about 88 percent recommended on Steam, with roughly 700 reviews. That is a strong result, even if it may have been helped by an existing audience and pushed against by a few people determined to dislike the project.

The positive feedback centered on the basics: the game was fun, some puzzles produced a satisfying aha moment, the controls felt good, and the polish, presentation, sound design, and soundtrack helped the project feel like a complete commercial game.

That kind of praise matters because it confirms the player-facing experience. Even if the designer can see every compromise, players often respond to the whole: feel, clarity, presentation, pacing, music, and whether the puzzle finally clicks.

The most common criticism was length. The game was about two hours long. Some players wanted more. Some felt the price was too high for that runtime.

Refunds were much lower than feared: around 2 percent. Some of those were technical issues, some were taste mismatches, and only a smaller slice were likely people who finished the game and then demanded their money back because it was short.

There is nothing wrong with a short game. But short games need careful pricing, clear expectations, launch discounts, and enough room for future sales. Value is subjective, so criticism around length and price is worth taking seriously without treating it as a moral failure.

Another criticism was that the game was too easy, simple, and straightforward. That was not a surprise. Making a puzzle game that works for a broad audience can pull against making a puzzle game that challenges dedicated puzzle players.

There is value in accessibility of difficulty. A game that many people can finish, including younger or more casual players, has achieved something worthwhile. But there is also a cost if more experienced players never get the tougher optional content they wanted.

A third criticism was that the game felt safe, plain, or unimaginative. That can hurt, but it can also be fair. A first commercial game may be polished and complete without being personally expressive, deeply novel, or unforgettable.

One of the hardest parts of release is shipping something while already agreeing with many of the negative reviews. The developer may know the game is too short, too safe, too easy, or not as inventive as it could have been.

But launch means handing that imperfect thing to players anyway. People will buy it, play it, review it, refund it, praise it, criticize it, and compare it to the game the developer hoped it could be.

That can be uncomfortable, but it is also the reality of finishing. A game does not have to be the best game ever made to justify its existence. Sometimes the real achievement is that it exists at all.

The first major success was internal tooling. Anything that did not appear in the final game but made development faster paid for itself many times over.

Mechanics could be dragged into scenes, snapped to a grid, and tuned with sliders and checkboxes. By late development, building and adjusting levels had become quick and easy.

Those tools took time to make, but they made iteration practical. For a level-heavy game, that was a good investment because the cost of changing a level dropped dramatically.

Another success was polish: animation, sound effects, juice, transitions, presentation, and game feel. These elements can make a modest design feel more complete than it really is, because they make every interaction more satisfying.

Playtesting was also essential. Once the game was shown to other people, almost every part of it improved. Friends, family, strangers, events, and public tests all revealed issues the developer could not see alone.

Accessibility work also benefited from being added early. Colorblind support, remappable controls, keyboard-and-mouse support, controller support, and a simplified background option were easier to maintain because they were built into features as they appeared instead of bolted on at the end.

The hint system was another success because it usually nudged players without stealing the aha moment. A good hint makes the player think: wait, I understand now. It does not simply hand over the answer.

For puzzles, that distinction matters. The goal is to keep players in the game, not send them to an external guide or leave them banging into a wall.

The game also allowed players to skip a level after being stuck for several minutes. That protected the overall experience. One puzzle could be difficult, but it could not become a permanent blocker.

The biggest production mistake was moving too quickly out of pre-production. Pre-production is where a team explores the big questions: what the game is, what the player does, what a level looks like, what the core loop is, how the art works, and what the overall structure will be.

In pre-production, ideas are cheap. A prototype can be thrown away. Ten answers can be tested quickly. Nothing is too expensive yet.

If production begins before those questions are answered, changes become costly. Art may need replacing late because the camera distance was not settled. Level structure may drift. Work gets thrown away because foundational decisions were not actually made.

Another mistake was not having a strong plan for the full game. A vague image of the finished project is not a production roadmap.

The project only started moving toward the finish line once it had concrete answers: how many worlds, how many levels, what the story beats were, what needed to be built, and what could be cut.

This is unglamorous work, but it matters. A solo developer still needs milestones, scope control, and a way to know whether the project is converging or merely accumulating features.

Some development time went into details that did not matter enough. A menu highlight that behaves perfectly across mouse and controller input might be nice, but if it takes a full day, that day cannot be spent improving puzzles, controls, or game feel.

This is a common trap because small polish problems can feel concrete and solvable. Deeper design problems are harder, more ambiguous, and more emotionally risky.

The launch response made the priority clearer. Players remember whether the core game is interesting, clear, and satisfying far more than they remember tiny interface edge cases.

A 2D puzzle platformer can look like a modest first project, but it combines several difficult crafts. Platforming requires responsive movement, animation, controls, and level feel. Puzzle design is a discipline of its own.

Strong puzzle designers spend years learning how to introduce mechanics, explore consequences, hide solutions, create aha moments, and avoid tedious execution. A first-time developer trying to do that while also building every other part of the game is taking on a lot.

Adding physics makes the challenge even harder. Puzzles need control and legibility. Physics adds unpredictability, edge cases, and chaotic solutions that the designer has to either embrace or contain.

Working mostly solo means full creative control, flexible scheduling, and the satisfaction of touching every part of the game. It also means spreading one limited skill set across art, animation, sound, programming, writing, level design, production, marketing, accessibility, QA, and support.

A collaborator focused entirely on music can give that one discipline full attention. A solo developer rarely gives any discipline that much focus because every problem is theirs.

The game might have been better, and finished faster, with more delegation. But the experience might also have been less personal and less enjoyable. The lesson is not simply to avoid solo development. It is to decide deliberately which parts should stay personal and which parts would benefit from help.

After launch, the question becomes whether the whole project was worth it. Maybe there will be game jams, smaller interactive experiments, or another commercial game one day. Maybe there will not.

What cannot be taken away is that the project went from idea to release. It was played by thousands of people. Most players did not refund it. It earned meaningful money. It received criticism that was useful and praise that was encouraging.

The finished game still has flaws, missed opportunities, bugs, compromises, and lessons attached to it. But it is real. For a first major release, that is not a small thing.