A Tale of Two Game Engines
Published 2 years ago
Indie Engine OR Professional Tool?

A Love Letter

I first discovered Unity sometime back in 2007. Having friends who were working in the AAA industry, I immediately recognized the immense change that it would bring to the game development arena. Needless to say, I dove into learning the editor.
Before Unity, I taught myself many languages, frameworks and even built my own (albeit simple) 3d engine. The energy I spent crafting my abilities beforehand, afforded me the opportunity to speed through the tutorials and documentation with ease.
After landing my first contract job using Unity, I knew that I would continue down this path to develop a lasting career.

The Bad

When starting out in Unity, one of the greatest feelings is the ability to quickly prototype a MonoBehaviour and slap it onto a GameObject. The feeling you get when you make your first physics-based sphere game is one of utmost satisfaction.
After the initial haze of excitement wore off, something began to bother me. Since I had come from a more traditional software engineering background, my traditional instincts of SOLID principles were near impossible to replicate out of the box.
One of the downfalls of catering to the non-engineer is that the typical on-boarding path for users, encompasses many bad programming practices. Often, unity developers will have learned C# from using Unity rather than from school, or external projects.
So, as you do, you hit the community forums. Searching thread after thread until you find others who have the same problem; and hopefully a solution. Unity being a young product, meant that the community resources were also immature.
Alas, there was no clear answer. Each new project was a learning experience; testing the bounds of the engine's compiler and capabilities. Eventually, I decided to build a set of frameworks to enforce SOLID principles through modular DLLs.
As a hiring manager, I've encountered countless great candidates who knew Unity, but didn't understand the basics of C#. Imagine a candidate who knows how to use Adobe Photoshop, but doesn't have any artistic skill. The challenge then becomes: How much are you willing to train?

The Good

One of the greatest things that the Unity3D company did, was create an ecosystem for indie game-developers. Not only to provide an affordable engine, but also create a means to shape a more user-friendly game development pipeline.
This has led to more prominent engineers advocating for better systems and improvements that did eventually make their way into the engine. You can also see the engine beginning to shift toward better approaches such as ECS; which will have a good effect overall, but I fear will take years to fully take hold.


The two Unitys I see are at odds with each other. On one hand you have the indie game engine that is so easy to use that anyone can make a game; however, teaches bad programming practices. And, on the other you have the professional game engine that is beginning to understand the needs of SOLID developers.
Although I don't believe the onus is on Untiy3d to teach anyone C#, they should provide an ecosystem that fully embraces C# as a first-world language and not just for scripts. Although I see AssemblyDefintions as an attempt to help solve some problems, it still ends up creating a facade around C# such that non-engineers believe C# == Unity.


So, Is Unity an Indie Engine or a Professional Tool?
In my opinion, it's both. Watching Unity change over the last 8+ years has been amazing. I liken it to watching a child grow up and finally begin to get its own personality and voice. As with any product, there will be challenges and successes, and I believe Unity will continue to elevate the game development pipeline.
I, for one, look forward to the next iteration and wish you all luck in your endeavors.
Devon Klompmaker
Director of Technology - Manager