AgentGames

Search titles, descriptions, models and tags. Press Enter to see results.

👻 Guide

How to make a horror game with AI

Sound does most of the work and quiet does the rest. The hard part of a browser horror game is leaving things out, including the monster.

Updated 5 October 2026 7 min read By the Agent Games team
Jump to a section
  1. Four steps to a game that unsettles people
  2. Why the jump scare stops working
  3. Sound, and the button browsers make you add
  4. Limited sight, and what the player fills in
  5. Pacing: long quiet, short loud
  6. Common questions
  7. Where to go next

Ask for sound, limited sight and a threat the player hears long before they see it. Then ask for the quiet. The instinct in this genre is more monster, more noise and a scare on a timer, and all three stop working almost immediately. Restraint is not a style choice here. It is the mechanic.

A scare spends tension. Quiet builds it.

Players adjust to anything repeated. The second identical scare is startling, the third is a pattern and the fourth is funny. So the design job is spending as little as possible: a sound without a source, a corridor you cannot see the end of, and long stretches where nothing happens at all.

Four steps to a game that unsettles people#

Paste the prompt below and play it with headphones on

It writes a dark building, a narrow field of view, a threat you can hear moving, and no scares on a schedule.

Turn the sound off and play it again

It should fall apart. If it plays the same without audio, the audio is decoration and the tension is coming from somewhere cheaper.

Take something away

Make the lit circle smaller, or remove the second sound effect. The build usually improves. That is the test this genre runs on.

Watch one other person play the first minute

Where they stop walking is where the design is working. Where they walk faster is where it is not.

PromptCopy this, paste it, send it
Build a quiet top down horror game as ONE self-contained .html file.
No frameworks, no images and no audio files. Draw with canvas shapes
and make every sound with the Web Audio API.

START: the game opens on a title screen with a single start button.
Nothing moves and nothing sounds until it is pressed. Browsers refuse
to play audio before the player has interacted with the page, so
create the audio context inside that button handler and start the
first sound there.

THE PLACE: a dark building of connected rooms on a grid, described in
a data object. Arrow keys or WASD walk.

SIGHT: the screen is black apart from a soft circle around the player
and a narrower cone in the direction they face. Walls stop the cone.
The player must never see a whole room at once.

THE TASK: four switches hidden in the building, then the exit. Show
how many are left and nothing else.

THE THREAT: one thing moving through the rooms. Do not draw it at all
until it is inside the lit circle. Make it audible the whole time: a
slow step sound that gets louder as it nears and quieter as it goes,
panned left or right depending on which side it is on.

PACING: the threat spends most of its time far away and unhurried. It
closes in now and then, then loses interest. The long stretches where
nothing happens are deliberate. Do not fill them.

SOUND: the steps, one low room tone that never stops, and one short
sound for being caught. All synthesised, all sparse.

CAUGHT: the screen fades, the room tone stops and a restart button
appears. No gore, no screaming. Restart from the entrance.

PHONE: dragging walks the player and the facing follows the drag.
Include canvas { touch-action: none; } so a drag cannot scroll the
page.

Base movement and every fade on the seconds that elapsed since the
previous frame, never letting that value rise above 0.05. Put walk
speed, sight radius, cone angle, the threat's speed, its hearing
range and the room tone volume in one CONFIG object at the top, each
with a comment.

The two paragraphs to leave alone are START and PACING. The first is the browser rule and skipping it gives you a silent game. The second is the one a model will quietly undo, because filling empty time looks like an improvement from inside the code.

Why the jump scare stops working#

A scare is a payment, not an income. It spends whatever unease the player had built up, and leaves them at zero. Fire one every ten seconds and nothing ever accumulates, so after a minute the player is not frightened. They are waiting, and waiting is the opposite of what you wanted.

The first build, and the one that keeps working A scare on a timer trains the player. After the second one they are counting. More monster setInterval(scare, 10000)A loud noise on a schedule.Startling once. Expected twice.By the third it is a rhythm. Less, and later heard long before it is seenSteps that get slowly nearer.Sight that ends a few paces out.Quiet long enough to be noticed. Tension is anticipation. A scare spends it, so you cannot spend it often.
The left hand column is what a first prompt tends to produce, because it is the easiest thing to write and it reads as scary in the code.

There is a second reason this matters more in a browser than elsewhere. You have no detailed monster to show. A shape drawn with canvas rectangles is not frightening when the player gets a good look at it, so every second it spends on screen works against you. Keeping it hidden is not a limitation you are working around. It is the stronger choice anyway.

Say this plainly in your prompts, because models will not infer it. Ask for the threat to be invisible until it is close, ask for the gaps between events to be long, and ask for no timed scares at all. Those three sentences do more for the result than any amount of description.

Sound, and the button browsers make you add#

Sound carries this genre, and in a browser there is one rule you cannot design around. Audio will not play until the player has clicked or tapped once. A game that starts straight into a dark corridor starts in silence, and silence that was not chosen reads as a broken build.

So a browser horror game needs a start screen with a button, and the first sound has to begin in the handler for that press. This is the single most common reason a first attempt feels flat, and it is not a bug in the game logic. The audio simply never got permission to begin.

What you wantWhat to ask forWhy it works
Dread that never liftsOne low room tone that never stopsThe player stops hearing it and misses it when it cuts
A threat with a positionStep sounds panned left or rightDirection without anything on screen
A threat with a distanceStep volume rising as it nearsThe player tracks it by ear and chooses a route
A moment that landsOne short sound, used almost neverRarity is the whole effect
ReliefSilence when a door shuts behind youTaking sound away is also a sound cue

All five can be synthesised in the file, so none of them costs you an asset or a loading screen.

Keep the count of distinct sounds small. Two or three the player comes to know beat a dozen they cannot tell apart. Recognising a sound is what lets them feel the difference between near and far.

Limited sight, and what the player fills in#

A circle of light around the player is the cheapest effect in this genre and the most effective. It is a black canvas with a soft radial hole in it. What it buys is not atmosphere. It is the player's own imagination, which is better at this than anything you can draw.

Where the tension actually comes from All five are cheap in a browser. None of them is a detailed monster. Sound Steps, breathing, a door. Louder as it closes in. Limited sight A circle of light. The player invents the rest. Heard, not seen A threat with a sound and no shape, for a while. Quiet stretches Nothing happens. This is what makes the next thing land. One steady task Something to do with shaking hands. A switch, a lock. Remove any one of these and the other four get noticeably weaker.
These work together or not at all. Limited sight with no sound is just a dark screen, and sound with full visibility gives the player nothing to wonder about.
  • Make the radius smaller than feels fair. Then test it. Almost every first build is too generous, and a wider circle removes the reason to move carefully.
  • Add a facing cone. Having to turn to look is the whole point, because it means the player chooses what not to see.
  • Let walls stop the light. A corridor you cannot see down is worth more than any drawn detail at the end of it.
  • Never show a map of the building. Being lost is a feature, and it is free. A map deletes it in one line.

The same thinking applies to anything you put on screen. One line saying how many switches are left is enough. Health bars, timers and warnings all tell the player where they stand, and not knowing where they stand is the thing you are trying to build.

Pacing: long quiet, short loud#

Pacing in horror is a ratio, and the quiet side of it has to be uncomfortably long. A stretch where nothing happens feels like a mistake while you are building and feels like the best part while somebody is playing. Trust the second reading, because yours is the only session that already knows what happens next.

The practical version is a threat that mostly ignores the player. It wanders, comes closer, then loses interest and goes. The player hears all of that, so the gaps are not empty. They are spent listening, and listening is the activity the whole design is for.

Keep the loud moments rare and short. One sound at the point of being caught, and nothing else above the room tone. If you find yourself adding a second big moment to keep things interesting, the quiet stretch before it is the part that needs work instead.

👻Horror games written by AI

Common questions#

Can AI make a horror game?

Yes, and the code is the easy half. The hard half is asking for less than the model offers. It will fill every quiet gap and put the threat on screen early, because both look like improvements from inside the file rather than from the player's chair.

Why is my game silent?

Browsers will not play audio until the player has interacted with the page. Add a start screen with a button, create the audio context in that button's handler, and start the first sound there. Nothing in the game logic needs changing.

How many jump scares should a short game have?

Fewer than you think, and none on a timer. A scare spends the tension you built, so each one has to be earned by the quiet in front of it. If a scare could happen at any moment, the player braces continuously and stops feeling it.

Should the monster be visible?

Not early, and not for long. A shape drawn from canvas rectangles loses all of its weight once the player studies it. Let them hear it for a long time first, then show it briefly and take it away again.

Does horror work without good graphics?

It works better than most genres without them, because the player supplies the detail. Limited sight, sound that carries distance and a threat kept off screen do not depend on art at all, which is why this genre suits a single file.

How do I make it scary without anything unpleasant?

Unease comes from not knowing, not from content. A sound with no source, a door that is open when you left it shut, a corridor that ends out of sight. None of that is distressing to look at and all of it makes a player slow down.

Where to go next#

When somebody plays it with headphones on and stops walking, put it up. It gets a page recording the model and the prompt behind it, and the first thing you learn is which sound people actually noticed.

The general method is in how to make a game with AI. If the building is turning into a place with people and locked doors, the adventure guide covers how to hold that state. Wording for common faults is in the prompt guide, and the horror games here are best played with the sound up.