My experiences with Unity and Unreal

I am going to start off this post by saying this post is not about which one is the best engine. I think that question is irrelevant. “Better” means a different thing for different people, as each team has their own requirement on their engine. Also worth keeping in mind, is that the world of computer science is way bigger than Unity and Unreal. There are tons of engines out there, and some out do these engines in certain tech by quite a large margin. I use both engines privately and professionally, and am quite grateful that they are available for easy usage.

So what I am going to be attempting in this post is to tell you of my experiences with the two engine and what it feels like the biggest differences between the two. This might be helpful for people who are starting a new project, and want to know if one or the other engine is worth considering for their project, or people who are considering if they should invest time and effort to learn one of these two. Keep in mind that both engines change. So this post might be irrelevant in a year.

Different products have different target groups, they excel in certain things, suck at other things. As developers, we weight in the pros and cons, and take the best tool for a specific task.

So here are the most relevant points that I consider when I am starting a new project. Should I use Unreal or Unity?

Terms and Agreements

This is the first and most important thing for me when deciding which engine to use on a new project. These change, so always grab the up to date one and read through it.

Community, Documentation and Tutorials

For me, this feels by far like the biggest difference between the two engine. Notice the word ‘feels’ here. Because they are minor things, but you might be spending 80 percent of your time dealing with the documentation, tutorials and the community around the engines. I am going to divide the documentation stuff in two levels, mundane daily routine stuff you need to do which make up the majority of the tasks during the development, and the more advance higher level tasks with more lower level access which might break your project if you can’t do them.

So Unity has a very large user base. As far as everyday stuff are concerned, the documentation is very good, and there is an absurd amount of tutorials on anything you can imagine. I am always specially impressed how the first link to a Google search, is not only the question I needed answered, but there are 4–5 different variations of different solutions, ready to use AND compatible with Unity versions few years before and after the version the answer was posted for. Honestly the community management team from Unity is doing such a fantastic job. This was for everyday stuff, plenty of documentation and tutorials, and a helpful community that answers fast.

As for the more advance things you might want to do in Unity. This is where things get tough as a developer. Depending on the difficulty of the projects, something between 5 to 20 percent of the tasks I need to do fall under these categories. Here the documentation is greatly lacking. For stuff like these, Google won’t give you any answers. Since Unity’s source code is not accessible, your only chance is to ask in the forum and hope someone had a similar issue and spend a few days figuring it out. If not, you could be spending days without getting any results. It is possible to use dynamic libraries linked in from your C++ code to do certain things the engine can’t do, but I have never used this workflow, so I can’t comment on it. If I already know that a large number of tasks in the project are going to be things like these, I typically go for Unreal, because Unreal has always been the opposite for me.

You find answers to simple questions within seconds in Unity, and you need days for more complicated stuff. Unreal is the opposite. You will spend hours for everything! What does this checkbox do? Well good luck finding that out. The everyday stuff are really poorly documented in comparison. To be fair alot of the ease of use in Unity also comes from the community. The Unreal community is lovely, but way smaller. So there are way less easy solutions to easy problems. That is if you can’t code in c++ (I will get in to that in a bit). What also doesn’t help is that the version compatibility is not all that great. The forum answer you found from 2013, is probably not working in your version any more. The magic fix from that one Github commit? That was last version, now things are done different. Upgrading Engine versions has been a crusade that took us a few days everytime, and we rarely change engine code. Where Unreal shines, is for the more complicated tasks. You can read and change engine code, which means as far as you can program in c++, you will find the answer to any question within a few hours. You just need to traverse through the Unreal’s endless chain of hierarchical classes, includes and references. Unreal’s documentation is the code base itself. The code has very helpful comments here and there, and I rarely had issues following what is happening in the code. So where I spend days in Unity, slamming my head against invisible code I can’t see, feels much more productive in Unreal. You are only limited by your own ability as a programmer (and a giant existing code base that takes time to interact with), if something is not in the engine, just make it yourself. Having said this, I tend to do most my projects in Unity. Reason is simple, it is way more pleasant to use for easy tasks, which usually make up the majority of the development phase in most of my projects. If I have the need for a lower level access, and I know it, I choose Unreal from the start.

Also worth mentioning is that if you have an Unreal license and are part of the developer forum, you get really fast and helpful responses from epic employee.

C# vs C++/ Blueprints

Unity’s C# setup is easy to use, and teach to other people, it works relatively well right off the bat, I can rarely screw things up and crash the program and I have zero clue what is actually happing behind my code. Setting up a class and implementing things has always had a bit more overhead in c++ for me than c#. The price I pay for that, is the underlying ambiguity of what is really happening behind the level of abstraction. Again, depending on your use case, this can be a benefit (complexity is hidden, the abstraction leads to faster coding exprience) to a disadvantage (certain things you can’t do or nasty bugs).

Unreal has the Blueprints, C++ combination. First I am going to say what is going to happen if you only use one or the other.

Blueprints have been a bit more accessible for non programmers in my exprience than C# (artists, level designers …). That is very nice, since everyone can prototype simple interactions and try out their ideas. Like all things this comes with a cost. This is purely my personal opinion but using Blueprints for game logic is going to cost you an absurd amount of wasted production time. There are two reasons for this, first and the most important one, you don’t see scopes in blueprint. I have seen many times that people flag bools in the wrong scopes because it is not clear which scope the code is in. Second, simple maths, that you can write compactedly in a line of code, becomes an al dente pasta salad. Which is hilarious when you think about how people have collectively decided that node base is the way to go for shader programing, which is full of operations like these. My last problem with Blueprints? Those lines connecting the nodes are sometimes impossible to make straight in Unreal. It drives me nuts.

I like coding in C++ too. It is a different type of good than C#. It feels fantastic to know what is going on, and have the full control. It is like listening to Bach after coming back from a pop concert. If you are only using C++ in your Unreal project though, you are going to have a hard time involving all team members in the development. If you don’t have enough programers, simple tasks your average member could have implemented in 3 seconds in Unity, keeps getting pushed back for days, until your programmer has enough time to implement them. This has a bigger impact on project costs than you might realize.

C++ has other disadvantages to the advantages it offers (speed and freedom). Compile times can get really large. There is a hot recompile functionality in Unreal that compiles faster than C# script on my pc, but if you change engine code and have to build again? You take the day off and come back the next day. My coding speed in C# has always been faster than C++ for simple tasks. (C++ tends to gets faster the moment the stuff get a bit more complicated). Also what throws a simple error in Unity, if your programmer is careless (which we all are), will crash your program in C++.

There is a third option, you can write your main functionality in C++, and inherent from these classes as a Blueprint. You get the best of both worlds. Your programmer can implement complicated stuff as a node, which you can use in Blueprints to implement simple code flow. This is a very powerful combination, which I have been using in the past few Unreal projects. Only issue is copying over code from projects is not a simple copying a block of code anymore. There are nice ways to communicated back and forth between the C++ and Blueprints, it is a flexible system.

Hiring

Again one of the biggest factors people ignore. How fast can you find someone to help you out with a part/ all of the project in both engines?

Hiring for Unity is easier since the user base is bigger. Since their C# system is more accessible, most Unity users can code simple interactions.

Hiring for Unreal is hard. Most of the time you might want to hire a software developer and let them learn the engine on company time (which doesn’t take long). But even if you expand your search, finding a software developer is still harder than finding a creative coder that can help you out to script some stuff in Unity. (At least in my exprience)

Finding a good developer is equally hard for both engine. Someone who really knows their stuff in one engine, can easily transit to the other.

Performance

The C# vs C++ question regarding the performance is not as straight forward as you might think. Does a+b compile to faster instructions? C# has some runtime overhead, which C++ doesn’t necessarily have. But the question of performance is always connected to the task, the platform, the compiler and of course the programmer.

What is a simpler question to answer is the Unity’s C# and Unreal’s C++. Unity’s C# gives a fine performance off the bat, without optimization. However there is not so much you can optimize in Unity. Lower level optimization is not accessible, which is a determining criteria for some projects. I have had consistently 3 problems with Unity’s C# in terms of performance.

First, the garbage. Since I am not in control of where new memory is allocated, and when it is freed, I am forced to depend on their garbage collector, or not allocate memory in run time (pooling strategies and such). This can be a good or a bad thing, depending on the type of the project, its size and the number of people who are working on it (also their varying skill sets).

Second, really bad cache coherency. This is only an issue in certain tasks (analysing a giant array for example). If your team is abit bigger and your asset pipeline abit more demanding, this is a real killer for a project.

Render loop performance. For the same scenes (static unlit meshes with the same number of chunks, vertices and texture sizes), I have had faster and more stable render loop in Unreal. I never looked into why this is the case, it seems to me that it is a combination of faster culling and draw commands on the API side as well as how the buffers are setup in the engines.

Unity’s new releases look exciting though. They are addressing all these issues one by one. With the Data Orientated Design (also known as common sense) the cache coherency would be addressed. There is an incremental garbage collector as experimental feature and the new scriptable render pipelines are looking good. I haven’t used HDRP much but from the quick benchmarks I did, the loop was faster and the performance more stable. With the addition of the experimental support for Vulkan and DirectX12 plus the job system, Unity might speed up its API draw calls considerably in the coming releases. How well this integrates and maps to the already well established Unity community, time will tell. Until then, for performance intensive projects, I always lean abit towards Unreal. All other things considered, the lower level access is the main reason.

Other factors

There are other minor factors that differ from projects to projects. You might find certain tasks to be more often done in one engine. For example lots of VFX people do their VFX experiments in Unreal. This was I think mainly because of the material editor. With the upcoming shader and vfx graph, this might change in the future. Level design and architectural visualization were also two areas where the companies mostly used Unreal. This was probably due to the light baker and some other features in Unreal that made it easier for those tasks. Again this might change in the future. Last of these areas is virtual production. The last VFX conference I visited, Unreal seemed to be the only choice for these studios. Unity on the other hand is a very popular engine for Independent games. different reasons for this. Some I have already mentioned. The Unity social account also gives a lot of visibility to the smaller developers that are making cool things in their engine or sharing information with the community. This might be a huge plus factor for people who are trying to build their portfolio and break in to the industry by widening their reach.

Stuff I think are not true

I have read some stuff on both engines that I would like to take a few line to say, that my experience has been different.

“Unreal games are prettier”. How pretty a game is depends on the designers. If you use the standard setup of the engines without changing anything, unity games will look like unity starter scene, and unreal games like unreal starter scene. You might argue one is prettier than the other. But that’s not the point, you can make gorgeous games, both in terms of visual fidelity and aesthetic in both engine.

“Unreal or Unity games crash more, have more bugs …” again, the stability of the game is a result of the code the developers write. Nothing inherent about the engine that I have experienced makes this to be the case.

“True developers only use c++ or Unreal is the advance engine the pros use.” True developers develop games. Whatever does the job, go with that. Generally the avoid tech A and you must do it in tech B is most of the time not a great advice. As I stated in the beginning, everything has advantages and disadvantages. What is a bad choice for a project might be the ideal choice for a different one. Making games is hard, so take the tech that works best for you.

Hope you enjoyed reading, you can follow me on my twitter IRCSS. If you find any factually incorrect information, please let me know.