As a QA Engineer I’m coding on a regular basis, be it for writing automated tests, be it for generating test data, be it scripting for automating reports and process and more to help with bits and pieces. Having some coding experience always helped me to understand the developers a little bit better. What are their obstacles and hurdles to overcome when dealing with complex features or bugs? However, I don’t write code on a daily basis and I am by no means proficient in any particular programming language. It can feel quite hard to admit that when I see what everyone else is doing, and at times I’ve wondered if I could be much better at my job if I sat down and invested the time in becoming more skilled at it. Hence I decided to kick-off an own development project.

Goal

Learning about Unity by developing an endless runner which should be playable on mobile devices.

Getting Started

Without any prior knowledge in Unity I started with the very basics and installing Unity where I was a bit surprised about the download size. For most programming languages tutorials are available and Unity is not any different there. Try them out, they will help you get started and learn all you need about the Unity Tools, the Editor, how to run the game and later on what is needed to compile it on device.

Development

One important factor is to have a vision of the game you want to create. I love dragons so I wanted to create and endless runner where a dragon flies through a canyon and has to avoid some rock formations and trees while collecting diamonds of different colors and value.

Out of this the most important part is the canyon so I started to think how an endless canyon could be created. There are several ways but I decided for using preset tiles which can be instantiated as needed. Right now the whole canyon consists of 4 different canyon tiles which can be instantiated randomly. If the dragon is now flying always forward we would create new tiles as the dragon moves on. When flying for some time I noticed an increase in memory as each new tile consumes additional memory. To overcome this bottleneck it is possible to destroy the object once the dragon has passed it which resolved the issue of piling up memory.

With this approach the obstacles in the canyon were easy to add by designing the canyon tiles already containing them. One problem less to solve. However the dragon should die when getting in contact with them. This brought me into the concept of colliders for the first time and I can tell you, it is way harder to make the colliders work in the way you anticipate them to work in the game. Without the problems I faced I would still think it can’t be that hard to make two objects collide. The moving part of the dragon was quite straight forward as well as long as I was only testing with the editor.

The diamonds where a bit tricky as well as I didn’t want a fixed position and always the same color on the canyon tile and I also didn’t want to create many more canyon tiles with the diamond the only difference. For solving this problem I decided to only add spawn points to each of the canyon tiles on which a diamond of random color could be spawned while the spawn point was also chosen randomly from the defined ones. This gave the whole canyon a more natural flow. Additionally these diamonds should be collectable so they would need to be destroyed on contact and points added to the score.

Till this point it took me roughly 2 to 3 weeks to finish the basic concept of the canyon. Till the first try on an actual device I needed a UI for the start and death screen which brought me into contact with different scenes and their handling in Unity, especially on how to pass information between these scenes.

When running the game for the first time on an actual device I ran into multiple issues: The touch handling is way different than moving the dragon with the keyboard and the performance can be of concern. As result I had to go back to the drawing board. For the touch handling I tried different solutions but nothing really wanted to work as expected till I found a way of dragging the dragon sideways. The performance problem was a bigger issue as the whole process of instantiating and destroying many objects was just too much for the limited resources on the device which required a different approach. As result I ended up with object pooling which keeps the memory consumption constant and reduces the impact of the garbage collection.

After all the troubles I’m quite happy about the outcome.

Learnings

• Creating a running game with Unity is easy but complexity increases very fast even for small projects.
• Issues which look easy from the outside can be complex from the inside e.g. colliders and visual issues with overlapping objects.
• Testing with the editor is not enough as issues/problems with touch handling will only surface on a device.
• Even with the best intentions in mind memory and performance problems can arise so watch out.