When the game scenario my child wrote by hand filled a sheet of A4 paper, I thought there would be nothing left to surprise me.
But once the game actually began to move, my child took out another sheet. This one was not for the next scene of the story. It was for writing down, by hand, the things that needed to change after playing the game.
Character sizes, movement, transformation scenes, and the exact words to be spoken outside a cave: the list grew to more than thirty handwritten change requests.
That was how our home became a tiny game development team. My child wrote the scenario and the requests as the designer; I organized those requests, passed them to AI for implementation, and reviewed the results together with my child.
What becomes visible when a game begins to move
Everything feels natural on paper. Galsaengi moves like Galsaengi, Block looks as big as Block should, and Guardian Fairy knows to protect the hero.
On a screen, though, none of that happens automatically.
Good Zombie had to be the largest, Block a little smaller, Galsaengi smaller still, and Guardian Fairy the tiniest of all, flying close to the hero. The way each character moved mattered too.
These were not minor cosmetic changes to my child. They were a way of closing the gap between the world imagined and the world that had appeared on the screen.
When I had only heard the ideas, I had not noticed all those differences. Building the game made the necessary changes much clearer.
Grouping more than thirty requests into workable batches
As the change requests accumulated, handling each one whenever it came up became difficult. Some affected other features, while changing too many things at once made it hard to see what had actually happened.
So we grouped related requests: character sizes and movement, scenery and locations, items and transformations, or dialogue and guidance. Sometimes we implemented batches containing more than five changes.
I kept my child's handwritten list beside me and checked items off one by one. We marked what had reached the screen and left unfinished items on the list. When a new idea appeared, my child wrote that down too.
Watching the check marks gradually increase was surprisingly satisfying. Complicated development terminology did not matter to my child. What mattered was whether something written on that sheet of paper really happened in the game.
Those words had to come from Guardian Fairy
One particular request stayed with me: a line of dialogue near the cave.
There are crystals here, but there is a Bad Zombie inside the cave.
My child insisted that Guardian Fairy had to say it.
I initially thought that simply displaying a warning would be enough. But my child did not want anonymous text to appear on the screen. The little friend who had followed the hero since the beginning of the game needed to give the warning directly.
Once I understood the difference, the line sounded different to me. My child did not want a generic instruction. It was a moment in which a companion says, "Be careful."
The same idea applied to Guardian Fairy protecting the hero from attacks. The fairy had to be a guardian in more than name.
That detail felt both sweet and meaningful. My child was not simply asking for another feature. My child was preserving the personality of a character they had invented.
The moment Galsaengi becomes Block
I also remember the transformation sequence.
The game begins with Galsaengi. Break rocks and collect three crystals, and the hero transforms into Block. Collect more crystals, and the hero changes into Good Zombie.
When characters that had once been folded and cut out of paper began transforming on the screen, the game gained a little sense of celebration. The screen darkened, large transformation lettering appeared, and a glowing effect played.
It did not need to be spectacular graphics. What mattered was that the rule my child had chosen was actually unfolding before us.
And even after the hero became Block and then Good Zombie, Guardian Fairy was still nearby. The roles decided on paper remained part of the game.
My child planned it; I checked each change
This project helped me understand a little better what AI had done and what it had not done.
AI helped turn the requests I had organized into code, modify features, and test new screens. That made it possible to try building a small game that I might otherwise have hesitated to start.
But AI did not decide which part was more fun, how large each character should be, or when Guardian Fairy should speak and what the fairy should say.
Those decisions belonged to my child.
My role was to listen to that vision, divide it into work we could manage, and review the results together. Because it was not something we could finish in one pass, we ended up talking about it even more.
My child imagined; I organized; AI helped implement. Then we looked at what appeared on the screen and came up with the next idea.
When will this game be finished?
At first, I thought I was making a game for my child.
Over time, it began to feel different. My child was not merely playing: they had created characters, imagined an adventure, and written both the scenario and more than thirty changes in their own handwriting.
I looked for ways to bring that story onto the screen. With AI's help, I implemented it, checked it with my child, and changed it again.
Rather than something I had made alone, the game felt like a small world we were shaping together.
It might not be finished anytime soon. Tomorrow, my child may come up with another idea.
Now I find myself looking forward to that.
A story that began on the desk as paper became something moving on the screen, and that moving screen is already giving us new stories.