From having ideas to shipping games

In this post, we will tell you the story of how we managed to develop and release a game. Have you released a game? Are you currently developing a game? Are you still waiting for the muse to come and kiss you?
No matter at which stage of your journey you are, you might find something useful for yourself in this post about how Hornachsen Games began to make, and actually ship games.

We are not the first to write about this topic. In fact, many indie developers write about this topic, so you will find some parts of this post to be a reiteration of what others might have said and written before us. But this post is also a somewhat personal story, since it’s the story of Hornachsen Games’ way out of the deep pit of starting and giving up, into the bright realm of shipping games.

But where should we start? The members of Hornachsen Games started making games quite some time ago, so there might be a lot to cover, but for the sake of brevity, we will focus on the more recent history of our game development endeavor.

Change of environment, change of skills

We had been making stuff related to games for over a decade, using tools like the various versions of the RPG Maker, or early versions of the Game Maker, built maps for CounterStrike, Warcraft3, and built modifications for games like Mount & Blade, so we can safely say we were not totally new to the gamedev matter when we started working on games to actually release them.

It was the end of 2015, I finished university earlier that year, when I moved to Japan. I had some interviews while I was still writing my bachelor thesis, and landed a job at an IT company in the center of Tokyo. Apart from some self-taught bits of programming, I wasn’t especially great at anything code related, but I went to Japan, started learning coding properly, became a system engineer. I primarily worked on web systems, using languages like JS, HTML (and their derivates), and sometimes Java and C#. Even though nothing I did at work was related to games in any way, I still would say that I learnt the skills needed for making games by working as a system engineer.

Some of you might think that the coding used for building systems (as in Web systems etc.) is too different from the skillset needed to build a game. And in fact, looking around you will find a lot of comments, articles and so on where people who have experience in software or web will ask what they need to know to make a game. In many cases they are told that their skills are too different from what they need for making games, and I think those sentiments are right in some cases.

If you think about making a game and dream about big open worlds with high fidelity graphics, complicated physics calculations and stuff like that, then yes, your Javascript and PHP knowledge will probably not carry you very far. The real problem though is not about your skills being a bad fit for game development, but about your expectations regarding what you as a single person can expect to create without having ever made a game before.

I dreamt of making big games, too. Most of us do. It’s when you realize you are expecting too much where the real game development can start. It’s not solely about reducing scope. It’s not about using a piece of software proficiently. It’s about having a good idea, a sense for analyzing what is needed to realize that idea, the skill to be able to let go of all those fancy details, and most importantly: the will to get your project done.

Ways into making games

So, how do you start making games? There is a famous phrase which pretty much summarizes how things should go: JUST DO IT! There’s not much more to it. You don’t know how to just do it? Then follow these steps.

First step: Grab some piece of software (random examples: Unity, Unreal, Game Maker, Construct, Godot…). Why is this the first step? Because you will need software anyway, and it makes the following steps a lot easier.

Second step: Start using the software.

Third step: Fail at using the software. If you don’t fail, you’re probably a genius and should just go ahead.

Fourth step: find someone who can help you overcome failure. Having a personal coach will most likely go a long way, but since most people can’t or don’t want to afford a coach, you might start searching Youtube for some tutorials for beginners. If you’re using Game Maker Studio, I can recommend the tutorials of Shaun Spalding and HeartBeast. They explain the code they’re writing very easily understandable, and if you follow along, you will be able to make a simple game by just doing what they do. The point is, that you should try to understand what every line of code actually does. If you understand what the code does, you will be able to abstract its use for different situations.

Fifth step: Make your game.

We started making an ambitious platformer game after we went through the above steps. Ambition is not a bad thing, but if your first project is too ambitious, you won’t likely finish it. How is that different from having a scope problem? Scope is mostly about quantity of content or features. If you decide to feature 70 unique stages, 527 unique weapons and full synchronization, you might have a scope problem, or too much time. Ambition covers less tangible aspects of your game. What kind of feelings do you want to invoke? What should gameplay feel like? Who do you want to reach? If your ambitions are off, you might be able to make some game, but you might have problems making your game.

The game we started making did not leave any kind of impression we would have wished for. If you run into this kind of problem, you can either restructure the whole experience, or let go. Anyway, you should analyze what went wrong, and how you can avoid walking the same path in the future. We saw that the scope of our project was manageable, but our skills were nowhere close the level needed to make our game the unique experience we had thought of. So it was time to let go. This was when I started working on TopStack.

Finish the game you started

TopStack was a simple idea: One screen stages, simplistic visuals, well defined and transparent interactions, easy to learn, hard to master type of play. These ideas already laid out the framework for the games scope, and if we properly balanced the difficulty, we would also be able to realize our ambitions regarding the game’s feeling. Long story short: TopStack was finished in less than two months, and we finally released a game. And having released a game once, you are definitely able to release a second or third game, just as we did! Even tough it might not always feel like it, you can only move upwards. You will get better at making games, and I firmly believe that just the prospect of becoming better should be quite an incentive to make that game and release it. And I think this also is the real takeaway: Your first game might not be a masterpiece. You should manage your expectations and not be too critical. By learning to find the help you need, you can improve your skills easily. You will get better at making games. You can release a game!

Conclusion

Some of the things written in this post might sound abstract, and you might even think that this kind of random rambling won’t get you anywhere. I do believe however that everybody who really tries to make and release a game will finally be able to do so. If you don’t have the skill to make a game, you can either learn the required skills or change the tools to fit your needs. Don’t listen to people who tell you that you have to use Tool A, or have to do XYZ, and pay N money for courses to be able to make a game. The internet is full of useful information, there are more people willing to share their knowledge than ever before. Use that knowledge! You don’t have to reinvent the wheel, so you also shouldn’t feel guilty because you copied some lines of code from a tutorial. Do whatever it takes (and is legally safe) to make your game!

Thank you for reading this post. Do you have any questions? Any stories to share? Leave us a comment!