A Programmer's Blog

The path how I became a game programmer

Nov
11

I haven’t been writing for the past 4 years. The reason is that I had really problems in motivating me to update the blog. I think it was primarly because of my career’s focus. This post is about the past 4 years of my life.

Last time I wrote I was still working for Memonews/Sentric on our big data project, with Hadoop, Ruby and such. Shortly after this, I eventually began to start working for their unbrella company, YMC. There I worked mostly on various mobile projects (Android & iOS, checkout my blogposts here). But focus shifted more and more towards web between 2014 and 2015. I developed mostly pretty small PHP websites with the Symfony Framework. During that time I realized that, while my most experience so far is indeed web development (I write PHP code since 2000), it wasn’t really not what I wanted to concentrate my future on.

That’s only part of the story, the other part is that since 2013 I already was a bit depressed at YMC, as there was just not so much sophisticated work and I felt pretty subchallenged. So I began with a new hobby, a hobby I tried often before, but never kept going. That hobby was game development. That’s how Moyo was born.
After working a couple of months on Moyo, I lowered my job at YMC to a 60-80% position to give my new hobby more time. I was very glad that YMC was so flexible and I am very thankful for that. 60-80% from a Switzerland salary is still enough to have a good life, especially if you live nearby the German border, where you can buy things cheaply. But having so much extra time helped me to develop my game development skills a lot.
I never went up to 100% at YMC again. I released Moyo in May 2014, as a free browser game and a (optional payed) desktop game with better graphics and gamepad support.

It was fun to create Moyo, but it took me over 1 year to build. Most of the time was spend working on the engine. I knew, in order to produce games more quickly, I have to learn one of the popular game engines. That’s why I began trying new engines like Godot and Unity. For the next year or so, I attended many online gamejams, which helped me to learn Unity a lot ( you can check out my projects here ). I think the coolest games I produced at that time were Alice in the Mushroom Hole, the VR title The Captain took your Ducky and probably Dragon Fightress or Ace of Traze.

Programming games is what I like more than any other work, so I started to think about how I could make my living out of it. I often thought it might be cool to quit my main job and just work on the stuff I like most, but I knew it’s gonna be hard. Very hard. Probably too hard. I am not good at Art, Sound Design and especially Marketing. And it were already hard times for indie developers, as there were just so many of them.
I checked out other options. My (now) wife and I wanted to leave Switzerland anyway to get back to Germany, that’s why I started to check out if there are probably some game companies nearby I could try. I found only one in Offenburg, which was around 150km away. It’s Black Forest Games and it’s where I eventually started working for 🙂
I earn a lot less than before, but it’s still enough to have a good living and I finally do what I enjoy most.

In the future I will write about game programming topics. Right now I work mostly with the Unreal and Unity engines. Especially for Unreal there isn’t enough information available in my opinion. Unreal has a lot of features with little documentation and it’s often hard to figure out how the stuff works. This was the main pusher why I decided to start blogging again. I want to write about these things that took me ages to get working and wished I had found more information for upfront.

Do It Yourself!

Jul
06

In the current project I am working on, we have about 50 external JAR-Dependencies. About one of ten bugs in our software is caused by one of these dependencies. They are not only hard to find, but hard to fix either. And even if you get it fixed within the source-code and create a patch, there is no guarantee that the fix will ever make it in the next version. Many open-source-projects are not very active or the maintainers are just too lazy to implement patches.

So, if you want to keep your dependencies update-able, it often results in ugly workarounds. I remember my time as a flash-developer, where we had to subclass nearly every component in the Flex-SDK and do really dirty hacks to get everything working as suspected.

The way of introducing a new dependency often looks like this: We need to implement a new feature, and the first thing we do is to research about stuff already done. During the research we maybe find a library which solves exactly that problem, and the initial effort to implement the feature using that library may not very high. But problems arise with time, when the software is being tested in real world situations, with real data and conditions. This may be months after the library has been introduced. Some of these problems become really time-consuming, and some of them cannot be solved in an acceptable amount of time.

I believe we should spend much more time before adding new external dependencies to our project. We should not only care about how fast we can implement our features with them, but also how good they are maintained, how easily patches can be committed and also if it wouldn’t be more efficient to just implement it by ourselves!