 Okay, hi, I'm Andrew Plotkin. I've been messing around with interactive fiction since about 1978, first playing it, then writing it, and then working on the tools that are involved in having it happen. This talk is about the tech. Now, when I'm talking about interactive fiction, at this time in this talk, I'm talking about the old-fashioned, parser-based interactive fiction where you type commands, and then the game spits text back onto the screen. The term interactive fiction has gotten very broad over the past few years. There's twine, there's choice-based games, there's narrative indie games. Those are all awesome. This talk is about the Zork format. So the Zork format, the Zork format. So in 1979, a bunch of geeks sat down in Cambridge to invent a virtual machine. They wanted to port their game Zork to home computers, but there were a lot of home computers, and because it was 1979, there was the Apple II, the TRS-80, there was gonna be a whole bunch more in the next couple of years, and they wanted to be able to write a game once and run it anywhere. So they invented this virtual machine. They set up a company called Infocom. They shipped 35 games using the Z machine, and then VGA graphics were invented, and that was the end of Infocom. But there were a lot of Infocom fans on the net. The internet was a thing by then. So a group called the Infotask Force sat down and reverse-engineered Infocom's format and created a open-source interpreter so that people could still keep writing the same game files. This is where I showed up. In about 1993, I decided to write a nice-looking Z machine interpreter. I wanted scroll bars, copy and paste, proportional fonts, all the things that you get in a GUI system. At the time, I was most familiar with X Windows and UNIX, so I took a terminal window Z machine interpreter called ZIP, and I turned it into an X Windows interpreter called XZIP. A couple of years later, I learned Mac OS programming, System 7, as you see, and I decided to port XZIP over to the Mac, so I took the same underlying engine, ZIP, and I wrote Mac display code for it, and I called that Mac ZIP, which was short for Mac XZIP, which is a terrible name idea, but not my last. I also started writing IAF games at that point using a open-source tool called Inform, which targeted the Z machine. That's a different talk. Next port was a Mac port of TADS. TADS is a different open-source IAF development system. It had its own interpreter and engine for playing the games, so I took the Mac display code and stuck it on top of TADS interpreter, and I got a new engine, which I called Mac ZIP. So at this point, we've got these things, and clearly, there's an opportunity to modularize. Modularize is the hardest to pronounce word in this entire talk. If you take the display library over the top, and you plug it into one of those interpreter engines, then you have a new interpreter, and then it's much easier to port things to new platforms, and also I could fill in that fourth square on the grid, which I never got around to doing before. Plus, there were all these other IAF engines coming out because it was a popular thing. AGT, Hugo, Alvin, Adryft. So I figured if all of these used the same display library as a base, then porting each of them to Mac Windows, et cetera, becomes very easy. We also needed a new virtual machine because Infocon Z machine was aging out. This was like 1997. It was a 16-bit design. There were a bunch of other limitations. It was starting to cramp ambitious informed games, so we needed a new setup for that. So here is the grand plan. First, I designed the API. Then I write a display library implementation for X Windows, for Mac, one for terminal windows. Somebody else can do Win95. Then I designed a new 32-bit virtual machine for interactive fiction. At the same time, everyone else is porting their IAF virtual machines over to use my display library. And after that, all IAF technology works uniformly. It's portable. It's awesome. So I got started on that. I named the display library Gluck and the virtual machine Gluck because I figured the entire IAF community was on the internet, and so no one would ever have to say any of these names out loud. It didn't matter if they were hard to pronounce. Sort of. So going down to the UI design, there's a reason that informant heads and all of these other IAF systems use the same basic UI interface, which is that they were all trying to replicate Infocom. And Infocom's first game, Zork, was basically Colossal Cave fanfic. So all of these games go back to mainframe terminals and teletype machines. The game is gonna output a stream of text. It's very abstract. You can do anything with the text. You can render it in proportional font. You can run it through voice to text, text to speech, if you want. Infocom virtual machine added simple styles just like boldface and italics. They also added an optional status window, which was basically a terminal window, a grid of characters. But that's still pretty abstract and it's easy to port over to new systems. So when I designed my system, my display library, I took that model and I generalized it just a little bit. I said, okay, you have one or more windows, but every window is either a text grid or a text stream. And the windows can't overlap. We're not getting into that. The interpreter's gonna handle all the text rendering, all the decisions about fonts and so forth. So you wind up with a model which is more flexible than the Z machine, but it will still run on anything from a GUI system all the way down to raw telmet. Obviously if you're playing over telnet or a raw text stream, then you only have one window and it's a stream, but the game can cope with that as graceful degradation. So now we have a text model which will cover the least common capability set of the Z machine, TADS, Hugo, and all these other systems. Problem was everyone is ambitious. Everyone's trying to expand their common IF model to include graphics, sounds, smell division, et cetera. Infocom did this with their Z machine version six, which is a mess, but we'll get into that later. Multimedia TADS is HTML style. So I didn't try to handle the universality of all those capabilities. I came up with a simple modest display model for my virtual machine. And I said, okay, my system's gonna use that. Everyone else can use the basic text window capabilities. You'll have a look port that's great. It'll be portable. It won't have all your fancy multimedia. So here's the result of my grand plan. My virtual machine has decent multimedia support. All these other engines, you can either use the native port, which has multimedia or the gold port, which has less capable. But that turns out to be kind of interesting. Even though these interpreters are limited, there's stuff you can do with them. Why? Because we, at this point, have the idea of playing IF games in a web browser instead of having to download an interpreter. Well, what does that mean for my display library? My display library was a C API. It was literally defined by a C header file. So how do you run that in JavaScript? Well, you can port the C API over to a JavaScript API. That's easy. You could abstract it and say, describe each call as a data object, render the data object, and then you can pump out, auto-generate a JavaScript API or the C API or whatever you want. That's better. Let's take a step farther back. The C API is a bunch of function calls, but it's actually an event loop. The idea is that you make a bunch of output calls, then you call the magic select function to the interpreter blocks and waits for input. So if you're gonna do that on the web, well, a web application already has an event loop. You don't need to write one. So take another approach. Say all of the game output for the turn is going to be represented as a single JSON object. The gamers can generate that, shoot it out, and then wait for input, which in the form of a JSON object describing the next player command. We don't have to change the game structure to do that because we can put the JSON layer on top of the JavaScript API I mentioned before. The game is still as the same. The game is calling the same gulk functions, but now those are JavaScript functions already generated from the XML, and all those do is generate a JSON output, shoot it out, and then set up the appropriate callbacks. So that's pretty cool. The reason it's cool is that, as we heard in the previous, one of the earlier talks, JSON is a really nice format. You can do a bunch of stuff with it. We could take the JSON data stream and log it, and now you have a transcript of the game which can be replayed later. You could shoot those JSON data objects over to another machine, and now other people are watching you play. You can have the, well, let's play version of interactive fiction. You can do regression testing on the JSON, to save my ass in Hadean lands. It's really easy to do regression testing on the content of a JSON stream. So you can do all these other things with it. I had so much fun playing with the JSON layer that I rewrote the JSON layer on top of the C API. So you could take one of the old C interpreter engines, slap on the C JSON display library, and now you have a process which does JSON standard and standard out, which is a great component. There's somebody who's doing that, using that as the basis for an Android interpreter. So obviously there's plenty of holes in the system. I've been, like, planning to integrate CSS for about 10 years now, and I keep not having enough time, but other people are working with it. There are other things in progress. And on the upside, Sky once used a look library to hack the internet on agents of shield season one. That's pretty cool. Thank you for listening.