Spooky Hollow: the math game Hannah actually asked to play

Everybody is talking about how fast AI can turn an idea into software, and the speed is real. The part I keep finding more useful is how quickly it gets the software in front of the one person who can tell you whether the idea works. A test suite can prove that every addition problem is valid. It cannot tell you whether your daughter wants another round.

Hannah is working through C6, and addition is one of the places where more repetitions matter. The problem is not explaining the idea once. It is getting enough deliberate practice without turning the evening into a negotiation over another worksheet. She already spends short sessions on a tablet, loves Roblox obbys, and will take a kid-friendly spooky theme over almost anything else.

Naturally, my brain went here:

What if the worksheet were the ghost hunt?

That became Spooky Hollow, a Roblox game where Hannah crosses a haunted valley, catches a ghost, and solves an addition problem to turn it into a friend. Catch eight and a crowned boss appears. Beat the boss and the level is complete. The math is not a gate between her and the game, it is the thing the game is about.

I started with her constraints, not mine

The design brief was unusually specific because the player was sitting in the next room. Everything had to work on a tablet, every important action had to be a large tap target, and a session needed to feel complete before a child's attention moved somewhere else. The platforming could be exciting, but it could not punish her for missing a jump, so there is no fall damage and no death. Invisible catch planes return her to the last checkpoint, the stones are wide, and the RUN and JUMP buttons are intentionally hard to miss.

The learning progression was the part I refused to treat like game tuning. Eight levels move from sums within 5 through two-digit addition without regrouping, then finish with a mixed level. Counting hints are ten-frames, with two rows of five and full bars for tens, because that is the visual model she already knows. The rest of the game can get prettier or harder. Those progressions stay put.

Then I made one parent decision that changed the whole feel of it: five seconds per question. My first pass had no timer, then a later pass used 20 to 35 seconds depending on the level. Both were technically reasonable and neither created the brisk practice loop I wanted, so every question now gets five seconds. If time expires, the trail restarts. That sounds strict next to the forgiving platforming, but the distinction is deliberate. Missing a jump should not end the attempt. Running out the math clock should.

The wrong answer rule mattered more than the haunted village

The easiest version of this game would keep asking the same problem until Hannah tapped the right tombstone. It would also teach her that guessing is free, so the game has a harder invariant: a wrong answer always produces a brand-new problem, and only the first submitted answer counts toward the score. Closing the card, walking away, or re-entering the encounter cannot erase the attempt.

That small rule created some of the least visible and most important engineering in the build. The server keeps the correct answer to itself, records which ghost slots have already been attempted, and carries boss progress across cancels and re-entry. An adversarial review found two real scoring exploits in the first implementation, including a boss path that could push first-try accuracy above 100 percent. Both were fixed before the first playtest.

There are also three answer choices rather than a keyboard, because typing on a tablet would test motor patience along with arithmetic. The distractors stay close enough to require solving, hints show quantities rather than the answer, and the server validates every tap. None of that is visible in the artwork. It is the part that makes this a learning game instead of an obby wearing a math costume.

One day, eight levels, 72 ghosts

The entire world is code. A blank Roblox place starts the server, builds a 190-stud village square, four gates, eight separate haunted zones, 12-platform trails, cottages, a chapel, a manor, a wishing tree, and the Count's Moon Crypt. The build also creates 72 moving ghosts, including eight bosses, plus a garden where captured ghosts can follow Hannah around as pets. No part of the map has to be placed by hand, which means the whole game can be deleted and rebuilt from source without losing the world.

AI wrote most of that first version in one long day while I made the product calls. I decided that walking near a ghost should start the encounter automatically, that gates should teleport rather than force a long walk across an oversized map, and that every fall should return Hannah to a known checkpoint. The AI turned those decisions into 24 Roblox scripts and 4,367 lines of code, tests, configuration, and documentation. It also built a local test harness because Roblox Studio could not run unattended on the machine.

That harness generated 17,600 math problems across the eight levels and checked every answer range, distractor, and five-second timer. A second test opened the finished Roblox place file and confirmed that all 24 scripts landed at the exact paths the game expects. The linter finished with zero errors and zero warnings. Structurally, the first build was clean.

It was also not ready.

17,600 checks and the sign still blocked the door

My first screenshots found three problems immediately. The answer numbers were invisible because a screen-layer setting put them behind the card. The world validator reported twice as many ghost spawns as expected because it was counting the moving ghosts it had just created. The level label sat on top of the math card.

The second round was better and exposed something more basic: the sign for each level physically blocked the path from the start pad to the first platform. The pet album existed but rendered under its own panel. The third round found a replication race that sometimes killed the entire interface, the camera started inside the giant SPOOKY HOLLOW sign, and every gate faced away from the village square.

Every automated check had passed while the front door was blocked by a sign. That is not an argument against the checks, because they caught scoring exploits and math errors that a few play sessions would miss. It is an argument for knowing what each kind of evidence can prove. AI can build the world, inspect every script path, and generate 17,600 valid problems. Hannah is still the one who can tell me whether the game makes sense from the first tap.

What I am actually trying to learn

The immediate goal is simple: make addition practice feel like something Hannah chose. I will know that worked if she asks to play again without being asked to practice math first. Scores matter, but the second session is the more useful signal.

The broader experiment is the same one behind the rest of these builds. AI made it possible for one person to turn a specific learning need into a complete playable world in a day, then revise the whole thing between family playtests. The bottleneck moved away from typing the code and toward judgment: which rules protect the learning, which friction is useful, and which failure is just the game getting in her way.

Spooky Hollow is built and running locally, but it is not public yet. The next step is a private tablet test with Hannah, where the questions are no longer whether the place file compiles or the answers validate. They are whether five seconds feels energizing or frustrating, whether the touch controls fit her hands, and whether catching a ninth ghost sounds better than doing one more problem.

That is the review no agent can do for me.