Thoughts After Releasing My Game
I recently released my first game on itch.io.
The number of players is still pretty small, but publishing it taught me a lot of things I wouldn’t have understood otherwise.
In this post, I want to look back on four things I learned through the development and release process, rather than focusing on the game itself.
What I Learned from the Release
There were four main takeaways:
- Even if your game gets impressions, people may not play it if its appeal doesn’t come across at a glance
- Small asset-editing tasks can quietly drain your focus during development
- External assets should be managed not just as files, but as resources with source information attached
- Reusable modules still need a minimum amount of cleanup and adjustment
Even if your game gets impressions, people may not play it if its appeal doesn’t come across at a glance
First, here are some of the stats after release.
These numbers are taken from the itch.io dashboard:
- Views: 11 — probably the number of people who visited the game page
- Browser Plays: 6 — people who opened the page and actually played
- 7-day Impressions: around 1200 — not an exact number
- CTR: around 0.62%
Since I released it as a browser game, I thought the barrier to entry would be pretty low, so I expected at least a decent number of people to try it.
But in reality, the number of people who even made it to the game page was much lower than I expected.
That means even if I make some super innovative and incredibly polished game in the future, it won’t matter much if nobody ever clicks into the page in the first place.
What I learned
- The cover image matters a lot. If it’s a GIF, the very first frame needs to stand out
- A title that’s too long or hard to understand can work against you(Was my game’s title too long??)
- A short description should clearly tell people what the game is and what feels good about playing it
Small asset-editing tasks can quietly drain your focus during development
From here on, this is more about the development side.
In Godot, sound effects are usually handled as .wav files, and background music is usually .ogg.
That means audio assets I found online had to be converted into the right format before I could use them.
At the time, I didn’t have a local conversion tool, so I ended up stuck in a very annoying and inefficient workflow.
Basically, I had to upload 1 to 4 files at a time to an online converter, wait, download the zip file, extract it, and then import everything into Godot.
To make things worse, I couldn’t fine-tune the audio quality settings, so around 80% of the project’s file size ended up being audio assets.
(I’ve already reduced that a bit with a small update.)
From now on, I’m planning to use Shutter Encoder.
It can batch-convert files and adjust audio quality locally, which should make the whole process much easier.
One small note: .ogg files are exported as .oga, so I need to rename the extension afterward.
What I learned
- When too much time goes into little non-dev tasks, it hurts the rhythm of development
- Doing browser-based conversions and bouncing between different tools adds up more than I expected
- Having proper local tools for editing GIFs and audio makes things much easier
External assets should be managed not just as files, but as resources with source information attached
I once read an article saying that one important mindset for solo game development is to use assets made by other people whenever it makes sense.
I think that’s absolutely true.
Doing that lets me spend more of my time on game logic and on the kind of world or atmosphere I actually want to create.
But there’s a trap in that approach too.
When it’s time to add credits before release, it becomes really exhausting to figure out where each external asset came from and whether I’m actually using it within the license terms.
This gets especially messy if I’ve renamed files after saving them locally. At that point, it becomes hard to tell what came from where.
(Audio files are especially bad for this, since they don’t even have thumbnails, so they’re really easy to lose track of.)
This was only a small game, so I managed. But if I had tried to make a larger project with the same management style, I might’ve been a corpse by now.
What I learned
- Renaming files can easily break the connection to their source
- Stockpiled assets on your PC are especially easy to lose track of
- Leaving all the credit work until right before release is heavy
- It helps to track assets with IDs, a spreadsheet, or some kind of simple catalog
Reusable modules still need a minimum amount of cleanup and adjustment
I had some old modules for things like audio management and scene transitions.
I used to think they were pretty much finished, but once I actually tried using them, I found bugs and design choices that didn’t really fit the game I was making now.
Updating that code took more time than I expected.
They don’t need to be perfect, but I realized that if I want reusable modules to actually save me time, they need to be kept in a state where I can use them with as little friction as possible.
I also remembered that in the past, I spent a lot of time building reusable modules just because I enjoyed making them, only to end up not using them in an actual game.
So from now on, I want to keep reusable systems to the minimum I really need.
What I learned
- Don’t overcomplicate modules just because you want them to be generic
- Aim for simple modules that work well
- The only things worth polishing are the core parts you know you’ll use again in the next project
Final Thoughts
What I felt most strongly from this release was that making the game itself is important, but building an environment where I can keep making games consistently is just as important.
Even with a small game, there are a lot of things you only notice after you actually release it.
That’s why I think there’s real value in making more small games, learning from each one, and improving little by little.
I’d like to release another mini-game sometime in late April or early May.
END.
