I am severely tempted to try answer the above question just to cause World War III and watch the fireworks, but unfortunately, the typical answer it true: it depends.
But what does it depend on? Well, let me give you our reasoning regarding why we picked the engine we did.
First, we narrowed the search down to four pretty fast: Unity, Unreal, Cryengine and Lumberyard. There are others but for various reasons we didn’t shortlist them and I don’t feel qualified to discuss them (Source Engine being an example). It also happened to be an interesting time for the game engines. Unity 5 was out and improving, Unreal Engine had become free, Cryengine was going through massive changes, and Lumberyard was being released. Below is a summary of our considerations regarding each at the time (apologies if the info is in any way inaccurate):
- We had played with it a bit before
- It has a large community
- It has a large asset store
- It has made large gains on its rivals in terms of visual quality since the release of Unity 5
- Can use multiple programming languages including C#
- Very flexible and easy to use
- Since it is a jack of all trades, it is a master of none – workflows are not as streamlined
- Can be temperamental
- Has a poor reputation among some gamers
- Lighting and visual quality are not as good “out-of-the-box”
- Second largest community
- Second largest asset store
- Known for high quality visuals in 3D indie games
- Concise workflows tailored for 3D games
- Lots of visual code (some would count that as a pro)
- The workflows can limit flexibility
- Great reputation for visuals
- Uses multiple languages (including C++)
- A relative newcomer in terms of free access, which limits community and asset store size
- Extra audiosystem licencing cost if you have more than 200 files
- As per Cryengine
- New, and therefore less tested with a smaller community
- Must use AWS in multiplayer
Now I must say at this point that much of what you hear, and what we heard, about the various engines is hearsay and quite biased for various reasons.
We immediately crossed Cryengine off the list since it was similar to Lumberyard but had a potential downside regarding audiosystem licensing (the game was not multiplayer so the potential downside of Lumberyard did not apply).
Soon afterwards we narrowed it down to Unity or Unreal Engine. This was because we did not feel that there was significant gain in using Lumberyard, but being new and with a smaller community and asset store, it may have a disadvantage. The size of the community and store are significant considerations for a small studio. You do not need an in house tree specialist for most games (nor could a small studio afford to hire one), instead you can buy non-core details like that from expert creators on a per item basis. Even big AAA studios do this for some items. Only models specific to your game need to be bespoke (of course that sometimes will include things like trees).
The last two in the race need to be discussed in a bit more detail. Unity has a larger community (which can help with problems you are facing) – but due to its temperamental nature it probably needs it. I have seen a few very odd bugs in Unity that require the program to be closed and opened again. It’s fast, so its not normally a big deal, but it is a huge issue when you don’t know that is what’s going on. Hours debugging your code when it is the engine that is the problem can be infuriating.
Furthermore, the larger asset store isn’t a huge advantage. For one, Unreal Engine has features as standard that you need the asset store for in Unity. Also, most assets on any of these stores are of little use. Some are out of date, many are very poorly optomised, and many work great except for the fact that customising them is virtually impossible. Some people will disagree, but a huge portion of assets sell by looking good at the start rather than being usable. There are, of course, some gems though.
On the other hand, Unity’s poor reputation among some gamers is totally unfounded. It can make any game you want. The problem is that for a long time it was the only free engine (not that anything is completely free). This meant that lower budget and inexperienced devs all used Unity. There is nothing wrong with that (we are in that category I guess!) but naturally it means that the average quality would be lower. That isn’t the engine’s fault.
As for out-of-the-box quality, if you are making a game this can be helpful, but surely isn’t required. Also, optomisation is key in game development, and one could argue that Unity simply strips things down as a design choice, letting you add what you need in you own time.
So far nothing I have said was decisive for us between the two. However, what was decisive was the workflow and languages.
Unreal Engine is great at whipping together 3D games, with many things “templated” so to speak (switching weapons for a character is a breeze for instance). But we like freedom even if it means more work. This was especially important on our first game since we didn’t know where the project would lead (you must remember that game engine choice is a very early decision). This is also linked to the programming language used. Unreal Engine is designed for “visual coding”. You can use traditional coding to interact with that though. Some people love visual coding. We, however, do not. If anyone reading this has no coding experience and is going to start making a game, my advice would be to just learn basic coding. Visual coding is as much effort and harder to control and debug when something goes wrong (and believe me, it will).
With that in mind, we opted for Unity, warts and all. Other engines will be better for certain games I’m sure, but all engine can make all games. Anybody who can tell you “which game engine is best” is probably just telling you which one he learned to use first. But maybe that’s just the cynic in me speaking.