Teaching my kid to code with a modern MUD
Mirrored from Hacker News — AI on Front Page for archival readability. Support the source by reading on the original site.
My eight year old daughter wants to make video games.
She’s obsessed with this idea. She likes playing video games too, but it’s just not the same. Experiencing the world, even defeating the world, is too passive. She wants to make the world.
So I made her a game where she can make games. A multiplayer world made of text and images and a tiny new scripting language, where she can take anything and everything apart to see how it works. I first learned to code in the days when View Source was a reliable teacher, and I think she deserves the same.
The game has a lot of limitations. The language, Cant, is
not a very good language, and that’s on purpose.
But it also turned out to be a lot of fun. I call it:
Canon
Canon is a modern, web-based take on the classic MUDs of the Old Internet.
For the uninitiated: back before World of Warcraft made the MMORPG a big studio genre, we had text-based MUDs (and MUCKs and MUSHes) where players could adventure and socialize in vast realms made of pure written words.
I spent countless hours exploring these imaginary places. I wanted to make something in that spirit that would feel more familiar to a modern audience.
Canon has strong opinions about what makes a good MU*, and what makes a good learning environment. Every room, object, and interaction in Canon is player-created, and it can all be inspected, copied, and modified.
The kiddo loves it. If you’re the kind of grownup who’s into roleplaying or text adventures, or has some nostalgia for the age of telnet and the early web, you might like it too.
But first, recipe blog style, let me tell you how we got here.
Training wheels for the bicycle for the mind
Do you remember HyperCard? If not, do you remember Myst? (If not, congratulations on being young. Bear with me.)
Bill Atkinson dreamed up HyperCard in 1985 after an LSD trip. I first encountered it in 1989, in my 4th grade computer lab, and also had my mind expanded.
HyperCard works like this: there are cards.
I mean, that’s pretty much it. That’s the genius. There are cards, and you can put computer things on them. Buttons and text and pictures and video. Cards get stacked together. A HyperCard app is called a “stack”. Get it?
And then all those buttons and pictures and things: you can make them clickable. And you can tell them to move between cards in the stack. It’s a choose your own adventure book as UX.
(If this sounds kind of like a web site, well, yes. HyperCard was one of the first real usable instances of HyperMedia and influenced Tim Berners-Lee’s development of the World Wide Web.)
on mouseUp
go to card id 123
end mouseUp
That there is valid HyperTalk, the programming language underlying HyperCard. But for the most basic interactions like that – click a button, go to a card – you don’t even need to know HyperTalk. You can wire things up using a simple GUI editor.
If you can click a button you can use HyperCard. And if you can use HyperCard, you can program HyperCard.
I could write a whole series of posts about this. But the two things I want to impart to you now are as follows:
- HyperCard was magic.
- HyperCard sucked.
It was magic and it sucked
In many ways HyperCard stacks were not good apps. They were heavily constrained by the card metaphor. They used input elements from the MacOS visual language, but they did not, and could not, feel like normal native MacOS applications. HyperTalk made the same mistake later repeated by AppleScript: trying to make a programming language look more like natural language, thus failing to be either thing well.
To any real programmer it was a frustrating underpowered environment. But those same flaws and constraints made it magically accessible to two hungry groups: non-programmers and curious kids.
The first group produced a ton of stuff. The Internet Archive has a playable collection of thousands of stacks. If you remember the Early Web, just browsing the thumbnails should give you a familiar feeling. Games! Zines! Fandoms! Manifestos! Somehow porn! Before the web, people with a Mac and Something To Say traded stacks on floppies.
I fell into the second camp. At nine years old I found HyperCard on my elementary school’s Macintosh SE and quickly discovered that unlike most computer programs, everything in HyperCard was editable. I started making the first thing that popped into my mind, which was a Street Fighter style fighting game with two crudely drawn players.
Which is what I call the box of dead floppies in my parents’ basement.
I didn’t know anything about programming, much less advanced gamedev concepts like sprites. But I knew I could link buttons to cards. So I did that. With the determination only a hyperfocused child can muster, I set about drawing individual cards for every possible combination of player moves and positions, with buttons as “controls” to move between them. I’d found me a hammer, and I could see how to make a game out of nothing but nails.
You’re on card 154. Player 1 is in quadrant 2, idling. Player 2 is in quadrant 3, defending. If player 1 presses the “attack” button, go to card...
It took me weeks staying late after school. But it worked. I made a game. I could play my own creation. I’ve spent my whole career chasing that high.
But that was just the beginning. One of the really clever things Bill
Atkinson did was to make it so when you edited HyperCard behaviors
with the GUI, it just wrote the corresponding code for you.
About halfway through my laborious clicking-and-linking project, I
noticed the Script… button in the editor, pieced together
its implications, and started using a copy & paste HyperTalk
snippet and a systematic naming scheme for all my hundreds of cards to
speed up development.
Near the end the computer teacher (I’m pretty sure we just called the class “computers”) noticed what I was up to and dug the HyperCard Reference Manual out of a drawer for me. This was my first experience reading a tech manual cover to cover.
Many years later…
I’m not going to make my daughter learn HyperCard. I’m a bit of a Troll Dad, but not that mean.
But I did want to reproduce the magical combination of creative freedom and mechanical constraints that made HyperCard so eye-opening for young Nick. Canon needed:
- Instant gratification. As soon as you put a thing on screen, it’s already part of the game.
- View Source. Everything in the game should be built with the game’s own tools, and freely editable/copyable/take-apart-able.
- A GUI for the simplest interactions.
- A smooth learning gradient from GUI to writing raw code.
- Just enough power in that code to build a wide range of fun game mechanics, and to teach basic programmer ways of thinking.
- But limited enough that a beginner could grasp the entire set of primitives.
Instant gratification
The great thing about a text-based world is that you can add anything you want just by typing “there is a [thing] here”. You’re constrained in how you can build – no fancy 3D visualizations or impressively realistic physics engines – but have unlimited freedom in what you can build.
Canon is made of three things:
- Players
- Rooms
- Items
Players and Rooms are both just text descriptions and, optionally, images. To make either, you just answer a question: what does this look like?
Discussion (0)
Sign in to join the discussion. Free account, 30 seconds — email code or GitHub.
Sign in →No comments yet. Sign in and be the first to say something.