Prototype Feature Completion Checklist

Hi! In the previous lesson, you fixed the purpose of this project: a small first-person test room that lets you test looking, walking, sprinting, crouching, and one door. Now you will turn that plan into something practical: a checklist you can use to tell the difference between “the prototype is finished” and “this would be a cool future idea.”

This matters especially for an imaginative game concept. An abandoned theatre could eventually have curtains, stage lights, strange sounds, secrets, and creatures—but your first test needs clear controls before it needs a big mystery.

---

A checklist is a promise you can test

A completion checklist is not a wish list. It is a short set of promises about what your prototype will definitely do.

For each required feature, write a sentence that you can test in the running game. Compare these two versions:

Too vague	Testable checklist item
Make movement feel good	I can walk forward, backward, left, and right without passing through walls.
Add crouching	Holding Left Control makes the player low enough to pass beneath the low obstacle.
Make a door	Standing near the door and pressing $E$ opens or closes it.

The second column is better because you can launch the game, try the action, and honestly tick the box only when it works.

A checklist item describes the result, not the way you build it. For example, “write a movement script” is a task; it does not prove that movement actually works. “The player can move with $W$, $A$, $S$, and $D$” is a result you can prove.

---

Use priorities to protect your project

Game teams often use a method called MoSCoW prioritization. Its odd name is an acronym:

• Must have: required for this version to succeed.
• Should have: important, but the first test can still work without it.
• Could have: a nice extra if there is spare time.
• Won’t have, for now: a saved idea that is deliberately not part of this version.

The most important category is Must have. A feature is a Must only when leaving it out would stop this prototype from answering its main question:

Can a player comfortably look around, move, sprint, crouch, and use one door in a small first-person room?

For example, crouching might be harder to build than adding theatre seats. But crouching is still a Must because it is one of the controls being tested. Theatre seats are not a Must, even if they make the room feel more like your future horror-game setting.

---

A fast way to sort an idea

When a new idea appears, do not decide based only on how exciting it sounds. Instead, ask these questions in order:

1. If I remove this, can I still test the five planned actions?
   If the answer is no, it is a Must have.

2. Does it make the test clearer or more pleasant, but the test would still work without it?
   Put it under Should have.

3. Is it mainly decoration, atmosphere, or an optional extra?
   Put it under Could have.

4. Does it need a whole new system, or turn this into a different kind of game?
   Mark it Won’t have, for now.

Here are some examples for your theatre test room:

Idea	Category now	Why
Mouse look	Must	Without it, you cannot test a first-person view.
$W$, $A$, $S$, and $D$ walking	Must	Movement is one of the prototype’s main tests.
A low passage	Must	You need it to prove crouching works.
One door that opens and closes	Must	This is the one interaction being tested.
A short on-screen “Press E” reminder near the door	Should	Helpful for clarity, but the door can still be tested without fancy interface design.
Dark blue walls and a dim warm light	Could	It supports the theatre mood, but plain colours work for a movement test.
Torn curtains and rows of seats	Could	Interesting scenery, but not needed to test the controls.
A monster that chases the player	Won’t have, for now	It would require enemy behaviour, sound, losing conditions, and lots of extra testing.
Keys, locked doors, and an inventory	Won’t have, for now	This creates a puzzle system instead of testing the planned door interaction.
Multiple rooms and a full theatre map	Won’t have, for now	One room is enough to test the controls.

“Won’t have” does not mean “bad idea” or “never.” It means: I am saving this idea so it does not interrupt the current build. A separate idea list is a creative storage box, not a bin.

---

Your prototype’s completion checklist

Copy this into a notebook, document, or notes app. Keep it somewhere you can see while working in PlayCanvas.

PROJECT: First-Person Theatre Test Room

SUCCESS QUESTION:
Can a player comfortably look around, walk, sprint, crouch,
and use one door in a small first-person room?

MUST HAVE — required before the prototype is complete

[ ] The project launches in a web browser.

[ ] The player sees through a first-person camera and can look
    around using the mouse.

[ ] The player can walk forward, backward, left, and right with
    WASD, and cannot walk through the room walls.

[ ] Holding Left Shift makes the player sprint.

[ ] Holding Left Control makes the player crouch.

[ ] The room has a floor, walls, a ceiling, a doorway, and a low
    passage that requires crouching.

[ ] One door can be used from nearby with E and can be opened
    and closed.

[ ] I can play through the room and test every required action.

SHOULD HAVE — add after the Must list works

[ ] A simple reminder appears when the player is close enough to use the door.
[ ] The room is easy to see, with simple lighting and different wall/floor colours.
[ ] Movement feels controlled rather than too fast or slippery.

COULD HAVE — only if the required prototype already works

[ ] A few theatre-like colours or materials.
[ ] One flickering light.
[ ] Simple curtain or seat shapes made from blocks.

WON'T HAVE IN THIS PROTOTYPE — save for a future project

[ ] Enemies, combat, health, or a game-over screen.
[ ] Inventory, keys, locks, or puzzles.
[ ] A full story, dialogue, cutscenes, or saving.
[ ] Multiplayer, mobile controls, or controller support.
[ ] More rooms or more usable doors.

The Must have section is intentionally short. If it grows too long, completing it becomes much harder. A useful rule is:

Do not add a new Must-have because it sounds fun. Add one only if the prototype cannot test its main controls without it.

There is one important exception: if you discover a bug that prevents a Must-have feature from working, fixing that bug belongs in the project. You are not expanding the scope; you are keeping your original promise.

---

Tick boxes only after evidence

A common mistake is ticking a box when you have created part of something. For example, you might make a door-shaped block and think, “Door done!” But a door-shaped block is not yet a usable door.

Use a tiny test for each completed item:

Checklist item	Evidence before ticking it
Walking	Launch the game and try all four movement directions near walls.
Sprinting	Hold Left Shift and notice a clear speed difference.
Crouching	Pass beneath the low passage while crouched.
Door interaction	Stand nearby, press $E$, and see the door open and close.
Whole test room	Play through all of the above in one running session.

This turns “I think it is finished” into “I tested it, and it works.”

For now, leave the boxes empty. You will tick them gradually as later lessons teach you how to build each part. That is normal: a checklist is useful because it shows what is still missing without making the project feel mysterious.

---

Keep an idea parking lot

Whenever you imagine something beyond the scope, write it down immediately under a heading such as Theatre Ideas for Later. Then return to your current checklist.

For example:

THEATRE IDEAS FOR LATER

- A ghost light shining onto a stage
- A backstage maze
- A note left in a dressing room
- A silent mannequin that changes position
- A locked prop-room puzzle
- Strange applause after the player opens a door

This is a good habit for a designer. You are not trying to stop ideas from appearing. You are making sure each idea has the right time to be built.

Once all the Must-have boxes work, you can look at the Should-have list. Only after that should you choose a small number of Could-have ideas. The Won’t-have list waits until a future project or a later version with a new, deliberate scope.

---

Key takeaways

A completion checklist turns your prototype scope into testable promises. For this project, the required list is built around one purpose: proving that first-person looking, walking, sprinting, crouching, and one door interaction work in a compact room.

Remember:

• A Must-have is required to test the prototype’s central actions.
• A Should-have improves the test but can wait until the Must list works.
• A Could-have is optional atmosphere or polish.
• A Won’t-have, for now item is a protected future idea, not a rejected one.
• Tick a box only after testing the result in the running game.

Next, you will open up the PlayCanvas editor more confidently by learning what its main areas—the viewport, hierarchy, inspector, and asset panel—are for.