14. Lesson identity
This lesson maps one small cycle on paper. It does not build a playable micro-loop. It does not teach Lesson 3.
15. Learning objective
After this lesson, you can take one small repeating gameplay behavior, diagram it as INPUT/ACTION → UPDATE/RULES → PRESENTATION → FEEDBACK, and explain how perceivable feedback informs the player's next input.
16. Why this matters
Lesson 1 asked you to see a loop in a description. Seeing is not yet enough to reason about the loop. “Fight enemies” still sits in your head as a blob.
When you write the parts down, you can point at them. You can notice a missing input, an unspecified rule or state update, a result the player cannot perceive, or feedback that does not support another decision.
Later in the course, a clear behavioral map will help you brief an AI agent without saying vague things like “make combat better.” This lesson does not ask you to prompt an agent or edit a project.
17. Prior knowledge
Lesson 1 of this module: you can classify a short description as a feature description, a loop description, or an incomplete behavior description. This lesson does not repeat that classification drill. It asks you to map one cycle that is already a loop.
18. Core concept
A game loop is easier to reason about when you externalize it. The job is behavioral clarity, not formal diagram notation.
Instead of holding “fight enemies” in your head, write something you can inspect: the player attacks → the rules determine the hit and update the target's state → animation, sound, and a health display expose the result → the player uses that feedback to choose the next attack or another action.
This is a behavioral model: rules determine and apply the state change, presentation makes the result perceivable, and feedback is the information the player uses to choose the next input. It is not an engine loop or an architecture diagram.
19. Mental model — INPUT/ACTION → UPDATE/RULES → PRESENTATION → FEEDBACK
INPUT/ACTION → UPDATE/RULES → PRESENTATION → FEEDBACK
↑______________________________________________|
INPUT/ACTION — the player's command or action in this cycle.
UPDATE/RULES — the rules that evaluate the input and apply any state change.
PRESENTATION — the visible, audible, or otherwise perceivable way the game exposes the updated state.
FEEDBACK — the information the player receives and uses to choose the next input. Draw a return arrow from here to INPUT/ACTION.
Draw it on paper. Arrows and a return mark are enough. No UML, flowcharts, or state machines.
20. Concrete examples
Collect. You pick berries. The rules check the bush and update the basket count. The bush changes and the new count appears. The remaining target count tells you whether to search for another bush.
Avoid. You duck under a swinging log. Collision rules determine whether it hits and update your state. Motion, sound, and the safety indicator expose the result. That feedback helps you time the next duck.
Attack. You throw a snowball. Hit rules update the snowman's state. A section falls away, or a miss effect appears. What you see tells you whether and where to throw next.
Interact. You pull a lever. The rules check its condition and update the gate. The gate opens or a locked signal appears. That feedback tells you whether to pass or try another input.
Each example is one cycle, not a whole game. None of them require an engine.
21. Boundary — sequence vs loop
Not every chain of steps is a repeating gameplay loop.
Press Start → an intro cinematic plays → the title disappears. That can be a clear sequence. It does not, by itself, return the player to another gameplay decision.
Ask: Does this cycle meaningfully return the player to another decision or action? If it runs once and the activity is over, you mapped a sequence. Recurrence here is about gameplay reasoning, not a mathematical proof that something repeats forever.
22. Common mistakes
Noun chain with arrows. Player → inventory → enemies → shop. Those are names. They do not identify an input, the rules and state update, a perceivable presentation, or useful feedback.
The whole game. One cycle, one behavioral question, one repeating unit. If your page includes combat, crafting, travel, and a story campaign, you have not drawn one cycle. Narrow it until one behavioral question remains.
State change mistaken for presentation. “Health decreases” describes an update. Add how the player perceives it: for example, a shorter health bar, a hit animation, or a sound.
Feedback without loop closure. Draw the return arrow and state which next input the player can choose because of the feedback.
23. Practice
Worked example
Description: You choose when to run between waves. Collision rules determine whether the wave hits and update your position. Movement, spray, and sound show where you ended up. Seeing the next wave and your position helps you choose whether to wait or run.
INPUT/ACTION: run or wait on the pier.
UPDATE/RULES: collision and movement rules determine the hit and update your position.
PRESENTATION: motion, spray, and sound show whether you remain on the pier.
FEEDBACK: your visible position and the approaching wave inform the next choice to wait or run.
Loop closure: that feedback leads back to the next run-or-wait input.
Choose and map
Read these four descriptions. Choose one that is a repeating gameplay loop. Map it as INPUT/ACTION → UPDATE/RULES → PRESENTATION → FEEDBACK, including a return arrow to the next input. Commit your map before opening the models. Do not ask an AI to map it. Do not write code.
1. The game has a bestiary, a skill tree, and a photo mode.
2. You toss bait. The rules determine whether a fish bites and update the catch state. The float moves and the catch count appears. Those signals help you decide when to pull or recast.
3. You press Start. A studio logo plays. The title screen appears.
4. You step on a pressure plate. The rules update the bridge state. The bridge extends, or a locked signal appears. What you see tells you whether to cross or try another action.
Check the eligible choices and model maps
A correct choice is 2 or 4. 1 is a feature list. 3 is a one-shot sequence.
Model map for 2: INPUT/ACTION toss bait → UPDATE/RULES determine the bite and update the catch state → PRESENTATION show float movement and the catch count → FEEDBACK use those signals to choose pull or recast → next input.
Model map for 4: INPUT/ACTION step on the plate → UPDATE/RULES evaluate the condition and update the bridge state → PRESENTATION show the bridge extending or a locked signal → FEEDBACK use that result to choose cross or try another action → next input.
Practical check
Draw one complete cycle of your game. Label the player action, immediate feedback, resulting state change, and what sends the player back into the next cycle. Check that every arrow has a clear cause and effect.
Missing part
This description is incomplete on purpose: You talk to the merchant.
Name which parts of INPUT/ACTION / UPDATE/RULES / PRESENTATION / FEEDBACK are missing or too thin. Commit your answer, then open the check.
Check the missing parts
INPUT/ACTION is named. The rules and state update, their perceivable presentation, and the feedback that could inform the next input are not given.
Your own cycle
Take one idea from a game you imagine. Map one behavior only — collect, avoid, interact, attack, or reach something. Not a whole game. Draw or write INPUT/ACTION → UPDATE/RULES → PRESENTATION → FEEDBACK, then one sentence for why it continues.
24. Validation / self-check
Point at your map:
What input or action does the player provide?
Which rules evaluate it, and what state do they update?
How does the game make the updated result perceivable?
What information does the player gain for the next choice?
Does an arrow connect that feedback to the next input?
If one part or the return connection is missing, the map is incomplete. Also ask: Did I describe behavior, or did I drift back into feature names?
Scored performance check
Without copying an earlier example, map this behavior: You press a button to launch a paper plane. Flight rules update its path according to the current wind. The plane's motion and landing marker show the result. You use the landing position and wind indicator to adjust the next launch.
Submit a four-part diagram with a return arrow and one sentence explaining how feedback leads to the next input. Score one point for each item:
all four canonical parts are named in the correct order;
the input and rule-driven state update are behaviorally specific;
presentation states what the player can perceive;
feedback identifies information used for the next choice;
the return arrow closes the loop.
Passing check: 4/5, with presentation and loop closure both present. Revise the map if either is absent.
25. Key takeaways
Diagram one cycle as INPUT/ACTION → UPDATE/RULES → PRESENTATION → FEEDBACK → next input.
Rules determine and apply the state change; presentation exposes it; feedback informs the next action.
A sequence of steps is not automatically a repeating gameplay loop.
Arrows between nouns are not a map.
Map one small unit. The next lesson will ask you to cut what does not feed that unit. Do not do that work yet.
26. Knowledge check
Stop and answer each item before opening its answer panel. This check covers the four-part loop, a missing part, sequence versus loop, and noun chains.
Which description is a mapped repeating gameplay loop, not a chain of nouns?
Answer
Answer: You kick the ball. The rules determine whether it enters the goal and update the score. The goal animation and scoreboard show the result. You use that feedback to choose the next kick.
Why: B identifies an input, a rule-driven state update, a perceivable presentation, and feedback that informs the next input. A is a noun chain. C only sketches a genre and features.
Map: INPUT/ACTION — you pull the rope. UPDATE/RULES — the mechanism updates the bell state. FEEDBACK — you hear whether the signal succeeded and decide what to do next. Which part is missing?
Answer
Answer: PRESENTATION — how the updated bell state becomes perceivable
Why: The map names the input, update, and feedback, but it does not state how the player perceives the updated bell state. Ringing sound or visible movement could provide the presentation.
You press Continue. Credits roll. The words “The End” appear. This is closest to:
Answer
Answer: A one-shot sequence
Why: Steps happen in order, then stop. The player is not returned to another gameplay decision in that cycle.
If you draw arrows between player, inventory, enemies, and shop, you automatically have a gameplay loop.
Answer
Answer: False
Why: Arrows between nouns do not identify the input, the rule-driven state update, its perceivable presentation, or the feedback that informs the next input.
27. Connection to the next lesson
The next lesson in module 1.1 will ask you to cut a tempting feature that does not feed the loop you can now map. Do not refuse features yet. Leave this lesson when you can put one small cycle on paper and say why it continues.
28. Executable work — Pulse Loop (fix-pulse-loop)
Open academy-fixtures/pulse-loop. Inspect src/game.mjs. Run node src/cli.mjs demo then node src/validate.mjs. Collect evidence/last-run.json with --write. Later stages keep this same repository and run node src/cli.mjs progression. Do not start a second game. Git: checkpoint after a successful run. This artifact continues through later stages.