Create a Small Horror Game with AI and Test Its Rules

Make the threat understandable before making it frightening

To create a horror game with AI, describe a small playable encounter rather than asking for an entire haunted world. Define where the player goes, what opens the exit, when the enemy notices the player, and how the player can escape pursuit. Atmosphere supports those rules; darkness and loud noises cannot replace them.

The illustrative project here is an abandoned maintenance station with one keycard, one exit, and one patrolling enemy, not a generated or tested game. You will separate route completion, enemy transitions, lighting, and sound into checks that can reveal why an encounter fails. Start on a desktop browser with keyboard and mouse; mobile controls and broader compatibility need their own design and testing.

Copy this constrained horror brief

Create a short first-person browser horror prototype in one maintenance station. Use a connected entrance, corridor, keycard room, and exit room. Controls: WASD movement, mouse look, E interaction, Escape releases pointer lock. The player collects one yellow keycard and uses it at the exit to win. Display the objective and interaction prompts. One enemy patrols three corridor waypoints at 1.5 meters per second. It detects the player within eight meters only with unobstructed line of sight inside a forward 90-degree viewing cone. On detection it chases at 2.5 meters per second. After losing line of sight for five continuous seconds, it visits the last seen position, searches for three seconds, then returns to patrol. Contact causes a clear loss screen with Restart. Restart restores the keycard, player, enemy, and objective. Include a low industrial hum and distinct enemy footsteps; keep the keycard and exit readable. No combat, inventory grid, procedural map, or jump-scare sequence.

Treat the distances and timings as the encounter’s acceptance criteria. Keep them visible in your project notes when reviewing a change.

Step 1: Build the route without the monster

Ask for movement, collisions, the keycard, exit interaction, and restart first. Walk the entire route. Try the exit without the card: it should remain locked and explain what is missing. Collect the card once, check the objective update, then reach the exit and confirm a win.

Restart from the completed attempt and repeat. If the door stays open or the card disappears permanently, the reset is incomplete. Fix that before adding threat. A useful map makes the destination and detour recognizable.

SEELE can be used to request a prompt-led scene and subsequent gameplay changes. The specific interaction, input handling, and browser behavior still need inspection in the output. Do not infer compatibility across devices from one desktop preview.

Step 2: Test patrol, chase, and escape separately

Add the enemy only after the route works. Initially request a temporary debug readout showing its current state, detected target, and last seen position. This is a development aid, not finished horror UI.

Observe one complete patrol circuit. Stand within detection range in an open corridor and check the transition to chase. Then repeat from behind a solid wall: distance alone must not trigger visual detection. Walk behind the enemy outside its viewing cone and compare the behavior.

Next, break line of sight around a corner. The enemy should not continue tracking the player's hidden live position. Reappear before five seconds to confirm that visibility resets the loss timer. Remain hidden longer to check movement to the last seen position, a three-second search, and return to patrol. If the enemy sticks on geometry, isolate that corner and ask for a navigation fix rather than adding more enemies.

Step 3: Give light and sound specific jobs

Request lighting that keeps the walking surface, keycard, and exit distinguishable at the intended display brightness. Reserve deeper darkness for optional corners, not mandatory interaction text. Avoid rapidly flashing effects by default and provide a comfortable volume control.

Define two audio goals: a quiet industrial hum establishes place, while enemy footsteps help communicate proximity. Footsteps should be distinguishable from ambience without abrupt, excessive loudness. If directional or distance-based audio is requested, test movement around the enemy instead of assuming a sound file is spatially positioned.

Test once muted. Players should still understand the objective and loss state through visible feedback. Audio improves the encounter but should not be the only way to learn a required instruction. Also check that the volume setting remains usable during a loss screen and after restarting.

Step 4: Make one verifiable revision

Use a precise follow-up request:

Keep the map, patrol speed, detection cone, loss-of-sight delay, audio, and objective unchanged. Reduce chase speed from 2.5 to 2.0 meters per second. Explain the changed setting and retain the previous working build for comparison.

Repeat the same chase from a marked start position along the same corridor. Compare travel time and whether the player can reach the same corner; record the route and observations. A changed configuration alone does not prove a better experience. Ask a fresh player to attempt the route and note whether they understand how pursuit ends.

If the revision changes patrol or resets the keycard logic, reject the unrelated changes and request a narrower patch. After accepting it, rerun the locked-exit, win, loss, and restart tests.

Use SEELE to iterate on one observed problem

SEELE can support prompt-led scene creation and subsequent changes to gameplay code and assets. Supply the constrained brief, then request the route before the enemy or atmosphere. At each stage, the relevant output is a candidate encounter you can run against a known test, not a promise that every requested behavior is already correct.

When reporting a problem, include your position, enemy state, input, expected transition, and actual observation. A request such as “the enemy detects me through this corridor wall” is more actionable than “make the AI smarter.” Keep a working version before each revision, and confirm available project and export options rather than assuming engine or device support.

Finish one encounter before expanding

A useful first slice has a reachable goal, an understandable threat, and a complete restart. It does not need multiple endings or adaptive difficulty. Keep the encounter small enough that you can explain why the player was detected and how pursuit ended. Atmosphere should sharpen that experience rather than conceal broken rules.

Take the brief to SEELE and request the route first. Preserve each working version and keep test notes alongside it. Add another room or enemy only after the original objective, chase, loss, and restart still work together.

FAQ

Should the monster detect sound in the first prototype?

Not necessarily. Visual detection alone makes the first state transitions easier to diagnose. Add sound detection later as a separate rule with a defined noise event, distance, and investigation response. Otherwise, a chase through a wall becomes ambiguous: you cannot tell whether visibility is broken or sound detection triggered correctly.

How dark should the game be?

Dark enough to support tension, but not so dark that mandatory paths and interaction targets disappear. Test at the actual screen size and ordinary brightness. If players miss the card, improve contrast or placement before adding stronger fog. Visual discomfort and unreadable objectives are not evidence of effective horror.

When is the prototype ready to share?

Share a clearly labeled prototype after testing the full objective, enemy transitions, loss state, restart, audio controls, and target browser. Tell testers about rough edges and intense content. A playable encounter is not a polished commercial release; broader device testing, rights review, and accessibility work remain separate tasks.