1. Lesson identity
This lesson does not build a playable micro-loop. It does not teach the rest of module 1.1.
2. Learning objective
After this lesson, you can look at a short game description and classify it as a feature, a repeating gameplay loop, or an incomplete behavior, and give a brief reason.
3. Why this matters
A first idea for a game is often a shopping list: movement, enemies, health, coins, doors. The list can sound like a product. Players do not play a list.
They enter a cycle. They act. The game answers. Something is different. That difference gives them a reason to act again.
If you cannot see that cycle, later work has nothing to protect. You will be tempted to keep adding names until the idea “feels like a game.” Extra names do not create a repeating experience.
Later in this course you will need to describe behavior clearly enough that an AI agent can reason about it. That skill starts here: seeing what repeats. This lesson does not ask you to prompt an agent, edit a project, or use a coding assistant.
4. Prior knowledge
Course prerequisites only. You do not need programming, an engine, or prior game-design vocabulary.
5. Core concept
Think of a game in two different ways.
Feature-list thinking names capabilities and objects: movement, enemies, health, coins, doors.
Loop thinking names a repeating relationship: the player moves through space, meets a threat, takes an action, the game evaluates the result, state changes, the player receives feedback, the player chooses the next action.
A feature description tells us what the game has or allows — including a bare capability such as “the player can dash.” A loop description tells us what repeatedly happens between player and game. An incomplete behavior description starts to describe a causal or repeating sequence but stops before a necessary response, change, decision, or return is stated.
A game loop is a cycle the player can enter again. Features can be real and still not, by themselves, form that cycle. They gain meaning through relationships and repetition, not by sitting next to each other on a list.
You do not need a formal four-part implementation model yet. First see whether a cycle is described clearly enough to reason about.
6. Mental model — Act → Respond → Change → Again
Hold four questions against any idea:
What does the player do repeatedly?
What does the game respond to?
What changes because of that action?
Why does the player act again?
If you cannot answer them from the description, the loop is not yet clear enough to analyze. These four questions are this course’s working model, not a universal definition of every game loop.
The next lesson diagrams the same cycle as INPUT/ACTION → UPDATE/RULES → PRESENTATION → FEEDBACK. The four questions here are how you recognize that cycle before you draw it.
Keep this model smaller than the Stage 1 micro-loop you will build later. Do not turn these four questions into an engine spec in this lesson.
7. Concrete examples
Collect. You pick up a coin. The score changes. You keep searching. The coin is a feature. The repeating search is the loop the description gives.
Avoid. You move. An obstacle is in the path. You steer. Surviving the next second is why you steer again.
Attack. You strike. The target’s state changes. Feedback tells you whether to strike, wait, or leave.
Interact. You use a key on a door. The game checks a condition. A result is shown. If that result sends you looking for the next key, the interaction is feeding a loop. If it happens once and never again, it is closer to a single event.
None of these examples require an engine. They require you to see repetition.
8. Common mistake
Wrong assumption: “My game has many features, therefore it has good gameplay.”
A pile of disconnected names is not a player experience. Feature count is not behavioral coherence.
Ten screens, bars, and items can still leave the player with nothing to do next. One small coherent cycle can already form the foundation of a playable game experience.
A related mistake is treating a genre label (“it’s a platformer,” “it’s an RPG”) as if it were a loop. A genre label suggests conventions and expectations, but it does not by itself describe the specific cycle your player repeats.
9. Practice
Worked example
Take this list: movement, enemies, health, coins, doors.
As a list, every item is a feature description. None of them, alone, says what repeats.
A loop version of the same material might be: the player moves through space, meets a threat, takes an action, the game evaluates the result, something changes (position, threat, resource), feedback arrives, the player chooses the next move.
The nouns did not disappear. They started to mean something because they sit inside a cycle.
Your turn
Classify each description as FEATURE DESCRIPTION, LOOP DESCRIPTION, or INCOMPLETE BEHAVIOR DESCRIPTION. You are judging what the text tells you, not whether a real game could contain that capability. Write one sentence saying why. Do not ask an AI to classify them for you.
Use the wording as evidence. A bare capability is a feature description; an incomplete behavior description starts a sequence but leaves out a necessary response, change, or return.
Try first. Compare with the notes only after you have written your own labels.
1. The game has a health bar, an inventory screen, a map, and a crafting menu.
2. You search rooms for coins. Each coin raises your score. The rising score is why you open the next door.
3. The player can dash.
4. You swing at a target. A hit knocks it down. The fallen target, or the ones still standing, tells you whether to swing again or move.
5. You enter a shop, buy a better weapon, and then…
After you label them, check your reasoning:
1. Intended label: FEATURE DESCRIPTION. This description tells us things the game has — objects and screens. It does not say what repeatedly happens between player and game.
2. Intended label: LOOP DESCRIPTION. Search, collect, score change, and a reason to search again. The coin can be a feature; the repeating search is the loop this description actually gives.
3. Intended label: FEATURE DESCRIPTION. This is a bare capability statement: it tells us an action the game allows, so it is a feature description. It does not describe the game’s response, a resulting change, or a return to the action, so it is not a loop.
4. Intended label: LOOP DESCRIPTION. Attack, evaluation, a visible change, and a decision to continue. That is a repeating encounter cycle, not a list of combat features.
5. Intended label: INCOMPLETE BEHAVIOR DESCRIPTION. This begins a causal sequence, but it stops before describing the result, the next decision, or a return to the activity. It is therefore an incomplete behavior description, not yet a loop.
Practical check
Choose a familiar game and describe its core loop in four steps: player action, system response, consequence or reward, and the reason the player repeats the action.
10. Validation / self-check
Use this test on your own ideas:
If I removed the feature names, could I still describe what repeats and what changes?
If the description collapses into silence without the words “shop,” “dash,” or “inventory,” you were holding feature labels, not a described cycle. If you can still say what the player does, what the game answers, what changes, and why they continue, you are thinking in loops.
11. Key takeaways
A feature description tells us what the game has or allows. A loop description tells us what repeatedly happens.
Ask: what repeats, what the game responds to, what changes, why the player acts again.
Feature count is not behavioral coherence.
Incomplete behavior means the description does not yet give enough response, change, and reason to continue — not that the capability is “not a feature.”
You will name the parts of one cycle in the next lesson. This lesson only asks you to see that a cycle exists.
12. Knowledge check
Answer these four items for yourself before reading the answers. This is a short comprehension check: they test whether you can tell a list from a cycle.
A description lists a map, a shop, a jump, and a health bar. This is closest to:
Show answer and feedback
Answer: A feature list
Why: Those are feature descriptions: capabilities and objects the game has. A loop description would say what repeats, what changes, and why the player continues.
If a prototype includes many features, it necessarily has coherent gameplay.
Show answer and feedback
Answer: False
Why: Feature count is not the same as behavioral coherence. Disconnected names do not form a repeating player experience.
“You dash past a guard. The guard turns toward you, and then…” This is closest to:
Show answer and feedback
Answer: Incomplete behavior
Why: The text begins a causal sequence: the player acts and the guard responds. It then stops before stating what changes, what the player decides, or how the activity continues, so it is an incomplete behavior description.
Which description is closest to a repeating gameplay loop?
Show answer and feedback
Answer: You grab a gem, your count goes up, you look for another gem.
Why: Grab → count changes → hunt again. The other options are a list of nouns or a genre label, not a cycle.
13. Connection to the next lesson
The next lesson in module 1.1 will ask you to draw one cycle and name its parts. Do not do that work yet. Do not build a playable loop. Leave this lesson when you can tell a shopping list from a repeating behavior — including when the text is too thin to be either.
Preview only: the cumulative artifact is Pulse Loop at academy-fixtures/pulse-loop (fix-pulse-loop). Do not run it yet. Next lesson you will map and execute it.