About the Almanac
This is a working notebook for learning game development properly — kept in the open so it stays honest, and so anyone else can use it.
Why this exists
Writing something down is the cheapest way to find out whether you actually understood it. Every page here began as a note from someone working out a problem, and the games came out better because the notes existed. That's the whole method: documentation first, because you cannot write a clear explanation of something you only half know.
It's free, and it stays free — but free isn't the point. The point is that making games is supposed to be fun, and most people who quit don't quit because the maths got hard. They quit after three weeks stuck on something a good paragraph would have unstuck in ten minutes. Everything here is written to get you through those weeks and back to the part you came for.
So take what's useful, ignore what isn't, and go build something you enjoy building. That's the entire ambition.
What's here
Curricula are complete courses for building one game each. Every project starts with an architecture document — the whole design mapped before any code — followed by stages sized to a single sitting. Each stage ends with a checklist you verify in the engine yourself.
Systems are tutorials for the parts that outlive the game they were written for — state machines, enemy AI, pathfinding, steering and flocking, boss fights, inventories, saving, main menus, event buses. Each one starts from the simplest thing that works, shows you the exact point where it breaks, and only then earns the more complicated version. Read one when a project needs it, or when you want the general treatment of something a stage only touched.
Library shelves are curated paths through other people's excellent teaching: pixel art, shaders, 3D modeling, programming. Every entry says who made it, what it teaches, and when to read it. Where a subject already has a great source, the shelf points at it rather than rewriting it worse.
How the tutorials work
Early stages show complete, explained code. Later stages deliberately show less — a skeleton with the bodies missing, then requirements with no code at all. That fade is the point: reading working code teaches recognition, and writing it teaches everything else.
A few stages ask for a real design decision between two sound options, with the trade-offs laid out and the choice left open. Those decisions are what make the resulting game yours instead of a transcription.
Using it yourself
The curricula target Godot 4.7 with typed GDScript, but the design reasoning travels to any engine. Nothing here needs an account — ticking a checkpoint saves progress in your own browser and nowhere else. Start at Curricula if you want to build a whole game, Systems if you need one mechanism you can reuse, or Library if you want to get better at one craft.
Colophon
Written by Sugor while learning. Built with Next.js, rendered from markdown, deployed on a small server on every push. The source documents live beside the game projects they describe.