I have always been curious to understand how games work internally and their mechanics. I’m also impressed by the evolution of artificial intelligence, 3D design and how much games look so realistic in the last decade. I’m a doer, I’m a software engineer in my daily work, with nearly 10 years of experience working on web and mobile applications with also skills in managing cloud infrastructures, servers and all these stuffs.

I started my game development journey in July 2019 and learned Unity in the goal of making my own first game. This article will go through what I learned in the process of this one-month project and obviously the mistakes I made.

Finding the good game engine

As I use Python in my daily job, I first tried to find a free game engine based on this programing langage, this way I would not need to learn the scripting langage itself but more the way the game engine works. I benchmarked the Python game engines and found the promising Panda3D. I tried this during 2 or 3 days, it seemed really powerful but the amount of code to achieve a simple thing was huge. Also the lack of a visual editor to manage 3D objects for example is a bit discouraging, everything needs to be done in scripting. The community is also a bit young and finding answers to some issues is complicated. I guess it’s a good engine but not really adapted for a game design beginner like me.

So I started over my research to find an easy to learn engine, with a wide community and also completly free. Unity seemed to respond to all of these criteria, so I decided to give it a try !

My Unity learning path

The number of resources to learn Unity is incredibly high. You’ve got a lot of YouTube videos and tutorial articles which introduce you to Unity. But as a start, I choosed to follow the Unity Learn plateform courses, and I think it was a good decision. Indeed, they are really well explained and with some practical examples of games to do step by step.

I started to discover the Unity interface, then how to do a simple 2D plateformer game with the 2D game kit. This kit is awesome by the way (a 3D kit also exists) because it allows you to have a pretty working game in few hours without coding scripts at first, so you can focus on the fundamentals of the Unity interface and the game objects, components, Prefabs, materials and texturing. That’s already a lot to discover and even if it was a bit frustrating for a passionate of code like me, you really get a quick look at the important Unity’s features.

I also followed the 3D kit course, as I wanted my first game to be in 3D and then I gave a try to the John Lemon’s haunted jaunt game tutorial, which was definetly one of the most all around tutorial. I highly recommend this one for those who want to begin Unity, because it contains a bit of C# scripting, camera management, lighting, post processing, enemy handling, etc.

I also go through the Roll-a-ball tutorial, which is a simple game to learn more about physics fundamentals, mainly gravity, force and colliders and is more scripting-oriented than others.

Starting my own game

This last Unity tutorial gave me the idea to create “Being a ball”, a simple 3D platformer game where you should cross some obstacles and get gold gems.

Not really original you might say, but after reading the experience of some other game developers, the important goal to me was to actually FINISH a game, make it available to other people and get some feedbacks as quickly as possible. So I set myself a 30 days deadline and not a day more to release the best game I could do.

Things I have done right

I’m used to web development and project of this kind, so I tried to transpose some concepts from my software engineering experience for this game project.

Planning what needs to be done

I defined an MVP (Minimum Viable Product), that means the minimum number of features my game should contain to be playable, like the player which is a ball, the platforms to roll onto them and some gems to collect. I think it’s important to restrict yourself and don’t set unreachable goals, because you may fail to achieve it and it’s discouraging. You may risk to give up your project by trying to do too much for a first version of your game.

Defining small tasks

I used Trello to start writing very simple steps to get these first features done. What I like to do is tasks that will take like one or two hours, no more. If it’s too long to complete maybe you could split it in more tasks or elementary steps. That way in 2 or 3 days, I had an ugly and annoying first playable version of Being a ball, but at least it existed and I started defining other tasks to improve stuffs like gameplay, graphical design, etc.

Using version control early

I used Git like in my other software developments project, to keep track of my game changes. It’s safe to use version control at the start of the project to get a backup of what you’ve done so far, but you could also revert your changes quickly using git checkout or going back to a previous commit. It’s very useful if you want to experiment things and drop them if you’re not satisfied (without having to remember every single stuff you changed).

Making some useful Prefabs for the game levels

Unity Prefab system is really powerful, it helps you reuse objects, scripts, animations and everything you want between multiple scenes. I think it’s a good pattern to think early about what Prefabs you will need, for me it was platforms of different shapes, a gold gem, a trampoline, exploding TNT box, obstacles like some crates, etc. It’s also important to keep your project structure clean with folders and parent / child game objects to keep things easy to retrieve and edit.

Keep graphics simple

I’m not an artist, I’m not good at drawing or at 3D modeling. I think you have to be aware of your skills before launching yourself in this kind of project, even if it’s an occasion to improve yourself in some parts of game design, you need to go step by step. That’s why I decided to use only Unity and not a modeling software like Blender because it would consume way more time if I have to learn this too ! What I wanted is a playable and fun game not a perfectly designed game, I will have all the time to learn about it later.

Asking for help

When you get stuck too long on something, it’s a sign you have to ask somebody’s help or find some resources on the Web (YouTube videos, articles, stackoverflow questions, etc). Like I said earlier the Unity community is awesome and you rarely ask a question that nobody has previously answered.

Planning “marketing tasks”

I think it’s important to post updates on social medias about your game development, show screenshots / small videos. It helps to get visiblity and you can get first feedbacks from people which may be interested to play your game. All of this take time that should be considered, like creating video trailers, post devlogs or create a nice logo for your game, etc.

Things I have done wrong

Going further in understanding physics

I think I should have learned more and read more documentation about how physics works in Unity. It’s a difficult subject but it’s very important to make the gameplay feels natural. I struggled with some stuffs like making the player rolling on a moving platform, jumping only once, etc. I have not enough skills with Raycast system which seems very useful to handle this kind of issues. I made the common mistake of putting physics manipulations in the Update loop method, even if I read it everywhere that it shoudn’t be the case ! Now I get that’s it’s non-sense and it should be in the FixedUptade method. I still have more to discover about physics to make good games.

Caring too late about performance issues

This one was tough and was for sure my biggest mistake. I have looked about performance subjects only 4 days before releasing Being a ball and found out that my game performances were pretty bad since the start of the project. Indeed when I was running my game on a high resolution screen (more than 2000 pixels large which is common now for modern laptops) it was so slow you couldn’t play it. So I learned to use the Profiler and found some relevant issues, but still not enough to get better performances. I learned about Occusion Culling and optimizing textures, but changing the textures at this point of the project would represent a huge work load. So I fixed it in a dirty way by limiting the max resolution of the game to 1900x1200 pixels, which significantly improved the performances but has the consequence to lower the quality on higher resolution screen. It’s a trade-off I made, but it’s a great lesson I’ve learned and I will care about performances earlier next time.

Not caring about screen resolution

In Unity editor you can change the resolution of the game when testing it. I simply ignored it at first because the game was running smooth for my low resolution laptop. Then I built my game and tried it on another laptop and like I said it was not playable at all because of performance issues. The UI elements were not scaling great to the screens so I had to change it everywhere (menus, scores, instructions texts…). I definitely should have spotted this issue earlier and it costed me an unnecessary stress at the end of the project.

Not doing unit tests

I didn’t consider the time it will take me to manually test my game after each small change. Even if Unity editor is relatively quick to launch the game, as your game gets bigger it becomes painful to be sure everything works correctly. As a software engineer I can’t live without unit tests in my daily job, that’s what makes you confident about your work. I should have applied this even if it seemed more complicated to me doing automated tests for a game compared to another kind of software or web application. The time consumed to learn and do unit tests would have decreased the actual time to manually test my game.

Make an alpha / beta version

My goal was to finish a game, but maybe I should have published a first version earlier at mid-stage for example, with some of the game mechanics. This way I would have had feedbacks earlier, on a not finished game and this would have helped me focus on what is really important to improve, in order to make a more playable game.

Conclusion

Of course Being a ball is not a perfect game. It certainly could be a lot better, but still I’m proud that I achieved the goal of releasing my first public game and learned a lot in the process. Like all projects we have to try, make mistakes, learn from them and be better next time. Considering all other side projects I have done last years in software developement and open source for example, I have often given up at an early stage and I’m happy it was not the case with this game. In a bit less than one week it has reach 200 downloads, which is more than I expected and more importantly, I get some first feedbacks to make fixes and improvements to my game.

Now I will take some time to learn more about 3D modeling, with Blender and then work on a new project, maybe a 2D game or some 3D models. If you want to follow my daily improvements let’s get in touch !

Twitter : https://twitter.com/ThomasHim1

Instagram : https://www.instagram.com/tomahim.gamedev/

Email : dev.tomahim@gmail.com

Thank you for reading, I really enjoyed this game development project and was also amazed to discover a great community of indie game developers, very supportive and respectful of other people work !