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

The Godot Roguelike Example by statico is a finished small game. MIT licensed, 2D and tile based, seen from above. Its description covers procedural dungeon levels, field of view and fog of war, turn processing, monsters with their own behaviour, items and equipment, an inventory screen, combat and a HUD, plus a debug tool for previewing map generation before you commit to it.

The Godot 4 Roguelike Tutorial by Bozar is a different kind of thing. Also MIT and also 2D, it is written as a teaching sequence: dungeon prefabs to build levels from, shadowcasting for the field of view, Dijkstra pathfinding for how the monsters come at you, permanent death, a visible seed, a sidebar of state, and help and debug screens.

The distinction is worth holding on to. An example project shows you a result. A tutorial shows you an order of operations, and the order is often the thing you were actually missing. If you want to end up understanding your own roguelike, the tutorial is more valuable even though it looks like less.

Carving rooms and joining them with corridors is a solved problem with well-known recipes, and both projects have it working. What is not solved by having it working is whether the results are worth walking through. A generator that produces valid dungeons and a generator that produces interesting ones are separated by a long stretch of tuning: room sizes, how much dead end you tolerate, whether the player can see far enough ahead to make a choice, how loot and threat are spread across a floor.

The genuinely fiddly pieces are the ones people underestimate. Field of view that is symmetrical and does not flicker, fog of war that remembers what you saw, turn processing where everything acts in a defined order and nothing acts twice. Those are unglamorous, they take longer than expected, and inheriting them working is real value.

Two small things matter more than they sound. A visible seed lets you reproduce the run somebody complained about. A map preview tool lets you look at two hundred dungeons in a minute instead of playing into them one at a time. Both of those exist in these projects, and both will save you days.

A roguelike is not its dungeon generator. It is the interactions between the things inside the dungeon. The reason players start a fresh run after dying is that they suspect a different combination might work, and that suspicion only exists if there are enough things to combine. Ten items and six monsters is a demonstration. The depth arrives somewhere past that, and it arrives through combinations rather than through count.

What a starter gives you is the machinery for making monsters and items, not monsters and items. Deciding that this thing is fast and fragile and hunts in threes, that this weapon is worse in a corridor, that this potion is a trap unless you have already found the other one, is design, and it is most of the work. It is also the enjoyable part, which is easy to forget while you are staring at generation parameters.

Balance here is measured in runs played. Not a session of playing: dozens of runs, mostly losing, noticing which deaths felt fair. There is no shortcut and no starter project shortens it.

Every part of a roguelike is written against an assumption about the turn. One action per turn, everything moves after you do, one monster occupies one tile. Those assumptions are invisible right up to the moment you break one. Adding speed, so that a fast monster gets two moves, means the turn loop, the animations, the input handling and the monster behaviour all need to agree about something they previously did not have to think about.

That is the trade of starting from someone else's roguelike. You get a working turn model, and you get their turn model. Changing it means reading enough of the project to know who depends on what, which in a turn-based game is nearly everything.

This is where the tutorial project earns itself. Code written to be read is code you can change. If you do not read GDScript at all, the honest position is that you have a playable roguelike and a locked design, and this is a genre where the design is the whole product.

Stage Engine approaches it from the other side. It is a desktop app for Mac and Windows with Godot bundled inside. Rather than adopting a stranger's turn model, you describe the run you want and Director 1 writes the GDScript in your project: the generation rules, the turn order, the monsters and the items, all against your design instead of somebody else's. You play the runs and say what is wrong, which is the same feedback loop as tuning a template, minus the reading.

What this is not: there is no template picker in Stage Engine, and neither the Godot Roguelike Example nor the Godot 4 Roguelike Tutorial opens inside it. Those are public repositories you clone and open in Godot. They are a separate route to the same genre.

Building needs an internet connection, because Director 1 and asset generation come over the network. Playing the runs does not; the game runs locally on the copy of Godot inside the app. The download is free, Indie is $10 a month and Pro is $50, and paying buys more usage rather than a different engine.