Why the ‘Death of Unity’ is a Lesson in Games Development

Across social media, the dramatic portent was that we were witnessing the beginning of the “death” of the Unity platform. Forums were alight with furious feedback, well-regarded games studios boycotted the engine, YouTube was awash with tutorials and developer vlogs on moving away from Unity.  After a brief ‘radio silence’, Unity representatives emerged from their huddle in what was widely interpreted as a climb down, with a new pricing structure that has since largely calmed the flames. For now, the Unity debacle appears to be over, but it has raised a significant issue for the game development community: overdependence.

Game engines are without question, exceptionally useful tools that have empowered developers, especially those working in the independent and small-medium enterprise spaces, to build games of complexity, scale, and quality that would be impossible if all elements of their games were built from scratch. Their pleasant graphical interfaces and relatively gentle technical learning curves have enabled those without a programming background to enter the world of games development.

The problem here is that, for many developers, there is little reason to ever consider using alternatives, such as game frameworks, for their next project. Subsequently, this issue is compounded by the all-too-common affection and even dogmatic affiliation that is fostered between developers and their favourite engine. They grow comfortable with the engine, in many cases to the extent that they become dependent on it. Though extremely unlikely, were Unity to disappear tomorrow, not only would thousands of projects stall, but a great deal of those projects would also never recover because the pivot away from Unity as the central development pillar would be impossible.

So, what is the solution?

Of course, this is a complex and multifaceted issue, but for educators in the game development space, one key lesson should be taken from the Unity pricing story: teach your students engine agnosticism. Sitting on the shelf alongside Unity, we have Unreal Engine, Godot, Game Maker, CryEngine, GDevelop, Amazon Lumberyard (the list goes on…). Each engine provides a unique profile of benefits and drawbacks but, from an educational perspective, the key variation is that they present a different way of creating games. They may utilise a different underlying scripting language, arrange their toolset in a dramatically different layout, emphasise particular techniques and high-level development strategies over others. Learning a new engine follows a similar pedagogic principle to learning a new language or musical instrument – the more you learn, the easier it is to learn.

Engine agnostic developers are far more capable of pivoting, should a specific tool become unavailable (or unaffordable). They enhance their capability to solve development problems from multiple approaches with a better understanding of an optimised pipeline, over a dogmatic, false presumption that there is a single, right way of doing things. They can exploit their oversight to identify the best configuration of tools based on the unique needs of a project. Their adaptability affords them, and their teams, far greater flexibility, resilience, and security – helping them stay in business and make better games.