Define what Version 1 is NOT. Freeze the feature set. Shipping requires constraint.
Discussion Question: The video talks about building the smallest possible version of your game that's still fun. Think about your game right now: if you had to ship it TOMORROW, what would you cut? What would you absolutely NEED to keep? Is your game already fun without all the features you wish it had?
Today is not a building day. Today is a decision day. You write down exactly what is and is NOT in Version 1. Then you commit to it. Every feature request from now on gets the answer: "Version 2."
Professional game studios call this a feature freeze. After the freeze, no new features are added — only bug fixes, polish, and testing. This is how games actually ship.
V1 Includes:
- Manhattan base zone
- Camp hub
- 3 danger tiers
- XP banking
- 1 Boss encounter
- Tier unlock gating
- One deeper Manhattan zone
V1 Does NOT Include:
- Multiple bosses
- Inventory system
- Skill trees
- Story cutscenes
- Multiplayer
V1 Includes:
- 14-lot base block
- 3 build tiers
- Debt cap (-50)
- Interest pressure
- Car unlock
- Second block
- Tier gating
V1 Does NOT Include:
- Custom house interiors
- NPC characters
- Rental income system
- Stock market
- City-wide expansion
Time: 20 minutes | Materials: Index cards or paper slips, a "judge" (parent/sibling)
Setup: Each kid writes down 5 features they WISH they could add to their game. One feature per card. Be honest — write the ones you really want.
The Trial: One at a time, each feature goes on trial. The kid plays prosecutor:
- "Your Honor, this feature would take approximately [X] days to build."
- "We have 10 days left in the course."
- "Adding this feature would mean [what gets delayed or cut]."
The jury (parent or sibling) votes: IN or OUT.
The rule: Maximum ZERO features survive. The point is not to sneak one through. The point is that everything is out. Version 1 is locked.
After all 5 are rejected: Take the rejected cards and put them in a pile labeled "VERSION 2 IDEAS." They're not gone — they're deferred. That's not a loss. That's discipline.
Both children can clearly explain what Version 1 includes and does not include. The excluded list is longer than the included list.
This IS the scope definition. No additions after today without removing something.
Making the included list too long — if Version 1 has twenty features, it's not Version 1, it's a wish list.
Not being specific about exclusions — "no extra stuff" is not an exclusion. Name every feature you're cutting.
Thinking "maybe" counts as "no" — "maybe" is "yes" in disguise. If it's not explicitly included, it's excluded.
Leaving the excluded list vague — the excluded list should be specific and longer than the included list.
This is the most important non-technical lesson in the course. The ability to say "No" is the difference between shipping and not shipping. Ask: "How does saying No protect the project?" Celebrate the constraint. The excluded list is an achievement, not a loss.
During the Feature Trial: Play your role as judge seriously. When they present a feature, ask hard questions: "How many days?" "What breaks if we add this?" "Can Version 1 be fun without it?" The answer to the last question is always yes — if it weren't, that feature would already be in the game.
The emotional moment: Some kids will genuinely feel sad cutting features they love. That's healthy. Acknowledge it: "It's hard to say no to something you're excited about. But saying no now means you can say yes later, when you have time to do it right." This is a life skill, not just a game dev skill.
After the activity: Tape the VERSION_1.md printout somewhere visible. For the rest of the course, any time they say "What if we added..." point to the list. The answer is already there.
Looking ahead: Next week we make the game FEEL good — visual feedback, HUD, and polish. The features are locked. Now we make them shine.
Both games have defined feature sets locked in VERSION_1.md. The included list is specific. The excluded list is longer. No new features will be added — only polish, bug fixes, and visual feedback from here forward.