Cosmic Breakout Post-Mortem
For the sake of personal closure, for creating a historical record and for anybody interested, I decided to write a small port-mortem for my first published game Cosmic Breakout, despite the very limited scope of the game.
Numbers
The game released on Steam and Steam provides a few interesting numbers. So let us take a look at them first. Of course, the numbers here will be very low, nothing spectacular. Getting them high has never been a goal while developing the game, so this is not an indication of failure to me. In fact, I was somewhat surprised that some of them even reached two digits:
- Wishlists:
108
- Sales:
13 copies
- Lifetime unique users:
16 users
- Lifetime unique users - Demo version:
24 users
Sampling date: 2025-01-04
Not very impressive, but it was still nice to see that at least few dozen people got to play the game.
Development
In the beginning there was nothing
As mentioned in other blog posts, it has been my vision from the very beginning to create games with my own engine. Since this was my first game, I also had to write said engine from scratch. That means no existing code base, snippets or examples to rely on. For a few reasons I also decided to write my own OS-abstraction layers instead of using something like SDL. But maybe more importantly: I have never written a game engine or similar by myself. My day-job as a developer evolves much more around web-requests, databases and image-processing pipelines, not around realtime multimedia applications. So, despite being a competent developer, I lacked (and still lack) a lot of experience in the field.
Just getting started took up a huge amount of time. Thankfully I stayed very motivated throughout that initial phase of “pure” engine development, without seeing anything that resembles a game. This phase took around 6 months.
Finding vision
After bringing the engine to a somewhat usable state and being able to write a few small test programs, it began to dawn upon me that I now really had to start writing my game. For some reason that felt like a hard step to take: Going from all the low-level, techie things (that are a lot of fun to code) to a real end-user experience that will be open to the public and that goes way beyond writing code. But I did not spend all those months on my engine just for some tech-demos, this I was sure of!
From the very beginning I have been convinced that I had to keep the scope of the game really, really small. Otherwise, there would never be a release. Like when you just started learning to ride a bicycle, you should devinitely not try to make the Pan-American Highway on the same day. Maybe a decade or two later. For me this (and keeping the limitations of my engine in mind) also meant to start with something that is based on an arcade-classic or a similar small-scoped type of game: Simple input/output, a single mechnic, a few effects. My decision fell onto creating a Breakout clone, as it was one of the few arcade games that I still remember to really have enjoyed playing as a kid. And there is also a nice gamedev talk on YouTube that explains the idea of “adding juice” to a simple game to make it more exciting, where they were using Breakout for their demonstration.
But it still wanted my own twist on the formula of course. So I would use polygons instead of blocks, triangles instead of rectangles and bosses instead of layers of walls.
Developing the game
With that vision for the game set, I started working on it. The core part of the game was quickly done in a few weeks. But the rendering-parts of my engine were still lacking quite a bit. Many things still needed to be added and refactored. Also, a parser to load meshes needed to be written. Trying to keep it somewhat reusable, I wrote an (incomplete) glTF loader, which also took quite a lot of time. The rendering-parts and the glTF loader made it very clear to me, that material-handling is one of the more complicated things in a rendering engine.
Apart from those programming efforts, I also spent quite a lot of time on finding sound assets. Especially the background tracks I wanted to somehow “feel good” and match with the gameplay. Further, I dipped my toes in creation of sound effects from home-made recordings. It is fun to do, but I definitely lack the experience to produce something that is close to what I envison the result to be :)
Next up was the design of bosses. Simple, in principle: Using blender, adding a few polygons and colorizing the (flat) mesh. In practice, things required quite a bit more effort. The design process itself needs to be something very iterative, on multiple levels: Finding the right shape, the right triangle-size and count, level-testing, colorizing and combination with the background “environment” of each screen. In the case of this game the shape of the boss was also directly coupled to the experience and difficulty of the boss, as the shape of the boss directly influences the way the ball bounces around. Similar to the experience with sound-processing, I found it an interesting part of the development. Thanks to my experience with blender, I was a bit more productive compared to working on sound effects.
In this first game I consciously tried to keep costs to an absolute minimum and do as much as possible by myself. However, for future games I will most likely try to avoid creating “aesthetically pleasing” assets by myself.
That main part of the development took my around nine months. That was more than the originally planned six months but still acceptable, considering that I have family and work as a full time freelancer.
Finishing the game
Finishing a game is really difficult. I have heard many other developers express this in one way or another. And it is difficult. But why? When looking at my own experience, I noticed the following issues:
- Optimization and polish take a lot of time
Prototypes and game play mechanics are comparatively easy to implement. It is frequently done in the number of thousands, at game jams. From what I have seen so far, I would say that polish and optimization easily take up half of the development time, or more. Even in my simple game, I had, for example, to optimize my (initially naive) implementation of the collision detection.
- You need to let go many of your ideas
I had quite a few more ideas of what I wanted to include in the game. And surely, I could have added all or most of that. But I had to be strict in reminding myself that this is my first game. And that it would be kind of shitty. And that it would not need all those things. Instead:
IT. JUST. MUST. RELEASE!
I felt that I was really brutal in that regard and the final experience has become rather minimal because of it. But I was now already nine months in, excluding the inital engine development and releasing was more important.
- There are many non-development tasks just before the finish line
There is soooo much to do, if you want to release a game somewhat properly. Especially when you are doing it all for the first time and need to research the most basic things, like how to add a demo build on Steam for your game, or how to sign binaries to prevent being flagged as malware.
To give an impression: Here is an incomplete list of things that need to be done before release (that have nothing to do with development):
- Making a trailer
- Taking decent screenshots
- Writing titles and descriptions
- Setting up a Steam project
- Setting up multiple Steam builds
- Creating assets for the shop frontend
- Getting approved by Steam
- Acquiring a Windows-Certificate to sign binaries
- Creating Steam achievements
And, and, and, the list goes on…
This does not yet include testing on different systems/hardware and getting some feedback from other people.
Release!
While getting closer to the release date, I had an increasing feeling of “this is not enough, it is way too short and has insufficient polish”. And that feeling was of course true. But I wouldn’t allow more delay than I already had. Also, I was now really getting to a point where I wanted to just cross the finishing line and “get over it”.
Hitting the release button in the Steam interface felt good. The deed was done, my game was out in the wild and I actually did release a game. Yay! I also felt released mentally.
Success?
Obviously this game was not successfull in terms of finances. It did not even make up for the Steam store fee, not to mention the many hours of development work. Still, I was surprised that there were a handfull of strangers somewhere in the world that would be interested enough to buy and play the game. There was even a small YouTube channel uploading some gameplay footage.
Now to be honest, the game might be considered to be somewhat “shitty”, depending on the expectations of the player. It is short, has very simple graphics and a single game mechanic. Despite that, I am still satisfied that I was able to come up with something a bit more than a pure breakout-clone. It is definitely more than a game-jam prototype and certainly not an asset flip :D
And last but not least: In terms of what my initial goals were, I am confident to say that I fully succeeded. I wanted to get the experience and go through all steps that it takes to release a game on Steam. In addition to that, it was necessary to see whether my engine and the OS-abstraction layers were stable enough to run on a range of different systems. If I didn’t go the full route to a Steam release, the incentive to walk through all those “non-developer”-steps would have been much lower.
So, to sum up: It was a very valuable experience, especially considering that those were my first steps into “real” game development. I have now a decent foundation (of code and experience) to proceed on. After the release, my engine got a big and necessary overhaul, which makes especially rendering faster and simpler to use. The next game is also already a few months into prototype-development. Thanks to the experience that I have now, I am confident that I will be able to make something that is significantly larger in scope and that will take much more time. (This, of course, is not what they recommend, with short development cycles, small games, etc. but they also don’t recommend writing your own engine ;)
Thanks for reading, and I wish you have a good day :)