Game Engine Choices: How I Chose Unity by Default
Over the past decade the tooling and runtime engines available to game developers have advanced quickly. Game development engines are now used by most independent game studios — and even many of the larger studios — to build titles ranging from small indie releases to major AAA industry giants. When looking to create a game, as I am doing, one of the first decisions that must be made is which engine to use.
The selection of a game engine is an important choice, and one that is nearly irreversible. Though it is technically possible to re-implement your entire game on a different platform if your original choice turns out to be flawed, the amount of wasted time, effort, and resources will be considerable. In addition, since I am developing a game with heavy usage of 3D models and other graphical assets while leveraging purchased content, there is a degree of lock-in based on money spent in the asset store of the chosen platform.
Comparing Game Engine Options
When I began toying with modern game engines in 2017, there were three existing commercial game engines that I considered: Lumberyard, Unreal, and Unity. At that time, the three were very different:
- Lumberjack, a relatively new game development ecosystem based on CryEngine that Amazon had recently licensed, was still not very usable, and had essentially no asset store or content available for quick prototyping.
- Unreal was considered by many to be the premier in terms of quality. Unreal was also the most expensive, charging a percentage of total profit beyond a certain point, and potentially charging more per-title. The asset ecosystem was rich enough, but it was geared more towards professionals than hobbyists.
- Unity was inexpensive, cross-platform, and easier to “play” with, having a rich asset store of not only content, but scripting solutions to plug-and-play to build out game concepts.
At the time, I had no specific plans for creating anything publishable: my employer had fairly restrictive requirements around side-projects and I had other hobbies, but I wanted to explore what game engines had become and learn some new skills along the way. Given the relatively superficial observations I had made, Unity seemed like the obvious choice. It was, and remains, cheap for a single developer to use, and the breadth of available content to leverage is simply huge.
The Pros and Cons of Choosing Unity
My confession is that, despite knowing that the selection of a game engine can be critical, when it came time to begin developing Magic of the Realm: Adventures, I did not even pause to consider an alternative. By now, I have been using Unity in a “hobby” capacity for several years, I am familiar with the constructs and tooling, I have invested in a number of assets that help with various game development tasks, and it is simply a comfortable and default choice.
This is not to claim that Unity is a perfect solution. In fact, there are a number of challenges I’ve faced so far in using Unity, many of which will be the subject of future posts. The goal here is to talk about the pros and cons of accepting the default choice, and why I haven’t chosen to make a change now, when it’s still early enough that the cost would be manageable.
As with any decision, it is important to weigh the costs and advantages of each option in order to make an informed choice. I am developing MOTR:A as a hobby, but I do intend to finish and publish the title. As such, decisions I make are very similar to business decisions made during any technical product development process.
First, this is not an easily reversible decision. Already at this point I have invested considerable capital in both time and money in the Unity ecosystem — primarily asset purchases and education. I know the tool, own many assets, and understand the programming paradigm and am relatively fluent in C# at this point.
All of that goes out the window if I change engines (though I am a long-time C++ developer, so shifting to a C++-based engine wouldn’t be too bad on the language front). While sunk-cost theory would tell us that cost already incurred has no future value, replacement cost must be included in our decision, and replacement cost is already high.
Second, this decision is not being made in a vacuum. In truth, almost no decision is made without some sort of context and inertia, but in this case, as discussed above, there is considerable existing investment. Along with that, the relative costs of future development, as well as royalties and models for future revenue shares must all be considered. Finally, each of these engines (and the others available today) have their own ecosystem and future roadmap — it is important to understand how changes in the tools you use might impact your delivery.
Third, the long term consequences of a particular choice are relevant to the overall cost/benefit analysis. In this case, it is worth noting that Unity has a rich set of technology integrations, including VR/AR targets, consoles, mobile devices, and obviously Windows, MacOS, and Linux. Though other game engines also have broad platform appeal, the nature of Unity, and the goals of the business behind Unity, drive adoption of new technologies and platforms as a first-class effort. Many new technologies are first available in Unity compared to the various engines, and this means that future Magic of the Realm titles that leverage alternative technologies can be contemplated. Perhaps I will never get there, but knowing it’s an option is a valuable consideration.
For all of this, and the simple fact that I can make progress without re-learning many things, the choice to stick with Unity is not, perhaps, a default after all. And while it is not the only choice, Unity is a solid choice — there are many thousands of titles released each month that utilize Unity across many platforms.
Accepting My Decision to Use Unity
The game engine you choose for your independent game development is important. It will define and proscribe your boundaries, your possibilities. It will dictate language, ecosystem, and even licensing terms for your final product. And it is not a decision that is easily changed once investment is made. If you are choosing from among industry leaders, however, and so long as the choice you make can support what you need, there are few “wrong” answers. I may have chosen Unity by default because I already had it and knew how it worked, but since it meets my needs, that doesn’t mean it’s the wrong choice. If I had over 3 years of experience in any other major game engine, such as Unreal, it wouldn’t have been wrong, either.
