First-Person Movement and Door Interaction Prototype

Hello! This course begins by building a very small first-person prototype in PlayCanvas: a test room where you can look around, move, sprint, crouch under an obstacle, and use one door. It is not meant to be a complete horror game yet. It is a safe, small space for proving that the controls feel right before you add theatre scenery, monsters, puzzles, or a story.

In this lesson, you will decide exactly what this first prototype is—and, just as importantly, what it is not. A fixed scope protects a project from becoming too large to finish.

---

A prototype answers one important question

A prototype is not a mini version of every idea for the final game. It is a rough playable experiment built to prove something specific.

For this course, the question is:

Can a player comfortably explore a small first-person space using walking, sprinting, crouching, and one simple door interaction?

That is enough to learn a great deal. You can notice whether walking feels too slow, whether sprinting is exciting or uncontrollable, whether crouching is clear, and whether the door is easy to use.

The room can look plain because its job is to test gameplay. Game developers often call this kind of space a test room or a gym: a scene designed to experiment with one part of a game rather than impress people with finished art.

The image shows an important idea: basic shapes are not “bad graphics.” At this stage, they are useful tools. A plain wall makes it much easier to tell whether the player is colliding with it properly than a wall covered in fancy posters, torn curtains, and props.

---

“Core feature” does not mean “cool feature”

It is easy to imagine a suspense game and immediately picture flickering lights, secret rooms, a creepy soundtrack, locked doors, a monster, notes to collect, and complicated puzzles. Those could be good future ideas. But they cannot all be part of the first prototype.

A feature belongs in this prototype only if removing it would stop you from testing the player controls and one interaction.

For example:

• Removing mouse look means it is no longer a first-person test.
• Removing walking means there is no movement to test.
• Removing sprinting means you cannot judge whether moving quickly feels good in the space.
• Removing crouching means you cannot test passing under a low obstacle.
• Removing the door means you cannot test whether the player can interact with something in the environment.

But removing a monster does not stop any of those tests. Removing a detailed theatre lobby does not either. They are ideas for later, not requirements for now.

This is not giving up on imaginative ideas. It is protecting them. If you finish the small version, you will have working controls that future rooms, stories, and scary moments can build upon.

---

The fixed scope for this project

A scope should be written in observable language. “Make movement good” is too vague: two people could disagree about whether it is finished. “The player can hold Shift to move faster” is observable: you can launch the game and test it.

Here is the scope contract for the prototype you will build through this course.

Prototype statement

Create a browser-based first-person test room where one player can use a mouse to look, use the keyboard to walk, hold a key to sprint, crouch to pass beneath a low obstacle, and open or close one nearby door.

For now, choose standard desktop controls:

Part of prototype	Fixed decision	What “working” means
View	First-person camera controlled by the mouse	Moving the mouse changes what the player sees without the camera flipping upside down.
Walking	$W$, $A$, $S$, and $D$ keys	The player moves forward, left, backward, and right, and does not pass through the room’s walls.
Sprinting	Hold Left Shift	The player moves faster only while Shift is held.
Crouching	Hold Left Control	The player becomes low enough to move beneath a low passage, then returns to normal height when there is space.
Door	One door, activated with $E$ nearby	The door can be opened and closed deliberately, rather than being only a decoration.
Test space	One compact indoor room	The space has walls, a floor, a ceiling, a low passage, and one doorway.

A few choices here might seem tiny, such as choosing $E$ for the door or deciding that crouch is held rather than toggled. They matter because a fixed scope prevents you from repeatedly changing the rules while you are still trying to build them. You can improve them later after testing, but first you need one clear version that works.

---

Define the boundary: what is deliberately absent

Every good scope has two sides:

1. Included features tell you what must be built.
2. Excluded features stop extra work from sneaking in.

For this prototype, the following are deliberately out of scope:

• enemies, combat, health, weapons, or stealth detection;
• multiplayer or online features;
• inventory, keys, locked-door puzzles, collectibles, or saving;
• a menu system, levels, cutscenes, or a complete story;
• detailed theatre models, character models, animations, or realistic sound;
• more than one usable door;
• mobile touch controls or controller support.

This does not mean these ideas are bad. It means they do not help answer the current question about first-person movement and a door. If a new idea appears while you work, give it a name and save it in an Ideas for Later list rather than adding it to the build immediately. The next lesson will turn this distinction into a proper completion checklist.

Scope creep is what happens when “just one extra thing” becomes ten extra things. A monster might need animations, sound, pathfinding, damage rules, game-over screens, and more testing. Suddenly the movement prototype has turned into a different project.

The simplest defense is a useful sentence:

If it does not help test looking, moving, sprinting, crouching, or using one door, it waits.

---

Think in terms of proof, not perfection

The finished prototype does not need to prove that the final abandoned-theatre horror game is complete. It needs to prove a smaller set of things:

• Can the player understand the controls without confusion?
• Does the room provide enough space to feel the difference between walking and sprinting?
• Is the crouch obstacle low enough to require crouching but not frustrating?
• Can the player approach the door, use it, and understand what happened?
• Do these actions feel suitable for a slow, suspenseful game rather than a fast action game?

At this point, “good enough” has a practical meaning: every scoped feature works reliably enough to test. A grey box room with a wooden-looking rectangle for a door is more valuable than a beautiful theatre hallway where the player cannot move properly.

The later parts of the course will gradually build the specific pieces in this scope. First you will make the room, then add simple scene components and scripting, then create the first-person player, then add sprinting and crouching, and finally make the door interactive. The scope stays the same while the prototype becomes more complete.

---

Keep this one-page plan

Before opening PlayCanvas, keep the following short plan somewhere easy to find, such as a notebook or a document:

PROJECT: First-Person Test Room

Goal:
Test first-person looking, walking, sprinting, crouching, and one door.

Player controls:
Mouse: look
WASD: walk
Left Shift: sprint while held
Left Control: crouch while held
E: use door

Room:
One indoor test room with walls, floor, ceiling, low passage, and one door.

Not in this prototype:
Enemies, puzzles, inventory, story, multiple rooms, detailed art, multiplayer.

This is your project’s guardrail. When you get a brilliant idea for a secret ghost, a broken elevator, or a stage full of mannequins, write it down—but do not let it replace the small test you are trying to finish.

---

Key takeaways

A prototype is a focused experiment, not a full game. This course’s prototype has one clear goal: test first-person looking and movement, sprinting, crouching, and a single usable door in a compact room.

Your fixed scope includes:

• mouse look and keyboard walking;
• hold-to-sprint and hold-to-crouch controls;
• one low obstacle and one usable door;
• a plain, browser-playable 3D test room.

Everything else—including enemies, story, detailed theatre art, and extra mechanics—waits for later. In the next lesson, you will turn this scope into a completion checklist, separating the features that are required from exciting ideas you want to save.