That is not neccesarily a good thing though, if we filter for quality there will be more parity.
I respect other engines too, and Unity has become very powerful with alot of tools. Havent used it in two years, but I have seen it has grown stronger.
But Unreal has grown a lot farther than Unity has done within two years.
Unreal 4 is choosen to make FFVII or Shenmue 3 because it is an engine more professionnal than Unity is, to make AAA games.
While Unity tries so hard to get Final Fantasy game to be made on it… and we know it’s MOBILE game final fantasy XD :rolleyes:
Bet they got heartbroken for that. Oh well, it’s Unity and it’s for mobile + 2D games.
Doing a search of VR enabled titles on Steam with the terms Unity and Unreal returns 20 results for Unreal and 9 for Unity. Not every game is going to list their engine in there, but hard to imagine more than twice as many that used Unreal to name drop it while less than half that number name drops Unity.
That’s not how I check the engine. Since I have many of them installed I can just go to the steam commonapps folder and in case of Unity search for _Data folder or mono stuff. For the others I’ve seen either the devs post about them or engine mentioned somewhere else, like on forums or articles. First page of the results alone is almost 20 titles.
EDIT: this post is written from a very personal point of view. I’m a coder and just tried both engines. I don’t wanne give some kind of final verdict. This is just about my personal experience trying them out for a specific project I had in mind. I’m not the guy who tells you which engine is better, just telling you which engine is better for me and why. Can change with project and people who work on them. Thanks.
Nice discussion, just my 2 cents.
I’ve been working on game engine programming (also game code) as a pro for 15+ years. Last year I was bored in my non-game job and curious about the 2 engines. I started with UE, because it was promoted as the ‘pro’ engine and used C++, my preferred language.
I tried to implement the bare bone of a cRPG, starting with an inventory system, followed by a turn based combat system.
Doing a dynamic UI in UE4 (drag&drop) was just hell. I wanted to do most of it in C++, but the engine forced me into BP all the time. I managed to do it at last…
For the turn based combat i used the navmesh. It was ok so far, but lacked some features.
The experience so far was a bit disappointing. Too far away from the marketing, you could say.
I resumed my work some 4 months ago and tried to merge the 2 projects. I failed. Most of my classes were C++ classes derived from UE engine classes that had BPs derived from it. I could not merge the projects… a perfect time to try out Unity.
Again I started with the UI. Unity overhauled their UI system lately and it was a breeze. Within 2 days I had a basic Drag&Drop system and a clear idea how to go from there. It quickly developed into more than I wanted. I started with combat, again using navmesh, this time unity wise. It was almost the same experience as it was in UE, both systems are pretty similar.
Ok, what did I learn?
Right now, i prefer Unity a lot. As a former engine developer, engine design means a lot to me. This is where Unity shines. Basically, there are only 2 things in Unity. A Container (Game Object in Unity speech) and a component. Any complex object in Unity consists from hierarchically ordered game objects, each of them having several components defining how it is working. A C#-Script is a component by itself. It controls the other components, e.g. UI, NavMesh Agent, whatever. Probably it’s not clear from only describing it… just like Morpheus said, you have to see it for yourself. It’s extremely flexible and powerful, simply brilliant. Everything is built around that system. Sorry if I sound like a fanboy. But this is something really outstanding, unmatched by anything I’ve seen before. Too bad no one mentions it.
UE is a first person shooter engine with a good renderer that wants to become more. There are Actors, then Pawns, then Characters, each of them C++ like abstractions you would expect in an FPS scenario. There are templates for 3rdPerson and FirstPerson. If you think about it, what’s different between FP and 3rdPerson? Camera is different and that’s it. But in UE the FP template has an ‘arms only’ mesh, a gun and you can shoot. This is what FP is for UE, a First Person Shooter. They think very much in the FPS box and try to add more systems around their FPS Shooter to appear like a generic game engine. But they aren’t.
Exporting stuff to another project:
As already said, impossible (for me) in UE, a breeze in Unity (tried it).
Coding- workflow:
If you dare to get out of your little C++ box, there is much to discover in C#. Things like giving a callback function as a parameter is a breeze, almost as simple as in JavaScript. In C++, that’s simply syntax hell. This is why people use objects for this purpose since centuries in C++. This inflates your code. Though it’s so easy in C#, it changes your coding style, allowing you to write easy to read and easy to maintain code.
Coroutines are another killer feature in Unity. They used some C#-Enumerator system and turned it into coroutines. This is a topic by it’s own, just let me say that you can replace all this behaviour tree mambo jambo with a few simple functions. Also allows for lots of other stuff, i’m on a learning curve here, too.
Compiling in Unity takes between 1 and 10 seconds, with an average of 2 seconds. Compiling in UE takes between 1 second and one minute, with an average of 30 seconds if you change a C++. If you change a header, well…
That’s because UE uses a tool to precompile your headers. You cannot do this by your own. So using precompiled headers cleverly gets you nowhere. UE doesn’t care about your *.sln. It compiles everything in your /Source folder.
For me as a coder BP’s mean annoyance. I can do the same easily in C++ without dragging funny boxes around. As it gets more complicated, BP’s really look like worst spaghetti code…
Well, if you understand this you should work in theoretical physics.
Where UE shines is the future. They really (atm) listen to their community and are improving rapidly. That’s a big catch in Unity. You get the feeling that Unity concentrates on marketing and ‘checkbox’ features to promote their product. They don’t improve what is already there and make it more usable. From what i’ve read in the internet this is also because their base technology is C++ and the project grew to big to be properly maintained. Don’t know if this is true, but it lets alarm bells ring in my head. I’m used to work with big C++ code bases and if people begin to understand they cannot maintain it anymore it is usually too late… project dies. Hope they find a solution.
Saying all that, working with the sub systems is the biggest part with both engines. You need all this navmesh stuff to let your characters run around. You need the UI system to present… well… the UI. Both engines delivered only a fraction of what i expected from the marketing (except the Unity UI). My experience here is too limited to have a clear choice, meaning i didn’t touch too many systems.
I would recommend UE to make a shooter and Unity for anything else. But may both engines live long and prosper… we don’t need a monopoly here.
Only my 2 cents… i don’t want to offend anyone.
For someone with 15+ years of pro experience, you sure don’t seem to know what you’re talking about.
I’m hearing the same regurgitated nonsensical ******** in your post that I see from Unity fanatics…such as implying that UE4 is somehow a “Shooter-only” engine and Unity does it all! I laughed out loud when you mentioned 4.6 uGUI. UE4 UMG is far more complete, less buggy, and better integrated with the UE4 workflow.
You sound like you still have that UE4 beginner mentality that Blueprints are some how “cheap” and should be avoided at all costs because you’re a “real programmer”
Well… thanks for your kind words.
BPs are a good thing if you are not used to programming. I know an artist who really got useful stuff going with it. Also saw a few very good tutorials how to use them in level design. Pretty useful. Not complaining about BPs, they are great, but not for me.
Edit: Poster deleted his post.
Edit2: He didn’t delete it… only by blind eyes 
BPs are very good for prototyping without turning your C++ classes into spaghetti code. It’s very clear that BPs are the “backbone” of the UE4 workflow and should be embraced, not fought against. Even many classical programmers are coming to their senses about visual scripting. There is nothing superior about refusing to let go of or change old practices.
BP’s are also not the superior solution for any problem. Most code out there is not C++. C++ is good for performance critical stuff. C# is better for logic. Different languages for different purposes. This is why they exist. BP is good for game logic, but it’s bad for e.g. algorithms. There is no one fits it all in coding.
UE4 is “young” in the same way that Unity 5.x is “young” – they both build on earlier versions of very mature engines.
Unreal shipped a major, AAA, game, before Unity even existed.
That being said, of course there are differences. And, if you’ve spent years learning and adapting to a particular engine, of course a transition would be expensive.
However, don’t listen to the mis-information from those who have only used one of the engines.
For example, callback functions in C++ are very easy to write:
void my_function(SomeObject * obj, int someArg) {
obj->installCallback(&](Whatever *what) {
what->do_the_thing(someArg);
});
}
This is no more syntax than in C#.
like half of Steam Greenlight or Early Access for example.
To be fair, “git diff” on a blueprint is not helpful, and “git merge” is even less so.
That could perhaps be fixed with a textual representation of the blueprint actions/nodes.
Also, visual programming falls down when you need modularity in a large code base.
Blueprints are great for what they’re designed for: Building game logic for level designers, within an engine dedicated to supporting them.
Blueprints are not great for general-purpose programming.
Why is unity so popular?
Because popped collared salesmen and Microtransactions
I really wouldn’t compare UE4 C++ to standard C++. It is much more akin to a “scripting” language than just “pure” C++, it manages so much more for you. What BP’s are really useful for, in your example, is implementing complex algorithms or behaviors in C++ and then wiring them together in BP. For me, as a programmer, BP’s can be a godsend as they provide me with another mechanism to separate responsibilities in a clear and concise way.
Then there is also the UE4/BP beginner who just hooks up all functionality they can dream off in a BP and complain that BP’s are a mess. Through the years I have, arguably, seen code that is a bigger mess than the BP spaghetti picture from your earlier post.
This is a good point. I can clearly see what you mean. Level designer needs some some stuff from you in C++, you expose it as BP and he uses it in his BP logic chain. Makes perfect sense to me. Just wanna say that in my first post i talked from a ‘lone programmer wolf, try it out with coding’ perspective. The post is not a final verdict, it is written from a very personal point of view. If you work in a team you are completely right. Gonna try to make this more clear.
As a “lone wolf programmer” it’s often useful (not always) to sort your logic out in BP and then re-build it in C++. This is one reason it is said to be a good tool for prototyping. You can build some base systems that communicate with each other very quickly in BPs without dealing with stuff like C++ compilation. Assuming you know the API and your C++ isn’t rusty (like mine is), it’s pretty easy to re-built that logic in C++.
I’ve used Unity3D and UE4 for some time and this is my take.
Unity is a bare bones engine, to the point you can barely call it a game engine.
There are pros and cons to it.
pro:
being bare bones (with some game API throw in), you can make any type of game without modding the code too much
con:
if you want to just make a working game, you have a lot of coding to make that happen.
it might take you time to learn common game conventions, like having a game controller or how to properly setup multiple levels.
UE4 is a GAME engine with components and modules that make it easy for any non programmer
pro:
non programmer can do a lot of things you’d need a programmer to do, i.e footsteps, anim notify, and now procedural mesh slicing
con:
You have to rework some things that seem basic, i.e static camera(because that doesn’t come out of box)
If you are a programmer and worked on games using “old school” methods using c++, java, etc., then Unity works for you since it has a graphical interface as a pro
If you haven’t, then UE4 is really good learning tool.
BUT
to answer the question:
-easy to use
-works on lower spec systems
-easily outputs to many builds, including popular mobile devices.
I think Unity is popular is due to the fact that it’s more mature and established compare to UE4. It also supports wider range of platforms than UE4 and they all happen to work. UE4 seems to work well on PC and consoles only.
Asset Store for Unity has more goodies (which is again related to the age of the engine), which helps attracting indies.
Another point toward Unity is that Unity Corp. doesn’t work on any games. All they do is work on the engine and surrounding services. Epic also makes games, and thus spread very thin. Because of that engine (and engine support) suffers a lot, especially mobile / VR platforms and features that are not used in Epic’s games.
A lot of folks already created infrastructure around Unity, so switching engine isn’t an option for them.
These are the factors that make Unity more attractive, IMO.