Build a Game Engine
Thirty-plus tutorials, one machine. This is the map: 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. 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.
01How to read this
This is 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; the Read pill marks one you can open right now.
If cache behavior and threading are old news, skip to the math or the renderer. If you only came for physics or pathfinding, those are complete and 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
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. Every node links to a written tutorial; click one to trace its prerequisites.
04The curriculum
The whole series, grouped into phases. Each phase ends somewhere useful, and the two milestones are where the pieces become something you can run.
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. Both of these are already complete.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.Off the critical path
Engine-relevant, but not a dependency of the capstones.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 come with the full source in C++ and Rust, walked through end to end.
06How each tutorial holds the bar
Every tutorial in this series clears the same gates as the ones already published. The point is that a senior engine programmer should read any page and not find a 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. CRC Press. 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) and Vol. 2 (Rendering). 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. 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.