Prototype Poppy Playtime: scope, mechanics, and design lessons for a first-person horror prototype

Prototype Poppy Playtime: scoping a first-person horror prototype that holds together

A clean prototype of a Poppy Playtime-style game is not a small horror scene with a chase. The commercial game combines three pressures: a first-person camera that has to stay readable while the player is being hunted, a tight grappling-hook system that doubles as the puzzle and traversal tool, and a small but loud cast of toy characters whose behavior has to feel deliberate, not random. A team that treats the genre as “just stealth” usually produces a flat vertical slice where every encounter plays the same way. A team that treats the prototype as a systems problem, where the toy AI, the player tool, and the level grammar all constrain each other, can ship a build that actually demonstrates the fantasy within a fortnight.

This article walks through how a small team can scope, design, and validate a prototype poppy playtime build without copying the game’s IP, art, or puzzles. It is written for producers, technical designers, and solo developers who already know Unreal Engine or Unity well enough to wire up a first-person controller, and who need a concrete plan for what to cut, what to keep, and how to test the result before committing to a vertical slice.

What the reference design actually relies on

Before drawing a single room, it helps to be specific about which design elements a Poppy Playtime-style prototype needs to preserve, and which ones the player only notices because the full game spends dozens of hours polishing them. A prototype is allowed to be ugly. It is not allowed to lose the systems that create the fantasy.

The three load-bearing systems

The reference design published and updated by MOB Games under the Poppy Playtime franchise rests on three systems that all have to work in the same frame:

• A first-person character controller with full mouse look, crouch, sprint, and a clear distinction between walking pace and running pace, because stealth timing depends on that gap.
• A two-handed cable tool that can extend a left hand and a right hand, grab distant objects, pull levers, and re-route power. The cable is the same tool used for combat against large toys, so the prototype cannot split it into two unrelated gadgets.
• Toy AI with a hearing radius, a sight cone, a chase state, and at least one scripted “stun” reaction when a specific environmental object is used. Without that reaction, the toy is just a moving wall.

What the prototype can drop without losing the pitch

A first vertical slice rarely needs more than one toy archetype, one environmental hazard, and one multi-step puzzle. Story cinematics, multiple chapters, multiple grabbable tool upgrades, and full audio mixes can wait. A clean prototype that demonstrates one toy, one tool, one puzzle, and one chase is enough to decide whether the project deserves a longer pre-production phase. The product page for the first chapter is the simplest external reference for what a finished chapter actually ships with, and the rest of this article assumes the prototype is targeting a similarly small surface area.

Scope and team shape for a two-week prototype

Most independent horror prototypes collapse because the team tries to model a full level before the core loop is playable. The schedule below fits two engineers, one technical artist, one designer, and one audio generalist, and is the most common shape that ships a credible vertical slice on time.

Week one: graybox, controller, and one toy

Days one and two should be a graybox of a single room, plus the character controller and a placeholder grab mechanic. Days three and four add one toy that can patrol, hear footsteps, and chase the player on sight. Day five is a first pass at a stun interaction, usually a door the player can slam shut in the toy’s face. Days six and seven add the first puzzle, a power-routing task where the player has to grab a battery and slot it into a fuse box, while a toy patrols the connecting corridor.

Week two: pacing, audio, and the playtest

Day eight introduces a second room and one scripted chase moment. Day nine is the first audio pass: a heartbeat curve tied to toy proximity, a single footstep set, and one breath loop for the player. Day ten is internal playtest one, recorded and reviewed the same day. Day eleven fixes the top three blockers, day twelve adds an on-screen affordance for the grab range, and day thirteen runs a second external playtest. Day fourteen is for the recording of a single unbroken gameplay clip and a written postmortem.

Roles that can flex and roles that cannot

Producer or lead designer. Owns the daily cut, the playtest list, and the scope freeze on day six. Without a written cut, every playtest becomes a moving target.

Engineer for the controller and the cable tool. This is the highest-risk role. The cable system has to handle grabbing a static mesh, holding it, releasing it, and re-grabbing a different object, all without breaking collision. If this role slips by more than a day, the audio pass and the chase moment both lose their anchor.

Engineer or technical designer for the toy AI. The toy needs a perception component, a state machine, and at least one navmesh link for the scripted chase. This role is allowed to be the same person as the cable engineer on a two-engineer team, but only if the level design is already locked before they start.

Technical artist. Owns the lighting pass, the post-process volume, and the first-pass asset integration. A horror scene lit like an office kills the genre, and a horror scene with no shadows at all kills the threat. The technical artist’s job is to find a middle ground the graybox can actually hold.

Audio generalist. Owns the footstep set, the toy vocalizations, the heartbeat curve, and one stinger for the chase. The audio role can be a contractor for the prototype and still ship a useful build, as long as the Wwise or FMOD event names are stable by day eight.

Designing the grab-pack and cable system

The two-handed cable is the most imitated element of the reference design, and also the one most prototypes get wrong. The most common mistake is treating each hand as a separate raycast. The grab system only feels right when both hands share a single cooldown, a single retract animation, and a single “busy” state that locks the player out of sprinting while a hand is extended. For broader context on Poppy Playtime, the Wikipedia article provides a concise reference for this section.

State machine for a two-handed cable

The state names below are deliberately engine-agnostic. In Unity they map cleanly to an Animator with two bool parameters, and in Unreal they map to a state tree with the same transitions. The point is the transitions, not the engine.

State	Entry condition	Exit condition	Player movement allowed
Idle	Both hands retracted, no active grab	Player presses left or right fire while aiming at a valid grabbable	Full walk, sprint, crouch
Extending	Fire pressed and a valid grabbable is in range	Cable reaches target or misses	Walk only, slower turn rate
Holding	Cable tip touches a static grabbable	Player releases fire, or target becomes invalid	Walk only, no jump
Retracting	Fire released or target lost	Cable reaches hand anchor	Walk only, jump allowed on the last frame
Cooldown	Retract complete	Cooldown timer reaches zero	Full movement after timer ends

The cooldown state is what prevents the player from spamming the cable and trivializing the toy. A two-second cooldown is long enough that the player has to plan a pull, and short enough that an honest mistake is not punished.

Validation rules for a believable cable

Before the prototype is “playable,” the cable system has to pass four scripted checks. None of them is about art, and all of them are about feel.

• Distance check: the cable can reach a handhold that is exactly at the maximum advertised range, and the visual tip touches the handhold at the same frame the system registers the grab.
• Snap check: a small static mesh placed 0.25 meters behind a door frame can still be grabbed, because the cable sweeps a small volume at the tip instead of a perfect ray.
• Release check: if the grabbed object is destroyed mid-grab, the cable enters Retracting within one frame and does not leave a ghost object in the world.
• Failure feedback: if the player fires the cable at a non-grabbable wall, the system plays a short thud and the cooldown starts immediately, so the player learns the failure mode within the first attempt.

Designing the toy AI without making it feel random

The reference game is unusually disciplined about how its toys behave. Huggy Wuggy, CatNap, and the smaller enemies all share a perception pipeline: a hearing radius, a sight cone, a memory timer, and a scripted “lure” state. A prototype can copy that pipeline with a single behavior tree and still feel distinct from the reference, as long as the toy reacts to specific player inputs instead of every player input.

Perception pipeline that holds up in playtest

The pipeline below assumes one toy, one patrol route, and one chase corridor. It is intentionally boring. Boring AI is easier to balance than clever AI, and a prototype does not need clever AI.

Sense	Stimulus	Detection radius	Detection angle	Memory duration	Notes
Hearing	Player footstep, player sprint, player cable miss thud	14 m walking, 22 m sprinting	360 degrees	6 seconds	Crouching drops footstep loudness by 70 percent
Sight	Direct line of sight to the player capsule	18 m lit, 9 m in shadow	110 degree cone	4 seconds	Crouching does not affect sight, only the player’s silhouette
Scripted lure	Specific interactable in the level, for example a noise maker	Entire level	360 degrees	15 seconds	Used once per chase, never reused
Hazard	Door slam, fuse overload, power surge	10 m	360 degrees	8 seconds	Triggers the toy’s stun state

Two design rules matter more than the numbers. First, hearing must dominate the early game, because a player who has not yet seen the toy needs to be taught that the toy exists. Second, sight must dominate the chase, because a chase that is triggered by sound alone becomes a guessing game the player can ignore.

The three states a prototype actually needs

A full state machine for a horror toy can run to a dozen states. A prototype can collapse that to three, and the third state is the only one that is allowed to be polished.

• Patrol: a fixed spline with two or three waypoints, a slow walk speed, and a one-second pause at each waypoint. Patrol is what the player sees most of the time, so the toy’s walk animation and footstep set have to be believable even at this stage.
• Investigate: triggered by hearing, sight, or a scripted lure. The toy walks toward the last known stimulus, plays a single vocalization, and either returns to patrol or escalates to chase. The escalation decision is the single place the prototype has a small amount of randomness, and that randomness is what makes a second playthrough feel different.
• Chase: full sprint toward the player, no pathfinding tricks, and a single melee attack. The chase is the only state where the toy’s speed is allowed to be slightly faster than the player’s sprint, because the player is expected to use the environment to break line of sight.

Level grammar for a single chapter

Horror levels are not corridors. They are small rooms connected by short sight lines, with one chase corridor and one puzzle room. A prototype that copies that grammar will feel finished even with placeholder art. A prototype that copies a long corridor from the reference game will feel empty even with full art.

The four room types

The reference design uses the same room grammar across its chapters, and a prototype can use the same four room types with three of them grayboxed.

• Safe room: no toy access, one or two pickup objects, a save point. Used to reset the player’s heartbeat curve and to teach a new mechanic before the next chase.
• Patrol room: open layout, multiple sight lines, the toy visible at the far end. The player has to read the toy’s patrol and pick a path.
• Puzzle room: toy blocked by a one-way door, puzzle in the center, and a hazard that the player can trigger if the puzzle goes wrong. The puzzle is allowed to be obvious in a prototype, as long as the loop of fail, retry, and succeed is readable.
• Chase corridor: a long, narrow room with one door at each end, no side rooms, and at least one obstacle the player can grab with the cable. The chase corridor is the only room where the toy is allowed to sprint from the start.

Sight lines and lighting as design tools

A common mistake is to light the level as if the player is exploring an office. Horror lighting needs a hard contrast between a key light and a fill light, with the fill light at 20 percent or less of the key light. A patrol room lit at 80 percent fill looks like a museum. The same room lit at 15 percent fill looks like a playroom after hours. The difference is one or two light values, not new assets.

Sight lines are even cheaper to fix. A sight line is the distance the player can see from a given doorway before something blocks the view. A good rule of thumb for a prototype is that every doorway should have a sight line of between four and eight meters, with a clear “cover” object placed at the midpoint. That cover object is what the player learns to run toward when the chase starts.

Audio design that a prototype can actually finish

Horror audio is usually the last system a prototype schedules, and the first one that makes the difference between “scary” and “flat.” A prototype does not need original music. It needs three layers of diegetic sound, one sting, and a heartbeat curve that follows the toy’s distance. For an independent view of buy poppy playtime: chapter 1, the verified article adds source-specific context to this discussion.

Layered ambient that does not collapse

The three diegetic layers are continuous sounds that have to be mixed so that they do not interfere with each other. A common failure mode is a single ambient loop that is too loud, which means the player cannot hear the toy’s footstep set. A working prototype mixes the layers so that the heartbeat is always at least 6 dB louder than the ambient, and the toy’s footstep set is always at least 3 dB louder than the heartbeat when the toy is within ten meters.

• Background hum: a low-frequency loop, around 60 Hz, that sits under the entire level. Plays at -18 dB. Used to make silence feel uncomfortable.
• Mechanical rattle: a mid-frequency loop, around 250 Hz, that sits in the patrol rooms. Plays at -12 dB when the toy is patrolling, fades to -24 dB in safe rooms.
• Heartbeat: a layered loop that follows the toy’s distance, with the BPM mapped to the closest distance in the last three seconds. Plays at -9 dB at one meter, -18 dB at twenty meters.

The single sting

A prototype only needs one sting, and it should be reserved for the moment the chase starts. A sting is a short, high-frequency sound, usually under one second, that fires once and never repeats. The point of the sting is to train the player to flinch, and a prototype cannot afford to use it more than once because the second use is always less effective than the first.

Playtest design for a two-day validation cycle

A prototype that does not get playtested is not a prototype, it is a build. The most common failure is a playtest that runs for two hours and produces a list of complaints. The fix is a 25-minute playtest with a written script, a recorder, and a single hypothesis to validate.

The hypothesis template

Before each playtest, write a one-sentence hypothesis. The sentence has three parts: a behavior, a metric, and a threshold. For example: “Players will complete the fuse puzzle without dying more than once, on the first attempt, within four minutes.” If the playtest does not produce a number that can be compared to that sentence, the playtest is not done yet.

What to record

Two cameras and a system log are the minimum. One camera follows the player’s hands, the other follows the player’s face. The system log captures player position, toy position, the cable state, the toy’s state, and the audio bus levels every tenth of a second. The system log is what makes a playtest reproducible, because it is the only artifact that can be replayed without the player.

What to ask the player

After the playtest, ask the player exactly three questions. The first question is “what were you trying to do when you died?” The second is “what did you think the cable was for, before the tutorial?” The third is “did you feel chased, or did you feel herded?” The third question is the one that decides whether the prototype is selling the fantasy, because a player who feels herded is going to feel herded for the entire chapter.

Common failure modes and how to diagnose them

A horror prototype that is technically complete and emotionally flat usually has one of three problems. The fix is different in each case, and the diagnosis is what most teams skip.

The flat-chase failure

Symptom: the player reaches the chase corridor, the toy spawns, the chase happens, and the player feels nothing. Diagnosis: record the chase and look at the player’s face. If the player’s face is calm, the chase is too slow, the sting is too quiet, or the chase corridor is too wide. A working chase has a corridor of no more than four meters wide, a toy that closes the gap in under three seconds, and a sting that fires the same frame the chase starts.

The invisible-toy failure

Symptom: the player walks past the toy three times without noticing it. Diagnosis: the toy’s silhouette is too low or too similar to the background. A horror toy needs a silhouette that breaks the background, usually with a tall, narrow shape and a saturated color. A toy that is shorter than the cover objects in the room is a toy the player will walk past on every playthrough.

The trivial-puzzle failure

Symptom: the player completes the puzzle in under thirty seconds, and the prototype loses its only moment of relief. Diagnosis: the puzzle has no failure state. A puzzle that cannot fail is a fetch quest. A working prototype puzzle has at least one state where the player has to start over, and that reset is what gives the success state its weight.

The over-instrumented failure

Symptom: the prototype has every system running, the playtest is technically clean, and the player still does not feel threatened. Diagnosis: the prototype is showing its work. A player who can see the toy’s navmesh, hear the toy’s debug footsteps, and read the toy’s perception radius on screen is a player who is no longer roleplaying. The fix is to remove every debug overlay before the second playtest, not to add more systems.

Validation gates before committing to a vertical slice

Once the two-week prototype is finished, the team has to make a single decision: greenlight a longer pre-production phase, or shelve the project. The decision should be made on the back of four numeric gates, not on gut feel.

Gate	Measurement	Target	Source
Chase completion	Percentage of playtesters who reach the chase corridor	90 percent or higher	System log
Puzzle success	Average time to complete the fuse puzzle on first attempt	3 to 5 minutes	System log
Toy encounter rate	Number of times the player sees the toy per playthrough	4 or more	System log
Player-reported fear	Self-reported tension on a 1 to 7 scale after the playtest	5 or higher	Post-playtest survey

If three of the four gates pass, the project is worth a longer pre-production. If only two pass, the team should write a postmortem, archive the build, and apply the lessons to the next prototype. A team that greenlights on a single gate is usually greenlighting on enthusiasm, and enthusiasm is the worst metric in horror design.

Frequently asked questions

What engine is best for a prototype poppy playtime build?

Both Unreal Engine and Unity are workable. Unreal has a stronger out-of-the-box first-person template and a faster lighting pass, which is useful when the prototype is short on art. Unity is faster to iterate on for designers, and a smaller team can usually wire up the cable system in less time. The choice is usually a matter of which engine the team already has a working controller in, not a matter of which engine is “better” for horror.

How long should a prototype poppy playtime build actually take?

Two weeks is a realistic target for a team of four or five. A solo developer should plan for four to six weeks, because the cable system, the toy AI, and the audio mix each take about a week of focused work for one person. A team that quotes a prototype in less than two weeks is usually planning to skip one of those three systems, and the prototype will show it.

Can a prototype be made without original art?

Yes, and it usually should be. The point of a prototype is to validate the systems, not the art. A grayboxed level with a single primitive toy mesh, a flat ambient loop, and a placeholder cable material is enough to run a playtest. Replacing the placeholders with original art is a separate phase, and that phase should not start until the playtest gates are passing.

How do you avoid copying the reference design too closely?

The safest approach is to keep the genre and the camera, and change every named element. A prototype can use a first-person camera, a cable-based tool, a single toy archetype, and a horror tone without copying a specific character, level, or puzzle. The legal risk is in the named characters, the art, and the level layout, not in the camera or the tool. A team that keeps the tool generic and the toy abstract will be able to ship a prototype that is clearly a different product.

What is the most common reason a horror prototype fails?

Over-instrumentation. Teams that ship a prototype with every system running, every debug overlay on, and every audio bus audible are usually the same teams whose playtesters report feeling nothing. A horror prototype is a magic trick, and the magician is the one who decides what the player is allowed to see.

How many puzzles should a prototype have?

One. A prototype that ships with three puzzles is a vertical slice, not a prototype, and a vertical slice that has not been playtested is a prototype that is lying about its size. The single puzzle should be the most representative puzzle of the game, the one the team would put in the first thirty minutes of the final product.

Should the prototype include a save system?

No. A save system adds at least two days of work, and a two-week prototype is short enough that a single playthrough is the entire playtest. The only time a save system is justified is when the team needs to run partial playtests, and that is a sign that the prototype is already too long.

How do you measure whether the prototype is actually scary?

Self-reported tension is the cheapest metric, and it is the one most teams should use. Ask the player to rate their tension on a 1 to 7 scale immediately after the playtest, and ask the same question after they have seen the chase once. A working prototype produces a higher number after the chase, because the chase is supposed to be the most tense moment. A prototype that produces a flat number is a prototype that has not yet built the player’s expectation.

What is the difference between a prototype and a vertical slice?

A prototype is a system test. A vertical slice is a content test. A prototype that is “ready for vertical slice” is a prototype where the cable, the toy, the audio, and the level grammar have all been validated by at least two playtests. A vertical slice is the first thirty minutes of the final product, with final-quality art, final-quality audio, and final-quality pacing. The two phases should never be merged, because a prototype that is also a vertical slice is usually neither.

Related reading

• Design within reach: a working guide to the brand and what it offers
• Grand design in branding: what it is and how to use it