I've worked with both commercially. Shipped an early access prototype with Unity, currently working in Unreal.

The first thing I would say is that I'm amazed that some people would still rather do it all themselves. Of course, you can do everything that these engines do, and in some cases better. But there is just so much work in these engines that to replicate it would take so long. I've worked commerically on in-house "code what we need" engines, and literally once a week a different artist or designer would come and ask, "how do we do <X>, like in UE4 or Unity" and the answer is, "we don't have that yet. It'll take a couple of months to code it", so it never gets done and everyone suffers.

I'm perfectly happy with Unity for the most part. I use it for my personal projects and I recommend it to newbies when all other factors are equal or irrelevant. But I'm concerned that the success of their Asset Store basically discourages them from improving the core product, which we've seen from them ignoring UI for years and then shipping the new UI in a suboptimal state, for example. Some say the same applies to Mechanim, though I've never used it. And I'm also concerned that they want to get in a toe-to-toe fight with Epic over rendering features while leaving everything else sub-standard or broken. But maybe they feel they have the hobbyists and indie market already sewn up, so it's only AAA left to compete for.

Comparing UE4 to Unity is interesting. UE4 is much more fully featured - the animation system, the controllers, Blueprints, data tables, behaviour trees and tasks, integration with source control... and that's before you even consider the higher performance and scope for graphical quality.

But a lot of things in UE4 are underdocumented or simply undocumented, the community is not very helpful, and there are still plenty of bugs. If you're an AAA studio with a support contract, those bugs will (probably) get fixed for you before you ship. If you're anyone else, get set for hours or days of digging through engine code to try and understand it, only to have to fix a bug in Epic's code. And the code is complex. You get all the downsides of a large inheritance hierarchy with all the downsides of a component-based system, with all the fun of sprinkling magic macros and auto-generated code throughout the code base too. You need to be in it for the long haul, and you need experienced C++ coders to do well. With Unity it's more straightforward; generally speaking, if it's implemented, it's documented, and someone will help you out on the forums if you ask. So a large part of the decision is about whether you're happier digging into other people's code or not.

It's kind of unfortunate that Unity got such a bad rep, cause it's not super different from Unreal imo. 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).

Plenty of large studios use Unity however you probably don't realise it it - the problem stems from the licensing terms; if you use a free version you have to throw up a splash screen, if you pay you don't.

So, Joe Hobby who produces the poor/basic looking game has Unity splashed all over it.
Meanwhile AAA Developer who has shelled out money doesn't mention it.

Just two words: "Pokemon GO"

Not really adding anything new, but I'll jump on the "they're both good, but use the appropriate tool for the job" idea.

I've used both, and prefer UE4 over Unity, but I'm pretty sure that's just because I prefer that workflow (and appreciate the full source access). To me, Unity is sort of this black box, and I don't always trust that it's doing what I want, but with Unreal, I can just dig in and figure out exactly what it's doing. On the other hand, I feel like Unity provides a very "fast" way to work, and is a little more non-programmer friendly for some tasks.

For a huge fancy high-performance, crazy graphics, FPS, all-the-buzzwords kind of a game, I'd go for Unreal right away cause I can't think of a reason not to. For a smaller, more casual game, where performance is not as important, but things need to be done quickly, I'd go for Unity. For in-my-free-time projects where I'm the only one working on the game, I tend to roll my own "engines" for the sake of learning how all the pieces work, challenging myself, etc., since time is not a concern.

In theory you get total control over each pixel one way or another, so yes. In practice, lots of other factors contribute to whether that's feasible or not given whatever performance, competence, or budget constraints you have. In particular you can't dig deep into how Unity implements its rendering so certain approaches are just not available to you.

To my knowledge, both Unity and Unreal seem to be more than capable of producing the same graphical fidelity, no? I've seen some posters here saying otherwise, so I'm sort of curious.

You could make AAA games with both, however in scale Unreal will win over Unity (Lumberyard should be 10%-20% better than Unreal, although I have no way to confirm it.)

[spoiler]

First you need to know that there is a limit of how many objects can be drawn in a scene, regardless of the vertices and polygons in them. For mid-range PCs this should be 250-300, so even if the mesh is one triangle you can only render that many of them.

Batching joins these objects into a new mesh, batching engines are vertices focused Unity has a 65 000 vertices limit per batch. So you can render 300 * 65 000 = 195 000 00 vertices

Unreal is a instance engine, instancing draws the object in more than one point. Hierarchical instancing can be seen as a combo of both batching and instancing. Unreal has a polygon limit of 64 000, so in theory it should only render 192 000 00 polygons. However using the hierarchical instancing I have rendered over 4 000 000 polygons on a mid-range PC. Here is a tutorial for people who wan't to test:

The 54% value, that is unity only performed at 54% of Unreal's power, I have is a average from my day job, the developers I work for tested each part of Unreal against Unity to see what engine was better for them. In this post https://www.gamedev.net/topic/686886-unity-terrain-details/ I was having problems with the grass, I reached 60% of the amount of grass I had in Unreal.

I consider my 60% more realistic for the average developer, because at work professional programmers and art, made for them was used. My personal results in this test is closer to what a normal person could do.

[/spoiler]

What is killing Unity is it's skin deep approach. New developers aren't aiming for a match 3 game or a simple platformer, they want open worlds and cinematic graphics. Unity pretends that it has everything you need to make these games, so people start making them and when they reach the point where the real work is done, Unity just doesn't have the tools, these developers also don't know what is missing as they have never worked on games like this.

So the developers think this is it, there isn't any more; they publish half made games that at first glance even look like full games. The half games swarm the store fronts, dragging down Unity's reputation.

The half build tools, irritate content creators; we already have to offer our services at a discount so that Indie developers can use us, asking them to buy tools or hire more programmers isn't a option.

In the AAA market content is king and Unity just not keeping up with Unreal. The license isn't a factor for AAA developers, because they can just arrange a lump sum agreement with Unreal. Don't know if it's related, we are using a older Unreal 4.10, could also be that they just don't want to update the custom changes with each release.

Unreal is also advancing at a fast rate (or maybe it just feels that way because I still get to work with a older one). It even now has a way to merge meshes in the engine, when Unity a batch engine that benefits from it more, still only gives a link to a script for it.