Roguelike game maker: the run is a system, and systems are code

A roguelike is not a level you build, it is a set of rules that produce levels, plus a set of items that modify the rules, plus a difficulty curve that responds to how the run is going. Nothing about that is visual. It is all systems talking to each other.

Which is why roguelikes are slow to prototype conventionally. Every idea for an item is a code change, every generation tweak is a code change, and most of them turn out to be bad. The genre rewards testing a hundred ideas and keeping eight.

Flockbay writes those changes as GDScript in your project. You describe the item, the generation rule, the enemy modifier, and you play a run. Then another. The cost of trying a bad idea drops to the length of one run.

More on this: AI card game generator: the rules engine is the game

Random is easy and boring. What makes generation good is constraint: rooms that connect in a readable way, a guaranteed route to the exit, encounters spaced so you get to breathe, a shop that shows up often enough to plan around.

Those constraints are yours to specify, and specifying them well takes playing a lot of generated runs and noticing what keeps going wrong. Too many dead ends. The good item always comes too late. The third floor is always easier than the second.

You feed those observations back as rules. That is the actual craft of the genre and it is not something a tool can do for you, no matter who is writing the code.

Even a generated game has handmade pieces: the hub you return to, the boss arena, the set of room templates the generator arranges. Flockbay builds those from the brief, in whichever kind of world the project is, and you walk them and say what is wrong. When one is a pure-taste call, exactly where the boss stands or how wide the arena is, the same world tools are buttons around the Godot editor's view for you to press.

The look of the place is also yours to judge. In a 3D dungeon that means terrain, water, weather and lighting; in a flat one, the tile ground, the band of scenery behind it and the sprites standing on it. Flockbay sets them from the brief and changes them when you say. Either way it matters more than it sounds for a game people will see a hundred times. A generated world that always looks the same colour gets tiring fast.

You will play more runs of your own roguelike than of anything else you make, and you will still be wrong about the balance, because you are the person who knows every rule.

Getting builds in front of other people early is the only reliable correction. The game is a real build running locally on the bundled Godot, so handing it over is a normal thing to do rather than a publishing event.

More on this: Godot roguelike templates: an example, a tutorial, and the part neither one covers

Desktop app for Windows and Linux, free to download, Godot inside it, games running locally on your machine. Building needs an internet connection; playing what you built does not.

The world tools are free. Flockbay is free, AI included: free hosted AI every day, or your Claude or ChatGPT plan, your own agent, or an API key. Worth knowing for this genre in particular, since iterating on rules leans hard on Flockbay.

Length first. A run that takes forty minutes and ends badly through no fault of yours is infuriating; one that takes eight minutes is forgiven anything. Pick a target length early because almost every other balance decision hangs off it.

Then the shape of a loss. The best roguelikes make you feel that you understand what went wrong, which is a design property rather than an accident. If your testers shrug when they die, the run is not communicating.

Both of those are judgements made by playing, which is the part of this genre no amount of written code shortens. What the tool changes is that acting on the judgement takes minutes instead of an evening.