6. Conditions - NariShakti 6. Conditions | NariShakti Humane ClubMade in Humane Club

6. Conditions

Conditions

She spent four days trying to fix a game that couldn’t be fixed. The conditions made perfect sense in her head. They made no sense to anyone else.


If this, then that. But only then.

Conditions, I told her, are the decisions a system makes based on what’s true at a given moment.

She already knew this. She’d been living inside conditions her whole life.

If the bag is packed the night before, mornings are calm. If it isn’t, they aren’t. She’s experienced that consequence more times than either of us would like to admit.

If it’s the right time of day and the weather is good, they go to the park. If it’s too sunny, they don’t. If it rains, they don’t. Multiple conditions, all of them have to be true at the same time. Miss one and the plan changes.

Every game she’d built so far had conditions running quietly underneath it. The skull when a robot wins: that’s a condition. The game ending when a wrong option lands in the wrong bucket: that’s a condition

The interesting question about conditions isn’t whether you understand them conceptually. It’s whether you can write them precisely enough that a player, someone who hasn’t seen the design doc and doesn’t know your intentions, can follow them through to a logical outcome. A condition that makes sense to the designer and a condition that makes sense to the player are not always the same thing.

That distinction took five days to land. And it required burning a quest to the ground to get there.

I want to be honest about what those five days felt like from my side. It was the hardest stretch of the series to hold. She was working hard. The thinking was serious. And I kept having to say: it’s still not working. That’s a difficult thing to keep saying to a child who is visibly trying. The temptation to move on i.e to call it close enough and tick the box, was real.

How she chose what to build

She came to this session with the theme fully formed. A quest at midnight. An owl guarding a map. Dungeons with traps. Mystical books that might contain a duplicate. Competitors who rush to the spot if you make noise. A witch. A ghost. A potion that must not touch the gem.

She’d been reading fantasy and adventure stories for years and had noticed, without naming it, that good stories are built on conditions. Every branch in the narrative follows from a choice the character made. She wanted to build that.

She wrote a detailed document. The structure was genuinely ambitious. Here is what she had:

I read it carefully. The imagination was vivid. The world was rich. And the conditions were almost completely disconnected from the player’s experience.

Look at Level 1, Question 1. The consequence of dancing for the owl is that competitors rush to the spot which leads to a ghost haunting you. The chain requires the player to predict not just the immediate consequence of their action but a second-order consequence involving competitors they haven’t met yet. There is no information in the game that would let a player reason toward this outcome. It’s not a condition but a trap dressed up as a choice.

Look at Level 2, Question 1. Playing music causes competitors to take the map. Why? How would a player know that? The condition exists in her imagination but not in the game’s logic.

There was also a witch flying around in Level 2. The constraint was already in place by this point: black and white, no animations, no confetti, logic visible on its own and it was doing exactly what it was supposed to do. The witch had nowhere to hide.

I pointed at one condition: if the player clicks mystical books, the game ends and asked her to read it from the player’s side. You’re in a dungeon. You don’t have the map. Someone tells you there are two options: dungeons, slow but safe, or mystical books, faster but riskier. You choose the books.

The game ends.

She saw it immediately. A real condition gives the player something that follows logically from what they did. This one just stopped the game.

She went back and tried to fix it.

Four days on a whiteboard

She didn’t disengage. That’s the first thing worth saying. For four days she kept coming back: thinking out loud, drawing on the whiteboard, filling pages with notes and scribbles and diagrams. She was trying to untangle a game that had become too complex to reason through.

She even reached for a framework she’d encountered in a book Back of the Napkin by Dan Roam (See, Look, Imagine, SHow) trying to separate what was visible in the game from what needed to be inferred and what could be designed differently. The thinking was serious and sustained.

But the game couldn’t be rescued because the foundation had a flaw that effort alone couldn’t fix. The conditions were built for the story she had in her head, not for the player trying to navigate from outside it. No amount of revision would change that because the problem was in the original design decision: consequences that made sense to the designer but were invisible to the player.

The constraint did exactly what it was designed to do: made the logic the only thing left to look at. And the logic didn’t hold.

I asked her to let it go and start something new.
She didn’t argue. She sat quietly for a moment. Then she turned to a new page in her notebook. That moment, choosing to let go of something you’ve invested four days in, is not a small thing. I didn’t make it smaller by commenting on it.

The design doc

She arrived at Baby Town.

When Vasuda was three months old, Sabi had written a song: Baby is walking in the baby town. She’d been watching a baby being managed, scheduled, soothed, fed, and kept calm for months. She knew the logic of it: the trade-offs, the timing, the sequence of decisions that determined whether a day went well or fell apart.

She sat down and wrote it all out.

Look at the conditions in Baby Town compared to the quest. Every consequence is something a player could reason toward: bath before park means the baby gets dirty again, which costs more time. Massage is faster than a lullaby, which is faster than a bath so the most efficient choice to calm the baby is clear once you think it through. The conditions are grounded in logic the player already has access to, drawn from the real experience of managing a baby’s day.

The quest’s conditions required the player to know things they couldn’t know Eg: that dancing would alert competitors, that competitors would summon a ghost, that the ghost would haunt you. Baby Town’s conditions require the player to think. That’s the difference.

And she built it from a song she wrote when Vasuda was three months old.

Design → Build → Ship

With the design doc done, she opened ChatGPT.

The instructions were precise, minimal, and completely without decoration. Black background, White font, consequences written underneath each situation, no robots, confetti or animations. Just the logic of the game, visible on its own.

She got the output she wanted cleanly.

Then she tested it herself. One issue: the penalty system wasn’t calculating correctly. Time and energy weren’t being deducted in the right amounts after certain choices. She described the problem precisely, sent a single correction prompt, and it was fixed.

Two prompts. Clean output. No tears, no blank screens, no twelve-attempt debugging sessions.

The build reflected the thinking. When there is nothing decorating the logic, the logic has to hold on its own and hers did.

What this is actually building

After Baby Town was done, I asked Sabi to write down what she thought had gone wrong with the midnight quest and what had gone differently with Baby Town.

This is what she wrote:

While making the midnight quest, I had a story of what would happen in my mind. But it was too complicated to put down on pen and paper. I was too wrapped up in my story that I did not see it from the player’s perspective and that my story wasn’t clear to the player. I also made a lot of decorations, and focused more on that. In fact, I even spent 1 entire hour trying to make a witch fly across the screen.

While making Baby Town, I had drawn everything out and I had structured my thoughts. This helped me put my ideas down to paper. This helped me make the game clearer. I also was not focused on making decorations or flying witches.

What I learned: Don’t get enamoured by what ChatGPT or any AI builds. If your core logic isn’t strong, what use is all that confetti, and a witch flying around.

I don’t have anything to add to it.

Conditions is where she learned that clarity is a design choice. Baby Town proved it. ⚡️

What I understand now: I couldn’t have told her what was wrong with the Midnight Quest by describing it. She had to build it, look at it under the constraint, try to fix it, and run out of fixes. That process (building something, discovering the flaw is foundational, letting it go) is one of the most valuable things in the series. It can’t be taught. It has to be experienced. The four days were the lesson.

What’s next

Baby Town is sitting on her laptop. The Sherlock Holmes game is very close now. She has sequences, patterns, categorisation, cause and effect, and conditions. One more concept and the mystery is within reach.

Next up is loops: doing something until it’s done, and the precise question of what done actually means. And the moment she realised that searching for something you might not find is a loop with a very uncomfortable stopping condition.

Your turn

Use this section as a reference before and after the session. This is the kit for you to try.

The concept

A condition is a decision a system makes based on what’s true at a given moment. At 8–12 the interesting challenge is not whether your child understands conditions conceptually. It’s whether they can write conditions that make sense to a player who hasn’t seen their design doc. A condition clear to the designer is not always clear to the player.

This session may take more than one sitting. The four days in this post are not a failure. They are the process working as intended. A game whose conditions only make sense to the designer is doing exactly what it needs to do: showing the gap between what was imagined and what was built.

Green flag: your child reads their own conditions from the player’s side without being asked. That’s the hardest instinct in this session and the most valuable.

Try this

Find a rule in the house that has a condition and ask them to find the loophole. The situation where the condition is technically met but the intended outcome is wrong. Finding the loophole is not misbehaviour. It is exactly the right kind of thinking. A child who can identify a loophole has understood that conditions need to be precise, not just present.

Then try to close the loophole together. Rewrite the rule so it cannot be gamed. This is harder than it sounds. Every fix tends to introduce a new edge case. That difficulty is the concept.

Before the design challenge: a screen-free activity (15–20 minutes)

Get out a board game or card game your child knows well. Ask them to read the rules and find every conditional statement: every ‘if’, ‘when’, ‘unless’, ‘except when.’ Write each one as a formal IF/THEN statement.

Then find one rule that is ambiguous where you’re not sure exactly what the condition covers. Try to rewrite it so it has no loopholes. This is harder than it sounds. A loophole-free condition requires specifying not just what’s allowed but every edge case that might be claimed as allowed.

This produces exactly the instinct the session needs: precision before building.

Going forward

If your child races through this:

Ask them to take the Midnight Quest design doc and fix it: not by simplifying the story but by rewriting each condition so a player who has never seen the design doc could reason toward the correct choice. The constraint: every consequence must follow from information the player already has at the point of making the decision. This is genuinely hard. It is also the exact skill the concept is trying to build.

If your child needs more time:

Don’t move to Baby Town immediately. Stay with the physical anchor longer: find three or four conditional rules from daily life and write each one as a formal IF/THEN statement. Then test each one: is there a situation where the condition is technically met but the intended outcome is wrong? Fix the rule. Do this with multiple examples before opening the design challenge. The concept needs to feel precise in language before it can be precise in a game.


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