They both have realms where they are easier than the other. Some things fit better than others.

But no matter which you choose you're going to have a lot of work before the game is finished. The bigger the game, the more effort you need. For the type of games typically discussed on the forums, both engines are able to handle anything that can be thrown at them.

For the AAA games mentioned above, where companies are spending tens of millions of dollars to develop, then they're going to be spending quite a lot of money to customize the engine to whatever their needs are. That is assuming either engine is close enough to their needs and usable for their games, anyway.

I would say that Unity is simpler/easier in general, but Unreal is going to be way easier in the case where you're trying to do something complex that it supports as an out-of-the-box feature :)

Unity is the better choice for small games like most mobile games, 2D games although for a Rayman clone Unreal would be better, simple 3D RPGs on the same level as what RPGs maker could do although with 3D graphics.

Any game where you need more than one artist, it would be better to use Unreal.

As a person who doesn't like 3rd party engines and at the same time a person who has worked with one (Unity) for two years professionally, I think I can make some contribution to this thread.

As I mentioned, I don't like 3rd party engines. I like to write my own code. After I had worked on some private projects, including writing my own engine (and eventually releasing a Steam game on it) in C++, and other from the ground-up stuff, I joined a company where they used Unity. It was the first time I think when I was using "somebody else's engine" and I really liked it. Unity is well structured, has a couple of simple building blocks (game objects and components) and you can build your way up towards a game any way you want. They did a great job in separating the engine (what Unity is) and the gameplay (which you write yourself). And because of that various people around the world build their tools and share them with the world (AssetStore) thus proving Unity's modularity. It took me like a week of work with Unity to really find myself a way around it. I felt like home. Of course, Unity has its weak spots, sometimes ones you would not except to find in a piece of software like this, but still when I'm in a need to use a 3rd party engine, I go for Unity.

As for Unreal... I had a really hard time figuring out how to work with Unreal 3. So much that I gave up. Then I tried Unreal 4. I nearly ended ditching it also altogether like I had ditched Unreal 3 because it turned out that one simple task I wanted to accomplish was almost impossible to do. I wanted to have an animated skeletal mesh and set one of the bones to my own local-to-world matrix. I tried to do it in C++. I googled for it. Turned out there are many people asking about it and nobody gives clear simple answer to that. Because there is none! Turned out that I could "relatively easy" to what I wanted but only via a BluePrint. From that on my adventure through Unreal 4 was a bit easier but still I stumbled upon a lot of hurdles. With Unreal it seemed like I constantly had to google how to do this or that. There is a lot of complex building blocks in there that you can use but getting to know them takes time. Also, Unreal 4 tries to pretend it has a similar to Unity gameobject/component model. That is only partially true. For instance, in Unity you can have a hierarchy of game objects and each game object has its own set of components. That's it. In Unreal on the other hand components can have hierarchies what was very misleading for me. Another thing was when I created a simple template project. I have the list of objects in the scene, I more or less see/know what they are. Then I run the project and suddenly I have twice more game objects in the scene out of thin air. Objects like "GameMode" or other intrinsically related to Unreal's beloved Gameplay Framework. Yeah, the Gameplay Framework itself is something I didn't like. The doc says that Gameplay Framework is just a set of useful classes built on top of the engine that can help you making your game (you know, the old PlayerController or Pawn from Unreal 3). Well, if Gameplay Framework was really such a nice framework built on top of the engine and not part of it I don't think there would be references to its classes all over the engine's options menus. There are even some C++ structs related to PlayerController in UnrealEngine.h file.

To sum up: Unity is well-structured to me and the fact the source code is not published does not bother me much as the engine itself is elegantly separted from gameplay which you write yourself. A couple of building blocks you can arrange the way you want. Unreal on the other hand seems very cluttered with a lot of various objects/classes, interrelated to one another. I can imagine you can do more optimized stuff in Unreal 4 than in Unity but you will end up with code maintenance nightmare.

I started using Unity several years ago. I chose it because it supported C# and I was familiar with XNA. I wanted to use Unity the same way XNA worked, so I started writing a code base which was able to convert between Unity and C#, starting with the Vector3 class. I got carried away. I started writing more and more code in C# and XNA, and eventually ended up creating my own engine from scratch in pure C# & XNA. This was a mistake, and a trap, and I knew it, but continued anyways because it was fun.

Then it was time to get serious. I was trying to create both a game and a game engine at the same time. The requirements of my game drove the development of my game engine, so if a game requirement wasn't implemented in the game engine, I had to go in and add it myself. Finally, one day, I wanted to render 3D text in the game. I could implement it, but it would take me 2 weeks to implement it. It wasn't a question of whether I was smart enough to eventually figure it out, it was a question of whether I wanted to put game development on pause in order to add yet another missing game engine feature. 2 weeks cost. How many more missing features will I need to add in? How many more weeks will that add to my schedule? How well tested is my home brew engine? Can I confidently release this and say that it'll work on all hardware platforms? I'm a capable engineer and I proven to myself that I can create an engine, but I'm also just one engineer. Engine companies have hundreds of engineers just like me (if not smarter!), working to build perfect game engines. Do I want to make a game, or make an engine? I decided to revisit using a game engine.

So, what game engine should I use? I didn't really like Unity because the UI was too confusing and busy to me. What else is out there? I discovered the CryEngine. It looked amazing. The price was very affordable. Okay, what does the API documentation look like? How do I get support if I get stuck on something? The answers: Non-existent and you're on your own. Nope. Not doing that. The learning curve is too steep and it would be trial by error.

Then there was Unreal Engine 4. It had just come out as 4.1 or something. I liked that the engine was able to support the workflows of multiple disciplines, and it was well designed to be elegant, yet powerful. Best of all, the complete engine source code was available. If something is confusing, missing, buggy, or incomplete, I can go in there myself and look at it or modify it as needed. The blueprint system was also an excellent way to bring non-coders into the project to implement game design mechanics. The engine was also quite affordable: $20 a month + 5% net. The documentation was somewhat okay, but it still needs some work (especially on the API side). To be fair however, the existing documentation is "good enough" in the general sense, and if there's something deep I need to know, I don't expect the documentation to cover it, and I'd have to find my answers in the source code itself. The other nice thing about UE4 is that it is constantly being updated with major releases. The tech world moves really fast. You want your engines to stay current. Your studio or project may lock onto a particular version, but usually the benefits of upgrading usually outweigh the costs.

I can't really be objective: I am a UE4 fan. Unity is a great engine, and I'm sure I'd do great in Unity if I spent the time to learn it inside out. Both engines are very capable of delivering AAA content. Both have compelling reasons to give them a good look. Both have strengths and weaknesses to consider, but neither are disqualifying. At the end of the day, you are going to have to list out what you want to get out of a game engine and then match requirements against offered feature sets. Whether you ultimately choose Unity or Unreal, it probably won't matter or affect your game nearly as much as your creative talents do.

My few cents on this debate are the following.

If the usage you foresee does not require a lot of programming (i.e. direct manual programming), Unreal is way easier than Unity do to the well crafted blueprint system. If, as any reasonably professional game developer, you plan to do (or to have other people in your team) to do heavy coding, Unity is way easier than Unreal. Not so much because it relies on C# versus C++. What makes coding in Unity easier in comparison to Unreal are three things. First, the online material you can find on how to things in Unity is much bigger. For what I hear, Unity's official community is also often much more inclined to help and give answers to newbies. Second, Unity's documentation is miles better than Unreal's. Third, Unity's code API is way better design. Or, to be direct: Unreal's API is a mess, badly documented, and with some functions with the silliest, cryptic prototypes I have ever seen. going over Unreal's engine source code, I find it to be just as bloated and confused.

On the other hand, I never understand this idea that C++ is so much harder than C#. At the beginning? Sure, by all means. However, since it have orders of magnitude more online and academic material, in a long term, advanced project, try finding source code samples of advanced algorithms and in-depth books on C# and you will see what I mean. In the long term, it is my solid believe that if you can learn only one of those languages, C++ will payoff so, so, so much more.

Also, Unity's easiness comes with a price. Unreal has way more functionality out of the hat. I mean, Unity included basic features like GPU instancing and 9-sprites only last year, for god sake! The refinement of Uneal's rendering system is certainly also unmatched by Unity. Sure, you can get Unity games looking pretty great, but the cost of time and effort is leaps and bounds more than in Unreal. It is not a surprise that commercial games made in Unity usually look bad, while even a novice prototype made in Unreal often looks great: because Unreal is set up in a way that is far easier to achieve the good-lookingness.

However, that comes with a huge cost too. It is absurdly harder to customize the shading pipeline in Unreal than it is in Unity. Not to mention to use custom computer or geometry shaders. It is a few clicks away in Unity. It often is hellish nightmare in Unreal. So, even if Unreal is open source, in practice, the high costs in terms of programming time often make it so that you get much less flexibility in Unreal than in Unity in terms of the look of your game. That is probably why so many online videos and people's prototypes made in Unreal all look great but all have the same artistic look.

But talking about open-sourceness, it is plain ridiculous that at this point, with Unreal, CryEngine and Amazon's engine being free to use and open source, Unity is still expensive for any serious indie usage and closed source. The fact that it is closed source creates two basic problems: 1) total lack of flexibility in what regards anything that lays within the engine (in Unity, you can't even merely make a GameObject skip view-frustum culling if you want to!); 2) you are in Unity's hands if there is engine-related bug that is affecting your players. I, for once, would never, ever work by option with an engine over which I do not have access to source code if needed. Never. Ever.

I also think that the business model pursued by Unity is very debatable. Their new pricing options look very bad for most indies. Their new versioning name that will start is still a mess. And they make odd choices, like leaving the dark theme of the editor for only those who pay subscription for their engine - i.e. if you want to use Unity free, you have to endure your eyes being hurt by that terribly looking white-ish UI. Anyways. Talking about money, a great side of Unity is that you can find tons of cool assets in their asset store either for free or very cheap. Good stuff in Unreal marketstore are way more expensive in comparison. However, in Unity's asset store is hard to find production-quality material.

I also think that the business model pursued by Unity is very debatable. Their new pricing options look very bad for most indies.

Most (successful) indie games take years to make. Lets say two man-years of work, and that your living expenses are $2000 per month.
So to break even you need to make 24*2k or $48k... however, the retail cut is only 70% and lets say you pay 25% income tax, which means you actually need to make ~$91k gross to receive your $48k net...
Then we can add on the cost of each engine:
Unity Pro is $125 per month, so $3000 total for 24 months, which gives us
((Months*Month_Cost + Engine_Cost)/Retail_Cut)/Tax == ((24*2000+3000)/.7)/.75 ~= $97k
Unreal is 5% of retail price after the first $3k.
If you set your target retail income at $97k (Our Unity baseline) and plug in the same numbers except for Engine_Cost (and also add the $3k threshold), then you can solve for Engine_Cost and compare directly with Unity. That looks like:
$97143 = ((Months*Month_Cost + Engine_Cost - Threshold)/Retail_Cut)/Tax == ((24*2000+Engine_Cost-3000)/.7)/.75
Solving for engine cost gives: Engine_Cost = $6000
...or, $250 per month... or, double the cost of Unity. Of course your mileage may vary; you can twiddle the numbers based on your own project timelines and living/development expenses to find the point where Unreal actually becomes cheaper than Unity.

Unity's Pro pricing is great for indies where "indie" means someone actually professionally producing an independent game. It's only bad vs Unreal when "indie" means any old hobbyist working during their evenings and weekends and/or out of their parent's house :wink:

[edit]Plugging those equations into Wolfram Alpha says that the point where Unity and Unreal cost you the same amount is when your per-month expenses are: $65.63*Total_Project_Months + $1575.
e.g.. for a 12-month project, if your per-month living/development expenses are over $2362.56, then Unity is cheaper, and if they're less than $2362.56 then Unreal is cheaper...
That's equivalent to ~US$28k per annum... I'm sure there's a lot of people who can get by on that kind of money per year, but the vast majority of 1st world households cost a lot more than that to run. So again: Unreal is far cheaper for hobbyists, Unity is far cheaper for professionals.

The fact that people seem to think that Unity is at all expensive goes to show how many people haven't done the math on Unreal's offer, or their own household budget...

So again: Unreal is far cheaper for hobbyists, Unity is far cheaper for professionals.

I agree with this, not taking into account AAA as professionals, however you also have to consider Unity's cost of tools. By my estimates to have even working basic tools will cost about $100-$180, for tools on par with Unreal $1200-$3000. Some of these are lump sum, others are monthly fees and that is just to get Unity to work on par with Unreal.

You could make these tools yourself however that would mean hiring extra programmers or adding time to your project.

If Unreal cost twice as much as Unity it's a profit, because not only does it have almost twice the power, it has much better tools and more flexibility out of the box.

Unreal also keeps upgrading the tools in the engine, where Unity only upgrades the base engine and networking.

Then there is also the factor that Epic games share a lot of there tech with Unreal 4. For example after they made Paragon, it became possible to run over 1200 characters on screen with the same impact as 12-16 normal characters.

Unity's documentation is miles better than Unreal's.

This is only slightly true, Unity's docs can be just as barren as Unreal's at times. Also because Unity is used by so many developers a lot of search results can lead to ineffective or sometimes wrong solutions.

With Unreal it often turns out to do X you need to toggle the X switch. With Unity to do X download this outdated X script and spend a day updating it, then you can do X however only when there is a blue moon!

a person who has worked with one (Unity) for two years professionally, I think I can make some contribution to this thread.

I think Maxest makes the most valid defence for Unity. That is for a developer who has been using Unity for a year or more, changing to Unreal would be difficult; because the approaches the two engines use, to game development, are the exact opposite.

However for newcomers to game development, the rewards of learning Unreal over Unity would be large; although a more difficult task.

The fact that people seem to think that Unity is at all expensive goes to show how many people haven't done the math on Unreal's offer, or their own household budget...

This I feel is also a very good point, if you plan on making game development your livelihood you should consider the price. I Also advice to factor the price of tools and other software you need to achieve your goals.

* Consider my two cents retracted. It is painfully obvious to me after browsing the forums that I do not belong here.

Best of luck to you all!

Wow. Has this community become so arrogant that anything besides creating your own engine is amateur? I'm already feeling like I don't belong here and I just signed up.

As much as it can seem that way at times, please take into account that the initial question:

As the title of the thread implies, the question is, which one do you like more?

You could simply answer I like X more than Y, but I much prefer the debates that grows over various features, weaknesses, strengths and yes "idiologies". I don't even mind that people reference their own experiences or beliefs in building their own engines, probably because one of the more common points made in the tech forums to new folks is:

"Write games, not engines".

There is a wealth of solid engineering, as well coding talent in the tech side of site and it has been like that since Gamedev's inception. It might seem that familiarity breeds contempt or arrogance, but sometime simple professionalism can also seem that way.

Be that as it may however, Welcome to the community, :)