A parent builds a text adventure for their eight-year-old. Not a course. Not a certificate. A dungeon with rooms and doors and a dragon that says something rude if you type the wrong verb. They post it to Hacker News. Two hundred and sixty-nine points, then the comments show up, and half of them are oddly hostile for a project that isn't trying to sell anyone anything. One commenter on the original thread says it plainly: this is a fun collaboration between a parent and a kid, it doesn't compete with anything, and it doesn't need to.
That's the whole pitch, and it's a good one. A MUD -- a multi-user dungeon, the text-based ancestor of every MMO you've played -- is a command interpreter wearing a costume. You type go north. Something reads that string, breaks it into tokens, decides what it means, and changes the state of the world. That's not a metaphor for programming. That is programming, the exact shape of it, minus the part where your kid has to care about for loops before they've seen anything worth looping over.
Why the command parser is the actual lesson
Every serious coding-for-kids product on the market solves the motivation problem by wrapping code in something that isn't a terminal. CodeMonkey has you write CoffeeScript and Python to catch bananas. codingforkids.io puts you in a code editor next to a dungeon map and has you type player.move_forward() to walk toward an exit. Both are honest about the trick: hide the syntax behind a payoff a kid actually wants.
A MUD does the same trick, but it does it with a parser your kid built or watched get built, instead of one hidden inside somebody else's platform. That distinction matters more than it sounds like it should. When player.move_forward() doesn't do anything, the kid on codingforkids.io hits a wall the product author designed. When your homemade parser doesn't recognize open door, you and your kid are debugging the same function together, and the fix is visible, not abstracted behind a vendor's runtime.
We've written before about why lexing and parsing still matter as a discipline even in an era of code-generating models -- the 2021 compiler theory that describes tokenizing input and building a semantic model of intent hasn't gone stale just because an LLM can spit out a working parser in ten seconds. A MUD's verb handler is that same theory at toy scale: tokenize the input, match it against a grammar of verbs and nouns, resolve what the player means, mutate state. Get a kid comfortable with that loop and you've quietly taught them the shape of every interpreter they'll ever touch.
Where the LLM actually earns its keep
The HN commenter's point about using an LLM for the base project is the right instinct, applied narrowly. Scaffolding a room graph, a starter inventory system, a handful of NPC dialogue trees -- that's boilerplate, and boilerplate is exactly what you want a model to burn through so the actual teaching time goes to the parts that require a human explaining why the code does what it does.
But scaffolding isn't the same as abdication. Treating AI output as done work rather than a draft is how bugs, security holes, and outdated patterns quietly move from a training corpus into your codebase -- engineers need to keep doing algorithm analysis, design pattern recognition, and code review even when the first draft came from a model, because the model doesn't know your requirements, it knows what similar code has looked like before. If you're generating the base MUD engine with an assistant, sit down and read the room-loading function with your kid before you ship it. That's not extra homework. That's the actual lesson. The code review is the curriculum.
Testing as play, not as a chore bolted on afterward
A MUD gives you test-driven development for free, if you let it. "Open the locked door" should fail until the key-checking logic exists. Write that failing case first, watch it fail, then write the minimum code that makes it pass -- that's the TDD discipline in one sentence, and it works exactly the same whether the thing under test is a payment processor or a wizard's tower with a stuck door. The difference with a kid is that the failing test isn't red text in a terminal, it's their character walking into a wall and getting an error message they wrote themselves. That's a far better hook into "why do we write tests before code" than any abstract explanation involving invoices or unit conversions.
The build itself is a small, sturdy stack
If you're standing up a MUD server rather than hand-rolling sockets, a lightweight Python API framework does the job well -- we've made the case elsewhere for FastAPI as a low-ceremony way to expose endpoints without a framework fighting you the whole way, and a MUD's command endpoint (take input, mutate world state, return a description) maps onto that shape cleanly. The harder problem, and the one people underestimate, is persistence: your kid quits after twenty minutes and comes back tomorrow expecting the dragon to still be dead. That's the same state-continuity problem we ran into building persistent memory for coding agents -- the gap between a session that remembers nothing and one that carries state forward is the difference between a toy and a world that feels real. A MUD world file, saved to disk between sessions, is the same idea at a scale a kid can hold in their head.
The alternatives, and why building beats buying here
If you don't want to build anything, the market has options. Machine Learning for Kids leans further into ML concepts, having kids train a classifier rather than write imperative logic. And one developer, watching their ten-year-old close the laptop by lesson three of a standard Python course and go back to YouTube, built a browser-based dungeon crawler from scratch specifically because the tutorial format had already lost. That's the pattern across every one of these projects: the platforms that stick aren't the ones with the most polished curriculum, they're the ones where the kid wants to see what's behind the next door.
A store-bought platform will always out-polish a parent's weekend project. It will not out-collaborate it. The kid working through CodeMonkey's banana-catching levels is alone with a product. The kid working through a MUD you built together is debugging a shared thing, watching you read a stack trace out loud, learning that "it doesn't work" is a starting point, not a verdict. That's the actual pitch of teaching a kid to code with a MUD, and it's worth building even if the comment section doesn't get it.
Sources
- https://news.ycombinator.com/item?id=49272631
- https://dev.to/zhutoulala/i-built-a-free-browser-game-that-teaches-kids-to-code-in-python-302c
Originally published at www.gladlabs.io.
Top comments (0)