Blog #9 – Making the Jump from Unity to Unreal


“You know, if you’re looking for an Unreal developer, you should probably hire someone else.”


That was me from about a month ago. I was talking to Stuart, the managing director at Hyper-Luminal games, at my job interview. They wanted a generalist gameplay programmer, I wanted to be a generalist gameplay programmer, it seemed a good fit. During our discussion it came up that the company had numerous upcoming projects that, for various reasons, needed to be done in the Unreal 4 engine, and that they would like someone experienced in the technology. I was honest about my hapless inadequacy with Unreal. I’d been meaning to learn it for a while, but hadn’t got round to it yet, so despite the teams assurances that they wouldn’t be picking a candidate based solely on Unreal 4 experience, I walked away expecting to be dismissed out of hand. Surprisingly, as evidenced by the fact that you’re reading this right now, I got and email a few days later informing me that I’d got the job. I suppose that my rugged good looks and overwhelming charm overcame my glaring inadequacies and inability to form coherent sentences. It happens more often than you might think.

To back things up a bit though, Hi! I’m Elliot, and as you may have surmised, I’m the newest code-monkey here at Hyper-Luminal. I’ve been doing a bunch of stuff during my time here, but my main focus has been one of the aforementioned Unreal 4 projects. (Stuart says if I mention what it is he’ll do unspeakable things to me, so it’s a secret for now, sorry.)

Speaking as someone with a heavy Unity background, (I’ve been using Unity since back when it cost money to own,) leaving my little Unity comfort bubble wasn’t the most pleasant thought in the world, especially during my first few weeks on the job. I wanted to make a good impression you know? Unfortunately for me, my chronic need for validation wasn’t really a factor in deciding which projects came our way. Sure enough, when I got in on my first day, Stuart sat me down in front of a PC loaded with Unreal and said some words to me that I’ll never forget. He said “Elliot, sit here and don’t get up until you’ve finished my damn game. I’m going to be in America drinking expensive champagne with movie-stars. Don’t try to contact me.”

As you can tell, it was pretty clear that if I ever wanted to taste any of that sweet movie-star champagne, I had to start producing results in Unreal, and fast.

For any of you Unreal advocates, I warn you that I’m going to start with my complaints first, but I promise I will eventually talk about things I like, just wait and see. Also, keep in mind that this post is from the perspective of a heavy Unity user coming over to Unreal, and is based only on my immediate impressions during the transition process, and is not a fully informed evaluation of both engines.

Loading up Unreal, as you might expect, the first thing I found myself asking was, how do I write code? Coming from a Unity background, one looks around for what looks like an assets view, (called the content browser in Unreal,) right click on it and hope to find “New Script”, or some equivalent. What one does find is “New C++ Class,” button, which initially seems promising, but, in what seems to be a running theme in Unreal, it’s not that simple.

To really work with code in Unreal, one must, (as far as I’m aware, I’m still pretty new to this,) create a Blueprint. Blueprints are a little hard to explain to a Unity developer, especially since the term sort of refers to two things. Firstly, Blueprints is the name Unreal gives to its (admittedly superb), visual-scripting system, which you find yourself using almost everywhere, it’s really quite elegant. Secondly, and what I’m talking about here, a Blueprint is an object that can be most closely compared to a Unity prefab. It defines what an object is and how it behaves, again using the Blueprints visual scripting system to do this. The Blueprints system in the Blueprint (confused yet?), is analogous to a c# script attached to a unity object, although you only get one. This can interact with the parent C++ code, and through this process, you get code from your C++ code-behind, into your blueprint, and then into the game.




An excerpt of a blueprints script. Note some of these blocks are C++ code calls and some are native Unreal functionality


It’s hard to complain about Blueprints, the visual scripting system is excellent. It is incredibly quick and simple to get relatively complex behaviours up and running, and even quicker to iterate on these. What does somewhat bother me is that, again, as far as I’m aware, to effectively turn your C++ code into game functionality, once must “plug-in” a blueprint object that represents chunks of the code. It’s a minor niggle, but this extra layer between writing code does become frustrating, especially when compared to Unity’s almost instant write->play transitions.

While blueprint-only development is excellent, from my experiences, C++ development is another story. My main gripe here is speed. Similar to the sometimes unwanted blueprint-layer above, there are many small roadblocks during day to day development that tend to interrupt ones flow. From having to spend an inordinate amount of time waiting on intellisense to catch up with you, to having to completely close and re-open the editor when you want to add a new C++ object to blueprints. Suffice to say, when compared to the very simple unity scripting environment, it hasn’t been a pleasant experience thus far.

My final point is a little thing about the interface. It strikes me that the Unreal interface is a lot more, for lack of a better term, “spread out,” than I might immediately expect coming from Unity. I suppose that just comes from the added complexity of the additional Unreal systems, but to get a good look at everything that effects what happens when you hit play, there are several menu’s and blueprints you have to investigate, all located in very different and sometimes unintuitive places, by my reckoning anyhow. This sort of thing lead to many moments of frustration when I hadn’t figured out exactly why something was happening, and for the life of me couldn’t find the segment of logic in the Unreal behemoth that was causing it.



Where to find everything that affects what happens when you hit play, Unreal vs Unity


Now that I’ve spent perhaps too much time talking about the things I immediately disliked, I suppose I should spend some time talking about the parts of Unreal that I feel are superior when compared to Unity.

Firstly, the oft-parroted fact that Unreal is a more powerful engine than Unity is by my albeit unformed estimation, essentially true. Even after Unity upped its graphical chops in the Unity 5 release, Unreal still looks better out of the box, and you need to work very hard in Unity to get it to measure up.

I don’t define “more powerful” solely as simply greater graphical capabilities however. In my eyes, the “power of an engine is also related to how it eases the development of large and complicated systems. This, in my opinion, is where Unreal really shines over unity. Unreal provides a lot of the “big boring systems” all ready out of the box, and it’s easier to build such systems of your own without them collapsing under their own weight too, as you can do it in proper, honest-to-god C++, rather than the component based C# Unity requires. It’s always been so easy in Unity to just throw scripts haphazardly into the scene until stuff works, leading to problems later down the line. Unreal asks you, sometimes a little too forcefully, to take a moment, take a step back and think, “wait, is this really how I want to do this?” Definitely annoying when you just want to get stuff moving, but for long term, complicated development, a much better approach.

To top this off, all of the editors and tools that ship with Unreal seem to be generally a much higher quality, with a more professional feel, than the Unity offering. One would have to turn to the Unity asset store to match some of the features that come in Unreal as standard, (which is why I suspect the Unreal asset store will never match the Unity one, because the demand isn’t there.)

The UI system in particular is worth a mention, as even after the new Unity UI update, Unity’s UI always frustrated me, and Unreal’s UMG designer feels like a godsend in comparison.

To round up, as far as I can gather I’ve had the same experience as every other Unity developer coming over to the Engine. It’s frustratingly different, especially after 6 years in the comfortable full-body pillow that is Unity. However, sometimes you need to go knock down a big brick wall, and although you could probably figure out a way to do that with your nice comfy pillow, it’s probably best that you go grab that big scary uncomfortable jack-hammer over there in the corner, even if that jack-hammer doesn’t make you feel as warm and fuzzy as you might like.


Tldr ; Elliot write whiny blog post ’cause he can’t deal with change, concludes nothing everybody didn’t already know.



Please Share our Development Blogs with the Community.

Leave a Reply

Your email address will not be published. Required fields are marked *