With Epic’s recent announcement that Blueprint and the Actor/Component system will be deprecated early in Unreal Engine 6’s lifetime, there has been no small amount of concern expressed online. Opinions run the gamut from indifference to ambivalence to outright despair and betrayal. It’s easy to see why - Blueprint scripting made programming accessible to many that it otherwise wasn’t and still isn’t. It launched entire careers. It has become a fixture of the engine and now, seemingly for no good, discernible reason (i.e. it’s not broken, unfinished or disused by developers) it’s going away. But that’s not what this article is really about.
This article is about why you have to get used to that.
No game engine is an island. A game engine is a product built atop a stack of technology much wider and deeper than you can reasonably know. Most of that is inconsequential, but what isn’t is that every game engine is a product. They are all made to do a set of things, under a list of priorities and assumptions, in service to an end goal. Through that lens, change is inevitable over time. In fact, in the ecosystem of modern technology, change is required to retain or enhance functionality and is usually driven by progressing hardware and software as well as security concerns.
Only a few years ago Unity held a near-monopoly on the indie game development world. It was the de facto engine used from individuals to teams and widely taught in schools. As with all things though, that has started to change. The engine’s usage, while still considerable, has declined notably from it’s pre-IPO saturation in the wake of a series of managerial decisions that range from insulting to disastrous.
Like Blueprint, Unity also launched myriad careers. When Unity dropped it’s original licence fee and made the base engine free in 2009, it introduced an entire generation to the concept of entity component systems and enticed many to learn how to program in one of several languages (for those unaware, Unity used to support 3 languages: Boo, Unity script - a variant of javascript and C#). With Unity’s decline however, those skills didn’t disappear.
Many of the hard skills in game development are purely intellectual. They are patterns of thought and approaches to crafting and solving problems that are, oftentimes, unique to our industry and discipline. What that means is that the technology, while reinforcing certain workflows, isn’t the most critical piece of the puzzle. It’s the skills we developed along the way.
Over the course of any given career, it’s more likely than not a game developer will work in multiple game engines and versions thereof. Even if your professional output revolves around a single engine we, as creators, tend to be an inherently curious lot who like to experiment. This leads us into trying new tools and workflows - either looking for something better, or just something different. If your daily work is in Unreal, you might want to try something lighter weight or smaller like Pico-8, for instance. However the workflows in these tools are drastically different. Is this cause for alarm?
Certainly not. Even if a new tool, given a fair shake, isn’t the right fit the experience of exploring it has value. It can reinforce what you like or don’t like about the tool you’re used to using. There will be, however, a core set of transferable skills that exist across all tools, in different forms and at different levels.
By far the most valuable skill anyone working in a field as dynamic and changeable as technology - even entertainment/technology like games - is learning how to learn. Developing skill, familiarity and a level of comfort in picking up, intrenalizing and applying new information, software and workflows. As I said above, working in a technology-based field means that change is required. It will happen whether you agree with it or not. Resisting that will only ever work against you. Instead, look at how your existing skills can transfer and be willing to expand them or develop new ones.
Unreal won’t be the last game engine you ever use. Neither will Unity, Godot, GameMaker or any of the others currently out there. So long as there are games there will be new engines made under different paradigms and we, as professionals, will have to learn to use them effectively.
Because game engines are disposable.