Can you give me detailed reasons for why Unreal 4 is better than Unity?

Yes I know there have no doubt been many Unity Vs Unreal threads before, but most of the time when I see such things they just tend to consist of childish “this engine sux lulz X is better lol” type of comments.

What I want to know, in detail, is EXACTLY what it is that gives Unreal 4 advantages over Unity. For example, I have heard that the creators of the System shock remake and Homeworld: Deserts of Kharak originally started out with Unity but then switched over to Unreal 4. What is the reason for this? Switching engines mid development is a pretty big decision to make so they must have very strong reasons for doing so. What are the most important advantages Unreal has over Unity that is causing so many devs to favor it over Unity? And please don’t give me childish replies like “cus Unity sux ass lololol”. As somebody who desires to become an indie dev himself, I really do want to know.

There is nothing childish in How is Unreal better than Unity? - Unreal Engine Forums

You should ask for those who had switched in first place, and in my opinion UE4 is a lot more friendly for artists than Unity. Unity has great appeal for coders that are not exactly artists. Of course there are pure coders using UE4 and of course there are artists using Unity.

What happens is that in Unreal most artistis will not need to relly on coders to do things, this gives great flexibility for them. In Unity, many artistis will need to relly on coders to achieve things.

Any tool is great in the right hands, but games with great visual quality depends more on an artistic vision, so Unreal just is the right tool for them. Thats why the change, thats why the preference.

Success in a game, or a movie, or a archviz requires brain and talent, no matter the tool being used. No engine will give success, but the commitment to learn it and explore it the full extents of it, the talent and brain will guarantee success!

What makes Unity worse for larger scale games? I heard people saying this many times but nobody ever really goes into details. You mention Unity being closed source which I guess is one reason but is there anything else? Are there some feature limitations that for some reason just make the engien poorly suited for larger scale game projects?

1 Like

The biggest problem in Unity is that it’s very barebones, there’s a bunch of basic systems that are missing and the things that are there are half-assed. For example, they didn’t really have a UI system there, they hired a guy to build one but it’s so limited it’s unusable so you have to use one of the UI systems from the store. You can do a lot with Unity–if you are OK with buying a lot of stuff from their asset store.
For Unreal, it includes all the features you need to make a game, but if you’re not a programmer and you need to do something advanced that you can’t do with Blueprints, then you are out of luck.
For me I use Unity at work because we make simpler apps, but otherwise I use Unreal.

Before I even began working on games I spent 8 months making tools to fill the gaps Unity editor had.
I never bought that NGUI thing, I built my own UI, was a lot like Slate, but C#.
Many always ask them to focus on building design and development tools, but more and more they focused on marketing shinny things, cloud services, things that contribute nothing to the actual act of building a game. The more they went the route the more I felt irritated until I left.
Then they hire that guy who used to run Electronic Arts… I didn’t like a single bit of that.
They tried to rise the price of Unity pro, was like a dooms day in their forums.

After I had my game design tools in place, had to workaround numerous limitations…
For example implementing custom culling and custom LOD system; Implementing an IK system, mechanim was buggy and closed source and sometimes a whole animation state machine would have to be redone until I’d find WHY the hell a transition didn’t work as expected. I couldn’t look into the source so I had to “guess”.

The navMesh generation had a bug that if your assets weren’t in 3DS MAX scale, it would take FOREVER to generate a navmesh in the level…
I spent 2 months resizing and reimporting assets in MAYA because I didn’t use 3DS Max and its default world unit scale :]

One day I open Editor and all ‘script references were missing’… Like that, for no reason at all.
(…missing-2.html )
Okay, I spent some time fixing it, had source control and etc, but still rebuilding meta files takes a long time wasted… but then another day it happens again.
And again… and then some more.

When page for UE4 subscription launched online I downloaded Unreal 4.0 and just said “-fk this sht, I’m out.”

Why is it better? I don’t know if it is necessarily better. Both engines are totally capable and both have strengths and weaknesses. You should look at what you want to accomplish and compare features to decide which one is right for you. The engine that best fits your own needs is the better engine.

Historically, UE4 vs Unity was like comparing big-brother to little-brother, but maybe things are changing… Looking back at old threads to sum things up in one phrase - Unreal flatters you more… Put in a half days work, and what you get back is better looking, regardless of asset store add-ons.

From a frame of reference of coding / level-design / core-gameplay etc… Unreal is mighty at meshes and mesh-counts. Even without instancing or merging. What this means is, you can have fun building worlds and worry about optimization / performance later. That’s not a wise thing in principle, but it does make the Editor lots of fun, and gives artists liberty / license / freedom ‘to go make something’.

On the downside, UE4 requires a much greater depth of knowledge of the framework. That’s a departure from Unity and its magical update calls… Bruno: ‘I hated UDK because it was like Unity, but less polished.’… Interesting POV… But UDK is still a great engine. Proof of that are the games still being released. UDK was always a level or two above Unity in looks. But either way UDK + Unity were easier, because you could just build things, without fully understanding the underlying framework. Kismet had no OOP model, which meant devs often created visual code monsters (even Epic, see Jazz)… But to progress in UE4 you need to understand the structure well. If you can’t do that, you may be lost forever… From the Unity versus UE4 thread linked above, this stood out as being where Unreal is still very weak:

What’s changed recently from those old ‘Unity versus’ threads, is that Unreal isn’t the community it was from 2014-2016. Plus the Docs, even Epic now acknowledge need urgent work. So what are Epic doing… Lots of vague promises, but nothing has materialized… We’ll have to see. This is a high flying time for Epic with lots to celebrate. But the industry moves quickly, so you can’t relax for long or become complacent…

So when are the Lumberyard vs Unreal threads starting??? :smiley: It’d be a closer comparison. Things are warming up with Amazon’s resources and Bezos’ ambitions / reach… :stuck_out_tongue:

One of the things about Unreal is you quickly find what it is and isn’t capable of. Unity tends to surprise you when you’re halfway through a project, and because it’s closed source you can’t even attempt to find out why.

Back when I was using it, you could make a variable that was anything and it wouldn’t complain, but it wouldn’t show up in the editor, and even if you made your own editor it wouldn’t save. In Unreal, in blueprint you can only ever make variables that are fully supported by both the editor and serializer, and in C++ it will throw an error on compile if you use something unsupported.

I still think you can nut out a quick game or prototype in Unity faster, but that’s because I’m a C++ guy and C++ is just slower to iterate than C# (compile times mainly, 1 second vs 30 seconds makes a big difference over time).

Im a C++ guy too, but I can simply say that blueprints are a life saver for artists. You don’t need to know programming to make stuff in Unreal, while in Unity you will face it immediatelly. In Unreal you can have C++ guys doing stuff that will be exposed as blueprints for artists to use the way they want, so this is completely a feature that one can’t ignore.

My very first asset that I have put in sale in the Marketplace I have the guts to make it in blueprints just for the sake of artists being more familiar with them. If they need speed, they can use nativization. Hard to not use it if the job allows it.

Unity let’s you do everything quickly but it also makes everything messy at some point. The editor and it’s features in UE4 give you a proper workflow/guidance with everything. And when something is bugged you can fix it yourself because you have access to the source-code. If you use Unity you have to code around all their engine bugs - and there are plenty and they are extremely slow updating their engine.

Another thing I didn’t mention earlier was the necessity of developing C++ sub-systems on Unity.
People mostly don’t know (because no docs on the subject) that it’s possible and necessary to develop game systems in C++ on Unity and I had to do it a few times (not my personal projects tho).

Long story short: a serious product with microtransactions built in Unity absolutely have to implement a C++ layer for some core systems.
Because Unity, and C# in general, are infected with WYSIWYG decompilers anyone can get free from the internet.

Hobby or small indie Unity projects are often fully written in C#, but company actually publishing a product based on microtransactions cannot accept kids decompiling their Unity games to patch microtransaction API function calls in C# code, so professional work on Unity often has plenty of C++ involved.

And, believe, dealing with that ain’t fun.
UE4 is so much easier, when I tell people Unreal is easier to work with than Unity, it’s about this kind of “hidden roadblocks” I refer to, but often people don’t believe me because they don’t want to invest months and months to learn UE4 & C++ while they have no idea C++ and HLSL programming awaits them down the Unity’s road if they don’t want to face microtransaction robbery by kids using C# decompilers…

A guy I know built a company just to sell C++ “native plugins” for the people caught off-guard by this problem when developing on Unity. When they find out people are activating microtransactions on their game for free, they buy his “Prime plugins”, he wins.

So… You cannot really avoid C++ if you want to professionally make any money out of the games you put so much effort to develop :confused:

This would probably wield consideration aswel after all was said here:…-engine-survey meaning not only gaming, not only movie making, arch viz is going far and well, and as of today a new product in the family: the Unreal Studio (with Datasmith) has started Open Beta, check it out!

I can talk from a programmers perspective… the framework feels more solid… albeit a little more restrictive (which isn’t a bad things in its own). Having a good framework can do wonders for code encapsulation and i just feel that everything i do is less clunky.

Now… i wouldn’t say it’s BEST… because things like missing Geometry shaders are starting to bite me in the *ss (but they can be done in .usf) but still, every plattform has it’s perks and it’s drawbacks

Speaking of shaders, isn’t Unity getting some new fancy tool in the 2018 version that allows you to create new shaders via node based system? I hear creating your own shaders is a pain in unreal 4. What is the reason for this?

Ps. I know almost nothing about shaders yet :confused:

I would not say it is a pain… but when you compare the easy material editor and this is all you know, shaders (HLSL) becomes harder, but its sintax is C++ or C# like, but for you to integrate it into the engine you need not only the HLSL knowledge but also C++ knowledge and to know the Unreal API for the wrappers to access it and enabling optimizations and reuse in another platforms. Besides this, you can put small HLSL nodes inside the material editor, so it is not painfull, but it has limits on their usage extent. There are few blogs, some even made by Epic’s employees which teaches how to create shaders inside Unreal with C++ etc.

Instead of replying PMs (this is a public discussion anyway) I will post some examples here of the issues I was talking about above:

This is all over the internet!
I know people who have lost all their revenue because of this (their games bombed very hard, zero profit and they gave up making games).

This is gold digged, Im saving up this info :slight_smile:

lmao Unity being crap to such an extent that people can just dig into the code and get all the microtransactions for free is hilarious. Can’t believe it’s so poorly made that this is actually possible.

But ain’t Unity’s fault. this is a problem with “.NET” systems;
Don’t get me wrong, I used Unity for over 6 years and I’d still use it if I didn’t have better options today.
I also developed .NET apps for a year or two and I know how easy is to decompile any .NET application.
People buy some “code obfuscators” that change variables and function names in hopes that will make harder to read C# code lol. Of course that helps nothing.

.NET languages were developed with other purposes in mind and it is absolutely great echosystem, but I still have no idea why the hell Unity picked it up to build a game engine.
They were looking at “scripting languages” popularity, maybe, I have no clue.