29. Lesson identity
This lesson teaches you to protect one mapped loop from features that do not support it yet. It is not anti-feature. It does not teach Game feel. It does not build a playable micro-loop.
30. Learning objective
After this lesson, you can take one clearly mapped gameplay loop and one proposed extra feature, then decide KEEP NOW, DEFER, or REJECT FOR THIS LOOP, and justify that decision with behavior — not excitement.
31. Why this matters
Lesson 1 asked you to see a loop. Lesson 2 asked you to map one. Mapping is not yet protection.
A mapped loop still attracts extra ideas: weather, shops, skill trees, photo modes, companions. Some of those ideas will later earn a place. Many of them pull attention away before the current behavior is coherent.
Move from “I have lots of ideas” toward “this feature either supports the loop I am building, or it does not belong yet.”
32. Prior knowledge
Lessons 1 and 2 of this module: you can tell a feature description from a loop description, and you can map one small repeating behavior as ACT → RESPOND → CHANGE → AGAIN. This lesson does not repeat those drills. It asks you to judge a proposed addition against a loop you can already point at.
33. Core concept — core loop vs feature gravity
A feature earns its place by supporting the behavior you are trying to create.
A feature may be interesting, impressive, technically possible, or common in the genre, and still not belong in the current loop.
Core loop — the repeating behavior you have mapped and are protecting right now. Not “the whole game I might ship someday.”
Feature gravity — the tendency for attractive ideas to pull a project outward before the current behavior is coherent.
You are still reasoning about a game loop with the analytical model from Lessons 1 and 2. You are not yet using a later implementation model. Do not treat this as product-management training, backlog work, or a rule that small games are always better.
34. Decision test
Use this small filter. It is not a studio process.
What is the loop?
What does this feature change inside that loop?
Does it strengthen an existing ACT, RESPOND, CHANGE, or AGAIN?
Does the loop still work without it?
Is this needed now, or simply interesting?
Then choose:
KEEP NOW — the feature directly strengthens the current bounded loop now. Keep it even if the loop could technically survive without it.
DEFER — the feature could strengthen this same loop later, but the required context, dependency, depth, or design is not present yet. Defer is not “bad feature,” and it is not a parking lot for every unused idea.
REJECT FOR THIS LOOP — the feature belongs primarily to another loop, system, or product layer, even if it may still be a good feature for the overall game. Reject-for-this-loop is not a lifetime ban.
DEFER and REJECT FOR THIS LOOP are not synonyms. Defer stays with this loop later. Reject belongs elsewhere.
35. Concrete examples
Supports the loop. Current loop: attack → hit or miss → enemy state changes → choose the next action. Proposed feature: enemy stagger feedback. The stagger helps the player read the result and choose the next action. That is KEEP NOW.
Does not support this version yet. Current loop: search → collect → count changes → search again. Proposed feature: a weather system that does not currently change search or collect decisions. Weather could later modify this same loop — visibility, which places hide finds, search conditions — but those relationships are not defined yet. That is DEFER.
Belongs elsewhere. Same search/collect cycle. Proposed feature: a tavern where players chat and trade hats. That belongs primarily to a social, trade, or collection loop. It could still exist elsewhere in the complete game. REJECT FOR THIS LOOP.
Depends on the claim. Same search/collect cycle. Proposed feature: day/night. If it has no current effect but a plausible later relationship to this same search loop, DEFER. If darkness or day/night materially changes the current search decision now, KEEP NOW. REJECT FOR THIS LOOP would only make sense if day/night primarily served a different loop or system rather than this search behavior. The label follows the behavioral claim, not the feature name.
None of these examples require an engine. None of them say “always cut.”
36. Boundary
This is not “features are bad.” It is not “never expand.” It is not “small games are always better.” It is not MVP theory, sprint planning, or a backlog system.
The narrow question: can this proposed feature be justified by the current gameplay loop?
AI coding agents make new features cheap to generate. That makes this judgment more important, not less. Cheap implementation does not make a feature structurally necessary. This lesson does not ask you to prompt an agent or edit a project.
37. Common mistakes
It is cool, therefore it belongs. Cool is not a behavioral claim. Name what it changes in ACT, RESPOND, CHANGE, or AGAIN.
The genre usually has it. Genre is a neighborhood of expectations, not a permit. A platformer “usually” has a shop. Your mapped cycle might not.
The AI can build it quickly, so why not? Speed of generation is not the same as need. An agent can add a skill tree in minutes and still pull you off the loop you were protecting.
Cut everything. Scope discipline is not minimalism for its own sake. If a feature strengthens the loop, it should stay.
38. Practice
Worked example
Loop: you judge when to run between waves. A wave reaches you or passes by. If it reaches you, it pushes you toward the pier edge and puts you into a brief recovery state. Before the next wave, you decide whether to wait for balance or run again.
Proposed feature: a photo mode with filters.
What does it change inside this loop? Nothing about judging the opening, running, being pushed, recovering, or choosing the next move.
Does the loop still work without it? Yes.
Needed now, or interesting? Interesting at the product level — a sharing layer, not this cycle.
Decision: REJECT FOR THIS LOOP. Photo mode may be valuable at the product level, but it does not strengthen the wait / run / wave / recovery cycle. It may still belong in the game later. It simply belongs outside this loop.
Classify proposed features
Here is one mapped loop. Classify each proposed feature as KEEP NOW, DEFER, or REJECT FOR THIS LOOP. Write one sentence of reasoning for each. Judge support for this bounded loop, not whether the idea could ever be good. DEFER and REJECT FOR THIS LOOP are not synonyms: defer stays with this same loop later; reject belongs to another loop, system, or product layer. Do not ask an AI to classify them.
Item 4 is thin on purpose. More than one label can be defensible if you say what would have to be true.
Try first. Compare with the notes only after you have written your own labels and sentences.
Mapped loop: You shine a lantern into a dark alcove. Something glints, or the alcove stays dark. Your find count changes, or it does not. You shine into the next alcove because you still want another find.
1. A short glint sound when something is actually there.
2. A weather system. Rain and sun do not currently change which alcoves hide finds, or whether shining is worth doing.
3. A tavern hub where lantern-bearers chat and trade cosmetic hats.
4. (ambiguous — reasoning required) A day/night cycle.
Notes after you try
1. KEEP NOW. KEEP NOW. The sound strengthens RESPOND: the player can tell glint from empty and choose the next alcove with better information. The loop still works without it, but it earns its place by supporting the current decision.
2. DEFER. DEFER. Weather does not currently change ACT, RESPOND, CHANGE, or AGAIN. It could later strengthen this same lantern/search loop — visibility, alcove availability, search conditions, or the value of shining — but those relationships are not defined yet. DEFER means possibly part of this same loop later, not a parking lot for every unused idea, and not a claim that weather is a bad feature.
3. REJECT FOR THIS LOOP. REJECT FOR THIS LOOP. Chat and cosmetic trade belong primarily to another behavior: social, trade, or collection — not shine → response → find state → search again. The tavern could still exist elsewhere in the complete game. REJECT FOR THIS LOOP is not a lifetime ban and not “bad feature.”
4. Reasoning. Ambiguous on purpose. As written, day/night is only a name. DEFER is sound if it has no current behavioral effect, but a plausible later relationship to this same search loop. KEEP NOW is defensible only if darkness or day/night materially changes the current search decision now. REJECT FOR THIS LOOP would only make sense if day/night primarily served a different loop or system rather than this search behavior.
Practical check
List three planned features, then cut the one least essential to the core loop. In two or three sentences, explain what development cost or player confusion the cut avoids and why the game still works without it.
Your own idea
Return to the tiny cycle you mapped in Lesson 2. Do not build anything.
Write one tempting additional feature.
Apply the five-question decision test.
Choose KEEP NOW, DEFER, or REJECT FOR THIS LOOP.
Justify the decision in one or two sentences, tied to that mapped loop.
39. Validation / self-check
For each proposed feature, ask:
Does this support the loop now? → KEEP NOW.
Could it support this same loop later if missing conditions were added? → DEFER.
Does it primarily belong to a different loop, system, or product layer? → REJECT FOR THIS LOOP.
Also ask: Did I keep this only because it is cool, common in the genre, or cheap to generate?
40. Key takeaways
A feature earns its place by supporting the behavior you are trying to create.
Feature gravity pulls attractive ideas outward before the current loop is coherent.
KEEP NOW strengthens this loop now. DEFER could strengthen this same loop later once a missing relationship exists. REJECT FOR THIS LOOP belongs to another loop, system, or product layer — not a lifetime ban.
Cheap AI generation does not make a feature necessary.
Cutting everything is not discipline. A feature that strengthens the loop should stay.
41. Knowledge check
Answer the four selected-response items before opening their answers. Then complete the practical item with a label and your own behavioral justification.
Loop: shine into alcoves → glint or empty → find count changes → shine again. Proposed feature: weather that changes none of those decisions now, but could later change visibility and therefore the same shine-and-search decision. Which label and reason fit best?
Show answer and rationale
Answer: DEFER, because a defined visibility effect could later support this same search loop, but it has no effect now
Why: DEFER. Weather has no effect on the loop now, so it is not KEEP NOW. A defined visibility effect could later alter where or when the player shines the lantern, which remains part of this same search loop. It is therefore not REJECT FOR THIS LOOP: the proposal is not primarily serving another loop, system, or product layer.
Loop: attack → hit or miss → enemy state changes → choose the next action. Proposed feature: enemy stagger feedback that helps the player read the result. Best label:
Show answer and rationale
Answer: KEEP NOW, because it strengthens how the player interprets RESPOND and chooses the next ACT
Why: KEEP NOW. Stagger feedback supports the current loop: it helps the player understand the response and make the next decision. Scope discipline is not a rule that every optional-feeling feature must wait.
If an AI coding agent can add a skill tree in a few minutes, that skill tree has earned a place in the current collect loop.
Show answer and rationale
Answer: False
Why: Cheap implementation does not make a feature structurally necessary. The test is whether the skill tree supports the current loop, not how fast an agent can generate it.
Scope discipline means you should reject every feature the loop can technically survive without.
Show answer and rationale
Answer: False
Why: Question 4 of the filter asks whether the loop still works without the feature. That is not the whole test. A feature that strengthens an existing decision, response, change, or reason to continue should stay.
Practical item — classify and justify
Mapped loop: shine into an alcove → see a glint or darkness → find count changes or stays the same → choose the next alcove.
New proposed feature: a collectible biography journal that unlocks entries after finds but does not change shining, reading the glint, the find count, or the choice of the next alcove.
Choose KEEP NOW, DEFER, or REJECT FOR THIS LOOP. Justify your label in one or two sentences before opening the model response.
Success criteria: name the loop step affected, or state that none is affected; state whether a behavioral effect exists now or only under defined future conditions; and distinguish support for this same loop from service to another loop, system, or product layer.
Show model response
REJECT FOR THIS LOOP. As defined, the journal affects none of the four steps and has no stated future condition that would change this same search behavior. Unlocking biographies primarily serves a collection or lore layer. It could still belong elsewhere in the game; the label is not a permanent ban.
42. Module 1.1 closure
Lesson 1: recognize a loop.
Lesson 2: map a loop.
Lesson 3: protect a loop.
Module capability: you can identify one gameplay loop, externalize it, and decide which additions to KEEP NOW, DEFER, or REJECT FOR THIS LOOP based on whether they support the bounded behavior.
Module 1.2 — Game feel — will ask how the player receives the loop you can now protect. Do not start that work here. Do not assemble a playable micro-loop. Leave this module when you can justify KEEP, DEFER, or REJECT FOR THIS LOOP from the cycle on the page.
43. Depth over extra coverage
If a proposed feature does not feed Pulse Loop (fix-pulse-loop, academy-fixtures/pulse-loop), DEFER or REJECT FOR THIS LOOP. Do not start a second artifact to look busy.