A town with no to-do list.

Somewhere to put a roof

PixelPunk is a game about making a place you would like to spend time in: a crooked roof, a warm window by the water, a bridge that takes the scenic route. You don’t balance an economy or unlock a technology tree, and no residents queue up asking for another fire station. Every part is available from the start.

The whole world fits on a 64 × 64 metre canvas. You paint land, carve out water, put down buildings and reshape them, and at some point you stop long enough to take a photograph. The small canvas is part of the appeal. At that size you arrange a town the way you would arrange a picture, and nothing in it needs managing.

The early captures already had stacked buildings, bright windows, neon and a view across the water. The mood was different, though: colder, shinier and lit much more evenly. Looking back, it’s clear where the project wanted to go long before it was clear how to get there.

Pixels, but not a painting

The world is real 3D. Buildings are generated from parameters, seen through an orthographic camera and rendered at a low internal resolution, which is where the pixels come from. Turn the camera and every roof has another side.

A painted sprite gets to pick one perfect silhouette. Procedural architecture has to hold up under whatever the player does to it, whether that’s a taller tower, a narrower house or a roof shoved into its neighbour. So the art direction has to be written down as rules, and the rules have to keep producing buildings that look intended.

It’s written in GDScript on a pinned Godot 4.6.3, using the GL Compatibility renderer, and all of the town geometry comes from the project’s own generators. For a small desktop toy, there is a fair amount of geometry code underneath.

Room to make mistakes

A building game needs a good answer to “actually, never mind”. In PixelPunk every edit is a transaction against a scene document. The history keeps the state before and after each edit, and undo puts the earlier one back. A long brush stroke counts as one decision, so it is one undo step.

The scene is a flat list of parts, each with a position, a rotation and some optional parameters, saved as versioned JSON. Rendering happens separately. Roofs, supports and other derived details are rebuilt from the document, so the save file never has to record individual bricks.

Version 2 of the format swapped whole-floor building heights for continuous dimensions, and version 1 scenes are migrated when they load. New optional parameters usually default to the old look, so an existing scene shouldn’t redesign itself when you open it. Each new feature makes that promise a little harder to keep.

Saves are replaced atomically, there are recovery saves, and the previous save is kept as a backup. None of that looks good in a screenshot, but it means you can try the ridiculous tower without worrying too much about the nice town underneath.

Then two houses touched

One procedural house is manageable. Push a second one through its wall and you have a different problem. Which wall goes? Where does the roof stop? Does the new corner need stonework, and what happens when you undo?

Getting separate pieces to look as if they belong to one place became the first big thread of the project. The buildings needed better manners, and the player shouldn’t be the one supplying them.