next »

[ElusiveDangus]

So i was talking to my friend the other day about unity vs unreal, and he was saying that unreal was no question the better option for 3D games, but a much inferior option for 2D games. After doing a minuscule amount of research i think i agree with him.

What do you think?

[Polly]

Apples & oranges .. it really depends on your project & preference which one of the two would be the best fit.

[InfiniteStateMachine]

Yeah this is not a really useful comparison. Too many external factors like what the game project is, what your team already knows etc.

[RustyFist]

Though the statements made above totally ring true, I would put forward my two-cents on the question. As someone who's been using Unity now since v2, has dabbled in UE4, and have many colleagues using both, I would break down the decision-making matrix thus:

UE4's greatest two strengths are its out-of-the-box aesthetic quality (relevant primarily to 3d games), and its visual scripting system called blueprint. If one includes the Unity Asset Store, Unity can provide close equivalencies in both of these categories, but will require both an outlay of money to buy UAS products, and some DIY spirit/experience.

The trade-off however, is that if one doesn't possess the background of a crack C++ programmer, you will be limited to the functionality of the blueprint system, and what custom blueprints you can find among the community. The skill-curve jump from 'using blueprints' to 'making blueprints' is significant.

Unity's advantage in this regard is that one can making fairly complex things with next to no programming background, and the process of learning to make more and more complex things is a much more smooth/gradual one. With Unity, you have javascript and C# to pick from, but MUCH more importantly, Unity's API is significantly more robust than UE4s. When I started with Unity 2, I was a capital-A-artist who knew a touch of python from college. Now there's not much that scares me code-wise. I'm certainly biased in this regard, but I think Unity is a simply unmatched platform to _learn_ how to make games using.

Simply put, Unity is designed to _not_ require source-code access, and so the sheer volume of helper/accessory/utility functionality that has been filled out is much greater. Couple the asset store with this, and if you can think of a problem-space, someone has probably already built a system to address it. It may not be ace-level, but it will at least be something usable/that can be built upon/learned from.

Additionally, Unity has been built around a component-based model (compared to UE4's much more classically insanely polymorphic model). In laymans terms, all of Unity's functionality is significantly more 'kitbashable'. It doesn't enforce a design/usage pattern on you. Granted, this means that it takes a great deal more careful work to really SCALE a game, but for small/mid-size projects (be they games, arch viz stuff, etc.) its much more nimble, flexible, faster to iterate on.

Unity has its problems as an engine, some of its systems are in perpetual WIP in a really shitty way, it is not terribly fast for really high fidelity stuff, its serialization system blows goats for quarters, but I can't imagine personally ever giving it up.

Also of relevance, being part of a contract studio, and being used to budgeting whole projects, I will put this out there. Whatever it is you want to make, big or small, if you're doing it in UE4, you'll need 3x+ the budget. The asset workflow is more cumbersome, it simply burns time. C++ programmers are more expensive than C# folk typically, and there'll be a larger volume of code that has to be written on the UE4 side typically. This doesn't mean UE4 is 'worse', as in many ways it is a more powerful engine, and you have the ability to fork and _deeply_ modify its source code if you need such a thing, but its clearly more expensive to utilize (as is cryengine, likely it's weird new sibling lumberjack, and unigine).

To give you a flippant conclusion to this, I would say this:

If you're making a visually high-end game, especially one you want to bring to xbone/ps4, are a C++ programmer, need massive terrains, or are making a game that you are certain you can top-to-bottom build out with a visual scripting language, give UE4 a shot.

For almost everything else, I'd give Unity the recommendation.

[InfiniteStateMachine]

Additionally, Unity has been built around a component-based model (compared to UE4's much more classically insanely polymorphic model). In laymans terms, all of Unity's functionality is significantly more 'kitbashable'. It doesn't enforce a design/usage pattern on you. Granted, this means that it takes a great deal more careful work to really SCALE a game, but for small/mid-size projects (be they games, arch viz stuff, etc.) its much more nimble, flexible, faster to iterate on.

This is straight up not true. Unreal has a fine component model, I'd say it's a lot easier to reason about work with than Unity's. You CAN use an inheritance based model but you could also do that with unity.

disclaimer : I have hundreds of hours on both engines. Probably more with unity (but that should change soon).

[RustyFist]

@InfiniteStateMachine Perhaps I didn't make my point with enough nuance. I didn't mean to state that Unreal doesn't have components. What I meant to say is that the each engine has their primary DNA/design pattern. UE4 has components, and you can certainly take a very component/composition approach to authoring with it, but that doesn't change the fact that its WAY more hierarchical in its base classes-structures than Unity is. I wasn't in any way implying this to be a negative quality. It's a lot more to deal with though if you're building new class definitions that inherit anything from this structure.

[InfiniteStateMachine]

@InfiniteStateMachine Perhaps I didn't make my point with enough nuance. I didn't mean to state that Unreal doesn't have components. What I meant to say is that the each engine has their primary DNA/design pattern. UE4 has components, and you can certainly take a very component/composition approach to authoring with it, but that doesn't change the fact that its WAY more hierarchical in its base classes-structures than Unity is. I wasn't in any way implying this to be a negative quality. It's a lot more to deal with though if you're building new class definitions that inherit anything from this structure.

That's still not true. That was maybe true 2+ years ago in the UDK/Urnealscript era.

If I make a new object in unreal it's either 1 level or inheritance from uobject with a ton of components or 2 levels of inheritance from aactor with a ton of components. Unity derives from gameobject with a ton of components. Uobject is a much cleaner interface with less data than gameobject as well so you are inheriting less behavior (edit : this may be out of date knowledge, I'm speaking from the 4.0 era of unity).

So in almost every case they have the same level of inheritance.

EDIT : Unity gameobject actually inherits from object so actually both engines generally have the exact same depth of inheritance when making new objects.  http://docs.unity3d.com/ScriptReference/GameObject.html

[RustyFist]

Huh.. fascinating. Point rescinded then. I was not aware that the method of interaction had changed so significantly since UDK (last time I dove deeply code-wise into unreal-land). My experience with UE4 has almost entirely been on the asset/content-workflow side of things, with a bit of tinkering with everything else. Thanks for the clarification!

[InfiniteStateMachine]

No worries. Up until Unreal 4+ the engine was a giant inheritance nightmare. They have a lot of work to do to let people know that they've moved on to a more composable workflow.

That actually brings up a good point. Unreal is not shy about making profound breaking changes in order to make the engine cleaner. That means that it can often not be very simple to port your project to a newer version sometimes depending on the changes across major versions.

[BigHandInSky]

Out of curiosity RustyFist/InfiniteStateMachine, how is the UI handled in Unreal 4? I haven't had a chance to look through it's documentation fully and was wondering how the workflow is compared to Unity's new uGUI system which has been growing on me a lot the past few versions.

[InfiniteStateMachine]

Slate is their multiplatform GUI library which the editor and everything is made with and then there's UMG which is a higher level usage of Slate which would be like their version of scaleform. https://docs.unrealengine.com/latest/INT/Engine/UMG/

I'm no professional UI artist so I can't really comment too much on how powerful it is but it's very functional. I've been able to do most of the work I need to do without checking docs or reference material. My guess is most professional UI artists will still want scaleform/iggy + flash.

I haven't used uGUI since with Unity there's always been some plugin that handles ui like nGUI or Coherent so I couldn't give you a comparison.

I actually LIKE the old Unity immediate mode ui framework. It wasn't pretty but man it was easy to use

[BigHandInSky]

Slate is their multiplatform GUI library which the editor and everything is made with and then there's UMG which is a higher level usage of Slate which would be like their version of scaleform. https://docs.unrealengine.com/latest/INT/Engine/UMG/

Damn that's a lot of tutorial right there, seems like Epic have stepped their tutorial game up since I last checked it (Although looking at Lumberyard's documentation makes anything else be a standout right now).

I actually LIKE the old Unity immediate mode ui framework. It wasn't pretty but man it was easy to use

I remember a couple years back trying to mess with Unity's old framework and just screaming off back to making bullets bounce around with the physics, in hindsight I think it was the lack of a good anchor system that constantly threw me off it (Although the current iteration has a lot to be desired with handling anchors in scripting).