Build Something With Your Kid

My daughter Sabina loves claw machines. She often wins a plushy in only a few tries, which makes each machine feel a little magical.

One day we found one that cost $3 for every try. We tried several times and won nothing. She wanted to keep going. I wanted her to think before spending more money, so I said we should stop. She went home sad.

At home, we decided to make our own claw machine game.

The first version was rough. The claw moved, toys sat in a pile, and sometimes one of them made it to the prize slot. It was not a particularly good game. But it was playable, and that gave us something we could experience together.

Sabina tried it and immediately started asking questions.

Could the claw turn this way? Why did that toy fall? That miss did not feel fair. Could we add more plushies? Could the prizes stay on a shelf after you won them?

Each question became a small problem we could work through together. We would talk about what happened, what she expected to happen, and what might need to change. Then we would use Codex to make a new version and try again.

Codex made it possible to move quickly, but it was just a tool. The interesting part was what happened between us while we used it.

The Real Project Is Not the Game

We eventually made four games together.

The claw machine came from that disappointing arcade visit. Bear Necessities came from a night in Tahoe when a bear tried to get into parked cars. Axie’s Gold Adventure combined her love of axolotls with places we have visited in Mexico. Chameleon Run started with a friend’s gecko and Sabina’s collection of rocks and crystals.

Every game began with something she noticed, remembered, or loved.

My goal was not to teach her how to code. It was to show her that her imagination could become something real. An idea did not have to stay an idea. She could describe it, make a first version, learn from it, and keep shaping it.

The games gave us a reason to sit together and do that over and over.

Sabina chose the characters, worlds, rules, rewards, and details. She played each version and noticed when something was confusing, unfair, too easy, too hard, or simply not what she imagined. I helped her slow down, explain what she was experiencing, and turn a reaction into a possible solution.

Instead of “It doesn’t work,” we could ask:

What happened?
What did you expect to happen?
When did it start feeling wrong?
Which part of the game might control that?
What could we change?
How would we know if the change worked?

That conversation is the real work. The game simply makes the thinking visible.

Learning to Think in Systems

A game is made of systems that interact: controls, movement, characters, rules, levels, rewards, difficulty, sound, and saved progress. Children do not need those terms before they begin. They discover the systems by playing.

When the claw picked up a toy but dropped it too easily, we did not just ask Codex to “fix the claw.” We had to think about the full sequence: move, lower, close, lift, return, and release. We had to decide how close the claw needed to be, when a grab should succeed, and how often a toy should slip.

When a ranger caught Ruby in Bear Necessities, we asked what the ranger knew. Did it see her? Did it hear her running? Was the food too close to danger? Was there a hiding place nearby? A result that felt wrong could come from several different parts of the game.

When we wanted 30 levels in Chameleon Run, we did not build each one separately. We made one system that could create many levels, then changed the speed, spacing, colors, traps, and rewards as the player progressed.

These are engineering ideas, but I am less interested in teaching her engineering terminology than in teaching her a way to approach problems.

A frustrating outcome is not one giant mystery. It comes from parts that have relationships and rules. You can name the parts, form a theory about what happened, change one thing, and test it again.

That way of thinking applies far beyond software.

Helping Her Articulate Solutions

It would be faster for me to play the game, decide what is wrong, and tell Codex exactly how to fix it.

That would also remove most of the value for her.

When Sabina says something is not fun, I try not to jump straight to the answer. I ask her to show me. I ask when it stopped being fun, what she wanted to do, what got in the way, and what she thinks should happen instead.

Sometimes her first solution is too large. Sometimes it creates another problem. Sometimes we try it and discover that the original version was better. That is all useful.

She is learning that solving a problem is not the same as immediately knowing the answer. She can use her experience, explain what she observed, propose a change, and learn from the result.

The point is not for every idea to be correct. The point is for her to become comfortable having an idea, testing it, being wrong, and continuing.

Designing for Productive Struggle

We also talk a lot about what makes a game challenging without making it frustrating.

A claw machine that wins every time stops being interesting. A claw machine that drops every toy feels pointless. A good version asks the player to improve their aim, makes the result understandable, and gives them a reason to try again.

The same principle shaped the other games.

In Axie’s Gold Adventure, getting spotted costs some coins, but it does not erase the entire journey. In Chameleon Run, later levels become faster and more complex, but the core controls stay familiar. In Bear Necessities, danger should create interesting choices, not trap the player somewhere with no possible escape.

I want the games to encourage productive struggle: challenges that require effort, give useful feedback, and feel achievable with another attempt.

That is also how we try to build them.

A bug is not a failure that ends the project. It is information. A bad idea is not embarrassing. It is a theory we tested. A difficult problem is not evidence that she cannot do it. It is something we have not broken down far enough yet.

The best moments are not when everything works immediately. They are when Sabina gets stuck, stays with the problem, and then sees her own solution work.

Building a High-Agency Mindset

Software can feel like a finished world made by other people. The buttons, rules, and experiences arrive already decided.

Making games changes that relationship.

If a rule is confusing, she can rewrite it. If a level is unfair, she can rebalance it. If a character does not exist, she can invent one. If the first version is bad, she can make a second version.

She is learning that the world around her is not entirely fixed. Things are made by people. Problems can be understood. Systems can be changed. Her ideas can affect what happens next.

That is the mindset I want to encourage: not “I already know how to do this,” but “I can figure out what to try.”

High agency is not believing every idea will work. It is believing you can take the next step, learn from what happens, and keep going.

Try It With Your Kid

You do not need to know how to make games. Start with something your child already cares about: an animal, a toy, a family memory, a sport, a place you visited, or a ridiculous joke.

Ask them to complete one sentence:

The player can ___, and they win when ___.

Then work through a small loop together:

Name the parts. Who is the player? What can they do? What is the goal? What makes it difficult?
Make the smallest playable version. Use whatever tool helps you get from an idea to something your child can experience.
Hand them the controls. Let their experience lead the conversation.
Ask before solving. What happened? What did they expect? What part might be responsible? What could they try?
Change one thing. Play again and see whether the change produced the result they expected.
Keep the challenge useful. Make failure understandable and another attempt worthwhile.
Stop while it is still fun. Leave something for the next time you sit down together.

You can see the plans, systems, iterations, and questions behind our games in the How We Built This pages.

The tool you use matters far less than the role you give your child. Do not just make something for them. Make it with them. Let them bring the idea, experience the result, explain what they notice, and decide what should happen next.

The finished game is fun. The more important result is a kid who looks at something difficult or unfinished and thinks, “I can figure out how to make this better.”