City building game maker: terrain first, then the simulation

Every good city builder is really a terrain puzzle. A river you have to bridge. A valley that is fertile and cramped. A coastline that gives you trade and takes away room. Flat unlimited ground is the least interesting map anyone can make and it is the one a generator produces by default.

So terrain comes first, and you build it. Flockbay gives you elevation, water and weather as hand tools. You raise a ridge, cut a river through it, decide where the ground is buildable and where it is not, and look at the result from the angle a player will actually see it.

This is slow in the way that matters. Ten minutes moving a river is ten minutes deciding what the game is about.

More on this: Open worlds are a scale problem before they are a design problem

Underneath a city builder is a web of resources moving between things. Population that grows if housing and food allow it. Jobs that need workers who need to reach them. Power, water, waste, roads, traffic, land value, pollution, happiness. Each is simple and the interactions are not.

You describe the model you want. Houses draw workers from within a walk of eight tiles. Factories raise pollution in a radius and pollution lowers land value and land value sets tax income. Flockbay writes the GDScript for it inside your project.

Then you play a hundred turns and find out that your economy collapses at the third district or never becomes tight enough to be interesting. That is the actual work of the genre and it is judgement rather than programming.

More on this: Godot city builder templates give you placement, not simulation

The player needs to build too, which means a placement system: a grid or free placement, valid and invalid ground, cost, rotation, a bulldozer, undo, and a road tool that snaps sensibly. That is a surprising amount of code and it is all a request.

Getting it to feel good takes iteration. Placement that fights the player ruins a city builder faster than a bad economy, because it is the thing they touch every second. Play it, notice the friction, say where it is.

You can also hand-build parts of the city yourself as fixed content: a starting settlement, a landmark, a ruin the player builds around. Those are placed by you in the builder and are ordinary parts of the world.

City builders get heavy in a predictable way: a lot of entities, a lot of pathing, a lot of small updates every tick. A few hundred simulated citizens is modest for the genre and a serious load for anything in a browser tab.

Flockbay is a desktop application for Windows with Godot bundled inside it, and your game runs on your machine at your machine's framerate. Nothing is streamed. What your computer can simulate is what your city can contain.

Building needs an internet connection because the chat, asset generation and world data come over the network. Playing the city you built does not.

City builders are among the largest projects a solo creator can attempt. Not because any single system is hard, but because there are many of them and they all have to agree with each other.

Having the code written for you removes a genuine barrier and does not make it a weekend project. What you should expect is that the parts you spend your evenings on are the map and the numbers, which is where you wanted to spend them.

Flockbay is free on your own AI: your Claude or ChatGPT plan, your own agent, or an API key.

A city builder is looked at from a distance, and the player has to understand the state of a hundred things in one glance. Which districts are unhappy, where the traffic is, what is not connected, what is about to run out.

That is an overlay problem and it is worth solving early rather than treating as polish. Colour by value, icons that appear at a zoom threshold, a warning that is visible without being noise. Ask for the overlays as soon as you have anything worth showing.

The test is simple: hand it to somebody who has never played it, and see how long they take to notice the problem you planted.

More on this: AI RTS maker for a genre with a hundred moving parts