A horror game maker for people who understand pacing
Horror is made of restraint, sound and timing, and almost none of it is technical. The technical part is what stops most people, which is the part this removes.
Horror is a pacing problem
What makes a horror game work is not the monster. It is the four minutes before the monster, where nothing happens and the player becomes certain something is about to. Get that wrong and no amount of design on the creature saves it. Get it right and a corridor with a dripping pipe is terrifying.
That means the craft is in timing, restraint and the shape of a space. How long the player is alone. How far they can see. Whether the sound stops or continues when something goes wrong. These are decisions you make by walking through the thing and feeling it, and then changing it because it was too slow or not slow enough.
None of it requires you to write code. All of it requires you to iterate fast enough to feel the difference between eight seconds of silence and twelve.
Build the place first
In Stage Engine you build the world by hand. That suits horror particularly well because the place is the mechanism. You shape the ground, put fog in the low parts, place the buildings, decide where the sightlines break and where a corner hides the rest of the corridor.
Weather and sky are part of the toolkit rather than decoration. A world where the light actually falls, where fog thickens, where rain covers the sound of footsteps, gives you the vocabulary horror runs on. A flat evenly-lit room does not, which is why so many first horror games feel like a well-lit warehouse with a jumpscare in it.
Because the game runs locally on the copy of Godot bundled with the app, the world can carry real terrain, weather and things moving in it without the compromises a browser tool has to make. That is what makes a dark forest an option rather than an ambition.
Then say what stalks it
Director 1 writes the behaviour. You describe it: the thing follows sound rather than sight, it loses you if you stand still for six seconds, it does not enter lit rooms, it gets faster the longer you have survived. That becomes GDScript inside your Godot project.
Then you play it in the dark, which is the only way to know. Almost always the first version is wrong in an instructive way — it is too fast, or too obvious, or it kills you before the dread has anywhere to go. You say what is wrong and it changes, and you go again.
That cycle is where the game gets made. Nobody designs good horror on paper. They design it by being frightened by their own build, or failing to be, and adjusting.
What to try in the first hour
Build one corridor and one room. Make the corridor long enough to be boring. Put a sound at the far end that stops when the player gets close. Do not add a monster yet. Play it, and see whether you tense up. If you do not, the problem is the space, and adding a creature will not fix it.
Then add something that reacts to the player rather than a scripted event. Reactive fear lasts and scripted fear works once, and the difference is worth learning early on a small scene rather than late on a big one.
Building needs an internet connection because Director 1, asset generation and world data come over the network. Playing what you built does not. The download is free with a free plan, Indie is $10 a month and Pro is $50 for more usage.
Questions
- Do I need to code to build the enemy behaviour?
- No. You describe how it should behave and Director 1 writes the GDScript into your project.
- Can I do first-person horror?
- Yes. First-person in a real 3D world is the shape the tool is built for.
- Does it handle darkness, fog and weather?
- Yes, and those are core rather than extras. Sky, weather and fog are part of how you build the world.
- Where does the game run?
- Locally on your machine, on the copy of Godot bundled with the app. No streaming, no browser.
- Can I make a 2D horror game?
- Godot handles 2D, but the tool is shaped around 3D spaces. For 2D horror, a 2D-first tool is a better fit.