36 min read

You built a core mechanic in Chapter 5. Your character moves. Your character attacks. There is input and there is output. Congratulations --- you have an interaction.

In This Chapter

Chapter 6: The Core Loop --- The Heartbeat of Every Game

You built a core mechanic in Chapter 5. Your character moves. Your character attacks. There is input and there is output. Congratulations --- you have an interaction.

Now I have bad news: an interaction is not a game.

A game is not a single action. A game is a cycle. The player does something, the game responds, and that response creates the conditions --- the motivation, the opportunity, the need --- for the player to act again. That cycle is the core loop. It is the most important concept in game design, and it is the thing that separates a forgettable tech demo from a game that devours four hundred hours of someone's life.

Every game that has ever held you past midnight has a core loop. Every game you put down after twenty minutes and never picked up again had a broken one. The core loop is the heartbeat of your game. If it stops, the game dies.

This chapter is about understanding that heartbeat, designing it deliberately, and building your first one.

6.1 What Is a Core Loop?

A core loop is the smallest repeating cycle of player action in a game. It is the sequence of verbs that a player performs over and over, where the output of one cycle feeds into the input of the next.

The simplest way to think about it is a four-beat cycle:

Act --> Feedback --> Reward --> Act Again

The player does something. The game tells them what happened. The result creates a new condition --- a new resource, a new challenge, a new opportunity --- that motivates the next action. And the cycle repeats.

This sounds abstract. Let's make it concrete with four games that represent four very different genres, audiences, and design philosophies --- and all four have immaculate core loops.

💡 Intuition: If you want to know whether a game has a strong core loop, ask one question: "Does the output of one cycle naturally create the input for the next?" If yes, the loop is self-sustaining. If no, the game needs external motivation (story beats, quest markers, achievements) to keep the player moving --- and that means the core is not carrying its own weight.

6.2 Four Core Loops, Dissected

Diablo: Kill --> Loot --> Equip --> Kill Stronger

Diablo --- and its sequels, imitators, and descendants --- runs on one of the tightest core loops in gaming history. You enter a dungeon. You kill monsters. Monsters drop loot. You equip the loot, which makes your character more powerful. You enter a harder dungeon. You kill harder monsters. They drop better loot.

The genius is in the escalation. The loop is not "kill, loot, equip, done." It is "kill, loot, equip, and now you can kill things you couldn't kill before." The reward is not just stuff. The reward is access to a harder version of the same loop. Every cycle makes the next cycle possible.

This is why people play Diablo games for thousands of hours. The loop never resolves. There is always a harder rift, always a rarer drop, always a better build. The moment you equip a new item, you are already thinking about the next one. The loop generates its own forward momentum.

The cycle in seconds:

  1. Act: Attack enemies (the verb --- clicking, using abilities, positioning)
  2. Feedback: Enemies die with satisfying visual and audio feedback; loot explodes onto the ground in color-coded fountains
  3. Reward: Pick up loot; compare stats; equip upgrades; feel power increase
  4. Escalation: Increased power unlocks harder content that drops better loot

Notice that the escalation step is what makes this a loop rather than a line. Without escalation, the player would equip the best item and stop. With escalation, equipping the best item reveals that "best" is relative --- there is always something better in the next difficulty tier.

🎮 Design Spotlight: The color-coded loot system in Diablo (white, blue, yellow, orange, green) is not just a UI convenience. It is feedback architecture. The player learns to ignore white drops and chase orange drops. The rarity colors create a hierarchy of excitement: seeing an orange beam triggers a dopamine response before the player even knows what the item is. The feedback is the reward.

Civilization: Explore --> Settle --> Build --> Expand

Sid Meier's Civilization series runs on a core loop that operates at a different timescale than Diablo's, but the structure is identical. You explore unknown terrain. You find a good location. You settle a city. You build improvements --- farms, mines, libraries, barracks. Your city produces resources, units, and culture. You use those outputs to explore further, settle new cities, and expand your empire.

The output of each cycle feeds the input of the next. A farm produces food. Food grows your population. A larger population works more tiles. More tiles produce more resources. More resources fund exploration. Exploration reveals new land. New land enables new cities. New cities produce more resources.

The famous "one more turn" compulsion comes directly from this loop. Every turn in Civilization advances multiple loops simultaneously: your city is one turn from completing a wonder, your army is two turns from reaching the enemy border, your technology is three turns from unlocking a new unit. There is always something about to pay off, which means there is always a reason to keep playing. The loop never reaches a natural pause point because the payoffs are staggered.

⚠️ Common Pitfall: "One more turn" is powerful but dangerous. If your core loop has no natural stopping points --- no moments where the player feels a sense of completion --- you risk creating compulsive engagement rather than enjoyable engagement. Civilization VI partially addresses this with the era system and agenda milestones, which create points where the player can feel they have accomplished something and put the game down. Whether they do put it down is another question.

Candy Crush: Match --> Clear --> Score --> New Board

Mobile games live and die by their core loops because the session length is so short. Candy Crush Saga has one of the most refined loops in the history of the medium.

You see a board of colored candies. You match three or more of the same color. The matched candies disappear. New candies fall from the top. The board state changes. You look for the next match.

The entire loop takes about three seconds. Match, clear, cascade, new state. The feedback is instant and intense: colors flash, sounds chime, the screen ripples. When cascades chain --- when clearing one match causes new candies to fall into another match, which triggers another --- the game produces a spectacle of incidental success. You did one thing; the game did five things in response. You feel clever even when the cascade was mostly luck.

What makes the Candy Crush loop addictive (and commercially devastating --- Candy Crush has generated over $20 billion in revenue) is the combination of:

  • Extremely fast cycles (3-5 seconds per action)
  • Immediate, overwhelming feedback (visual, auditory, haptic)
  • Variable reward (sometimes you get a boring match; sometimes you trigger a five-chain cascade)
  • Board-state novelty (every clear creates a new pattern to evaluate)

The loop itself is simple enough for a toddler to understand. The mastery ceiling is high enough that competitive players have spent years optimizing. This is the hallmark of a great core loop: simple to execute, complex to master.

📝 Design Note: Candy Crush also demonstrates how a business model can corrupt a core loop. The lives system (run out of lives and wait, or pay) and the difficulty spikes (some levels are mathematically impossible without power-ups) break the loop's self-sustaining quality. The player's motivation shifts from "I want to solve this puzzle" to "I need to buy this power-up." Once that happens, the loop is no longer intrinsically motivating --- it is an extrinsic treadmill. This is a design choice, not a design necessity. Tetris has a similar loop with no monetization pressure, and it sustains engagement through pure mechanics.

Stardew Valley: Plant --> Tend --> Harvest --> Sell --> Buy --> Plant

Stardew Valley is a masterclass in interlocking loops (we will explore this in detail in Case Study 2), but its primary core loop is the farming cycle.

You clear land. You plant seeds. You water them daily. After several in-game days, the crops mature. You harvest them. You sell the harvest. You use the money to buy better seeds, tools, or upgrades. You plant again.

The loop operates on a multi-day timescale (in-game days, not real days --- a crucial distinction from Animal Crossing). Each cycle takes about two to four in-game days, which corresponds to roughly ten to twenty minutes of real time. This pacing creates a rhythm: morning chores (water, feed animals, check crops), afternoon exploration or socializing, evening planning for the next day.

What makes Stardew Valley's loop exceptional is how the reward phase branches. Selling crops gives you money. Money lets you buy seeds (continuing the farming loop), but it also lets you buy equipment (enabling the mining loop), gifts (enabling the relationship loop), or building materials (enabling the construction loop). The output of the farming loop is currency that feeds every other loop in the game.

This is loop architecture. The farming loop is the trunk. Every other system branches from it. We will return to this concept in Section 6.5 when we discuss nested and interlocking loops.

6.3 The Core Loop in Thirty Seconds

Here is the most useful diagnostic tool you will learn in this chapter.

Take any game. Watch a player play for thirty seconds. What do they do?

That thirty-second slice is the core loop. It is the atomic unit of gameplay. If those thirty seconds are compelling, the game has a chance. If those thirty seconds are boring, confusing, or frustrating, nothing else matters --- not the story, not the graphics, not the twenty-hour campaign that "really gets good around hour four."

🎯 Design Heuristic: No one has ever saved a game by making the hours between core loops interesting. You can have the best story in gaming, the most gorgeous environments, the most innovative meta-progression --- and if the moment-to-moment gameplay loop is tedious, players will not reach any of it. Core loop first. Everything else second.

Let's apply the thirty-second test:

  • Celeste (30 seconds): Run, jump, dash, land on platform, die, instantly respawn, try again. The loop is movement and precision. The act is jumping. The feedback is immediate (success = progress, failure = instant respawn). The reward is reaching the next screen. The escalation is that screens get progressively harder.

  • Dark Souls (30 seconds): Approach enemy, observe attack pattern, dodge, attack during opening, manage stamina, evaluate risk. The loop is combat as puzzle-solving. The act is engaging an enemy. The feedback is health bars (yours and theirs) and stamina management. The reward is the enemy dying and dropping souls. The escalation is harder enemies and better gear.

  • Breath of the Wild (30 seconds): See something interesting in the distance, move toward it, encounter an obstacle or distraction, solve it or engage it, discover something unexpected. The loop is curiosity-driven exploration. The act is moving toward the unknown. The feedback is discovering what is there. The reward is resources, knowledge, or a new point of interest. The escalation is that every discovery reveals more map to explore.

  • Hades (30 seconds): Enter room, fight enemies, choose from offered rewards (boons, power-ups), move to next room. The loop is combat-and-choice. The act is fighting. The feedback is enemies dying spectacularly. The reward is choosing how to grow your build. The escalation is that each room is harder, but your build is stronger.

🧩 Try This: Pick three games you have played in the last month. For each one, describe the thirty-second loop in one sentence. If you cannot describe it in one sentence, either (a) you have not identified the core loop, or (b) the game's core loop is muddled. Both are worth investigating.

6.4 Designing a Core Loop: Verb, Feedback, Escalation

Most designers start with an idea. "My game is about exploring a haunted mansion." "My game is about building a space station." "My game is about raising magical creatures." These are premises, not designs. And premises do not become games until they have a core loop.

The process of designing a core loop has three steps.

Step 1: Start with the Verb

The verb is the thing the player does. Not the thing the player sees or experiences or feels. The thing they do with their hands on the controller.

Every great game can be reduced to a small number of verbs:

  • Celeste: jump, dash, climb
  • Dark Souls: attack, dodge, block
  • Stardew Valley: plant, water, harvest, sell
  • Minecraft: mine, craft, build, explore
  • Tetris: rotate, move, drop

Your first design decision is: what is the verb?

Not "what is the theme?" Not "what is the story?" Not "what is the aesthetic?" Those come later. First, the verb. Because the verb determines what the player does for the entire game, and if the verb is not satisfying --- if the act of doing the thing is not inherently interesting --- nothing you build on top of it will compensate.

💡 Intuition: If your verb is "click on enemies until they die," your game will feel like clicking on enemies until they die. If your verb is "position yourself precisely to exploit an opening in the enemy's defenses," your game will feel tactical and rewarding even if the visual presentation is identical. The verb is not the input. The verb is the decision the input represents.

Step 2: Add Feedback

Feedback is how the game communicates the result of the player's action. We will spend all of Chapter 8 on feedback systems, but for core loop design, you need to establish the feedback principle now: every action produces a visible, audible, immediate response.

When you attack an enemy, the enemy reacts --- a hitflash, a knockback, a health bar decrease, a sound effect. When you plant a seed, there is a visual confirmation and an audio cue. When you match three candies, the board explodes with color and sound.

Feedback serves two purposes in the core loop:

  1. Confirmation. "Your action happened. Here is the result." This is information.
  2. Motivation. "That felt good. Do it again." This is emotion.

The best feedback does both simultaneously. Diablo's loot explosion confirms that you killed the monster (information) and triggers excitement about what dropped (emotion). Celeste's dash produces a screen freeze and particle burst that confirms the dash executed (information) and makes dashing feel incredible (emotion).

Step 3: Add Escalation

Escalation is what turns a loop into a spiral. Without escalation, the loop is flat: do the same thing, get the same result, forever. With escalation, the loop grows: do the thing, get a result that enables you to do a harder version of the thing, which produces a better version of the result.

Escalation can take many forms:

  • Power escalation: You get stronger. Enemies get stronger. The numbers go up. (Diablo, most RPGs)
  • Skill escalation: The challenges get harder, but you get better at meeting them. (Celeste, rhythm games)
  • Complexity escalation: New systems unlock, new mechanics are introduced, the decision space expands. (Civilization, Factorio)
  • Narrative escalation: The stakes increase, new story beats are revealed, the world changes. (The Witcher 3, Undertale)
  • Scope escalation: The world gets bigger, new areas open, the map expands. (Breath of the Wild, Metroidvanias)

Most games use a combination. Dark Souls uses power escalation (leveling up, better gear), skill escalation (you learn enemy patterns), and scope escalation (you unlock new areas). Stardew Valley uses power escalation (better tools, bigger farm), complexity escalation (new systems unlock over time), and scope escalation (new areas like the desert and Ginger Island).

📐 Design Principle: Escalation without ceiling produces infinite games. Diablo III's Greater Rift system has no upper limit --- there is always a higher rift number, always better gear. This is why some players have played for ten thousand hours. Escalation with a ceiling produces finite games. Celeste's chapters have a defined end --- once you clear Chapter 9, the escalation is complete. Both are valid. Choose based on the experience you want to create.

6.5 Nested Loops: Session, Core, and Meta

Your core loop does not exist in isolation. It is nested inside larger loops and contains smaller ones. Understanding this nesting is essential to understanding why players play for five minutes, five hours, or five months.

Think of it as three concentric circles:

The Micro Loop (Moment-to-Moment): 3-30 Seconds

This is the smallest unit of play. In Dark Souls, it is one enemy encounter: approach, read, dodge, attack, evaluate. In Celeste, it is one screen: attempt, fail, respawn, attempt, succeed. In Candy Crush, it is one match: scan, swap, clear.

The micro loop must feel good every single time. This is non-negotiable. If the three-second interaction is not satisfying, the player will not survive one minute, let alone one hundred hours.

The Core Loop (Session): 2-30 Minutes

This is the cycle we have been discussing. In Hades, one core loop cycle is a complete run: hub, choose weapon, enter dungeon, fight through rooms, die or defeat the boss, return to hub. In Stardew Valley, it is one in-game day: morning chores, afternoon activity, evening planning. In Civilization, it is the "one more turn" window: start a project, see it through to completion.

The core loop is what structures a single play session. It provides the rhythm --- the tension and release, the effort and payoff --- that gives a session shape rather than an amorphous blob of gameplay.

The Meta Loop (Progression): Hours to Months

This is the long-arc loop that brings the player back across sessions. In Hades, the meta loop is the progression of the story, the permanent upgrades, and the relationship building between runs. In Destiny 2, it is the seasonal content cycle: new gear to earn, new activities to complete, new power levels to chase. In Stardew Valley, it is the gradual transformation of your farm from a weed-covered lot to a prosperous estate.

The meta loop answers the question: "Why should I come back tomorrow?" If the core loop answers "why keep playing right now" and the micro loop answers "why press this button," the meta loop answers "why boot this game up again." It is the loop that creates long-term retention.

🔗 Connection: These three loop levels correspond roughly to SDT from Chapter 4. The micro loop satisfies competence (each successful action feels good). The core loop satisfies autonomy (the player chooses how to engage within the session). The meta loop satisfies relatedness and purpose (the player's actions contribute to a larger arc that matters to them). A game that serves all three loop levels serves all three psychological needs.

How the Loops Interact

The critical design insight is that each loop level feeds the one above it.

Micro loops accumulate into core loops. In Hades, twenty individual room encounters (micro loops) compose one run (core loop). Each micro loop produces resources (boons, gold, darkness) that shape the run. The micro loop is the building block of the core loop.

Core loops accumulate into meta loops. In Hades, each run (core loop) produces permanent resources (darkness for the Mirror of Night, keys for new weapons, story fragments) that advance the meta loop. The core loop is the building block of the meta loop.

When these loops feed each other cleanly, the game feels effortless. The player is always progressing --- in the moment, in the session, in the long term. When the loops are disconnected --- when micro-loop actions do not contribute to core-loop progress, or when core-loop outcomes do not advance the meta-loop --- the game feels like it is wasting the player's time.

                    ┌─────────────────────────────────┐
                    │         META LOOP                │
                    │   (permanent progression,        │
                    │    story, unlocks)                │
                    │                                   │
                    │   ┌─────────────────────────┐     │
                    │   │      CORE LOOP           │     │
                    │   │  (session structure,      │     │
                    │   │   explore→fight→collect   │     │
                    │   │   →upgrade→explore)       │     │
                    │   │                           │     │
                    │   │   ┌─────────────────┐     │     │
                    │   │   │   MICRO LOOP     │     │     │
                    │   │   │  (single action,  │     │     │
                    │   │   │   3-30 seconds)   │     │     │
                    │   │   └─────────────────┘     │     │
                    │   │                           │     │
                    │   └─────────────────────────┘     │
                    │                                   │
                    └─────────────────────────────────┘

🔄 Reframe: Most designers intuitively design micro loops first (because they're fun to prototype) and meta loops last (because they require content). The strongest games are designed in the opposite direction: decide what the meta loop is (what brings the player back?), then design the core loop to feed it, then design the micro loop to feed the core loop. Top-down loop design ensures that nothing the player does is wasted.

6.6 Core Loop Diagrams: Visualizing the Cycle

One of the most useful tools in a designer's kit is the core loop diagram --- a circular flowchart that maps the cycle of player action. Drawing your core loop forces you to make the cycle explicit, to identify where the feedback happens, where the escalation is, and where the loop might break.

Here is a basic core loop diagram for Hades:

          ┌──────────────┐
          │  Choose       │
          │  Weapon/Boon  │
          └──────┬───────┘
                 │
                 ▼
          ┌──────────────┐
          │  Enter Room   │
          │  Fight Enemies│
          └──────┬───────┘
                 │
                 ▼
          ┌──────────────┐
          │  Choose       │
          │  Reward       │
          └──────┬───────┘
                 │
                 ▼
          ┌──────────────┐
          │  Next Room    │◄──── (repeat until death
          │  (harder)     │       or boss defeated)
          └──────┬───────┘
                 │
                 ▼
          ┌──────────────┐
          │  Return to    │
          │  Hub          │
          └──────┬───────┘
                 │
                 ▼
          ┌──────────────┐
          │  Spend        │
          │  Permanent    │
          │  Resources    │───────► back to top
          └──────────────┘

And here is the diagram for your progressive project's core loop --- the one you will build in this chapter:

          ┌──────────────┐
          │  EXPLORE      │
          │  (move through│
          │   the world)  │
          └──────┬───────┘
                 │
                 ▼
          ┌──────────────┐
          │  FIGHT        │
          │  (encounter   │
          │   enemies)    │
          └──────┬───────┘
                 │
                 ▼
          ┌──────────────┐
          │  COLLECT      │
          │  (pick up     │
          │   drops)      │
          └──────┬───────┘
                 │
                 ▼
          ┌──────────────┐
          │  UPGRADE      │
          │  (spend       │
          │   resources)  │──────► back to EXPLORE
          └──────────────┘         (with better stats)

Drawing this diagram is the first step of the progressive project for this chapter. Every loop you design should start as a diagram before it becomes code.

🛠️ Practice: Draw core loop diagrams for three games you know well. Use circles or boxes for each phase. Use arrows to show the flow. Label each arrow with what flows along it (loot, experience, resources, knowledge, access to new areas). Then compare your diagrams. How many phases does each loop have? Which loops have branching paths? Which are strictly linear cycles?

6.7 Common Core Loop Failures

Not every core loop works. Here are the patterns that kill loops, and how to recognize them before your players do.

Failure 1: The Dead End

The loop produces an output that does not feed back into the input. The player collects gold, but there is nothing to buy. The player kills enemies, but there is no loot, no experience, no progress. The loop reaches a dead end and the player asks: "Why am I doing this?"

Example: Early versions of Destiny (2014) had this problem. Players ran the same strikes and raids repeatedly, but the loot drops were so rare and so random that many runs produced nothing useful. The loop was supposed to be "fight, loot, equip, fight harder" --- but the "loot" step was broken. The loop had a hole in it, and players leaked out through that hole.

Failure 2: The Flat Loop

The loop repeats without escalation. The player does the same thing at the same difficulty for the same reward indefinitely. There is no growth, no change, no increase in challenge or capability. The loop is technically functional but emotionally flat.

Example: Many early mobile games suffered from flat loops. The player tapped, earned coins, bought upgrades that did not change the gameplay, and kept tapping. The numbers went up but the experience did not change. Cookie Clicker turned this into a deliberate commentary --- but for most games, a flat loop is a failure.

💀 Design Antipattern: The "number go up" trap. If your escalation is purely numerical --- more damage, more health, bigger numbers --- without a corresponding change in gameplay complexity, challenge quality, or decision space, you have a flat loop wearing escalation's clothing. The player sees bigger numbers but feels the same thing. True escalation changes what the player does, not just what numbers appear on screen.

Failure 3: The Bottleneck

One phase of the loop takes disproportionately longer than the others, creating a pacing problem that drains momentum. The player fights enemies quickly (exciting), picks up loot quickly (satisfying), but then spends ten minutes in inventory management deciding what to keep (tedious). The bottleneck kills the loop's rhythm.

Example: Diablo III at launch had an auction house that turned the loot phase into an economic optimization exercise. Instead of equipping what dropped, players sold drops on the auction house and bought optimal gear with gold. The core loop shifted from "kill, loot, equip" to "kill, sell, browse, buy" --- and the browsing/buying phase was long, boring, and antithetical to the fantasy of being a demon-slaying warrior. Blizzard eventually removed the auction house entirely.

Failure 4: The Invisible Loop

The loop exists but the player cannot perceive it. The cycle is technically functioning, but the feedback is so weak, the progression is so gradual, or the connection between action and outcome is so opaque that the player does not realize they are progressing. They cannot feel the loop turning.

Example: Many survival games suffer from invisible loops in the early game. The player gathers resources, crafts items, and builds structures, but the incremental improvements are so small that each cycle feels identical to the last. Valheim solved this with aggressive visual feedback: the first time you build a wooden wall, the camera pulls back, the structure snaps into place, and you immediately feel the difference between "standing in the wilderness" and "standing inside something I built." The loop becomes visible through feedback.

Failure 5: The Parasitic Loop

The game has a core loop, but it is competing with a secondary loop that the designer did not intend. The parasitic loop typically involves the metagame --- min-maxing, save-scumming, exploiting bugs, or engaging with systems in ways that bypass the intended loop.

Example: In The Elder Scrolls V: Skyrim, the intended core loop for combat is "explore, fight, loot, level up." But many players discovered that the most efficient way to level up was to repeatedly cast the same spell against a wall, or to pickpocket an NPC trainer to reclaim the gold spent on training, or to exploit the alchemy-enchanting loop to create godlike equipment. The parasitic loop ("exploit, optimize, trivialize") replaced the intended loop ("explore, fight, grow"), and it was the designer's failure to anticipate that players will always find the shortest path to power, even if that path is boring.

⚡ Key Insight: Parasitic loops emerge when the optimal strategy and the fun strategy diverge. If the fastest way to progress is also the most boring way to play, players will choose the boring way --- and then blame you for making a boring game. Your job is to ensure that the most efficient path through the loop is also the most enjoyable one. This is one of the hardest problems in game design.

6.8 Core Loop and Player Motivation

The core loop is not just a mechanical structure. It is an emotional contract. The loop tells the player what kind of experience they are signing up for, and it delivers on that promise every cycle.

This connects directly to Self-Determination Theory from Chapter 4.

Autonomy and the Core Loop

A core loop supports autonomy when the player has meaningful choices within each cycle. Hades offers the player a choice of boon after every room --- this is a core loop with built-in autonomy. Diablo III lets the player choose which dungeons to run, which builds to pursue, which items to prioritize. Stardew Valley lets the player decide what to plant, how to spend their day, which systems to engage with.

A core loop undermines autonomy when every cycle is identical and the player has no agency over how it unfolds. If the loop is "enter room, kill enemies, collect reward, enter next room" and the player has no choice about which room, which enemies, or which reward, the loop is mechanically functional but psychologically hollow.

Competence and the Core Loop

A core loop supports competence when each cycle produces a measurable improvement --- in the player's skill, their character's power, or both. The player should feel themselves getting better at the loop. In Celeste, each death teaches the player something about the obstacle, and success feels earned. In Diablo, each upgrade is visible and quantifiable. In Stardew Valley, the farm grows visibly over time.

A core loop undermines competence when progress is invisible, unearned, or arbitrary. If the player cannot tell whether they are getting better, or if success is determined by luck rather than skill, the competence need goes unmet.

Relatedness and the Core Loop

Relatedness in the core loop is about the player's connection to the game world, its characters, or other players. Stardew Valley's relationship loop feeds relatedness: you give gifts to NPCs, you learn their stories, you build emotional connections. Hades' dialogue system feeds relatedness between runs: every death produces new conversations with characters who acknowledge what happened. Even Dark Souls' messages from other players ("try jumping" scrawled on a cliff edge) create a form of relatedness within the core loop.

🪞 Reflection: Look at your progressive project's core loop diagram. For each of the three SDT needs, rate how well the loop serves it on a scale of 1-5. Be honest. If any need scores below 3, you have identified a weakness. You do not need to fix it now --- Chapters 11-15 will give you the tools --- but knowing where the weakness is will help you build better.

6.9 Designing Your Core Loop: A Process

Here is a practical process for designing a core loop from scratch. We will use this process for the progressive project, but it applies to any game.

1. State the Fantasy

Before mechanics, before code, before GDScript --- what is the player fantasy? What does the player feel when they play your game?

For our progressive project (the 2D action-adventure): "I am an explorer discovering a dangerous world, growing stronger with each challenge I overcome."

This fantasy tells us the loop needs exploration (discovery), combat (danger/challenge), and progression (growing stronger).

2. Identify the Core Verb

What does the player do? Not "fight enemies" --- that is too abstract. What is the physical action?

For our project: the core verb is move through space toward the unknown. Everything else --- fighting, collecting, upgrading --- serves this verb. The player is always moving, always exploring, always discovering what is around the next corner.

3. Map the Cycle

Draw the loop. What does the player do first? What happens next? What is the output? Where does the output go?

Our loop:

  1. Explore --- move through the world, discover new areas
  2. Fight --- encounter enemies that block progress
  3. Collect --- defeated enemies drop resources; exploration reveals items
  4. Upgrade --- spend resources to improve abilities
  5. Return to Explore --- upgraded abilities open new areas or make existing areas easier

4. Verify the Feed

Does the output of each phase feed the input of the next? Walk through the loop and check:

  • Explore produces encounters (feeds Fight)
  • Fight produces drops (feeds Collect)
  • Collect produces resources (feeds Upgrade)
  • Upgrade produces power (feeds Explore --- new areas become accessible)

Every connection is clean. The loop is self-sustaining.

5. Add Escalation

Where does the difficulty increase? Where does the complexity grow?

  • Exploration areas get more dangerous (enemies are tougher, hazards appear)
  • Combat encounters require new strategies (enemies have different attack patterns)
  • Upgrades unlock new abilities that change how you explore and fight
  • The world expands as you grow stronger

6. Define the Session Arc

How long is one cycle? When does the player feel a natural stopping point?

For our project: one cycle (explore one area, clear enemies, collect drops, return to base and upgrade) should take about 5-8 minutes. Three to four cycles make a satisfying 20-30 minute session. The upgrade moment --- seeing your character grow stronger --- is the natural session-ending satisfaction point.

✅ Checklist: Before you write a line of code, your core loop design should answer all of these:

  • What is the verb? (What does the player do?)
  • What is the feedback? (How does the game respond?)
  • What is the reward? (What does the player gain?)
  • What is the escalation? (How does the next cycle differ from this one?)
  • What is the session arc? (When does the player feel satisfied?)
  • Where is the SDT? (Autonomy, competence, relatedness --- how does the loop serve each?)

6.10 GDScript: Building the Core Loop in Godot

Time to build. We are going to implement the skeleton of our core loop in Godot using two scripts: a GameManager singleton that tracks game state, and a CollectibleItem script that handles the "collect" phase of the loop.

This is a scaffold. We are not building a polished game --- we are building the mechanical skeleton of the core loop. Polish comes later (Chapter 8). Enemies come later (Chapter 5 gave you the attack; Chapter 27 gives you the AI). What we need right now is the loop itself: explore, fight, collect, upgrade, explore again.

GameManager.gd --- The Loop State Machine

The GameManager is an autoload singleton (a script that exists throughout the game and is accessible from any other script). It tracks the current phase of the core loop and manages the resources that flow between phases.

# GameManager.gd — Autoload singleton tracking core loop state
extends Node

enum Phase { EXPLORE, COMBAT, REWARD, UPGRADE }

signal phase_changed(new_phase: Phase)
signal resources_changed(new_total: int)

var current_phase: Phase = Phase.EXPLORE
var player_resources: int = 0
var player_power: int = 1   # escalation: this grows with upgrades
var enemies_defeated: int = 0

func transition_to(new_phase: Phase) -> void:
    current_phase = new_phase
    phase_changed.emit(new_phase)

func add_resources(amount: int) -> void:
    player_resources += amount
    resources_changed.emit(player_resources)

func apply_upgrade(cost: int, power_gain: int) -> bool:
    if player_resources >= cost:
        player_resources -= cost
        player_power += power_gain
        resources_changed.emit(player_resources)
        transition_to(Phase.EXPLORE)  # upgrade completes the cycle
        return true
    return false

This is twenty-two lines. It does not look like much. But it is the spine of your game. Every system you build from here forward --- combat, inventory, progression, UI --- will talk to this manager. The Phase enum maps directly to the core loop diagram. The transition_to() function moves between phases. The apply_upgrade() function is where the loop closes: the player spends resources, gains power, and returns to the Explore phase with improved capabilities.

🛠️ Implementation Note: Set this script as an autoload in Godot: Project > Project Settings > Autoload > add GameManager.gd with name GameManager. This makes GameManager.transition_to(), GameManager.add_resources(), and GameManager.apply_upgrade() callable from any script in the project. Every scene, every enemy, every collectible can interact with the core loop.

CollectibleItem.gd --- The Reward Phase

This script goes on collectible items (resource pickups dropped by enemies or found in the world). When the player touches the item, it adds resources to the GameManager and removes itself from the scene.

# CollectibleItem.gd — Pickup that feeds the core loop
extends Area2D

@export var resource_value: int = 1

func _ready() -> void:
    body_entered.connect(_on_body_entered)

func _on_body_entered(body: Node2D) -> void:
    if body.is_in_group("player"):
        GameManager.add_resources(resource_value)
        # Feedback: visual/audio confirmation (placeholder — Chapter 8 adds juice)
        queue_free()

Twelve lines. The collectible detects when the player touches it, adds resources, and destroys itself. That is the "Collect" phase of the core loop, distilled to its mechanical essence.

The resource_value export variable means you can place different collectibles in the editor with different values. A common enemy might drop a collectible worth 1. A mini-boss might drop one worth 5. A hidden chest might contain one worth 10. This is the beginning of your economy --- and your economy is how the core loop's reward phase escalates.

📝 Design Note: Notice what these scripts do not contain: visual effects, sound effects, animations, particle systems, screen shake. All of that is feedback, and it lives in Chapter 8. Right now we are building the loop's logic. The loop needs to function mechanically before it can feel good aesthetically. This is a deliberate sequencing choice. Get the loop working. Then make it feel incredible.

6.11 Progressive Project: Build Your Core Loop Prototype

This is the chapter where your project becomes a game. Here is what you are building.

Deliverable

A playable prototype that demonstrates the complete core loop: explore, fight, collect, upgrade, explore again. The prototype should be playable in under two minutes and should loop at least twice (the player completes the cycle, upgrades, and starts the cycle again in a slightly harder or expanded environment).

Requirements

  1. Explore: The player can move through a small environment (at least two connected rooms or areas). Movement should use the input system from Chapter 3 and the mechanics from Chapter 5.

  2. Fight: At least two enemies exist in the environment. They do not need sophisticated AI yet (Chapter 27) --- they can be stationary, or they can move in simple patterns. The player should be able to defeat them using the attack mechanic from Chapter 5.

  3. Collect: Defeated enemies drop collectibles. Use the CollectibleItem.gd script above. The player picks up collectibles by touching them.

  4. Upgrade: There is a location (a chest, an NPC, a shrine, a terminal --- whatever fits your game's aesthetic) where the player can spend collected resources to gain a power increase. Use GameManager.apply_upgrade().

  5. Escalation: After upgrading, something changes. New enemies appear in an area that was previously empty. A door that was locked is now open. Enemies in the second area are tougher than the ones in the first. The cycle is the same, but the context has changed.

  6. Session arc: The prototype should have a natural end point after 2-3 cycles. This can be reaching a specific location, defeating a specific enemy, or reaching a specific power level. The player should feel the arc: weak at the start, growing through the middle, strong at the end.

Stretch Goals

  • Add a simple HUD showing current resources and power level (UI covered in Chapter 29, but a basic Label node works for now)
  • Add a second type of collectible with a different value
  • Add a visual indication of the player's current power (color change, size change, particle trail)

🎮 Design Checkpoint: When you finish the prototype, play it three times. On the third playthrough, ask yourself: "Is the core loop carrying the experience?" Are you playing because the loop is engaging, or because you feel obligated to finish the exercise? If it is the latter, your loop has a problem. Go back to Section 6.7, identify which failure pattern applies, and iterate. The loop must be compelling. This is the standard. Everything else is negotiable.

6.12 Interlocking Loops: When Games Have More Than One

Most games beyond the very simplest have multiple interlocking loops. Stardew Valley has a farming loop, a combat loop, a relationship loop, a fishing loop, and a crafting loop. Breath of the Wild has an exploration loop, a combat loop, a cooking loop, a shrine puzzle loop, and a gear loop. Hades has a combat run loop, a story loop, a relationship loop, and a progression loop.

The key question for interlocking loops is: how do they connect?

There are three common patterns:

Pattern 1: Hub and Spoke

One primary loop feeds all others. This is the Stardew Valley model: the farming loop produces money, and money is the currency that enables every other loop (buying gifts for relationships, buying equipment for combat, buying seeds for more farming). The farming loop is the hub. Every other loop is a spoke.

               Relationship Loop
                     ▲
                     │ (gifts cost money)
                     │
Mining Loop ◄── Farming Loop ──► Fishing Loop
                     │
                     │ (upgrades cost money)
                     ▼
                Combat Loop

Advantage: Clear hierarchy. The player always knows what the primary activity is. Risk: If the hub loop gets boring, the entire game collapses.

Pattern 2: Parallel Loops

Multiple loops run simultaneously and independently, sharing a player but not necessarily sharing resources. This is the Breath of the Wild model: the exploration loop, the combat loop, the cooking loop, and the shrine loop all coexist, and the player moves between them freely based on what they feel like doing.

Advantage: Player autonomy is high. There is always something to do. Risk: Without a clear primary loop, the game can feel directionless. Some players love this. Others bounce off.

Pattern 3: Sequential Loops

Loops unlock in sequence as the game progresses. The early game has a simple loop. The mid-game introduces a second loop that interlocks with the first. The late game adds a third. This is the Factorio model: first you mine and craft manually, then you automate mining, then you automate crafting, then you optimize logistics, then you manage pollution and defense. Each loop builds on the previous one.

Advantage: Complexity is introduced gradually. The player is never overwhelmed. Risk: If a later loop is less enjoyable than an earlier one, the game's quality degrades as it progresses.

🧩 Design Question: Which pattern does your progressive project follow? Right now it is a single loop (explore, fight, collect, upgrade). As we add systems in later chapters --- combat depth (Chapter 26), narrative (Chapters 20-23), economy (Chapter 24), progression (Chapter 25) --- you will need to decide how these loops connect. Start thinking about it now, even though you will not implement it until later.

6.13 The Core Loop Is Not the Whole Game

One final warning before we close this chapter.

The core loop is the most important thing in your game. But it is not the only thing. A game with a brilliant core loop and nothing else is a polished prototype. A complete game needs pacing, narrative, variety, surprise, aesthetic identity, and emotional resonance --- all of the things we will cover in Parts III through IX.

The core loop is the foundation. It is the concrete slab your house is built on. If the foundation is cracked, the house will fall no matter how beautiful the walls are. But a foundation without walls is not a house --- it is a slab of concrete.

Do not over-index on the core loop to the exclusion of everything else. Some games have done this --- they are technically impeccable, with perfectly tuned loops, and they are boring because they have no soul, no surprise, no moment where the player feels something unexpected. Celeste is not great because its core loop is tight (though it is). Celeste is great because its tight core loop exists in service of a story about anxiety, perseverance, and self-acceptance, and the mechanics mean something.

🎯 Final Thought: The core loop is the engine. But an engine is not a car. The engine makes the car go. The steering, the suspension, the interior, the paint --- those make the car worth driving. Build the engine first. Build it well. Then build everything else around it. That is what the rest of this book is for.

Chapter Summary

The core loop is the repeating cycle of player action that forms the heartbeat of every game. It follows the pattern: act, feedback, reward, escalation, act again. The output of one cycle must feed the input of the next, or the loop breaks.

Core loops exist at three nested levels: the micro loop (moment-to-moment, 3-30 seconds), the core loop (session structure, 2-30 minutes), and the meta loop (long-term progression, hours to months). Each level feeds the one above it, and all three must be satisfying for the game to sustain engagement.

Common loop failures include dead ends (rewards that go nowhere), flat loops (no escalation), bottlenecks (one slow phase), invisible loops (no feedback), and parasitic loops (unintended shortcuts). The most dangerous failure is when the optimal strategy and the fun strategy diverge.

The core loop connects directly to player motivation. Loops that support autonomy (player choice within the cycle), competence (visible progress), and relatedness (connection to the world or other players) sustain engagement. Loops that fail to serve these needs become treadmills.

Designing a core loop follows a six-step process: state the fantasy, identify the core verb, map the cycle, verify that each phase feeds the next, add escalation, and define the session arc. Draw it before you code it. Test it before you polish it.

Your progressive project now has a core loop: explore, fight, collect, upgrade, explore. It is a skeleton. Everything that follows --- from feedback systems to narrative design to polish --- is about putting flesh on these bones. But the bones must be strong. If the loop does not hold, nothing else will.