You have written C# for Unity's MonoBehaviour scripts and C++ for engine-level code in earlier chapters. This chapter puts two real, commercial engines side by side: Unity and Unreal Engine (often shortened to just "Unreal" or "UE"). Both are used to build real, shipped games. The question is not "which one is better" — it is "which one fits the job you want, and how much does switching between them actually cost you."
This is a comparison chapter, not a full re-teach of either engine. If a term looks new, it is explained the first time it shows up. By the end you should be able to read a job posting that says "Unity/C#" or "UE5/C++" and know exactly what kind of day-to-day work that implies.
A game engine is the software that already solved the hard, repeated problems — rendering pixels, playing sound, handling input, running physics, loading assets — so you can focus on your game's own rules. Unity and Unreal both do this job. Neither one is "the trick" that makes a game good; each is the workshop you build the game in.
The two engines make different trade-offs almost everywhere: what language you write, how a brand-new project looks before you touch anything, which platforms they are tuned for, and who tends to hire for which one. None of these trade-offs are about raw capability — both engines can technically ship a mobile gacha game or an AAA console shooter. The difference is which path is the well-paved one.
In Unity, almost all gameplay code is C#. You write a script, attach it to a GameObject (an object placed in the scene) as a MonoBehaviour (the base class Unity scripts inherit from), and Unity calls specific methods on it at specific moments — Start() once, when it first enters the scene, Update() every single frame.
using UnityEngine;
public class Health : MonoBehaviour
{
public int maxHP = 100;
private int hp;
void Start()
{
hp = maxHP;
Debug.Log("Health ready: " + hp + " HP");
}
public void TakeDamage(int amount)
{
hp -= amount;
if (hp <= 0)
{
Debug.Log("Character died");
}
else
{
Debug.Log("HP left: " + hp);
}
}
}Calling TakeDamage(30) and then TakeDamage(90) from another script prints:
Health ready: 100 HP
HP left: 70
Character diedIn Unreal, the same idea exists but the tools split into two layers. C++ is the language for the engine itself and for performance-critical or foundational gameplay code. Blueprint is a visual scripting layer — you wire up logic by connecting nodes instead of typing text — and it compiles down to real bytecode, not a toy. A common studio pattern is: engineers write C++ "building blocks" and expose them, then designers wire those blocks together in Blueprint for fast iteration on gameplay feel.
Here is the same Health idea in Unreal C++ (a real project splits this into a .h and a .cpp file; shown together here to save space):
#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "HealthActor.generated.h"
UCLASS()
class AHealthActor : public AActor
{
GENERATED_BODY()
public:
int32 MaxHP = 100;
void TakeDamage(int32 Amount);
protected:
virtual void BeginPlay() override;
private:
int32 HP;
};
void AHealthActor::BeginPlay()
{
Super::BeginPlay();
HP = MaxHP;
UE_LOG(LogTemp, Log, TEXT("Health ready: %d HP"), HP);
}
void AHealthActor::TakeDamage(int32 Amount)
{
HP -= Amount;
if (HP <= 0)
{
UE_LOG(LogTemp, Log, TEXT("Character died"));
}
else
{
UE_LOG(LogTemp, Log, TEXT("HP left: %d"), HP);
}
}Calling TakeDamage(30) then TakeDamage(90) prints the same story, just to Unreal's Output Log instead of Unity's Console:
LogTemp: Health ready: 100 HP
LogTemp: HP left: 70
LogTemp: Character diedSame logic, same result, different syntax and a different macro system (UCLASS(), GENERATED_BODY(), UE_LOG) wrapped around it. A designer who never opens that C++ file could build the exact same BeginPlay behavior visually:
Day to day, this changes how you work. In Unity you are almost always writing C#. In Unreal you constantly switch hats: C++ when you need raw performance or a reusable system, Blueprint when you are iterating quickly on gameplay feel.
Create a brand-new, empty project in each engine and look at the default lighting. The difference is immediate.
Unreal's default renderer includes Lumen (a system that calculates realistic bounced light in real time, without you baking anything by hand) and Nanite (a system that lets you use film-quality meshes with huge amounts of detail, without manually building simplified versions for distance — those simplified versions are called LODs). Together they mean a new Unreal scene looks close to photoreal (short for photorealistic — close to a real photograph) almost immediately, which is a big reason Unreal shows up so often in cinematics and film/TV virtual production.
Unity does not ship one fixed high-end renderer. Instead you choose a Scriptable Render Pipeline (SRP, a swappable rendering system): URP (Universal Render Pipeline — light, fast, tuned to run on everything from a flagship PC down to a mid-range phone) or HDRP (High Definition Render Pipeline — heavier, aimed at high-end PC/console visuals, closer to what Unreal gives you by default). A new Unity scene starts plain, and you build the look up from there.
Neither approach is strictly "better" — they are optimized for different goals. Unreal optimizes for looking great with less manual tuning. Unity optimizes for control over performance, which matters enormously when your target is a three-year-old phone, not a gaming PC.
Both engines can technically export to almost any platform — phone, PC, console, web. But "can" and "is tuned for, by default, with the least fighting the engine" are different questions.
Unity's lighter default footprint and long history on mobile hardware make it the practical default for games that must run well on a five-year-old phone with a small battery — which describes most of the mobile live-service market (games that keep shipping new content on an ongoing schedule, rather than being released once and left alone). Unreal's default visual power and console tooling make it the practical default for a game whose whole pitch is "look at this."
You can see the platform pattern in real, shipped games:
This is exactly why "which engine should I learn" has a different answer depending on the target. HoYoverse's entire shipped catalog runs on Unity. A big-budget console shooter studio is far more likely to be running Unreal. Indie studios split roughly by genre and ambition — a small 2D or stylized 3D game usually leans Unity; a small game chasing a cinematic look usually leans Unreal.
For a first-time engine learner, Unity is usually the gentler on-ramp. C# is a managed language (the runtime handles memory for you — no manual bookkeeping of allocation and freeing like raw C++), a script is a single file, and Unity recompiles it automatically in a few seconds every time you save.
Unreal's C++ side is heavier: bigger project setup, longer compile times for large changes, and a much larger engine codebase sitting underneath your own code. That is a real cost while you are still learning. But Unreal softens this with Blueprint — a lot of a first learner's early experiments happen entirely in the visual graph, with no C++ compile step at all.
This is also where your earlier chapters pay off. If you already fought through pointers, the stack vs the heap, and undefined behavior in the C chapters, Unreal's C++ is far less intimidating than it is for someone meeting C++ for the first time inside a giant engine codebase.
Here is the single most useful fact in this chapter: underneath the different names, Unity and Unreal use the same core shape. Something exists in the world as an object; that object holds components that give it data and behavior; those components run their own code at fixed lifecycle moments.
Look back at the Health example in section 2. Start() and BeginPlay() are the same idea with a different name: "run this once, right when I show up." MonoBehaviour and AActor are both "the base type a thing-in-the-world derives from." A Unity Prefab (a saved, reusable template — build an enemy once, stamp out ten copies) and an Unreal Blueprint Class (a class you build visually, then place many instances of) solve the exact same problem: define this once, reuse it everywhere.
This means learning one engine deeply is not wasted time if you later need the other. You are not starting over — you are relabeling a shape you already understand. The genuinely new part of switching is the tooling and syntax (a C++ compile step, a node-graph editor, different menu names), not the underlying ideas.
Putting the last six sections into one table:
Nothing in this table is a permanent law. Unity ships high-end HDRP games; Unreal ships lightweight mobile titles. Read it as "where the well-paved path leads," not "what is physically possible."
Given everything above, here is the practical split:
If your target is HoYoverse specifically (or a similar mobile-first, live-service gacha studio) — go deep on Unity and C#. Their entire shipped catalog runs on Unity, so this is not a guess, it is literally their stack. Prioritize: solid C# fundamentals (which you already have from earlier chapters), URP, mobile performance and profiling, UI systems, and the kind of "content that ships on a schedule" patterns live-service games rely on. Time spent on Unreal instead is not wrong, but it is not the efficient use of a focused runway toward this specific goal.
If your target is broad AAA, or you genuinely do not know which studio yet — learn both, but not at the same time and not to equal depth on day one. Start with Unity. It is the gentler on-ramp, and because of section 7, everything you learn about the GameObject/Component/lifecycle shape transfers directly. Once that shape feels natural, move on to Unreal's C++ and Blueprint. You will spend your time learning new names and new tools, not new concepts, so the second engine should go noticeably faster than the first one did.
public class Mover : MonoBehaviour
{
public int distance = 0;
public int speed = 4;
void Update()
{
distance += speed;
if (distance > 10)
{
Debug.Log("Reached checkpoint at distance " + distance);
}
}
}MonoBehaviour and the Unreal equivalent of Update().
(b) Update() runs three times in a row (three frames). List what, if anything, prints after each frame.
(a) The Unreal equivalent of MonoBehaviour is AActor (the base class a placeable "thing" derives from). The Unreal equivalent of Update() is Tick() (runs every frame).
(b) Frame 1: distance becomes 4. 4 > 10 is false, nothing prints. Frame 2: distance becomes 8. 8 > 10 is false, nothing prints. Frame 3: distance becomes 12. 12 > 10 is true, so it prints Reached checkpoint at distance 12.
Nam should go almost entirely Unity. HoYoverse's shipped catalog runs on Unity, so this is not a bet — it is matching the actual stack. Since Nam already knows C# well, the year is best spent on Unity-specific skills: URP, mobile performance and profiling, UI systems, and live-service content patterns. Spending significant time on Unreal instead would not be wrong in a general sense, but it does not move Nam closer to this specific goal, so it is not the efficient choice.
Ploy should learn both, in sequence, not in parallel. Start with Unity for the first few months — it has the gentler learning curve and, per section 7, teaches the exact same GameObject/Component/lifecycle shape that Unreal uses under different names. Once that shape is second nature, spend the remaining months on Unreal's C++ and Blueprint, since AAA console/PC roles skew Unreal more often than Unity. Because the underlying concepts already transferred, this second half should move faster than the first — Ploy is mostly learning new names and new tools (a C++ compile step, the Blueprint graph editor), not new ideas. A rough split might be 40% of the year on Unity first, then 60% on Unreal once the fundamentals are automatic.
The honest summary: Unity and Unreal are different toolkits built on the same underlying idea. Pick the one that matches where you actually want to work, go deep there first, and treat the other engine as a lookup problem for later — the object, component, and lifecycle model you already know will still be there, just wearing a different name.