Choosing a game engine

Author: Florian Graf | Published: 2019-04-23

Pexels James Wheeler CC0

There are many game engines and libraries out there. I had a look at several of them but in the end decided to go with Unity. Here is a short explanation as to why I chose Unity.

Deep Dark Caves

You could go down the deep dark caves and write a game from the very basics. Go with OpenGL or Vulkan and just write your own rendering engine, your own physics engine, etc. I personally would have loved to do this. It is a very interesting adventure to start from nothing and then learn all those different technologies. But from a business perspective this is just not feasible. The amount of required work is just astronomical and I ruled this out pretty fast for my project. I wouldn’t gain anything for my game doing it like that.

Small Libraries Adventure

A simpler approach than writing everything yourself would have been with the several smaller libraries for rendering that are available. Just to name a few: SFML, SDL, Ogre3D, Allegro, lwjgl.

I had a look at those libraries and was inclined to go on this adventure with them. Since I wanted to go the 3D route I looked closely at Ogre3D. If you would like to go with 2D I would recommend to take a look at SFML. But at the end I decided against them.

The reasoning behind it is basically the same for not developing everything from the bottom up. Even though those libraries are helpful quite a lot in the adventure of developing a game, they are mostly only rendering engines and provide no additional functionality. Also the tooling is mostly not the best. Again I wouldn’t gain anything for my game by going this route. I’m not expecting my game to be very performance hungry and thus needing a lot of basic optimization. Which is something you could gain when working with such low level libraries. I’m more interested in a fast production and more focus on the actual game concept than investing time developing things that might be already available elsewhere.

People playing my game, my future customers, wouldn’t gain anything from me using those libraries. I would love to use SFML again at some point for a small hobby project. But that project would be mostly for myself only. Just to try it out and play around with it.

Main Road

On the main road you find the major engines available on the market. They provide an all-in-one solution for game development. Usually the documentation is good, support is available or bigger communities around them exist. They don’t only solve things like rendering and physics but offer solutions to other parts of the game development process. I mostly took a look at Unreal Engine, Source Engine and Unity.

I went with Unity mostly because of five main reasons:

  • I personally really like the C++ language. And you would need to write C++ code to write a game in the Source Engine or the Unreal Engine. In Unity you’re using C# to write your logic. But my experience with C# is usually much smoother. The cycle of writing code, testing it and deploying feels much faster in C# than C++. Also C# has compared to C++ a huge standard library and also a lot of additional third party libraries at its disposal. So from my experience with C++ and C# I have to conclude that the development in Unity will be much faster.
  • I’m sure with the Unreal Engine and Source Engine you could gain a lot of additional performance, because you can write code and optimize it much closer to the hardware with C++ than with C# in Unity. But I don’t expect that my game will have any bigger performance issues. It will be a round based strategy game with simple graphics. Thus I expect to get enough performance for my game with Unity.
  • The Unreal Engine can provide stunning photo realistic rendering out of the box. It is something that is often mentioned as the big advantage of the Unreal Engine. Like I mentioned earlier, I don’t plan to have photo realistic graphics. The graphics will be rather simplistic. Currently I’m mostly looking into a low poly style. So this is not a feature I really need.
  • Unity licensing provides the most freedom at the lowest cost. Unity doesn’t bind you to a distribution platform like for example the Source Engine does. It also has a much lower price compared to the Unreal Engine, since it is not bound to a royalty on the sold game but has an inexpensive seat licensing model.
  • With its free licensing model and overall simplicity, Unity attracts a lot of indie and hobby developers. Thus it has a very big community. This also means that there is a lot of documentation and help around Unity. So far this has really proven to be true. I’m amazed by the amount of documentation and tutorials that are freely available. Partially provided by Unity themselves but also a lot by the community.

So in summary the Unity engine might not be the engine with the best performance or graphics possibilities, but should provide enough for my game. It is an all-in-one solution providing a lot of helpful tools for the development process. It provides a lot of documentation and has a big and active community. The price is right and allows risk free development.

Conclusion

Choosing Unity as my game engine was mostly a business decision. Luckily I really like C# and I think I can get along with the Unity Editor thus I’m not disappointed from a personal technological standpoint. So far the experience has been rather good and I’m happy with my choice.