1975 - Corn Hat

In the mid-seventies, the University of Illinois had PLATO: a network of terminals built to teach students chemistry, languages and mathematics. The terminals had touch screens and glowing orange plasma displays. They were among the most advanced educational machines on the planet. The students used them to kill goblins.

One of the results was Orthanc, by Paul Resch, Larry Kemp and Eric Hagstrom. You roll a character. You go down into a labyrinth. You fight whatever lives there. You climb back out and cash in your experience. Then you do it again, deeper, until the labyrinth wins. The labyrinth always wins.

It is one of the very first computer RPGs. Back then, the whole genre was a few students and one very big computer. The rules are still around, lovingly preserved on a page dedicated to the game. They are clear, complete, and slightly threatening.

Rearrange the letters of Orthanc and you get Corn Hat.

That’s a pun. It’s not a good pun. The game is not a serious game, so it has a pun of the appropriate quality.

What I Made

I mostly didn’t write this one.

I did the parts that decide what a game is. The architecture: the game states stack, the main loop, the window, the drawing plumbing. The load-bearing walls.

The game design: what you do, why you do it, and how badly it goes.

And the big pictures: the title screen, the tavern, the tomb (which you’ll be seeing a lot of) and the victory screen (which you won’t). I drew those myself, by hand, one line at a time. It was tedious and horrifically long, and it was the most fun I had on the whole project.

Then I stepped back and let an AI write the rest.

What the AI Made

Everything else. Fights, spells, items, levelling, the dungeon, the rules screens. What it had to go on was the rules of the original Orthanc, and a stream of general directions from me, delivered in the style of a manager who has read the first chapter of a book about delegation and is very excited about it.

This is what people call vibe-coding. I gave instructions. The machine wrote code. I read the code, gave corrections, and started again. I stopped when the game worked, or when I realised I’d been correcting a computer for three hours and it was dark outside.

Which brings us back to the name.

A generative AI doesn’t write the way you and I do. It works in tokens: small pieces of words. From everything it ever read, it learned which pieces tend to follow which, and it writes one piece at a time, each time picking one that seems likely. Most of the time, you get what you asked for. Sometimes, you get something plausible, well-formed, confident, and not at all what you meant.

You asked for a wizard’s tower. You got a hat made of corn. For a game made this way, the name felt right.

I initially wanted to draw the player and monsters at the end of the project, once everything was working. As such, I also asked AI to generate small placeholder drawings for them first. What came back looked exactly like the drawings your kid brings home from school. Wobbly, sincere and absolutely hilarious.

You don’t fix those. You tell your AI kid they are wonderful and you pin them on the fridge door.

I am not redrawing the monsters.

Why Let an AI Do It

Not laziness. Or not only laziness. Also quite a lot of curiosity.

Banjo is an API. APIs exist to be used by someone who didn’t write them. And these days, that someone isn’t always a someone.

So the question wasn’t “can an AI make a game?” It can. The internet is full of evidence. Some of it is even playable. The question was:

How far can an AI go with my API? And, the other way around: how well does my API hold up when it’s used by something that has never met me, cannot read my mind, and has no idea what I meant by that function name?

When a human developer is confused by your API, they open an issue. Or they send a slightly passive-aggressive message. Or they quietly switch to another library and you never hear from them again, which is the worst one.

An AI does none of these things. It just tries. It tries with the tireless optimism of a dog that has been shown a ball, and wherever the API is unclear, it guesses. Confidently. Repeatedly. With a comment explaining why the guess is correct.

I fully expected to spend the project watching it guess.

How Far It Went

Far.

The game is about 6,500 lines of C. For comparison, Moonlander was about 700, and I was quite proud of it. I am now slightly less proud of it.

Corn Hat has ten floors of dungeon, a character rolled on three six-sided dice, spells, a pack full of magical objects, and the aforementioned fridge-door bestiary.

Next to the Skeletons, the Ghouls and the Ogres you’d expect in a 1975 dungeon, the AI added a Part-Time Werewolf, a Goth Elf, a Locally Sourced Druid and, on the fifth floor, a Scrum Master, worth more experience than anything else at that depth.

I asked for this. I told it the monsters could have funny names. It took the job very seriously. Nobody told it how much experience a Scrum Master should be worth, and it decided, on its own, that the answer was: more than a Unicorn.

The story, on the other hand, is mine.

In it, the wizard’s tower Orthanc falls apart so thoroughly that “every stone came apart from every other stone and settled in an order with no relation to the one it went up in. The same tower, the same weight, all its letters shaken out.” Under the rubble, a farmer finds a hat made of corn husk, “far too old to still exist and quietly refusing to stop.”

That’s the anagram, told as a creation myth. I’m unreasonably pleased with it.

I did explain the anagram to the AI. It seemed important that it understood the name of the thing it was building. It understood.

And it judged me.

Politely, the way a waiter looks at you when you order the most expensive wine on the menu and ask for ice. It is a very particular feeling, being quietly disapproved of by the same entity that, minutes earlier, had invented the Scrum Master.

Mazes, Properly This Time

You may remember 1974. I set out to make Maze War. A baby arrived. The game shrank to what it is now: a maze you walk around in. One maze, the same every time, because generating mazes was one more thing I didn’t have time for, or sleep for, or, some nights, the correct number of working brain cells for.

Corn Hat has ten floors of labyrinth. A labyrinth has to come from somewhere. Labyrinths don’t grow on their own.

Well. Some do. Every summer, farmers grow a field of corn, also called maize, and cut a maze into it. A maize maze. For a game called Corn Hat, it would have been the obvious method.

But corn doesn’t grow in C.

So this time, I did it properly, in Banjo.

Banjo can now make mazes. Not in one way: in six. It can build a whole maze at once, or dig it one small step at a time, so you can sit and watch.

All six methods come from Jamis Buck’s Mazes for Programmers. It’s a whole book about making mazes, almost three hundred pages of it, on purpose.

I recommend it to anyone who has ever solved the maze on the back of a cereal box, and then sat there, spoon in hand, thinking: how the hell did they make it?

The book answers that. Many times over, because there are a lot of ways to make a maze. I stopped at six.

Look at them go. One of them, Aldous-Broder, wanders around at random until it has visited every cell, with no plan and no sense of urgency. It gets there eventually. It’s the only algorithm I know that has a personality, and the personality is “Sunday afternoon”.

The game where I wrote the least code is the one that made me write the most interesting code. The AI got the dungeon. I got the library that makes dungeons. It’s the part of Corn Hat I spent the most time on, and where most of the code I actually wrote for it lives.

As for Maze, the game: it’s still bland. But it now lives in the same library as six different ways it could have been otherwise. It knows. I can tell it knows.

How Banjo Held Up

Frankly? Really well.

The final code is clean. It uses the API the way I would have used it, which is either a compliment to the API, or evidence that the AI has been reading my commit history at night.

It calls the right functions, for the right reasons. It doesn’t reinvent what Banjo already does. It doesn’t hide what it’s doing behind seven layers of abstraction, each with a name ending in “Manager”.

It also didn’t take many rounds. I was ready for a long, patient back and forth: correcting guesses, explaining what I meant, explaining what I meant by what I meant. It didn’t happen. Most of my directions ended up being about the game, not about how to use Banjo.

Part of that is C.

Banjo is plain procedural C: functions and structs, and that’s it. There’s no inheritance tree to climb, no template to decode, no magic that happens because you named a method in a particular way on a particular day. What you read is what runs.

That’s a comfortable place for a human. It’s a comfortable place for an AI too. Nobody enjoys being surprised by their own code. Not even the ones made of tokens.

The preface of Structure and Interpretation of Computer Programs, a famous programming book by Harold Abelson, Gerald Jay Sussman and Julie Sussman, puts it like this:

Programs must be written for people to read, and only incidentally for machines to execute.

Programming languages are not made for machines. Machines don’t need them. A machine is perfectly happy with a long list of numbers. Languages are made for us: so we can read what we wrote yesterday, and so someone else can read it tomorrow.

So there’s something a little funny about asking a machine to write C. C exists so that humans don’t have to talk to the machine directly. And now a machine writes it, so that a human can read it.

It also leaves me with a question.

If an AI does this well with a small, plain language like C, maybe even better than with big, expressive ones like Python or TypeScript (expressive for us humans), then why give it those at all? Why not always ask it for the simplest, most bare-bones language there is?

And why stop at C?

Why not assembly?

I’ll just leave that here.

What I Learned

AI can already do nice things. It can build a real game on top of a small, stubborn, one-person C library, and use that library well.

I was worried Banjo would be unreadable to an AI: too short, too quirky, full of names that only make sense if you happened to be in the room when I picked them, and I was the only one in the room.

There’s no special trick to making an API readable for an AI. You make it readable for humans. Clear names, consistent patterns, and one obvious way to do each thing. The AI reads your API the way a newcomer does, just faster, and without sighing.

That sent me off on a whole new project.

If readability is what matters, Banjo had some catching up to do. So I went through the entire public API, one name at a time, for naming and consistency. Banjo now has explicit readability conventions, and a large part of the API has been renamed to follow them: windows, bitmaps, streams, events, drawing.

This was an easy case, though. A small game from the seventies, on a small API, with rules that fit on a single web page. Being impressed by that is like being impressed by a world-class chef making toast.

And there’s something else. Something the AI took from me without asking, and without even noticing.

The fun.

The best part of being a developer is the moment a problem that has been beating you for three days suddenly gives up. You stare at it. It stares back. Then it works, and for about four seconds, you are the smartest person who has ever lived.

The AI solved hundreds of those problems for me. It didn’t enjoy a single one of them. Neither did I, because I wasn’t there. Somewhere, hundreds of perfectly good four-second moments of genius went to waste, and nobody even noticed.

Still, I’ll give AI one thing. It’s a colleague who will never, ever start an argument about tabs versus spaces. It uses whatever you use, and it says nothing. That may be the greatest progress our industry has made in forty years.

The next one, I’ll write myself. Let’s see what 1976 has in store.