How games are
actually made.

Most writing about game development is either a tutorial that builds something nobody would ship, or a postmortem so abstract that none of it can be acted on. This is neither. Every piece below describes something in a game we actually delivered to somebody, with the constants, the trade-offs and the bugs left in.

That means it also records where we depart from the standard advice. Our engines use a fixed timestep rather than delta time, because a game that behaves identically twice is a game a test can play. Our builds do not use a sprite sheet, because a single self-contained file has no requests to save. Both of those are the wrong answer in plenty of situations, and the articles say which.

The through-line is that almost nothing that makes a game feel good is visible in a screenshot. A jump feels right because of an eight-frame forgiveness window nobody notices. A hit lands because four cheap effects fire in the right order, and because everything pauses for a few hundredths of a second. A character reads as walking because the animation is driven by distance covered rather than by a clock. Those are the details that separate a game somebody finishes from one they put down without being able to say why.

If you are here because you are thinking about commissioning something, this cluster is the honest answer to whether we can build it. If you are here because you are building your own, take whatever is useful.

Where to start