Comprehensible guide to choose between Unity and Unreal Engine

Because choosing the right tool for the job is a good first step!

Disclaimer: I'm not a professional game developer but I work with code and have been using them for a long time. This article is a technical assessment of both engines from my PoV.

Longstory short:

If you are solo developer use Unity, if your team has 10+ profiles with different attributes Unreal Engine, if you are a solo artist (and don't want to lear programming) you're screwd, otherwise read the whole article.

The (probably) most common question in regards to how to start with game development is what tool to use. Nowadays Unity and Unreal Engine are by far the two most popular game engines with Godot and Game Maker considered as far-off alternatives. Lots of AAA and Indie Games have been released using Unity or Unreal Engine, but enjoying a game built with an engine is not the same as enjoying that same engine.

Both tools were developed and are maintained with very different approaches and with very different goals, choosing the right one is not an option. Hammering a nail should be quite difficult if you are using a saw, right? IT tools work alike.

First of all, both engines are (mostly) aimed to be as generic as possible. Some engines like RenPy, or the Doom Engines were developed for building games for a specific genre. This is a to bladed sword, on one hand, you can build whatever your heart desires, on the other, it's gonna take time to develop the game subsystems (like dialog, progression, advanced physics (to some extend)… ) .

Unreal Engine

Let's continue explaining the Unreal Engine experience. It's over the top. It's an engine for bleeding edge, AAA games and you can guess it for the look and feel the first second. (Almost) Every project starts from a template based on the game mode you want to implement.

Unreal Engine is massive and have plenty of tools with plenty of uses: level editor, Blueprint editor, Animation Blueprint editor, a custom build tool, UI (Unreal Motion Graphics, UMG) editor, Static Mesh editor… You are bound to find a tool for yourself and for your profile.

From a programming standpoint it is possible to see, UE4 uses a lot of object oriented patterns. Everything that is part of the engine is a UObject, everything that can be spawned into a level is an AActor, everything that can be played as (Possessed in UE4 jargon) is an APawn, if you want that pawn to have an skeletal mesh you need an ACharacter. Looks simple, but there are more than 100 classes that can be inherited from, this means you need to understand a lot of the engine beforehand.

One of the most powerful tools of Unreal Engine is its custom Programming language, Blueprints. Blueprints are visual scripts that directly connect to the engine, can inherit C++ and do not need to be compiled. Each blueprint is an object, that means you can store data in them via member variables (AKA Cpp atributes). There's also a bunch of types of Blueprints for different means, there's generic BP, AI BP, Animation BP, Physics BP…

Example Blueprint from an official Scripting Tutorial.

Speaking about Cpp, is not a good idea to build gameplay tools with it. Unreal Engine uses a dialect of Cpp that is quite resemblant to the way wxWidgets apps were programmed, that means lots of custom macros with lots of attributes, adding tons of features.

Code sample from the UE forums. Lot of macros, plenty.

The Cpp runtime implements a garbage collector for UObjects and classes that derive from it. Also forbids their instantiations outside of the GC, every object must be instantiated using the function NewObject<Type>(args). This transforms C++ into an odd (and ugly) version of C# that runs twice as fast.

On a personal level, I only recommend using Cpp to build engine tools. That means, avoid this language when building application tools. If you need the extra performance you may want to nativize your Blueprints.

Summary in bullet points:

What makes it unique:

• Works better for teams with different profiles since there’s a tool for everyone.
• Is designed for bleeding edge, state of art games but can be downscaled to build discreet graphics games.

Pros:

• The visual scripting language may help teams with few (or zero) programmers to build their games.
• If you want to embed a C/C++ library is going to take time but it's possible to do so.
• Has the best toolset of every free-to-use game engine.

Cons:

• Requires a lot of time to learn.
• Not very well integrated with git.
• It's overwhelming for solo and new developers.

In the end, UE4 is a professional engine, you can build your whole career around it, at least nowadays. The most downside come from the fact that you need to build a career to use UE4 to its full potential.

Unity

On the other hand, Unity is way more kind at first sight and for a good reason. It was develop in order to offer an easy approach to game development, but time has passed and Unity tooling has come a long way.

Project template exist in Unity, but are not as In your face as they are in Unreal Engine, they consist mostly on a pre-built minigame of the genre you choose. Subjectively, I believe you are not loosing anything if you just start a Unity project from scratch.

Unity's approach to level and system design are more simple, everything that is deployed to a level is a GameObject. These game objects organize themselves in a tree-like manner in the level, a game object can be a father or a child of a a game object or a child of the Scene (Unity's word for Level).

Example of a scene hierarchy from unity docs.

Game objects have Components attached. Every game object have at least a component of type Transform and may have more. Examples of these components are 2DRenderer, 3DRenderer, Colliders and custom Behaviours. This may look hard to digest, but is quite an intuitive approach, since you can access any GameObject or Component from the editor at runtime and as an Attribute in you behaviours.

In order to create a custom behaviour you just need to create a file that inherits from the class Unity.MonoBehaviour and you're ready to go! Attach the file to a game object and it will run. This behaviours work like Unreal Engine's Actors, they have a life-cycle that execute a bunch of methods that can be overridden. Quite event-oriented if I may say so. These behaviour class can be inherited from both, UnityScript (JS runtime for unity) and C#, but most people use the latter for type safety, ease of use and performance.

From a question at Unity Hub. Behaviour attributes are serialized into the editor.

Outside of programming, Unity also has a bunch of tools for animation and AI. They many not contemplate as many cases as the Unreal equivalent but for the average or more repeated cases it gets the work done and it does it fast.

Summary in bullet points:

What makes it unique:

• Modular approach to everything, from engine installation to game release.
• Focus on simplicity over features.

Pros:

• Smoother experience, everything just work out of the box.
• Low chance of being overwhelmed, complex tools for complex tasks, easy tools for everyone.
• The absolute best build system for portable devices like Android an iOS.

Cons:

• Lack of maturity in advance tooling.
  - Example of this is the visual scripting tool. Can be used, but in order to develope a full-fledged game you'll need to write code.
• Interfaces (OOP interfaces, not UI interfaces) can't be serialized in the editor, this will lead to sub-optimal design decisions.
• Can't get into the 'guts' of the engine since it's closed source, denying the possibility of extending the engine with custom systems or Cpp libraries.

I'm always agains Unity because it encourages some ill practices and is not as mature as Unreal Engine, but I always end up using it for personal projects because, for me, is way easier to prototype things this way. Being honest with myself, Unity is as good of an option as any other engine