AI city builder maker: simulation you can watch

What makes a city builder good is not the buildings. It is the set of pressures between them: this needs power, power needs fuel, fuel needs a road, the road takes land you wanted for housing. Play is about resolving those pressures and the feeling of a city that is nearly working.

Building that means writing a simulation. Resource flows on a tick, demand that propagates, pathfinding for supply, agents with needs, and a save file that captures all of it. Every one of those is a real piece of programming and together they are the reason city builder projects are so often abandoned.

Director 1 writes them in GDScript inside your project. You describe the pressures you want and get a simulation you can run.

The map is the other half of the genre, and it is the half you build. Terrain with real relief, a river that constrains where bridges go, a coast, a mountain pass that makes one route obviously valuable.

This is the difference between a city builder with interesting decisions and a flat grid where every tile is the same. It is also purely spatial judgement, which is exactly the kind of decision that does not need a technical background.

The builder works like a level editor. You sculpt terrain, draw water, set weather and time of day, and place whatever should already be there before the player arrives.

The interesting failures in a city builder are visible ones. The trucks all take the same road. Nobody ever visits the second market. The population plateaus at four hundred for a reason nobody can see.

You find these by running the game and looking, which is why running locally matters. Stage Engine bundles Godot inside the app and your city runs on your machine, so a few thousand agents and a full map are a normal load rather than the thing that kills the preview.

When you spot something wrong you say so in plain words. Trucks are queueing at the junction and never taking the second route. That is a complete bug report and it does not require knowing what pathfinding is.

There is no menu of city builder presets here, deliberately. A preset encodes somebody else's economy, and the economy is the game. If your city builder is about water in a desert, or about a colony ship, or about a medieval town with one road out, a preset is in your way.

You describe the rules you want. If a rule is missing the tool asks for it rather than inventing a default, because an invented default is a decision you did not make.

Real elevation data is worth a mention here specifically, because a real landscape carries constraints nobody would think to invent. Rivers in awkward places, a plain that is slightly too narrow, a ridge that makes one approach obvious. Those constraints are free design.

A desktop app for Mac and Windows. Godot ships inside it and your game runs locally. There is no browser version and no streaming.

Free to download with a free plan. Indie is $10 a month, Pro is $50, buying usage rather than a different engine. Building needs an internet connection; playing what you built does not.

City builders have a specific failure that is worth designing against from the start: the player cannot see why anything is happening. The population drops, and there is no way to find out that it is because one road is congested, so the player stops making decisions and starts guessing.

The fix is in the presentation layer rather than the simulation. Overlays that show flow. A building you can click that tells you what it is waiting for. A chart of the last hundred ticks. These are all code and all worth asking for early, because a simulation you cannot see into is one you cannot design.

It also helps you enormously as the developer, because the same tools that let a player understand the city let you find out why your economy collapses at minute forty.

This is the sort of thing that gets deferred forever when you are writing the code yourself, and it is the thing most responsible for whether the genre works.