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.

Director 1 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.

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. Those you build directly in the builder, with manual controls, on a Mac or Windows desktop.

The look of the place is also yours. Terrain, water, weather and lighting are set by hand, which 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.

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

Free plan, Indie at $10 a month, Pro at $50, differing in how much AI usage they carry. That difference is worth knowing for this genre in particular, since iterating on rules is where the usage goes.

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.