Building a Game I Can Give to My Kid

I'm developing an online game, and my son plays it. That sentence sounds harmless — but it's the strictest design constraint this project has. Because I sit on both sides of the table: as a developer who wants features, and as a father who knows what's out there on the internet.

A few decisions that wouldn't exist without this dual role:

Accounts without an email address. A kid shouldn't leave a data trail just to stack blocks. So our accounts don't require an email — what we don't collect can't hurt anyone.

Public worlds only with a password. Strangers can't just wander into a kid's world. Whoever is meant to play along gets the password in person — on the schoolyard, not from the algorithm.

The playtime reminder. The game shows the session duration and gently reminds you to take breaks. Did I enjoy building that as a developer? Let's say: the father overruled the developer. (Justus's opinion on this is on record and differs.)

Reporting as easy as chatting. If something weird happens, you type /report — the rest (chat log, world context) goes along automatically. A kid shouldn't have to prove anything.

The interesting part: none of these decisions made the game worse. The password rule makes worlds more personal. The lean accounts save us privacy headaches. And the break reminder… well, it occasionally reminds the developer, too.

You build differently when your most important user sits at the same kitchen table. By now I believe: you build better.