Iron ChIF: Season One Episode 2 (Lancelot vs. SomeOne2, using ZIL)

otistdog · May 23, 2026, 6:59pm

Nearly all is in readiness. In addition to the competing chefs and these honorable judges, yet one more role will play a part during the coming contest, that of technical advisor. The role of technical advisor is subtle yet essential: to provide insight into the development system in use and context for the techniques demonstrated by the competing chefs.

For this episode, our technical advisor will be Tara McGrew (@vaporware), developer of the ZILF compiler and the world’s leading modern expert on the ZIL language. vaporware’s IF career has produced many technically impressive innovations, from well-known extensions for Inform 7 (Dynamic Objects, Hypothetical Questions, Conditional Undo) to dramatic re-inventions of core tools, such as Typed Inform, Guncho, FyreVM, and Linchpin.

Judges will be able to turn to vaporware for answers to their technical questions about any code that the competing chefs share during the match, and – for your edification – our final cast member has prepared an overview of ZIL in order to familiarize viewers with its unique distinctive features.

We now turn to our technical advisor, who will tell the audience and judges about this historically significant language and what sets it apart from other platforms.

vaporware · May 23, 2026, 9:31pm

ZIL: The origin

The very first version of Zork was written in the late 1970s, at the MIT Laboratory for Computer Science, in a sophisticated (for the time) language called MDL. It ran on a hefty (for the time) computer, the DECsystem-10, which was far more powerful than the “microcomputers” found in homes in the 1980s. That made it difficult to turn into a product they could sell.

In order to turn Zork into something that people could play at home on, say, a TRS-80 or Apple II, Infocom developed two key technologies: a small imaginary computer that could be implemented on home computers using an interpreter, and a language that could be compiled to run on that imaginary computer. They called the imaginary computer the Z-machine, and the language the Zork Implementation Language (ZIL).^[1]

Infocom’s compiler (ZILCH) is mostly^[2] lost to time, so working with ZIL today typically means using ZILF, a reconstructed set of tools that’s just compatible enough to compile all of Infocom’s games. Because of the tangled relationship between MDL, ZILCH, and ZILF–and the fact that ZILCH’s capabilities evolved over the years–it’s hard to nail down an exact specification of the language, so when I say “ZIL”, I mean “whatever ZILF will accept”.

The basics

Because Infocom was porting a game written in MDL, their new language bore a striking resemblance to MDL. Let’s look at some code from Zork 1 now:

<OBJECT SANDWICH-BAG
    (IN KITCHEN-TABLE)
    (SYNONYM BAG SACK)
    (ADJECTIVE BROWN ELONGATED SMELLY)
    (DESC "brown sack")
    (FLAGS TAKEBIT CONTBIT BURNBIT)
    (FDESC
"On the table is an elongated brown sack, smelling of hot peppers.")
    (CAPACITY 9)
    (SIZE 9)
    (ACTION SANDWICH-BAG-FCN)>


<ROUTINE SANDWICH-BAG-FCN ()
    <COND (<AND <VERB? SMELL> <IN? ,LUNCH ,PRSO>>
           <TELL "It smells of hot peppers." CR>)>>

The first thing you might notice is that it’s CONSTANTLY YELLING. ZIL is written in all caps!

You might also notice the unusual punctuation. The names of things frequently contain symbols like hyphens, question marks, and slashes. Commas, periods, apostrophes, and exclamation points are used as prefixes. And there are brackets everywhere: parentheses, angle brackets, and occasionally square brackets.

You might even notice that everything is written in prefix notation. We don’t write 1 + 2 * 3; we write <+ 1 <* 2 3>>.The condition that you’d write in Inform 6 as action == ##Smell && lunch in noun, or in Inform 7 as smelling something that contains the lunch, translates into ZIL as <AND <VERB? SMELL> <IN? ,LUNCH ,PRSO>> (PRSO being a variable name that’s short for “parser object”).

What you might not notice from looking at the code is that ZIL uses unfamiliar terms to describe some familiar things. Those variable names aren’t called “identifiers”, they’re “atoms”. Those numbers might be “integers”, but they’re also “fixes”. Objects don’t have “attributes”, they have “flags”. Words don’t go in the “dictionary”, they go in the “vocabulary table”. Performing an action doesn’t even make you the “actor”, it makes you the “winner”. (Very optimistic!)

Inside a routine, one of the most common things to see is COND. It’s the equivalent of an if or switch statement: each parenthesized clause contains a condition followed by what to do if that condition is true. (Side note: “true” in ZIL is usually written as T, and “false” is usually written as <>.)

Inside an object definition, one of the most important bits is the list of FLAGS, which generally control what the player is allowed to do with it: in this case, they can pick it up (TAKEBIT), put things in it (CONTBIT, short for “container”), or burn it. Another important one is ACTION, which gives the name of a routine that handles the object’s unique behaviors: in this case, smelling the sandwich bag when it contains the lunch produces a special message instead of the default.

The strengths

ZIL was influential enough that a lot of what made it special at the time it was created has since become “the way things are done”, thanks largely to Inform having been designed around the Z-machine.

Today, the biggest thing that sets ZIL apart is its macro system. Although, to be fair, it isn’t really “ZIL’s macro system”… it’s literally just MDL, because the ZIL compiler is also a MDL interpreter. That means a ZIL program has access to the full ~~horror~~ power of MDL^[3] while it’s being compiled, and one of the things you can do with MDL is write macros to make the language feel more “high level” than it is. For example, Adventure defines this macro to simplify random chances:

<DEFMAC PROB ('N)
    <FORM L=? <FORM RANDOM 100> .N>>

Now if there’s something that needs to happen 25% of the time, we can write <PROB 25> and the macro will translate it to <L=? <RANDOM 100> 25>. Those angle-bracket groupings that the whole program is made of are called forms, and this macro uses FORM to construct some new ones based on the argument passed to PROB. (This idea of representing code as data structures that can be manipulated by other code will be familiar to anyone who’s used Lisp^[4]; it’s also part of the Lisp-like MDL, and thus part of ZIL.)

That’s a simple example, of course, but the general idea is that you can adapt the language to fit the needs of the project and your own convenience, so that you can think more in terms of your game world rather than the nitty-gritty implementation details. Adventure defines dozens of nearly-identical rooms for its maze, using macros to boil it down to the map connections and avoid rewriting the identical descriptions and property values each time:^[5]

<MAZE-ROOM ALIKE-MAZE-3
    (EAST 2) (DOWN DEAD-END-3) (SOUTH 6) (NORTH DEAD-END-8)>


<MAZE-ROOM ALIKE-MAZE-4
    (WEST 1) (NORTH 2) (EAST DEAD-END-1) (SOUTH DEAD-END-2) (UP 14) (DOWN 14)>


<DEAD-END-ROOM DEAD-END-1 WEST ALIKE-MAZE-4>


<DEAD-END-ROOM DEAD-END-2 EAST ALIKE-MAZE-4>

Bureaucracy uses macros to load text from a file and encrypt it for a puzzle.^[6]

Libraries and extensions especially benefit: ZILF’s standard library defines macros for customizing the status line^[7], scoring achievements^[8], and replacing library messages^[9], wrapping these technically complex systems in a friendly package.

The challenges

Unlike the rule-based systems we’ve seen in previous episodes, ZIL takes a strict procedural approach to action handling: each object has a single action routine (or, rarely, two) attached, and each verb has a single handler routine (or, rarely, two) that handles its default behavior.

That means you can’t just write code and let the system figure out when to run it, or even explicitly tell the system when to run it, like you could by ordering rules. The action routines belonging to the verb, objects, location, player, etc., are called in a set order for every action, and you have to code around that order. So the choice of which object should handle a particular action often comes down to the order the system enforces, rather than what makes sense.

ZIL also provides very little by way of data structures: at compile time, macros can use the full set of types provided by MDL, but at runtime, there are Z-machine objects and tables and that’s it. If you want a piece of text you can modify, you’re better off writing code to print it on the fly when it’s needed; if you want a list that can grow and shrink, you’ll have to implement it yourself on top of tables.

And finally, keeping track of all those brackets can be maddening! It’s common to see piles of closing brackets like >>)>)>>>> at the end of a block of code, and most editors aren’t set up to highlight matching angle brackets, so you may find yourself coding with one finger on the screen to make sure they stay balanced.

For more detailed information about ZIL, see the links on the ZILF documentation page.

otistdog · May 24, 2026, 1:05am

Thank you, vaporware. A nearly-lost language, that rises like a phoenix from the ashes in large part due to your own efforts. Although ZIL may look primitive when stood next to more modern code, it is rooted in the Lisp family, which is well known for its power and flexibility.

Earlier, behind the scenes, the two competing chefs reviewed the three options offered to serve as challenge ingredient. Each chef has eliminated one option, leaving the third as the nucleus for their dishes-to-be. Now that they have chosen, there is no going back.

The battle will commence in just eleven hours, at noon UTC Sunday May 24th. We salute the chefs as they prepare themselves for the challenge ahead!

otistdog · May 24, 2026, 12:00pm

And now, the time for action has arrived… Three potential challenge ingredients were laid before the chefs, and those three have been winnowed down to only one.

Here in this event, people separated by oceans and continents collaborate virtually shoulder-to-shoulder, casually flinging information in instants across distances so vast that it would have taken months or even years for it to reach its destination in ages past. In much the same way, the history of transportation has often painted a picture of our shrinking globe, and the claim is made that in the modern world distance has been abolished as a meaningful obstacle.

And yet… space and time still limit us. One can send a report across the face of the earth in milliseconds, but not a sandwich. Although modern science informs us that space and time are part of the same existential fabric, it also warns that we will be forever constrained in our ability to traverse it.

What if, we ask today, we weren’t?

For this second episode of Season One, the challenge ingredient will be:

an artifact that connects locations throughout time and space

The development period has now begun! Allez keyboard!

OverThinking · May 24, 2026, 2:24pm

an artifact that connects locations throughout time and space

What an ingredient! It’s immediately inspiring, and calls back to a hearty tradition of games like Never Gives Up Her Dead or the Little Match Girl series. While those games often have pretty strict limitations on the player’s ability to actually do the spatial/temporal hopping, the specific wording of this prompt seems to me to invite something more flexible. There’s a lot to be interpreted in those nine words, and I’m eager to see what our chefs do with it.

J_J_Guest · May 24, 2026, 2:48pm

One of the wonderful things about IF is that it’s possible to create such an artefact! I’m very intrigued to see how each contestant interprets this ingredient!

lpsmith · May 24, 2026, 2:51pm

Agreed! And while the most obvious question is ‘how will our protagonists manipulate the artifact to progress?’ (and by that, I certainly expect ‘progress’ to mean ‘solve puzzles’), the other question that my mind immediately goes to is ‘how did the existence of this artifact affect the world our protagonists find themselves in?’

The simplest answer would be ‘it’s new, so it hasn’t affected it yet’. Then you get to take a standard modern/fantasy/sci-fi/whatever world and impose this new element on it. But it can be a lot of fun to take a world, give it the ability to create this item, and think through the implications. This is exactly where I started with ‘a scroll that affects the world around it’ for my own episode: I finally settled on the core contradiction/question inherent in how I envisioned that item: why does a scroll affect things without being read? What would happen if it was read?

Here’s the contradiction I see inherent in that ingredient: ‘artifact’ implies ‘old and poorly understood’. But ‘connected throughout time and space’ implies that the old and the new are next to each other! How is it possible to have an ‘ancient artifact’ from a lost civilization, when people from that civilization can show up on your doorstep, and shoot the breeze?

There’s a lot of possible answers to that question, and that’s not the only question you could ask!

We don’t often participate in these sorts of ‘write to this premise’ contexts, but our minds will often do it for us: a premise pops into our heads, and then we start thinking of the logical implications of that idea. I’m curious if my fellow judges thought through the creation of their own games in the same manner: did an idea start with a premise you had to think through the implications of?

agat · May 24, 2026, 4:29pm

What an ingredient! I think it’s one that lets the chefs really show off their skills by opening up possibilities for so many puzzles, interactions, even settings and narrative elements! But without a proper technique – with too little discipline – it can bring down the dish, turn it into a disjointed mishmash of various bits and pieces. How will our chefs tackle this theme? Let’s hope the resulting taste combinations are fresh and exciting, not unpleasant and clashing!

An interesting question! From my own experience, I have mostly written games that started with a narrative idea, with puzzles coming later. My two Rosalinda games are an exception – I actually envisioned a “game with a skeleton that can manipulate her body parts independently” first as a 2D action/puzzle game (I’ve been slowly learning some non-IF game development systems for years). I quickly realised it was way too ambitious, but the core idea stuck with me until it became The Bones of Rosalinda – a Twine game where I designed puzzles and locations with the protagonist’s unique skills (and her companion, Piecrust the mouse) in mind. It sometimes required writing extra dialogue/solutions based on which PC/body part the player may be controlling at the time, but the game is rather short, so things never felt truly overwhelming.

Interestingly, one of the inspirations behind Rosalinda was character switching in Day of the Tentacle, one of my absolute favourite point-and-click adventures, that I also immediately thought of when I saw the challenge ingredient. It has plenty of creative time-travel puzzles, and the verb interface makes it pretty close to a parser game for me in terms of how I think about puzzle solutions (speaking as a person who’s only started playing parser games a few years ago, mostly new ones, and knows very little about the classics!).

The more I think about the challenge ingredient, and the dishes being prepared in ZIL (the syntax shown in our Technical Advisor’s excellent overview filled me with dread), the more I respect I have for our chefs. This isn’t some easy Sunday cookout menu!

Joey · May 24, 2026, 4:55pm

Very chewy ingredient! Lots of possibilities here. My first thought goes to something like the books in Myst, but if course there are many ways this could be applied.

J_J_Guest · May 24, 2026, 6:37pm

My immediate thought was of the TARDIS. It’s old and unreliable, works using a technology that is strange and barely understood (even by its owner), and definitely connects places across time and space!

Lancelot · May 24, 2026, 9:08pm

an artifact that connects locations throughout time and space

The first thing that came to mind was the TARDIS from Doctor Who. But there are other devices that might fit the bill.

In the movie Time Cop, people were literally launched into the past using a huge tunnel-like setup (they could only travel to the past, not to the future).

In the latest Indiana Jones movie, the Dial of Destiny (Antikythera) was not a time travel device, but rather predicted where fissures in time would appear (and, if I recall correctly, it only led back to Archimedes in his own time frame).

I remembered reading the Time Patrol books by Poul Anderson, which originally used the time-policing premise that Time Cop is based on.

So… time to get some ideas written down and try my hand at some coding. In preparation for this endeavor, I went through the manuals written by Marc Blank and Steve Meretzky. I also read the articles published by my esteemed opponent on The Rosebush. Now it should be smooth sailing, right?

One small side note: It looks like people were relying on a copy-paste culture to start creating new games. Nowhere in the docs I went through was there any hint about what an empty game would look like (i.e. what is the bare minimum of code I need to write?). Fortunately, ZILF comes with a template for this.

With full confidence, I created my first room. It compiled without errors! Success! I downloaded the compiled file and uploaded it into iPlayIF:

Parliament Square
 
> look
It is pitch black. You can't see a thing.
 
>

Erm… hey, what? It turns out the docs I relied on advised using (FLAGS ONBIT) to ensure rooms are lit, but apparently ZILF expects (FLAGS LIGHTBIT) instead.

to be continued

Joey · May 24, 2026, 9:58pm

Up to a point, I’m in favour of brackets, though I suppose there are limits to what is reasonable. What’s the significance of the angle bracket versus the round bracket?

Almost every time! In Sub Rosa, many of the puzzles flowed out of the logical outcomes of the different magical items; there is a last lousy point in Mammal that adds a nice twist to the game that was entirely a natural implication of the premise. I find puzzle and narrative design is as much a fun exercise for the writer as it is the player.

OverThinking · May 24, 2026, 11:01pm

100%. It’s always “I’ve had an idea for a game about…” and I talk it through with my writer friends who invariably bring up some twist or implication I had never considered. Other things, like mechanics, puzzles, etc., only come into the picture for me in service of the story. The one exception I can think of is You May Not Escape!, where there is almost no story because the omnipresent “you are in a maze”-ness is the point of it all.

I was explaining to a friend why I would be so busy this week and when I mentioned what the ingredient was, they said almost this exact thing.

SomeOne2 · May 25, 2026, 1:44am

Ah, what a curious challenge, not because it’s a bad ingredient but because this is the kind of game that I know if I was let free scope creep would take the better of me and I’d be left writing code to an enormous game that doesn’t get finished for another three years. It’s just how I roll, guys…

I struggled at first to develop anything of any use whatsoever, but then my brain went, “ah, but would it be funny if by ‘space’ you meant ‘OUTER SPACE’?” Which, let’s just say, was a better idea than I had already had so far. Even so, I discarded it immedaitely as a bad idea, but I have kept the idea of perhaps being located in a spaceship, because while it would be cool to have something on Earth or something, if I did that there’d be an unfinished game and hundreds of rooms. At least a spaceship can be contained.

My next thought was, “okay, there’s gotta be mechanics”. By introducing the right complexity of mechanics to the artifact, you can just inflate the game experience enough so that it 1. it doesn’t feel like I’m trying to drag out gameplay using repetitive or tedious sets of moves such as solving a towers of hanoi puzzle to get it to a different pole; and 2. you don’t feel like the game is over immediately.

So, it’s now 9:45am. I’m going to just flesh out this idea a little more. I have something in mind, but I won’t tell!

lpsmith · May 25, 2026, 2:59am

The hoops described here ‘compiled → download → upload’ remind me that our chefs are not playing on a level field: they had to bring their own kitchens, and our challenger’s kitchen is the sort of thing I would burden an IF superstar with, should I want to give them a handicap.

Onno’s own computer is neither able to compile nor interpret their game! They start with borogrove:

create and edit the file online, click ‘compile’, then download the compiled file, then upload it to a different web site (iplayif.com) to see it in playable form.

It’s the sort of thing that would drive me bonkers. I’ve described my kitchen before (a combination of Visual Studio Code and the Inform 7 native IDE), and while it wasn’t quite as smooth as I would like, it was certainly a lot smoother than this! IIRC, one of the advantages of the ‘ink’ development system is that your edits are live: you type something in to your left window, and the right window (already running the game) updates in real time. This is, frankly, kind of magical. (Someone tell me if I’m off my rocker here–this is half-remembered lore from two years ago.)

This made me wonder if there might be a way to combine these two online pieces: an edit window, but also another ‘play the game’ window.

Then I mucked about with borogrove.app. And… it’s already there! You click ‘go’, and the right half of your screen becomes your compiled game. You can even click ‘go’ on the default ZIL game and it’ll compile and play it, (>X ME “You look like you’re up for an adventure.”)

So, Onno! Click the ‘Go’ button! Save yourself the time! You’ll need all of it!

(Also, the default game already had ‘LIGHTBIT’ in it, too.)

vaporware · May 25, 2026, 4:07am

The why of brackets

Generally, the difference is that angle brackets are for calling functions, and round brackets/parentheses are for grouping things together. In other words, <+ 11 22> is a function call that means “add 11 to 22”, and (+ 11 22) is just a list containing a plus sign and two numbers.

That’s the high level difference, the “why”. And that may be a satisfying answer on its own.

But there are exceptions, rare times when angle brackets mean something else. They’re hard to explain without the “how”, though, so let’s dig in.

Caution: this is about to get technical.

The how of brackets

If you go to the ZILF REPL and type <+ 11 22>, you’ll see the result 33. But if you type (+ 11 22), you’ll get the same thing back as a result: (+ 11 22).

Because of the whole “code as data” thing, every part of a ZIL program is actually a MDL object^[1]. Specifically, (+ 11 22) is an object of type LIST, and it contains three other objects of type ATOM, FIX, and FIX. <+ 11 22>, likewise, is an object containing those same three objects, but its type is FORM.

When they’re being used as data, that type tag is the only difference between them: angle brackets tell MDL’s reader to slap the label FORM on the object it’s making instead of LIST. But when they’re being evaluated as code, that’s when they diverge.

A FORM is evaluated by taking its first object as a function name, then calling that function with the rest of the objects as arguments; that’s why you see 33, which is the return value of +. A LIST, on the other hand, is evaluated by ~~creating another list with the same contents~~ evaluating all of its contents and putting them in a new list; that’s why you see (+ 11 22)^[2].

Usually, when the MDL interpreter is reading an object, either from the REPL or from your game’s source code, it’s because the object is going to be evaluated as code—but that depends on the context. In some contexts, the object is never evaluated as code, only used as data.

Let’s look at an example. When defining a Z-machine OBJECT, there are two special properties you use to add its names as vocabulary words: SYNONYM and ADJECTIVE. But what if you want to make more properties like that? (Maybe the object can change somehow, and you want to be able to copy over a new set of names for it.)

Well, you can use PROPDEF like so:

;; Define the properties...

<PROPDEF ALT-SYNONYM <> "MANY" A:ATOM = "MANY" <VOC .A OBJECT>>
<PROPDEF ALT-ADJECTIVE <> "MANY" A:ATOM = "MANY" <VOC .A ADJ>

;; ...and use them

<OBJECT PRINCE-ADAM
    (SYNONYM PRINCE)
    (ADJECTIVE HANDSOME)
    (ALT-SYNONYM BEAST)
    (ALT-ADJECTIVE HORRIBLE)>

Here we see two uses of angle brackets that aren’t function calls.

First, there’s <>. An empty FORM means “false”, and in this case it means we want the default value of our new properties to be zero.

Then there’s <VOC .A OBJECT>, which is part of PROPDEF’s mini-language for special properties. The "MANY" A:ATOM part before the = means you can give the property multiple values, and you’ll type them as atoms (bare words); and the "MANY" <VOC .A OBJECT> part afterward means they’ll be written to the story file as the addresses of vocab words that are marked as nouns. In this case, we aren’t making a function call to VOC, it’s just data for PROPDEF to interpret in its own way. Why is it written with angle brackets instead of round or square brackets? Because whoever designed PROPDEF at Infocom decided to use angle brackets in its syntax; they could just as easily have used something else.

I don’t bring this up only to say that fancy property definitions use angle brackets, but also to make a bigger point: ZIL macros, just like built-in functions, can elect to use code as data to define their own mini-languages like this. And within those mini-languages, all the various brackets and dots and whatnot are simply more data to be consumed and reinterpreted.

which is different from a Z-machine object! ↩︎
which technically is a different list from the one you typed in, although it prints identically ↩︎

SomeOne2 · May 25, 2026, 6:16am

I’m genuinely learning loads from Tara’s explanations of ZIL macros. I’m unlikely to use them in my game even if it would probably work a lot more efficiently if I had used them.

As for my game, it’s been quite a start. I think I’ve managed to cut down my project to something workable, even if it meant getting rid of some puzzles and plot points that would have been really cool to have in. I just can’t afford it.

By the end of the day today, I plan to have finished the main game mechanic, which, being the artifact, has now been oversimplified to the point of no return. I’m nearly done with it already, at 2pm, however, I am gonna now revise for an hour or two because next week from Monday to Friday I have seven exams, two of which end at 10pm. So I do need some time to focus on that, although I’m more worried about Iron ChIF than my GCSEs right now, lol. Other than the main mechanic, my idea has developed little from the morning. All I can say so far is that I have limited my map to exactly 9 locations and 3 days, one of which can’t be interacted with by the player (yet is still an essential room for the player). Oh, and the artifact itself? Its name is Arkanen. Don’t offend it. We all love it. It’s very, very useful.

agat · May 25, 2026, 6:33am

(Watches with fascination as the Challenger constructs a kitchen in the stadium. Is that a wood-burning stove the like of which she’s never seen before, or a pizza oven, or a blacksmith’s forge for making knives? Or something else entirely?)

(Nods along as her fellow judge speaks, pretending she knew at least some of that.)

I see our Iron Chef, after some deliberation, decided to portion the ingredient and only use the best parts for the dish, which is already beginning to take shape. A good call – we’re all hungry here, and waiting a year or two for the Scope Creep Banquet is not an option!

lpsmith · May 25, 2026, 6:38am

I love this description of the brainstorming process. Humor is an absolute game-changer here; there’s really nothing at all like it for getting your brain out of a rut and on to something better. Even if that ‘something better’ itself still needs iteration.

What I see Max grappling with here is a combination of inspiration and scope management. I went through this exact same phase on Day 1 of my own game, trying to decide how wide my scroll’s effects would be–basically per-object, per-room, per-region, or ‘entire map’. Strictly based on intuition, I went with ‘entire map’, and am glad I did, because the effects never hit an undue level of complexity while I was writing the game.

It’s difficult, though, because inspiration keeps telling you to make something AWESOME, and every limitation is one less cool thing for a player to discover. A truly awesome puzzle (at least in the parser milieu) often has a bunch of moving parts, but critically a unique response for every reasonable combination of those parts. I like to call this ‘limited, complete scope’: limited, so the full range of possibilities isn’t impossible to fill out, but complete in that every single combination within that range is accounted for.

Let’s imagine that Max decides on a space ship with five rooms and three time periods. That’s 15 unique room descriptions, if you’re going for ‘complete’ mode. Then you let the player transition, within any of the rooms, to either of the the other two time periods. That’s 30 possible unique transitions, which… seems like a lot? Maybe you decide that’s too many, and cut that back and say ‘going from the past to the future gets the same message regardless of what room you’re in’. Or maybe you say ‘you can only transition from the past to the present in the galley’, etc. Or maybe you just buckle down and write 30 unique transitions! Because honestly, 30 unique transitions would be amazing. But there’s only so much time. And there’s always only so much time.

(And then you realize you need a sixth room, which means 3 more room descriptions, and 6 more unique transitions. And a secret fourth time period! Oh, that’s another 6 room descriptions, and 12 more transitions. Only allowing transitioning in the galley is starting to look more enticing…)

But if you’re up for it, players love a wide-open system that’s thoroughly implemented. That’s the secret sauce of the language puzzle in The Edifice: there’s so many unique responses to unique combinations of words, and people just ate that up. Writing them was an absolute slog, but the payoff was huge.

(And now Max posted another update saying he has 9 locations and 3 days! My speculation wasn’t too far off!)

lpsmith · May 25, 2026, 7:04am

This is actually entirely runnable from your browser! Go to https://borogove.app/, and look in the lower right of the 3x3 matrix, where ZIL is. Click the green arrow there next to ‘Empty project’, or, if you want to be fancy, select ‘Small example project’ first. You get a window with ZIL code in the left half! Then click on the upper right ‘Go’ button, and the right half becomes that game.

It’s actually kind of slick. I’m sure trying to develop anything large in it would start to get unwieldy, but it’s pretty impressive. That’s our challenger’s kitchen!