I was tempted to close this as it is a "this vs that" thread, but it is in the lounge and we haven't had a good bash lately, so maybe this one will survive for a while.

To me the question is akin to: Do you prefer Rocky Road ice cream, or Chocolate Brownie ice cream? There are some small differences between the two and you can debate minor ingredients differences, but on the grander scheme of things they're effectively the same, provide fundamentally similar services.

These engines are far to be clean and not designed to be threaded correctly, these engines are good for prototyping.
My experience on shipped games : I got less issues working on Unity for mobile games than Unreal Engine.
You can write a game without writing an engine, simply working on needed features.

I'm curious to see other's opinions on whether that is remotely relevant with how either engine stands today, or if it is just a weird bias leftover from old internal development notes.

That is mostly gone these days. While implementation details are different, both work the same on a feature-by-feature basis. They both provide different defaults, and as you mention the defaults tend to favor a gritty FPS feel on Unreal and tend to favor a playful/cartoonish feel on Unity, but they can handle the same if you replace default shaders and replace default controllers.

Regarding the comments up top about threading models, both are designed fundamentally so they only expose single threaded gameplay. However, there are no restrictions on incorporating your own asynchronous libraries or doing multithreaded processing if you choose. I've seen several games that add it quite effectively, using all the cores continuously to good effect. Neither engine does it for you out of the box because typically entering the realm of concurrent processing expands your bugs and code complexity by orders of magnitude. Multiprocessing introduces the potential for bugs that change by observation, values that change mid-read or mid-write, deadlocks and livelocks and other frustrating or nightmare-inducing scenarios. Nothing prevents developers from using concurrent processing and the tools and libraries are available to those who want them, but I think both engines took the right approach to keep the general users in the relatively safe land of a single visible thread.

I just asked this question to myself in the last days. I've been looking for a job in almsot every company in the world, and 80% of them are requiring C++ experience, which means UE in most of the cases.

I've been using Unity almost every day for the past two years and I must say that now that I know it, I wish I started the Unreal Engine before. Don't take me wrong, I love Unity and it has a lot of great qualities, but I feel like that it's still too heavy for AAA projects, and has some behaviors that just let you ask "Why". Unity is great if you are new to gamedev, if you are a non experienced programmer, if you are a one-man show, or if you are developing for mobile.

The unreal engine has a learning curve the resembles the cliffs of Moher, but once you get into it, you can do magic (and find a way better job, if you are looking to work in the industry).

For me as an professional 3D artist I can't understand how people can even make a full game with Unity.

On the surface Unity looks like a full engine, however once you get to the real implementation stage you find that the tools you have are half made and a lot of the basics is just missing. ironically this is what makes it a good engine for mobile games, it has a lot less extra's that won't be used.

The worst for me is Unity's Prefabs and how they don't even work with batching, even if Unity is a batch engine. Why even pretend that the editor is any thing more than a placement tool, when all the tools are broken and the prefabs work against the batch manager?

I understand why so many programmers like Unity, because it's still a old code based engine disguised as and toolset engine. Sorry for the rant Unity is just getting on my nerves, indie devs please stop using it, it's broken and your artist hates it. <_<

Unreal is the better engine, no doubt listing the differences would take ages, they key point about Unreal is that it's made so that all of the people on a team can use it. The blueprints allow everyone to fix small problems and if needed a programmer can write code to add blueprints for special needs.

True because of Unreal's fully functional, feature filled, easy to use tools; it's a bit on the bulky side. However it is possible to dump what you don't use before packing the game.

The down side to Unreal is that it didn't keep any of the old shaders and tools, this combined with it's behemoth size makes it impractical for mobile games.

Also the 2D engine in Unreal isn't great, there are many free 2D engines that exceed it and even Unity's half build 2D tools is better. For 3D games Unreal is the best engine. ^_^

About self made engines, first I admire your skill and dedication, these engines are often slick and elegant. Unfortunately they are hard to use, if the developer isn't around to show you all the quirks things get messy fast.

Second, it would be near impossible for a single developer or indie group to make a engine like Unreal, even a streamline one.

I would never discourage anyone from making there own engine, I find that developers who made a engine in some point in there life, are just better to work with. So you have my admiration, however I have made a small engine in the past and I will never be doing that again. :lol:

Why is it though that larger studios have stayed away from Unity as opposed to Unreal? I'm genuinely a bit curious about this (seeing as we are debating the two engines).

Simple it can only reach 60% of Unreal's power out of the box. Also even if the differences between batching and instancing is considered small, once implemented instancing just outperforms batching in the long term. Especially because instancing works with a modular approach.