Build a Game Engine
You want to build a game engine, or just one part of one, and every subsystem seems to assume three others. This page is the map: a 48-tutorial series covering every system a game engine needs, in the order that lets each build on the last, from the cache up to a game you can play, with a graph that shows what to read before the module you came for. C++ and Rust throughout, Vulkan for the renderer. Read it straight through to build a 2D engine and then a 3D one, or drop in at any box you already need.
- Build a 2D engine from the memory model up to a small playable game, with a Vulkan sprite renderer, input, audio, physics and asset loading.
- Extend the same engine to 3D: physically based lighting, shadows, skeletal animation, 3D physics, spatial culling and navmesh AI.
- Find the shortest route to the one subsystem you need, using the dependency graph in §3.
- Read every system in C++ and Rust side by side, with the production concerns each sample leaves out listed after it.
01How to read this
You came for the 2D renderer, and it assumes textures, which assume a first Vulkan triangle, which assumes a window. This page tells you that chain up front. It's a collection, not one long page. Every box below is its own deep tutorial, the same kind the rest of the site is made of: a hard concept gets a live widget, every claim is cited, and the C++ and Rust sit side by side. The series just puts them in order and wires them together.
The order is a dependency graph, not a straight line. Prerequisites come first, and each tutorial links back to what it assumes and forward to what comes next, so you can also arrive sideways: land on Job Systems from a search, walk its prerequisites back to the memory model, then follow its "next" into the renderer. Every module in the series is written, and each card below links to its tutorial.
If cache behavior and threading are old news, skip to the math or the renderer. If you only came for physics or pathfinding, those stand on their own. The graph in §3 shows what each module leans on, so you can read just the spine that gets you where you want to go.
02The whole machine
If the job system calls into the renderer and the renderer calls into the job system, you can't build or test either one alone. An engine is layers. The platform layer talks to the operating system: the window, the input devices, the file system, the audio device. The core layer is what everything else leans on: memory, threads, math, containers. On top of that run the big per-frame systems (rendering, animation, physics, audio), then the gameplay layer, then the game itself. The decomposition here follows the one in Gregory's Game Engine Architecture[1].
The rule that keeps this buildable: a layer may call down, never up. The renderer can ask the job system for threads; the job system knows nothing about the renderer. Click a layer to jump to its tutorials.
03The path
Reading order is a graph. The widget below is the critical path to the first milestone, a complete 2D engine: the spine that runs from the memory model and the math through the Vulkan renderer to a game you can play. Each edge follows the prerequisites the tutorial itself lists. Click a module, or pick one from the list, to trace its prerequisites.
Worked example
Say you came for the 2D Renderer, page 23 in reading order. The graph says it needs Textures, which needs First Triangle, which needs Platform & Window and the GPU Pipeline; those need the Game Loop and 3D Math. That's 6 pages to read first, where reading straight through puts 22 in front of it. The 2D game at the end of the graph pulls in all 15 of the other boxes.
04The curriculum
Reading every page straight through is a long road, so it helps to know where the stops are. The whole series, grouped into phases. Each phase ends somewhere useful, and the two milestones are where the pieces become something you can run.
Worked example
Straight through, the 2D capstone is page 26 of 48 and the 3D capstone page 46. The two Advanced pages after it, streaming and save games, are optional extensions for a shipping open-world game. Phase 0 is optional depth: pull in Big O or assembly when a later page leans on it.
Foundations
The substrate. Optional depth you pull in when a later module leans on it.Memory & concurrency
The core layer everything else is built on.Math & numerics
What the renderer, physics, and animation all assume you know.The runtime spine
The loop that drives everything, and the OS it runs on.Resources
Getting data off disk and into the engine fast.Rendering: the 2D path (Vulkan)
From an empty window to sprites on screen.Audio
Sound, mixed on its own real-time thread.A complete 2D game
The first point where the engine becomes a game.Rendering: into 3D
Meshes, lighting, and the modern real-time look.Animation
Making meshes move.Simulation
The physical world, and the structures that keep its queries fast.Gameplay
The layer the game itself is written against.AI
Agents that move and decide.Networking
Many machines, one world.Tooling
Seeing inside the engine.A small 3D game
The same engine, extended into three dimensions.Extensions beyond the capstone
Optional systems a shipping open-world game needs, built on the finished engine.The site's other curriculum, Build a Language Model, runs from linear algebra and probability through a GPT trained in the browser to fine-tuning, inference and serving.
05The two milestones
A pile of subsystems is not an engine. Two points in the series are where the pieces have to fit together and run, and where you end up with something you can hand to someone.
The 2D capstone wires the runtime spine to a Vulkan sprite renderer, input, audio, the existing 2D physics, and asset loading, and ships a small playable game. It is the proof the foundation holds before the renderer gets hard. The 3D capstone extends that same engine: mesh rendering, a physically based lighting pass, shadows, skeletal animation, 3D physics, spatial culling, and navmesh AI. Both show the integration code in C++ and Rust (the main loop and the seams between subsystems) and end in a game you can play in the browser.
06How each tutorial holds the bar
Every tutorial in this series is held to the same gates. The goal is that a senior engine programmer can read any page and find no claim to push back on.
The reference spine for the whole series is Gregory's Game Engine Architecture[1] for the subsystem breakdown, Lengyel's Foundations of Game Engine Development[2] for the math and rendering, Real-Time Rendering[3] for the graphics, the Vulkan specification and vkguide[4] for the renderer, and Gaffer On Games[5] for the loop and the netcode. Each tutorial researches its own topic deeper from there.
- Jason Gregory. Game Engine Architecture, 3rd ed. CRC Press, 2018. Companion URL list: gameenginebook.com/urls.html. The chapter structure used here as the subsystem decomposition and ordering skeleton.
- Eric Lengyel. Foundations of Game Engine Development, Vol. 1 (Mathematics, 2016) and Vol. 2 (Rendering, 2019). Terathon Software. foundationsofgameenginedev.com. The primary reference for the math and rendering modules.
- Tomas Akenine-Möller, Eric Haines, Naty Hoffman, et al. Real-Time Rendering, 4th ed. CRC Press, 2018. realtimerendering.com. The standard reference for the rendering track.
- The Khronos Group. Vulkan Specification, and Victor Blanco's Vulkan Guide. vkguide.dev. The renderer targets Vulkan; the Rust ports use the
ashbindings. - Glenn Fiedler. Gaffer On Games. gafferongames.com. "Fix Your Timestep!" for the game loop; the networked-physics series for the netcode modules.