The biggest difference between them, IMO, is that Unreal comes from an AAA lineage and has relatively recently started extending its reach down to mobile and indies, while Unity comes from a mobile (iOS) / indie lineage, and has been steadily extending its reach towards greater and greater AAA ambitions.

What this means for users is that they're really both converging towards similar capabilities, but they come at it from different beginnings. Both companies have a huge staff dedicated to ongoing engine development, very capable people all around, so you shouldn't make the mistake of assuming that Unreal is somehow more legitimate. In practice, Unreal has put a lot of effort into user-friendlier tooling with UE4 but there are still more and sharper rough edges than in Unity's tooling. Unity is more friendly for the casual developer, but sometimes the fact that they assume lesser of the average Unity user can get in the way -- Usually you can get around it, but it sometimes seems like more work than it ought to be, or that what you need is more hidden.

Licensing is also a big difference -- both in terms of access to the C++ source code (which you might come to need for performance tuning) and in cost to you to license either engine for commercial use. Unreal offers up C++ source code access for free, while Unity charges ~$50,000 last I checked. For usage, Epic wants 5% of your gross revenue above $3000 per product, per year, but there's no seat license -- this is nice and simple; its also entirely free if you're using it to make CG films, IIRC. Unity wants $75/month subscription or $1500/one-time fee per seat, per platform-package (e.g. extra iOS, Android features, Consoles -- which I think are a higher fee), but they don't take a cut of your sales after that. Depending on what platforms you target, how many developer seats you're licensing, and how many sales you expect to do, one of these options will save you money; If you make a lot of sales, Unity works out to be less expensive in the end -- the break-even point is lower or higher as a function of how many seats and platforms you license, and whether you need C++ source; but, you pay unity up front, regardless of whether you make any sales at all. Unreal costs more when you're successful, but it doesn't penalize you if you have a commercial failure -- 5% is really never a burden. When I worked it out once, basically if you make less than a couple hundred thousand in sales, Unity is the cheaper option; if you make more than that Unreal costs you, but making "too much money" is a wonderful problem to have and you'll probably be overjoyed to give them their 5%. That 5% is definitely cheaper than a team of high-caliber engine developers.

That said, whichever is most comfortable and has learning resources and a community that suites you is probably the way to go. Your game is always more important than the engine, and these engines and toolsets are already close enough to parity that either will block you from achieving your vision.

The Liscense has a reference in it that you can contact them for custom liscensing, But I don't know at what point that would be viable.

But I agree, having to pay Unity/Epic is a good problem to have :)

The Liscense has a reference in it that you can contact them for custom liscensing, But I don't know at what point that would be viable.

If you are planning on spending more than around $10K on individual licenses, probably worth it to call them. The worst they will tell you is no deal, and it doesn't take much to ask.

Having the source code for UE4 is invaluable, this is why I don't get on with Unity.

Require a feature? Simply add it yourself. Need to fix a bug before the next release? Fix it yourself (and if your kind enough, create a pull request so we can all benefit).

Having the source code for UE4 is invaluable, this is why I don't get on with Unity.

Require a feature? Simply add it yourself. Need to fix a bug before the next release? Fix it yourself (and if your kind enough, create a pull request so we can all benefit).

Yes, with the caveat that 95% of small(-ish) devs, especially lone wolfs, lack the time or money to add features like that. And in most cases, it doesn't make any sense anyway to spend that time on a speciality feature instead of, you know, actually developing the game logic and content.

Being able to fix bugs is great, until you have to roll you bugfixes into newer versions of the engine everytime there is a new version out bringing features or other fixes you cannot live without.

Forking (which is what you are doing here basically) is always a double edged sword. Yes, if you create the pull request and you are lucky, Epic will quickly integrate the fix. Maybe that still takes some time though. Or maybe they go with a different fix that means you need to recode some things that built upon your own fix.

Not saying having the option is a bad thing (and definitely, Unity needs to get their source code opensourced at some point in the future too if they want to keep up with an Unreal Engine that starts to become almost as user friendly as Unity).

Its just not nearly as much a big deal as you make it look like. Not for 95% of devs that are happy with what the engine brings out of the box. Not for 50% of the other devs that are able to add the features over work arounds (as inconvinient and hacky as these sometimes are).

If anything, the fact Epic gives you the source and Unity does not (yet) just shows the different target dev groups... Unity (still) targets the small Indie, and the lone wolf, who usually have little use for the engine source. Epic (still) targets bigger Indies and Studios, that do have the time and money, and thus can afford the need for engine customizations.

Having the source code for UE4 is invaluable, this is why I don't get on with Unity.

Require a feature? Simply add it yourself. Need to fix a bug before the next release? Fix it yourself (and if your kind enough, create a pull request so we can all benefit).

Yes, with the caveat that 95% of small(-ish) devs, especially lone wolfs, lack the time or money to add features like that. And in most cases, it doesn't make any sense anyway to spend that time on a speciality feature instead of, you know, actually developing the game logic and content.

Being able to fix bugs is great, until you have to roll you bugfixes into newer versions of the engine everytime there is a new version out bringing features or other fixes you cannot live without.

Forking (which is what you are doing here basically) is always a double edged sword. Yes, if you create the pull request and you are lucky, Epic will quickly integrate the fix. Maybe that still takes some time though. Or maybe they go with a different fix that means you need to recode some things that built upon your own fix.

Not saying having the option is a bad thing (and definitely, Unity needs to get their source code opensourced at some point in the future too if they want to keep up with an Unreal Engine that starts to become almost as user friendly as Unity).

Its just not nearly as much a big deal as you make it look like. Not for 95% of devs that are happy with what the engine brings out of the box. Not for 50% of the other devs that are able to add the features over work arounds (as inconvinient and hacky as these sometimes are).

If anything, the fact Epic gives you the source and Unity does not (yet) just shows the different target dev groups... Unity (still) targets the small Indie, and the lone wolf, who usually have little use for the engine source. Epic (still) targets bigger Indies and Studios, that do have the time and money, and thus can afford the need for engine customizations.

I'm not talking enormous features here, the ability to extend a class interface, or even export it so it's visible outside the engine DLL saves a lot of time.

Thanks everyone for all the great answers!

I've decided to try Unreal first, due to my C++ history.

If it suits me, it's fine and I will go on with this engine without anything else.

If I think Unity might be better or easier, I will try that as well and then I will see which one I like more and

I will move on with the best.

Again thanks!

I'm not talking enormous features here, the ability to extend a class interface, or even export it so it's visible outside the engine DLL saves a lot of time.

Sure... I am not saying that it isn't a good thing to have the option. Just listing some reasons why it is not such a hot topic for many other small devs, or why it might complicate development.

Many times I would have wished to just open up Unity's source code and see why feature X wasn't working as expected or if I could just do the legwork myself when the guys at Unity dragged their feet.

In the end, most of the time there was a dirty hack or workaround that fixed the problem. Is this as nice as just rewriting the classes and properly implementing the feature in code instead of doing stupid editor level magic tricks? Of course not. And you are not even guaranteed that your "fix" will not be broken with the next upgrade of Unity, hopefully when Unity fixes the root problem that provoked the "fix" in the first place.

Still don't think most people will be to fussed over that because they will not need those fixes for their modest requirements.

@ TO: Good luck with your choice. You cannot go wrong with either engine IMO.

Pragmatic answer: why not just try both and see? They're both free, after all. When I started Unity it took me maybe four hours to make a very basic shmup, which let me get a feel for the engine. Unreal took me a little longer, I found it had a steeper learning curve, but a couple of days isn't a waste if it lets you find the right tool set for your needs. It's still quicker than waiting for us to tell you what to do. ;-)

...and for completeness: I ended up choosing Unity for my current project, but I've prototyped a possible future project in Unreal, and I may switch, just for the giggles.