Feature Prioritization for Prototype Scope

Good to see you again. You now have a focused first-game concept: a top-down 3D escape prototype in which the player recovers three energy cores and reaches the exit. The intended experience is capable exploration with satisfying route choices, and the win condition is clear enough to test.

The next design challenge is protecting that idea from becoming much larger than your first prototype can support. This lesson gives you a practical way to decide which features belong in the first playable version, which can wait, and which deliberately do not belong.

---

Scope is a design skill, not a lack of ambition

A game idea grows very easily. “Collect three cores and escape” can quickly acquire patrolling robots, combat, puzzles, dialogue, upgrade trees, procedural levels, online co-op, and cinematic story scenes. Any one of those could be worthwhile in another project. But adding them now would make it harder to learn whether the collect, navigate, choose routes, escape loop works.

Your first prototype is an MVP, or minimum viable product: the smallest playable version that can produce useful feedback about the core experience.

For this course, “viable” does not mean commercially complete, visually polished, or packed with content. It means a player can understand the goal, take the main actions, receive feedback, and reach a clear outcome.

Watch this short explanation of MVP thinking before applying it to your own game.

The central test is simple:

If removing a feature means the player cannot meaningfully perform the core loop or the prototype cannot test its intended experience, it is essential.

A feature may be exciting, difficult, or visually impressive without being essential. Conversely, a plain grey box that blocks movement can be essential if navigation and route choice are central to the game.

---

Three categories for this prototype

Professional teams often use the MoSCoW method to prioritize requirements: Must have, Should have, Could have, and Will not have for now. For a solo beginner prototype, we will simplify it to three practical decisions:

1. Essential: must be present for the first playable collect-and-escape loop to work.
2. Optional: valuable enhancement, but the prototype remains understandable and testable without it.
3. Out of scope: intentionally excluded from this prototype. It may be a good future idea, but it does not serve the current test and would significantly expand the project.

The important words are “for this prototype.” An out-of-scope feature is not a bad feature, and an optional feature is not being rejected. You are deciding what to build now so that you can get a functioning game, observe players, and improve the parts that matter.

For your project, use this translation:

MoSCoW term	Prototype term	Meaning here
Must have	Essential	The core loop or clear win condition fails without it.
Should have / Could have	Optional	Adds clarity, enjoyment, or polish, but can wait until the loop is tested.
Will not have now	Out of scope	Does not belong in this initial collect-and-escape prototype.

---

Decide by the player experience, not by feature excitement

Before categorizing a feature, return to your design foundations:

• Experience: feel like a capable explorer making satisfying route choices.
• Objective: recover three energy cores and escape the ruin.
• Win condition: collect all three cores, then enter the exit area.

Now examine each proposed feature using four filters.

1. Does it enable a required player action?

The player must be able to move through a 3D space, find cores, collect them, and reach an exit. Features directly enabling these actions are strong candidates for essential status.

2. Does it communicate an essential game state?

The player needs to know what is collectible, how much progress they have made, whether the exit is locked, and when they have won. The feedback can be simple; it does not need final visual effects or elaborate interface panels.

3. Does it test the intended experience?

A compact level with at least a small route decision helps test exploration and navigation. A perfectly straight corridor with all cores in a line would technically satisfy the win condition, but it would not test the route-choice experience you want to create.

4. Is there a smaller version that serves the same purpose?

This is the scope-saving question. For example:

• Essential need: the player can tell that the exit has unlocked.
• Smallest version: change the exit’s color or show “Exit unlocked.”
• Optional enhancement: a modeled door opens, lights activate, particles burst, and an alarm sound plays.

The need is essential. One particular elaborate implementation is not.

---

Your first prototype: essential features

Here is a sensible essential scope for the collect-and-escape prototype. These are not necessarily built all at once; they are the minimum set your eventual first playable build needs.

Essential feature	Why it is essential
A controllable player representation	The player must perform the central action: navigating the space.
A readable top-down camera	The player needs enough visibility to make movement and route decisions.
A compact 3D greybox space with boundaries, walls, or obstacles	There must be a navigable environment in which route choice can exist.
Basic collision where walls are intended to block the player	Routes have no meaning if the player can pass through every obstacle.
Three visible energy cores	These are the progression objects required by the objective.
A way to collect each core	The core loop requires player contact or interaction to change game progress.
Clear progress feedback	The player must be able to tell that collecting cores matters. A simple counter is enough.
A recognizable exit with locked and unlocked states	The player needs a destination and must understand when it becomes available.
A win response when the player enters the unlocked exit	The prototype needs a definite, testable ending.

Notice what is not on this list: detailed ruins, an animated character, enemy AI, background music, or a score system. Their absence does not stop a playtester from answering the key design question:

Is navigating a small 3D space to gather cores and escape clear and enjoyable?

This scope is deliberately aligned with the course’s early modules. You will first create the scene and greybox, then learn enough JavaScript to implement behavior, then add movement, collision, collection, and a win state. At each stage, you are building toward a playable version rather than assembling disconnected technical demonstrations.

---

Optional features: keep them visible, but do not let them block progress

Optional features are often useful. The mistake is not having them; the mistake is treating them as prerequisites for testing the core loop.

For your game, create an optional list in priority order:

Optional feature	Value it adds	Why it can wait
Cores slowly rotate or bob	Makes collectibles easier to notice	Static, high-contrast cores can already be found and collected.
Collectible particle effect	Makes acquisition feel more satisfying	The count changing and core disappearing already communicate success.
Sound effects for collection and unlocking	Reinforces important events	The game can be tested silently at first.
Decorative ruin models, textures, and lighting	Strengthens atmosphere	Grey boxes can test routes and readability.
An animated exit door	Makes unlocking more dramatic	A simple visible state change proves the rule works.
A timer	Adds urgency	It changes the experience from unhurried exploration to time pressure. Test the base loop first.
A moving hazard	Adds challenge and risk	It requires extra movement, collision, reset, and tuning work.
More than one level	Adds variety	One compact level is enough to test the core loop.

An optional item can become essential later if the design changes. For example, once you add hazards, a clear restart system becomes much more important because players will need repeated attempts. Scope decisions are conditional, not permanent labels.

---

Out of scope means an explicit “not now”

A first-time designer may hesitate to put ideas out of scope because it can feel like abandoning them. In reality, an explicit boundary protects the ideas that matter most.

For this prototype, classify these features as out of scope:

Out-of-scope feature	Why it does not belong in the first prototype
Online or local multiplayer	Multiplies technical complexity and changes the game’s central experience.
Combat system with weapons and health	Creates a different core loop that competes with exploration and collection.
Multiple enemy types with AI behaviors	Requires significant implementation and balancing before you have tested basic navigation.
Inventory, crafting, or equipment upgrades	Adds systems that do not directly support collecting three cores and escaping.
Dialogue trees, quests, or branching narrative	Requires content and interface work beyond the prototype’s purpose.
Procedurally generated levels	Makes it harder to control and test route design in a first greybox.
Open world or multiple large maps	Expands level-production work far beyond one focused test space.
Achievements, leaderboards, accounts, or monetization	Do not help establish whether the central play loop works.

A useful distinction: “out of scope” is not the same as “never.” You can save these ideas in a document called Later Ideas. This keeps them from being forgotten without letting them interrupt the current build.

---

Handle ambiguous features by splitting them apart

Feature requests often sound like one thing but contain several separate requirements. Split them before categorizing them.

Consider the request: “Make a cool exit door.”

That phrase could hide four features:

Smaller requirement	Classification
The exit exists as a visible destination.	Essential
The exit prevents victory until all cores are collected.	Essential
The exit visibly changes after the third core.	Essential, in a simple form
The exit plays a detailed opening animation with lights and sound.	Optional

Splitting prevents a false choice between “implement a beautiful door” and “have no exit.” The game needs an exit mechanic, not necessarily a finished art asset.

Use the same approach with “add enemies.” A single stationary hazard, a patrolling enemy, several enemy types, combat, damage, and health pickups are not one feature. They are a stack of systems. For now, all of them remain out of scope so you can establish the non-combat exploration loop first.

---

Create your scope board

In your design notebook, add a page titled Prototype Scope: Collect and Escape. Make three headings: Essential, Optional, and Out of Scope.

Start with the lists from this lesson, then add any ideas you already had. Give each feature a short reason rather than relying on instinct alone:

Feature	Category	Reason
Three collectable energy cores	Essential	Required by the objective and win condition.
Core pickup sound	Optional	Adds feedback but is not required to test collection.
Combat with robots	Out of scope	Adds a competing loop and substantial extra systems.

Finally, write this scope statement at the top of the page:

This first prototype tests whether moving through a compact 3D space, choosing routes, collecting three cores, and escaping through an unlocked exit creates a clear and satisfying experience.

When a new idea appears during development, compare it to that statement before adding it. If it does not help test the stated experience, place it in Optional or Out of Scope rather than immediately building it.

---

Key takeaways

A small prototype is not an incomplete version of a huge game. It is a deliberate experiment built to test a specific player experience.

For your 3D collect-and-escape game:

• Essential features enable movement, navigation, collecting three cores, understanding progress, unlocking the exit, and winning.
• Optional features improve feedback, atmosphere, challenge, or polish after the core loop works.
• Out-of-scope features such as multiplayer, combat, large-scale AI, crafting, and multiple worlds would distract from the focused first test.

When in doubt, identify the underlying player need, look for the smallest implementation that satisfies it, and defer everything else.

Next, you will move from the design notebook into production by creating and saving a PlayCanvas project and learning the main areas of its browser-based editor.