A few months ago I published a reverse bullet hell game called “Gothic Survival”. It’s available on iOS and Android.
I considered writing a technical description of some of the intricacies of developing and releasing a cross-platform game in Flutter, but honestly, many of those details have already faded from my memory.
Instead, this article attempts to distill the lessons from the experience itself:
- Scope reduction is mission critical.
- Assets are everything.
- It’s a marathon, not a sprint.
1. Scope reduction is mission critical.
This isn’t a new lesson for me. The importance of early and severe scope reduction is something I employed explicitly in my previous app, Kanjidex.
I still have pages upon pages of unimplemented ideas for Gothic Survival, but I didn’t hesitate to release way too early. The result was invaluable feedback from a couple of my earliest players (especially Pamalamalam - you rock dude). This completely deconstructed my list of development priorities and made the game far, far better than it could have ever been.
Releasing is a discrete skill within software engineering. It must be practiced and honed to be effective. Gothic Survival has convinced of this way of thinking more than ever.
2. Assets are everything.
Gothic Survival did not have a dedicated artist. I commissioned a handful of pieces from various artists on Fiverr, but everything else was purchased across a variety of pre-made game asset websites.
I estimate that I spent more than half of my time creating, collecting, and modifying assets for the game, including art, text, and audio. I became intimately familiar with GIMP, Audacity, and developing algorithms that programmatically enhance images - my favorite one magically adds “realistic” shadows to in-game art, which I didn’t even know was possible.
Pulling together assets from myriad sources while trying to maintain a single theme was, well, ludicrous. It took me weeks of struggling to realize that this was not the ideal way to develop a game. I was repeatedly forced to compromise on ideas due to missing assets. In the future, I will likely avoid building a graphically intense game without significant artistic support.
3. It’s a marathon, not a sprint.
Gothic Survival is my most used software to date. As the sole proprietor, any and all feedback is inherently directed to me. I wanted to act like a responsive game developer and did my best to keep up.
Put simply, this was not a realistic approach. Nightly hacking and releases in conjunction with a full-time job was ultimately unsustainable. My sleep schedule, enthusiasm, and health suffered. These factors led me to put the project aside when I inevitably burnt out.
I think this points to a deeper problem in which I approach my projects with an inappropriate degree of intensity. Then seemingly spontaneously, I lose steam and end up flipping the dial all the way to zero. Theoretically, doing a moderate amount of work from the start is the way to maintain a long-term application, but I find it difficult to contain my initial passion for an idea.
Sometimes, I just want to go “all out” - but I’m quickly realizing how unhealthy it turns out to be. Limiting my time and overall level of effort is something I’d like to work on more concretely in the next project.
The game is modestly successful - it has a few hundred daily active users and has made several thousand dollars to date. These statistics exceeded even my most optimistic expectations.
This was my first foray into game development. As my Dad elegantly phrased: I enshrined a piece of my soul in the game. I was the programmer, the artist, the writer, the musician, the marketer, and the businessman. But most importantly, I was the player.
If you’ve played Gothic Survival: I’m sorry I won’t be developing it further for the time being. Please know that I religiously read all your feedback and emails. Thank you so much for using my software - it means more than you know.