Unreal Engine after 20+ years of working with in-house engines: How I learned to stop worrying and love Unreal Engine?

Are you a technology programmer interested in expanding your skills and horizons? Do you want to get outside of your comfort zone and learn a different, new technology that is being widely developed by whole groups of people and developers? Maybe you have even tried Unreal Engine before, but decided it was not actually for you? Then this article is just for you! We are at the start of a revolution in customer communication, powered by machine learning and artificial intelligence.

A little bit about myself

I am currently a Principal Software Engineer at PixelAnt Games. I spent the previous 20+ years working at 2 studios. First at Tannhäuser Gate, working with titles like Mimesis Online or The Roots, and then at Techland, working with such games as the whole Call of Juarez series, Dead Island, Dying Light or the racing game Haste.  

What did I do over those years?   

The first studio, Tannhäuser Gate, was equipped with a small number of programmers, and yet the game had to be made somehow, so where was a whole load of code and a lot of areas of the engine that were being developed. There was no spot there I hadn’t touched. Then at Techland, I began to narrow down my field of interest, focusing mainly on things related to rendering and asset management.  In terms of rendering – materials system, frameworks, tools, and in terms of asset management, things related to how to store resources and how to pack them in bigger packages, how to manage those in runtime, while ensuring all those things that are interconnected are executed quickly and properly.  

During that time, from the very beginning, I always had a liking for consoles. I always loved working with new technologies, so I invested a lot of time and researched many areas related to consoles and found out that something I like a lot are code optimizations. I also love process optimizations, both on the micro scale (like for example optimizing a function so that it takes as little time as possible, looking at assembler, checking out how something works so it can be executed as efficiently as possible, because it’s executed per every frame, or a few times or a few thousand times per frame), but also on the macro scale, like for example processes that perform some huge tasks that take an hour, checking out whether they could perhaps be made parallel, on a few machines, or split within one process into more.  

I decided that I wanted to participate in projects that are smaller, which makes their completion time shorter as well, so that during my career I’ll be able to participate in a larger number of projects, place my name on more projects and above all draw satisfaction from it, while also exploring different genres. I also realized that I had my own ideas and wanted to bring those visions to reality – give them some frames, shape, and at the same time that required some tools and a team. I knew I couldn’t do these things by myself, and had to utilize some necessary tools, in order to create a game. First, I started working after hours, fiddling around with Unity. That’s where I created a few minor projects, but on the other hand, I didn’t want to devote my future and time to an indie type of engine. That’s why I turned my eyes to Unreal Engine.   

That was my second approach to it, as the first time the entry level was too high, whereas this time, once I had the experience with Unity, supported by some documents for people from this exact community on how to move to Unreal Engine, I decided that I was finally able to handle it and start some minor projects.

First steps on Unreal Engine

First was working on blueprints, where all of that was relatively simple; but then again one of the projects required creating a texture on a thread, decompression, then coding this into some GPU friendly formats. That required diving deep into C++, so I investigated it and concluded that the engine was immense. A whole lot of great technology was there, as we can see based on the games that run on this engine. The source code is available, so certain things that, for example, would “crash”, could be simply checked in the code to see what wasn’t working. It’s a nice thing that this engine is developed by a whole bunch of users: there’s the whole team at Epic Games, but there’s also a whole community of people who upload their fixes on GitHub or their own expansions. There’s also a marketplace, which has quite a lot of plugins to download. There’s Udemy with over 70 trainings, a few a dozen hours long, where we can learn pretty much any area of this engine, making the first steps. There is a community, Reddit and all those other “googled” things allowing us to sometimes find answers to questions, or to problems we run into.   

But to us it looks like you can learn the most by joining a team that works with Unreal Engine and preferably a team that is experienced. Not like where we just go on and decide that we will make a game on Unreal and we don’t know a thing, but instead you can be one of the many people that are making a game on Unreal. In 2021, when I joined PixelAnt Games, I pretty much fell in love with the people here and what they represented when it comes to values, energy, respect. This was exactly when I decided that it is indeed the time and, on the first day of his job here, I joined the project that is being developed within Sumo Digital. It is a project in Unreal and, what is phenomenal is that at the first stand-ups, first meetings, I met people that are veterans in working with Unreal Engine, which means that we do in fact have access to specialists. After the Epic team, this is the first line of people who have experience in how to work with Unreal. These include creators of Sackboy, a game published by Sumo, which won 2 BAFTA awards, as well as the people who worked with Crackdown 3.  

I joined a team related to a technological core and did things related to rendering. The first assignments were a complete deep dive into rendering and doing truly hardcore things. It seemed to me like it, but it turned out that at the end of the day, they weren’t that difficult.

What I like in Unreal Engine?  

This is my subjective opinion: 

UnrealGameSync 

The first environment, the first screen that welcomed me in Unreal Engine is the tool UnrealGameSync. It is a tool for synchronizing the project with a repository to the current version. This tool is nicely configurable, you can configure it by clicking one button. It gets launched, synchronizes with a selected change list, compiles the code if we need that, and it launches either Visual Studio or the Editor.  

Unreal Editor 

Unreal Editor is a comprehensive tool for working with the engine. I’ve often heard in the past that when Editor crashed, or didn’t work, someone said that “the engine stopped working”. I kind of didn’t realize that, because it’s not an engine, it’s an editor, but in Unreal it really is an engine’s front end, a comprehensive tool for working pretty much with every aspect of it that I have ever come across. Unreal Editor is obviously a giant editor, and because it is for everything, for every area of this engine, for working with it, there’s also a Level Editor, which is truly nicely done. There’s the Material Editor, where you work on nodes. My experience is that after adding a few of them, I usually make a custom node with HLSL and that’s when I have the best fun. There’s the Asset Management, very nicely done, there are those reimport matters or different settings. But what is the best here is the “Play in Editor” mode, which means that at the moment where we have the game, we have the level loaded, we want to play a bit, we don’t have to launch the game somewhere where it launches on the side, but instead, directly in the editor, or even upon clicking the mouse in the right spot, we can launch a specific level location, place the player and start. This mode has a few neat functions: in the case of network games, for example, it allows for a few clients to start on 1 computer, and, for example, the server is actually in a separate window. This is phenomenal when it comes to how you work with the game, because – a hypothetical situation – if we run around the level and something happens, or we want to check why something isn’t right, we pause and then we can detach the camera from the player, hover around levels, click each of those elements that are placed around and we can perform an inspection of these objects and go through their attributes, exactly the way they are designed, in the mode “Show hidden properties while playing”. This is brilliant, because it has a whole lot of object properties. The components and actors in Unreal are spacious, and thanks to this option, you can truly see all of it, you don’t have to launch a debugger or Visual Studio, navigate around some variables. Working with it is truly pure pleasure, I honestly can’t imagine anything else at this point.  

Another nice thing is that if I wanted to test my changes in the game, I just click the button “Cook Build“, and done. The build is “cooked”, everything takes place, the platform is selected, here you go, ta-da! We launch the exec after a moment. Editor is expandable through a system of plugins. We write our own in a very simple way, we download it from the marketplace, we exchange with other teams within a group.  Another thing is integration with Perforce: blueprints, materials, or different assets are written in binary form, which would make such text-based comparing impossible. That’s why an integration with Perforce is nice as when we have, let’s say, 2 blueprints, it displays a window for us: on the left side we have the previous version from Perforce, and on the right side the new one, so you can see what the difference is right away. When it comes to materials, it is a little bit worse, because we have a text dump, but that’s okay as well, when it comes to just the fact and possibilities of comparing.  

Blueprints  

It is something that probably small studios, or minor studios that make simple games, could probably 100% be able to work and to prototype, or pretty much complete the entire game based on blueprints. It is simply a system of nodes, where certain actions are executed. We can see it all in real-time, it’s nicely animating things like different flows, etc., so it all looks simply sugary and nice whereas we create professional games, so we only use it to prototype, and most things ends up in C++. As a front-end, as a quick test, when debugging something, or connecting some event with a mouse click or a button, all of that is amazingly quick to add without having to launch Visual Studio, or even compiling the code in the first place, launching, restarting the Editor.  You can use blueprints here to expand the functionalities of the Editor. This is also great, because whenever some functions are put into a mode that allows them to be executed through blueprints, we can also do exactly that.  

Working with source code  

Unreal Editor is one thing, but I am a programmer, so I spend way more time working with the source code. Another thing that we can say is visible at first glance is the way projects are managed on the project level and Solution. All of that is nicely generated and described as projects in C# files, all of that is generated on the folder level. There is the UnrealBuildTool, which binds it all together nicely here. Overall, it is a process that is not visible, which means it pretty much occurs upon this click, it is something that takes a few seconds and generates the whole project for us. When we’re talking about the source code, the interesting things include reflection – a mechanism for putting up data that is described using classes, or structures in the source code, for work both in the blueprints as well as the serialization, or putting up in some other ways. There’s an entire tool UnrealHeaderTool and with the use of such macros we can describe a structure, a class, we adequately select certain fields, certain properties, that should be visible, so we can see them in the blueprints. We specify it all using these properties and these macros which the UHT tool, which generates it for us, and it pretty much happens automatically. But here’s the thing: the source code database for Unreal is enormous, because, like all huge engines, it contains a whole lot of code and well managed, well-designed dependencies between projects can minimize certain recompilation processes that sometimes have to occur when we modify certain parts of the engine. In the case of Unreal, it is indeed like that as the compilation times for the engine source code can take a long time, while the automatic mechanism of Unity builds looks nice, which is for “gluing” several source files into bigger packages to make them compile faster. At the same time, it works very well, as it automatically detects which file we edit, and this file is excluded from such processes, compiling independently, so that we know there are no other external dependencies having any impact on it.  

Encountered issues  

Well, those were the nice things. I think the ones I’m about to describe, which are the potential problems, will not be something that could in some way disqualify, or cause reactions like “ugh, no thanks, this is poorly done”.  

After talking with people who worked with the engine for longer than I did, I recall that I will surely run into this type of thing and that there will be quite a lot of it. However, the thing that so far has caused me some trouble, that sometimes causes something to not work as expected, is the Garbage Collector mechanism and in overall object creation and management. Objects that inherit from a specific class UObject, are managed and tracked by Garbage Collector. This means that if we create such an object, sometimes we might want to store it, as we might need it in the future. And so, if we don’t wrap it the right way, we don’t use the right construction, we won’t find out, for example, if such an object even still exists, as such a regular pointer is not tracked by Garbage Collector. It has happened to me multiple times and is likely to continue to happen until it gets fixed in my brain, that it is necessary to properly describe certain types of data.  

For some time now, Unreal Engine has had a thing called Subsystems. I used WorldSubSystem and it turned out that its lifetime is a little different than expected and, for example, the moment the level gets disconnected, the Actors still exist, while the object is being deleted. The mode “Play in Editor” is phenomenal when it comes to both its utility value and productivity. Sadly, it also has its dark sides, but that seems kind of normal, when we think for a moment on how it could work. I mean, if within a single process we have several games launched, which is several worlds, then if we have some static variables that at this moment are in the same memory area, there is no way it could work, something will get broken for sure. My gut feeling tells me that it’s probably like this. And indeed, there’s a whole lot of curiosities like this that must be watched out for because something will simply stop working. But when such game is being made on blueprints, single player, or even a tutorial, a whole lot of which are available, then we are not even aware that it works like this. Meanwhile, the moment when we want to think about a simple game, but it’s a network game, and it is also related to the fact that one can launch those additional processes within, in this mode, they can be launched within one process. That’s exactly when those problems occur. The moment we launch them as separate applications, each one has a separate address space and there is no problem here.  

I think there could be some more upsides and downsides. Here I only listed the ones that I have run across and the ones I put most time into. 

Summary 

To conclude, Unreal Engine is a different engine, as there’s obviously no such thing as a general recipe for how an engine should be built. Meanwhile, I truly see a lot of similarities, certain mechanisms, certain patterns, certain concepts are similar between engines, because certain things simply work one way and not the other way.  

Learning Unreal is demanding, cause the Unreal Engine itself is demanding. There are the exact things I have mentioned that cause problems, but that’s good, cause that’s what learning is about. It’s a tool, an engine that was developed over many years, it still has its weaknesses, maybe even up to this day. It is, however, certainly being developed all the time, and by the community too, and what is nice is that it is also developed by the vendors, hardware or software suppliers. It basically means that the moment we have something like a new VR headset, or some other new equipment, an Unreal plugin often shows up first. And that’s great, because it instantly reaches a huge group of people who use this technology.  

How Unreal Engine evolves can be seen in what Epic presented in the preview version of Unreal Engine 5. It is the new Nanite technology, used for rendering geometry, there’s Lumen for lighting, there’s Chaos physics solution. You can see that it’s a whole lot of technology developed over years, and it has the advantage, that now, after this preview version, it will be “debugged” by a whole mass of enthusiasts, of early adopters. A few months down the road, when it finally gets to the official version, then it will already be a slightly more polished technology, and the studios will be able to decide whether to switch to it and utilize all the possibilities. That will certainly be amazing. 

WATCH VIDEO: