7. Loops

She was two years old the first time she understood loops. She just called it “Aa papa.” It meant up and down. What it actually meant was: do this again, keep doing it, I’ll tell you when to stop.

Again and again

A loop is an action that repeats until something stops it. She’d known this since she was two.

When Sabi was a toddler, her grandparents had a game with her. They would hold a blanket between them, she would stand in the middle, and they would bounce her up and down inside it. She loved it with the particular intensity that toddlers reserve for things that are exactly right. Every time it stopped, she would look at them and say: “Aa papa. Aa papa. Aa papa.”

It meant up and down. Or at least, that was what she was trying to say. What she actually understood was the loop — do this again, do it again, keep doing it until I tell you to stop.

That’s a loop. An action that repeats, governed by a condition that determines when it ends. The stopping condition in the blanket game was simple: she stopped asking. The loop ran until she was done.

I also showed her a recipe. Keep stirring the cake batter — not five times, not ten times, but until the right consistency is reached. The action repeats. The stopping condition is a state, not a number. You don’t count the stirs. You watch for the moment the batter tells you it’s ready.

That distinction — loops that run a fixed number of times versus loops that run until something becomes true — is where the concept gets interesting. And it’s exactly what she built into her game without me naming it first.

How she chose what to build

She came to this session with two ideas.

The first: a game about a person getting healthy. Starting at one weight, working toward another through food and exercise. Variables she could track, progress she could show, loops built around daily habits.

She thought about it for a few minutes and then put it aside. Designing food and nutrition accurately would require knowledge she didn’t have. She didn’t want to guess at the details and get them wrong.

So she went somewhere she knew — Math Playground. She’d spent hours on a game there where a duck collects coins, builds strength, and competes in swimming tournaments. She knew the loop intimately from the player’s side. She knew what made it satisfying, what made it hard, what the stopping conditions were.

She decided to rebuild it.

I was fine with that. Recognising a loop in something you’ve already experienced and being able to name it, design it, and implement it — that’s the concept working. It doesn’t matter that the idea came from somewhere she’d played before. The thinking was entirely hers.

What she added was her own. Three stopping conditions for the duck’s swimming loop — hitting an obstacle, getting eaten by a crocodile, or leaving the water to eat. She arrived at those herself, from her experience of playing similar games. She knew what should stop the loop because she’d felt it as a player.

The design doc

The Duck Champion

Mission: Make your duck the best swimmer in the world. Your duck has to learn many new things. But to keep going, your duck needs to keep eating special energy coins. You have to compete with other ducks in order to become the champion.

Variables

Money
Energy
Swimming level

Unexpected Variables

- You might encounter a crocodile
- You might dash into a tree
- You might need to make your duck go inside the river properly, where you will encounter a cave

You can move your duck with the arrow keys. In the middle of swimming, crocodiles, boards of wood, or trees might come your way. You must skillfully avoid them. If you collect enough coins from races, you will be able to afford swimming training. While practising swimming inside the river, you might encounter coins. You must collect those coins.
In practice, there should be two training areas. One should be in the water with the head up, and another should be underwater with the head under it. The loop in this is that the duck should be continuously swimming. The duck cannot stop until it hits something, gets eaten by a crocodile, or gets out of the water to eat food.

Instructions for ChatGPT:
Single HTML file. Yellow duck. Black and white river background. Mission clearly written at top. Player can see training area and duck position. Unexpected variables appear randomly. Game over if duck crashes. Four arrow keys for movement. Tournament button top left — clicking it adds black and white competitor ducks to the same obstacle course. Variables box below mission showing energy, money, and swimming level. Tournament win increases swimming level by one. Food Corner box — drag duck there and click Food to drop grains. Each feed costs 15₹ and increases energy by 30 pts. Game Over line and Play Again button appear on game end. Player wins by reaching level 15. First place in tournament increases level by one. Practice button appears after tournament. Instructions button shows player rules. Duck should look like a proper animated duck. River, crocodile, and obstacles should look realistic.

Look at the loop she designed. The duck cannot stop swimming. There is no pause, no rest, no moment where the loop simply waits. It runs until one of three things becomes true — obstacle hit, crocodile encounter, water exit. Three distinct stopping conditions, each one emerging from her experience of playing the game from the other side.

She didn’t name them as stopping conditions. She just knew, from having been a player, what should end the loop. That knowledge came from thousands of repetitions of “Aa papa” — from years of playing games and understanding intuitively what makes a loop feel right when it runs and satisfying when it stops.

Design → Build → Ship

She knew exactly what she was building before she opened ChatGPT.

That clarity showed in the output. The build went smoothly — the most technically ambitious game in the series so far, with arrow key movement, tournament mode, obstacle generation, a food system, and level progression to fifteen — and it came together without the false starts and frustration of earlier sessions.

When you know the thing you’re building from the inside — when you’ve been a player of it, when you understand why each element exists — the brief writes itself. The prompt was precise because the thinking was precise. The output reflected that directly.

What this is actually building

The “Aa papa” detail is the one I keep coming back to.

She was two. She didn’t know what a loop was. She had no vocabulary for repetition as a computational concept. But she understood, at two years old, that the thing she wanted was the thing to keep happening — and that she was the one who decided when it stopped.

That instinct — I want this to continue, I will tell you when I’m done — is the same instinct she used to design the duck’s swimming loop seven years later. The duck cannot stop until something stops it. The loop runs because it should run. The stopping conditions exist because every loop needs them, and she knew what they should be because she’s been a player long enough to feel when a loop ends correctly and when it doesn’t.

Loops are everywhere once you start looking. The cake batter stirred until it’s ready. The duck swimming until it isn’t. A child jumping in a blanket until she decides she’s done. The concept isn’t new to her. The name is.

What this session built was the ability to design a loop deliberately — to ask, before building: what is the action that repeats, and what is the condition that ends it? Those two questions, answered precisely, are the difference between a loop that works and a loop that runs forever or stops too soon.

She’s been asking those questions since she was two. She just didn’t know that’s what she was doing.

Loops is where the “Aa papa” finally had a name. ⚡️

What’s next

She didn’t wait for me to tell her.

The moment the duck game was done she looked up and asked: what’s next? Not in the way she’d asked after day one — curious, cautious, still finding her footing in the series. This was impatient. She’d built six games. She knew the pattern now. She wanted to keep going.

I told her: debugging.

She already knew what it meant — she’d been debugging since the construction game, since the pattern game’s friend found two bugs, since the categorisation game’s Play Again button refused to work. She’d been doing it all along.

What she hadn’t done was do it deliberately. As the point of the session, not a side effect of building something else.

And then I reminded her: after debugging comes decomposition. And after decomposition comes abstraction. And after abstraction comes variables. And after variables comes functions.

And after functions — finally, after all of it — comes the Sherlock Holmes game.

She closed the laptop and went to get her notebook.

New here? Start with the series introduction. Parent’s Guide: Computational Thinking for Pre-Teens