A game engine is a loop that never stops, a renderer, an input layer, a physics step and a pile of algorithms that all have to finish in sixteen milliseconds. This track builds one in ten milestones, starting from a blank browser window. Every milestone downloads as a single HTML file that runs the moment you open it, and every hard part inside it is one of the thirty Game Development puzzles. Until you solve a puzzle its slot in the engine holds a placeholder that runs but is visibly wrong, so you watch each bug disappear as you plug in your own solution.
The order is the order engines are actually built in. First a window and a game loop with a fixed physics step, then drawing a tilemap, then input and menus, then a whole small game, Snake, before movement, collision and physics at scale. After that come a scene graph for objects attached to other objects, enemy AI with behavior trees and A* pathfinding, procedural dungeons and progression systems, and finally the tools: a level editor with undo, sound effects and asset streaming. Each milestone lists its steps and says when it is done.
The game loop is an accumulator, a pause menu is a stack, a bullet pool is a free list, Snake is a deque, a scene graph is a tree, a dungeon generator is union-find, autotiling is a 4-bit mask and a spellbook is a knapsack. The thirty Game Development puzzles cover every pattern from sliding windows to dynamic programming, and each one plugs into exactly one milestone. That makes this the rare engine tutorial that doubles as coding interview practice: the function you write in the puzzle is the function the engine calls.
A browser. The engine is plain JavaScript drawing on an HTML canvas, with no libraries, no build step and nothing to install, so you can open a milestone, read every line of it and change anything. The puzzles can be solved in JavaScript, Python or C++, and the engine files take the JavaScript version. Unity, Unreal and Godot do all of this at a much larger scale, and the take-it-further step on every milestone points at how.
A canvas that fills the window, stays sharp on high-density screens, and runs a game loop with a fixed physics step, plus a frame-time graph that catches stutter.
Every engine starts here. Rendering runs as fast as the screen allows, but physics has to advance in equal slices or the game behaves differently on every machine. The loop that separates the two is the first thing Unity, Unreal and Godot each get right, and the frame-time graph is the first tool every engine programmer reaches for.
Done when: The balls fall at the same speed on a 60 Hz and a 144 Hz screen, and pressing H to fake a stall lights up the stutter in the graph.
Built from: The Steady Clock (the fixed-timestep accumulator that drives every physics step), Find the Stutter (the stutter detector behind the frame-time graph).
In real engines: Unity's FixedUpdate, Godot's _physics_process and Unreal's physics substepping are this loop. Frame pacing graphs like Unreal's stat unit are the stutter detector.
Take it further: Interpolate the drawn position between the last two physics states using the leftover time, so motion stays smooth when the frame rate and physics rate disagree.
A tilemap you can paint with the mouse, drawn with autotiled walls, sprites sorted so near things cover far ones, and an isometric view that knows which tile the mouse is over.
Before anything moves, the world has to be drawn correctly. Walls need to join up into shapes, sprites need to overlap in the right order, and the mouse needs to land on the tile it is visibly pointing at. All three are small algorithms, and all three are things players notice instantly when they are wrong.
Done when: Clicking paints walls that join into smooth shapes, the hero walks behind trees and in front of rocks correctly, and in iso view the highlighted diamond is always the one under the cursor.
Built from: Tiles That Know Their Neighbors (the 4-bit neighbor masks that pick each wall tile), Back to Front (the back-to-front merge of terrain and sprites), Which Diamond Did I Click? (the screen-to-tile inverse for isometric mouse picking).
In real engines: Godot's terrain sets and RPG Maker autotiles, the sprite sorting layers in Unity's 2D renderer, and the mouse picking in every isometric strategy game.
Take it further: Move from the 4-bit mask to the 8-bit blob tileset with 47 tiles, so inner corners get their own pieces.
An input layer that maps keys to actions, a stack of screens for title, play, pause and options, and a combo counter that rewards fast, accurate hits.
A game is mostly a conversation with the player's hands. Menus have to return you exactly where you were, and timing windows are what make controls feel tight. Both are data structures: a stack and a sliding window.
Done when: Pause and options stack on top of play and close back to it, the title screen can never be closed, and the combo meter climbs only while hits land close together.
Built from: Pause on Top of Play (the game state stack behind every menu), Keep the Combo Alive (the sliding time window that scores combos).
In real engines: The pushdown automaton from Game Programming Patterns, Unity's Input System action maps, and the input buffers in every fighting game.
Take it further: Add an input buffer: remember a jump pressed a few frames before landing and perform it on landing, which is how platformers make controls feel forgiving.
A complete game with a start, a score and an ending: Snake, with food, growth, self-collision and a screen-wrap mode.
Finishing a small game teaches more than starting a big one. Snake has every piece of a real game loop, state, input, rules, win and lose, in a hundred lines, and its body is the textbook use of a deque.
Done when: The scoreboard always agrees with what you see, chasing your own tail is legal, and wrap mode works on all four edges including the left and top.
Built from: Don't Eat Yourself (the authoritative score and crash check), Off One Edge, On the Other (the screen wrap in wrap mode).
In real engines: Blockade in 1976, the Nokia 6110 in 1997, and the deque plus set pairing that also runs LRU caches.
Take it further: Speed the tick up as the score rises, and keep a top-ten table in localStorage.
A side-scrolling platformer: gravity, running, jumping, a camera that follows, and collision against a tilemap that never lets the player clip into a wall.
Movement is where a game starts to feel like something. Tile collision is the reason 2D games can be big: checking only the tiles under the player makes collision cost the same on a tiny room and a huge level.
Done when: The player can run and jump across the level without sinking into floors, snagging on seams or leaving the map, and the jump hint updates as they go.
Built from: Standing on Solid Ground (the tile overlap test behind every move), Fewest Jumps to the Flag (the jump-count hint toward the flag).
In real engines: Celeste, Super Meat Boy and most tile-based platformers resolve collision one axis at a time against the tiles under the player.
Take it further: Add coyote time and variable jump height: jumping shortly after leaving a ledge, and cutting the jump short when the button is released.
An Asteroids-style arena with hundreds of moving bodies: a wrapping world, a bullet pool that never allocates, collision layers so you cannot shoot yourself, and a broad phase that avoids testing every pair.
One collision is easy. A thousand is an algorithm problem. Real engines survive by never allocating mid-game, by filtering pairs with bitmasks before testing shapes, and by only comparing objects that are near each other.
Done when: You can fire continuously without the pool running dry or growing, your bullets pass through you but break rocks, and the pairs counter stays far below n squared.
Built from: Recycle the Bullets (the bullet pool's allocator), Who Is Allowed to Touch? (the layer and mask filter on every pair), Only Check the Neighbors (the broad-phase pair count).
In real engines: Box2D's broad phase and filter bits, Unity's collision matrix, and the object pools every bullet hell is built on.
Take it further: Check the eight neighboring cells as well, so objects straddling a cell border still collide, and size cells to the largest object.
A scene graph where objects ride on other objects, a knight whose sword follows his arm, and a turn-based arena that knocks fighters out in order.
Real game objects are attached to each other. Moving a ship moves its turrets, and moving an arm moves the sword. A scene graph turns that into one rule, world equals parent plus local, and it is the backbone of every engine's editor.
Done when: The sword stays in the knight's hand whatever the arm and body do, and the arena eliminates fighters in exactly the order the ring dictates.
Built from: Where Is the Sword, Really? (the local-to-world transform for every object), Last One Standing (the elimination order in the arena).
In real engines: Unity's Transform hierarchy, Godot's node tree and Unreal's scene components all compute world from parent times local.
Take it further: Replace offsets with full 2D transforms, rotation and scale as well as position, multiplied down the tree as 3 by 3 matrices.
Guards driven by a behavior tree, a route planner over terrain with different costs, a turret that locks on to the nearest targets, and a tower placement planner.
AI is what makes a level a game. Behavior trees decide what to do, A* decides how to get there, and both have to be cheap enough to run for every enemy every frame.
Done when: Guards patrol until they see you and stop checking range when they cannot, the route cost matches the cheapest path you can find by hand, and the turret always tracks the closest two.
Built from: What Does the Guard Do? (the guard's decision making), Chase the Player (the cheapest route through weighted terrain), Lock On (the turret's lock-on), Fewest Towers on the Lane (the tower placement planner).
In real engines: Halo 2's behavior trees, Unreal's built-in Behavior Tree editor, and the A* over navigation meshes in Unity and Unreal.
Take it further: Return the path, not just its cost, by recording each tile's parent, and have the guards follow it.
A dungeon generator that guarantees every room is reachable, plus the systems that make a run feel like progress: levels, an inventory, loadouts, a spellbook, a tech tree and a trap room.
Procedural generation and progression systems are where game design meets algorithms most directly. A generator is only as good as its guarantee that the level is playable, and every number a designer tunes is backed by a search or an optimization.
Done when: Every generated dungeon is fully connected, the HUD's level, slots, loadouts, damage and research turns all match what you can verify by hand, and the trap room hint finds the cheapest route.
Built from: Are All the Rooms Connected? (the connectivity guarantee in the generator), Level Up (the level curve lookup), How Many Bag Slots? (inventory stacking), Pack the Loadout (the loadout counter), Spend the Mana (the best spell combo), Research Order (the research planner), Take the Least Damage (the trap room route).
In real engines: Roguelike dungeon generators from Rogue to Spelunky, Civilization's tech tree, and the stacking rules in Minecraft and every RPG inventory.
Take it further: Build a minimum spanning tree of corridors with Kruskal's algorithm, which is the union-find you already have, so dungeons connect with the shortest total digging.
A level editor with undo and redo, sound effects that play the instant they are triggered, an asset streaming planner, and saving and loading levels.
Engines are judged by their tools. Designers need undo, sounds need to fire without a delay, and open worlds need to load in the background without a hitch. These are the systems that turn a demo into something other people can build with.
Done when: Undo and redo walk the history correctly and a new edit clears redo, the trimmed sound fires with no lag, and the streaming plan never puts more in one frame than the budget says.
Built from: Ctrl+Z in the Level Editor (the editor's undo and redo), Cut the Silence (the silence trimmer for sound effects), Load It Before They Get There (the per-frame streaming budget).
In real engines: The Command pattern behind editor undo stacks, the import pipelines that trim and compress audio, and the level streaming in Unreal's World Partition.
Take it further: Store commands rather than results, each with do and undo, so any kind of edit can be taken back, and export the level as JSON a game can load.
Start with a window and a game loop that separates drawing from physics, using a fixed timestep so the game runs the same on every machine. Then add drawing, input, collision and entities one system at a time, getting each working before the next. Milestone one here is exactly that first step, and it runs in a browser with nothing to install.
JavaScript, drawing on an HTML canvas, so every milestone is one file that runs in any browser. The ideas carry straight over to C++ engines like Unreal or C# in Unity, and the puzzles behind each milestone can also be solved in Python and C++.
More than most people expect: an accumulator for the fixed-timestep loop, sliding windows for frame timing and combos, stacks for menus and undo, a deque for Snake, free lists for object pools, bitmasks for collision layers and autotiling, hashing for broad-phase collision, trees for scene graphs and behavior trees, A* for pathfinding, union-find and topological sort for level generation, and knapsack and grid dynamic programming for game systems.
No. Every milestone runs straight away with placeholders in the puzzle slots. Each placeholder is deliberately wrong in the way its puzzle is about, so the game shows the bug, and solving the puzzle and plugging in your function fixes it. Download while signed in and every Game Development puzzle you have solved is written into the file for you.
Because its unsolved plug-ins are placeholders, and a placeholder is meant to show its bug: the runner falls through the floor until you solve the collision puzzle, Snake never ends until you solve the scoring puzzle. The file says which bugs are showing when it opens, and the Plug-ins button in its corner counts how many plug-ins are working. Anything else, such as an error message in red, is a real problem worth reporting.
The ten engine files are free to download. The thirty Game Development puzzles that replace the placeholders are part of Premium, and you can preview any of them for free first.
See every Software Engineer project, learn the patterns in the DSA bootcamp, or browse all 576 practice puzzles.