Building a metroidvania when the map is the design

Metroidvanias are the genre where the structure comes before the content. Before a single room is fun you need a movement system worth exploring with, a way to gate progress, a way to remember what the player has unlocked, and a map that folds back on itself in a way that rewards a second look.

That is a lot of scaffolding for something that will change completely the first time you play it. Most attempts die there. The double jump exists, the wall cling exists, and the map is still a rectangle because laying out a good one was the third job on a list of three.

The order that works is the opposite: get movement roughly right, then spend almost all your time on the map, because the map is the game.

Jump height. Air control. Coyote time. The dash that cancels into a jump and the one that does not. This is code, and it is the code that determines whether your game feels good, so it deserves more iterations than anything else in the project.

You describe what you want and Director 1 writes the GDScript. Then you play it and say the jump feels floaty, and it gets less floaty. This loop is fast in a way that hand-writing a character controller is not, and it means you can afford to be picky about a value you would otherwise have set once and left alone.

You never have to open the script. You do have to play it, repeatedly, and have an opinion. That is the deal.

Placement is judgement. Which corridor loops back to the elevator, where the player first sees a door they cannot open, how far the shortcut cuts once it is unlocked — you cannot get that from a sentence, and you would not want to. You build it in the builder, in a 3D view, moving things around.

Stage Engine is built for worlds with real terrain, water and weather, which makes it a strong fit for the branch of the genre that goes outdoors — cliffs, caverns, a coastline you return to with a swimming ability. It is less obviously a fit for a strictly 2D pixel side-scroller, though Godot underneath handles 2D perfectly well.

Ability gates are the joint between the two halves. You place the gate in the world; Director 1 writes the check that decides whether it opens.

A metroidvania needs persistence. Which doors are open, which items are collected, where the last save point was, what the map screen has revealed. It is tedious code with no creative content in it at all, and it is exactly what to hand off.

Same for the map screen itself, fast travel, and the item log. Describe the behaviour, get the implementation, play it, correct it.

A desktop app for Mac and Windows with Godot inside it. Your project is a real Godot project on your disk. The game runs locally when you press play, at your machine's framerate, with no streaming and no browser tab in the way.

Building needs an internet connection because Director 1, asset generation and world data come over the network. Playing what you have built does not. There is no offline build mode and it would be dishonest to imply otherwise.

Between the map and the abilities sits the moment-to-moment: enemies that make a corridor worth traversing, a hit that feels like it connected, a boss whose pattern you learn. This is the content that makes the map feel inhabited rather than empty.

Enemy behaviour is code. Describe the pattern, the tells, the recovery window, and Director 1 writes it into your project. Then play it and say the wind-up is too fast to react to, because that is a judgement only made with a controller in your hands.

The one design warning worth stating: a metroidvania becomes tedious when backtracking has nothing new in it. Enemies that change with progression, shortcuts that unlock, or a reason to revisit are all things to plan while the map is still soft.