Module 5 · The HD era and indie (2005–2012)

Engines: Unity / Unreal / Godot

An engine is not "a program for making games" but a ready-made set of a thousand solved problems (the loop, rendering, physics, the pipeline, an editor, builds for every platform) plus a business relationship with a supplier. The engine you choose sets your graphics ceiling, your platform reach, who you hire and how dependent you are on a vendor.

~17 min🛠 engineering + 💰 business

The gist in 30 seconds

An engine sells you not a renderer but an editor and a pipeline — a thousand already-solved problems (the game loop, physics, asset import, scenes and components, input, builds for 10 platforms) so you do not write them from scratch. The three dominant ones in 2026: Unity (C#, the component-based GameObject model, a huge Asset Store, king of mobile and indie 3D; the business model is a per-seat subscription), Unreal (C++/Blueprints, AAA rendering: Nanite geometry + Lumen GI, the best image and the best virtual production; the business model is a royalty of 5%→3.5% on revenue above $1M), Godot (open source, MIT, GDScript/C#, lightweight, a scene tree, strong in 2D; the business model is free forever, the engine is yours). The choice is buy vs build plus vendor dependency: the Unity Runtime Fee saga (Sept 2023 → canceled Sept 2024) showed that an engine is a supplier that can rewrite the terms retroactively. Godot took off afterwards: its share at the GMTK Jam went 19%→37% in a year.

The mechanism: what an engine is and what you are choosing between

In modules 1–4 you assembled the primitives by hand: the game loop, fixed-point, collisions, netcode. An engine is a box where all of that is already done and wired into an editor. What it actually gives you:

The runtime: the game loop (that one, hidden behind your Update()), the rendering pipeline, physics, audio, input.
The asset pipeline: importing models/textures/audio, atlases, compression, per-platform formats.
Scenes and entities: a tree of objects plus components/nodes, level serialization, prefabs.
The editor: viewport, inspector, profiler, debugger — this is the actual product, not the renderer.
Builds and deployment: one project → PC, consoles, iOS, Android, web. Porting is the most expensive task an engine takes off your hands.

So "write your own engine" ≠ "write a renderer": a renderer takes weeks, while the editor plus the pipeline plus the platform ports plus years of polish is where the cost is. People write their own for control or extreme performance (id Tech, Decima, RE Engine), but few can afford it.

Three engines — what each one gives you

Axis	Unity	Unreal	Godot
Language	C#	C++ + Blueprints	GDScript / C# / C++
Model	GameObject + components	Actor + components, a Blueprint VM	a node tree (scene tree)
Strong at	mobile, 2D/3D indie, prototypes	AAA 3D, photorealism, film/virtual production	2D, lightweight projects, control
Image	mid-to-high (HDRP)	top (Nanite, Lumen)	growing, 3D still weaker
Business model	per-seat subscription (Pro ≈ $2k/yr)	3.5% royalty above $1M	$0, MIT, fork it
Vendor risk	high (Runtime Fee)	medium (Epic holds its terms)	none (the engine is yours)

A framework for choosing — five axes

You do not choose an engine by "which is best" but by the job, along five parameters: (1) the graphics ceiling — do you need photorealism or 2D pixels; (2) platforms — mobile/console/web; (3) the team — who you have and what they know (C# vs C++ vs nothing); (4) budget and money model (a fixed subscription vs royalties vs zero); (5) control and risk (are you willing to depend on a vendor who can change the terms). The decision is made early and expensive to change — moving between engines means rewriting nearly everything.

A worked example — who pays less

Engine money is counted differently in each case, and the crossover is not obvious. Unreal takes a royalty only on revenue above $1M (after the 2025 reduction the rate is 3.5% for games shipping on the Epic Games Store):

C_{UE} = 0.035 \cdot (R - 1 M $) when R > 1 M $

A game grosses $3M. Unreal: 0.035·(3−1)M = $70k (once, and $0 until you pass the million). Unity: the subscription does not depend on revenue — say 5 seats × ≈$2,000/year = ≈$10k/year for the whole of development, whether you sell $0 or $30M. Godot: $0. The takeaway: royalties are good when revenue is modest or you have one big hit (you pay out of success); a subscription is good at large volumes (a fixed cost against enormous revenue) but hurts if the game flops — you pay anyway; open source removes the money axis entirely and puts everything onto "you are your own support".

🕹 Games to play — and what to notice

You can spot the engine from the splash screen, the credits or the SteamDB tag. Play one title per engine and notice the correlation between engine ↔ genre/image — it is not an accident: the tool decides what is easy to do.

Unity Hollow Knight · Cuphead · Cities: Skylines · Among Us

The home of indie and mobile. One C# codebase runs on PC, consoles, iOS and Android; the Asset Store covers what the team does not have time to build. Hence the avalanche of 2D/3D indies and mobile hits (Pokémon GO is Unity too).

🎮 Play: launch Hollow Knight or Cuphead and notice the "Made with Unity" splash at startup. Then open the Technology tab on SteamDB for any game — the engine is listed there. Estimate how many games in your library are Unity; it is almost always the indies and the mobile ports.

Unreal Fortnite · FF7 Remake · Black Myth: Wukong · Clair Obscur: Expedition 33

For when you need the image. Black Myth: Wukong (2024) and Clair Obscur: Expedition 33 (2025) are the showcase for UE5: Nanite carries geometry of millions of polygons with no hand-made LODs, Lumen computes dynamic light with no baked lightmaps. Fortnite is Epic's own flagship.

🎮 Play: load any UE5 game and look for Nanite and Lumen in the settings; toggle Lumen off and on — you will watch dynamic indirect lighting disappear and the scene go flat. Notice the characteristic UE logo on the loading screen.

Godot Buckshot Roulette · Brotato · Cassette Beasts · Dome Keeper

Lightweight, open source, strong in 2D. Buckshot Roulette (2024) is a solo developer's hit on Godot; Brotato and Dome Keeper are indie successes. The engine is entirely yours: you can fork it and rebuild it to taste, with no royalties or subscription.

🎮 Play: run Buckshot Roulette or Brotato — notice how light they are (instant startup, a tiny download). That is the Godot aesthetic: small, responsive, often 2D. Compare the size of the build with any UE5 game (tens of gigabytes).

Deep end · engineering: what is inside an engine and how the three models differskippable

An "engine" is a bundle of subsystems under one editor. Architecturally, the three answer "how do you describe a game object" differently.

Scenes and objects

Unity — GameObject + Component. The object itself is empty and behavior is attached through components (Rigidbody, Collider, your MonoBehaviour). That is composition over inheritance — a direct relative of ECS (Unity DOTS took the idea to a data-oriented conclusion).
Unreal — Actor + Component, plus Blueprints. C++ for speed, and a visual Blueprint graph compiled into bytecode for its own VM — a designer can code without C++. Heavier, but all the AAA tooling rests on it.
Godot — a node tree. Everything is a node (a sprite, a camera, a body), and a scene is a subtree instanced like a prefab. Under the nodes sit "servers" (the rendering/physics server) separating the scene from the low level.

How your code runs

Unity: C# through Mono or IL2CPP (transpiled to C++ for speed and for closed platforms). Unreal: native C++ plus the Blueprint VM. Godot: GDScript (interpreted, tailored to the engine) or C#/C++ through GDExtension. The difference is the performance ceiling and who is able to write the code — which decides the makeup of your team.

The editor is the real product

All three have a renderer that is "good enough"; the competition happens in the editor and the pipeline: how fast you iterate, what the profiler is like, whether there is hot reload, how assets import, how alive the marketplace is. That is why your own engine is expensive not because of the renderer but because the editor and the pipeline have to be built and maintained for years.

Deep end · business: three money models, the crossover and supplier riskskippable

Choosing an engine is also choosing a contract. Three fundamentally different models.

Subscription vs royalty vs open source

Per-seat subscription (Unity): a fixed cost per year regardless of revenue. Predictable; cheap at large volumes; painful on a flop (you pay even if you earned nothing) and it scales with the number of seats, not with success.
Royalty (Unreal): you pay a share out of success and only above the threshold ($1M). Epic is betting on your hit. Excellent for indies and for a single blockbuster; expensive when revenue is enormous (3.5% of hundreds of millions is a noticeable sum).
Open source (Godot): $0, but "free" ≠ "no cost": you are your own support, your own plugins, your own missing features. You pay in time and in the risk of immaturity, not in money.

Supplier risk — the Unity 2023 lesson

On 12 September 2023 Unity announced the Runtime Fee: a charge per install of already-released games, retroactively, above certain thresholds. What blew up was not the amount but the precedent: a vendor unilaterally rewriting the terms on work you have already shipped, and on an uncontrollable metric at that (installs could exceed revenue). Over 1000 developers signed an open letter, a boycott started, CEO John Riccitiello left (Oct 2023), and in September 2024 the fee was canceled and the subscription restored (at raised prices). Godot surged on that wave: at GMTK Game Jam 2024 its share went 19%→37% in a year, and by 2025 it was roughly level with Unity.

The engineering conclusion: the price of an engine is not only money but the vendor's right to change the rules. Open source removes that right (fork it and nobody touches your terms again); proprietary keeps it.

Analogy

Engines are kitchens you rent for your restaurant. Unity is a fully equipped chain kitchen: everything is in place, the pantry of prepared ingredients (the Asset Store) is bursting, but you pay rent — and one day the landlord tried to charge per dish served, retroactively. Unreal is a Michelin-grade kitchen: the best equipment for high-end 3D cooking, but it is heavy, and the owner takes a percentage of the restaurant's revenue above a million. Godot is a kitchen you assembled yourself from an open blueprint: fewer ready-made ingredients, but it is yours forever, it is free, and you can knock down any wall in it.

Why it matters

Choosing an engine is one of the highest-leverage and least reversible early decisions: it sets your graphics ceiling, your platform reach, who you hire, your cost structure and how dependent you are on a supplier. It is not "which is technically cooler" but buy vs build plus dependency management: how much you are willing to hand over for a thousand solved problems, and at what cost in control. The same choice faces an engineer anywhere there is a convenient vendor and an open-source alternative.

🔁 Beyond games — where this transfers

The lesson is buy vs build and vendor dependency risk: take a ready-made platform for speed and inherit its terms, or roll your own for control.

ML / AI (your domain): choosing an engine ⇄ choosing a framework and a model provider. A closed API (OpenAI/Anthropic) = Unity/Unreal: fast, powerful, but the vendor can retroactively change the price, the limits, or deprecate a model out from under you — that is exactly the Runtime Fee for an ML team. Open weights you host yourself (Llama, Mistral) = Godot: more expensive in your own hands and infrastructure, but "the engine is yours" — no rug pull, you can fork it and fine-tune it. PyTorch vs JAX vs your own training loop, CUDA vs a bare GPU — the same axis of "abstraction and convenience versus control and ceiling". The main risk lesson from Unity: when you build on someone else's platform, you are building on its future terms, not only today's.

Software / infra: a framework (React/Rails) vs your own; managed cloud (AWS/Vercel) vs self-hosting — vendor lock-in, switching cost, the risk of changed pricing and ToS.

Business: a SaaS subscription vs revenue share vs buying a license — the same "fixed cost versus a share of success" crossover; supplier due diligence = assessing whether they can rewrite the contract out from under you.

The principle: dependency is not today's price but the counterparty's right to change the rules tomorrow. Count not only the cost but the reversibility and who holds the switch.

🔧 Run it and poke at it — on your home machine

What to play is above (🕹). This part is about opening an editor and seeing "engine = editor + scene + components" with your own hands.

🔧 Poke at it (debug) ~40 min, Godot or Unity

Download Godot (free, ~50 MB, no account) and open any demo project. Expand the scene tree and add a sprite plus a CharacterBody2D plus a script — you will see the composition of "node + components + behavior". Compare with Unity: the same object is a GameObject with components attached in the inspector. Find the game loop: in Godot it is _process(delta) and _physics_process(delta) — literally the render tick and the physics tick from the first lesson, now spun by the engine for you.

🧪 Test it (with architect eyes) ~15 min

Take 5 games from your library and identify the engine (splash / credits / SteamDB → Technology). Find the correlation: which genre/image on which engine? Then do mini due diligence: for your own hypothetical project walk the five axes (graphics/platforms/team/money/risk) and justify an engine — and separately answer what happens if the vendor doubles the price tomorrow.

Checklist: assembled an object out of nodes/components in an editor; found the engine's game loop (_process); identified the engine of 5 games; walked the 5 choice axes plus the "the vendor changed the terms" scenario.

Connections

foundation

The game loop — what the engine hides behind your Update()/_process(); now you can see who is spinning the loop.

foundation

Hardware constraints — an engine's asset pipeline automates exactly the work (atlases, formats, compression) that was done by hand in the 80s.

contrast

ECS and data-oriented design — what is under the hood of the component model; Unity DOTS takes it all the way down to data layout.

PBR rendering — UE4 (2014) and Unity (2015) made PBR the standard; the engine is what decided which materials you author at all.

Questions worth asking

If Godot is free and open source, why hasn't everyone left Unity?

A free engine ≠ zero total cost. Network effects hold people in place: a mature Asset Store, the job market (there are an order of magnitude more Unity/Unreal openings), ready-made ad/analytics/console SDKs, mountains of tutorials. On top of that, Godot's 3D and console tooling still lag behind UE, and moving means rewriting nearly everything. So the outflow after 2023 is real, but it is a shift in share, not an exodus: people switch on new projects rather than porting live ones.

Why does Unreal take royalties and Unity a subscription? Which is objectively better?

They are different bets on you. A royalty = Epic earns from your success and nothing while you are under $1M: ideal for indies and for a single blockbuster, expensive at huge stable revenue (3.5% of hundreds of millions). A subscription = a fixed cost regardless of outcome: cheap on a big seller with multi-million revenue, painful on a flop and on a bloated team (you pay per seat). The crossover: compute expected revenue × probability against seats × price. There is no "better" — only "suited to your risk profile".

The Runtime Fee was pennies for most people. Why did it tear the industry apart?

It was not the amount but three things at once: the fee was retroactive (on already-released games around which businesses were already built), based on installs (a metric untethered from revenue — reinstalls, demos and piracy could rack up charges above what you earned) and unilateral. That broke a basic piece of trust: "the engine my business rests on will not reprice my past work after the fact." Breaking that invariant is what caused the explosion, the CEO's departure and the reversal a year later. The lesson is not about Unity but about the nature of vendor dependency.

Why use an engine at all — why not write your own, the way Carmack did?

In-house engines do exist (id Tech, Decima, RE Engine, Frostbite) — for control and extreme performance in one specific kind of game. But the cost is not the renderer (that takes weeks) but the editor, the asset pipeline, the platform ports and years of polish — hundreds of person-years. What an engine sells is precisely a thousand solved problems and an editor, not the graphics. So in-house is affordable for large studios with a steady stream of projects, and everyone else is better off renting the kitchen.

Does the engine really dictate what the game turns out to be?

To a noticeable degree, yes — through "what is easy to do". Unreal pulls toward cinematic 3D (its tooling and Nanite/Lumen are built for it), Godot toward lightweight 2D, Unity toward mobile and toward games assembled out of the Asset Store. A tool shapes the path of least resistance, and teams slide along it (the law of the instrument: with a hammer, everything looks like a nail). So choosing an engine is partly choosing a genre and an aesthetic, not only a technology.