Build a game engine

Open a window, create a GPU context, and write the loop: pump events, clear the screen, swap buffers. Measure each frame with a monotonic, high-resolution clock, never wall-clock time, which can jump when the system adjusts it.

Log the frame times and look at them. You'll see that vsync on and vsync off behave very differently, and that even an empty frame isn't perfectly regular. Keep that log; you'll use it in every later milestone.

Split the loop in two: update(dt) with a constant dt, and render(alpha) where alpha is how far you are between the last two steps. Its core is a few lines:

acc += min(frame_time, 0.25);
while (acc >= DT) { prev = curr; update(&curr, DT); acc -= DT; }
render(lerp(prev, curr, acc / DT));

Don't drop the min. Without it, one slow frame makes the next frame run extra steps, which makes it slower, which asks for more steps. That's the "spiral of death", and clamping the frame time is the standard way out.

Write one vertex shader and one fragment shader, load a PNG into a texture, and draw a textured quad through an orthographic projection so one unit is one pixel. Then do the naive thing, one draw call per sprite, and measure it.

Now fix it. Put your sprites on a texture atlas, write every quad for the frame into one big vertex buffer, and draw it in a single call. Sort by texture and layer first. That jump in throughput is probably the most useful lesson about GPUs in the project: they're fast at big batches and slow at many small requests.

Keep two snapshots of every key and button: this frame and last frame. From those you get held, pressed and released. Games care about the edges far more than the state; a jump that fires while the key is held feels broken immediately.

Then add a layer of actions. Game code asks for jump or a move_x axis, and a small table maps keys, mouse buttons and gamepad inputs onto them. Be careful with fixed steps here: a press that happens between two updates has to be seen by exactly one of them.

An entity is just an ID. Components are plain data, like Position, Velocity or Sprite, stored in packed arrays. Systems are functions that iterate every entity with a given set of components. Choose a storage model: sparse sets are simpler and make adding components cheap, while archetypes group entities by their exact component set and iterate faster.

Make IDs generational: an index plus a counter that bumps when the slot is reused. Otherwise a system holding the ID of a dead enemy will quietly start steering whatever spawned into its slot.

Start with axis-aligned boxes and move one axis at a time, resolving overlaps after each. That alone probably handles most platformers. Then add a broad phase, such as a uniform grid or spatial hash, so you only test pairs that share a cell. Checking every pair against every other is quadratic and falls over surprisingly early.

Fast objects will tunnel: in one step they're in front of a wall, in the next they're behind it, and they never overlapped. Fix it with swept tests or by sub-stepping fast bodies. Keep this separate from game logic, which should only hear about collisions as events.

Your OS calls the audio callback on its own thread, asking for the next few milliseconds of samples. Mix every playing voice into that buffer, apply volume and panning, and clamp the result so it can't clip past full scale.

Inside it there's a hard rule: no locks, no allocation, no file I/O. Your game thread sends commands like "play this sound" through a single-producer, single-consumer ring buffer, and all the sound data is decoded before it's needed. If you've read Chapter 15, this is a real use for everything in it.

Finish the game. Add a title screen, a restart, and a way to load levels from a file. This is where you'll find which parts of the engine are awkward, because you'll be the one fighting them.

Then take the first step into 3D: a perspective projection, a camera, a depth buffer, and one mesh loaded from glTF. Your loop, ECS, input and audio shouldn't change at all. If they do, that's a design problem worth fixing now, before lighting and shadows pile on.