Once more to the LAKE

I thought I’d talk a bit about some of the craft choices I made in writing LAKE Adventure. It’ll probably sound a bit academic (hi, I’m a college professor), but I’m very interested in the forms of IF, in particular parser IF, in particular how parser IF can tell stories, and particularly in particular how we can continue to make parser IF stories memorable and meaningful in the future. And I think those are more questions of form than subject. That’s not to say all these choices were successful, of course, but I wanted to enumerate them to lay them bare.

Platform and presentation. I wrote a separate post about AGT. In the end, I think the online DOSBox presentation added to rather than detracted from the game. Perhaps in an ideal world, the graphical presentation of a text game shouldn’t matter. But we live our lives on the Web now, and we expect any page we visit to be uniquely well-designed. Quixe and Parchment certainly produce attractive results, but those pages can wind up feeling same-y as one plays through multiple games. Contrast games with the default layout to Assembly from this Comp. The changes are small, but the small splash of Ikea colors in the status line and the Ikea-appropriate font make the game seem more lively and thoughtfully constructed. I think my central thesis is this: it’s time for parser authors to put the same basic CSS care into their web releases that we might expect from successful Twine authors. (Of course, at the same time, we should release downloadable files for players’ use in interpreters, thus abandoning our stylings.) Vorple offers even greater possibilities, and it surprises me (according to IFDB) that very few Vorple games have ever been released.

Again, fundamentally these are text games and that formatting and presentation arguably shouldn’t matter. But I’m convinced it does. We judge books by covers—and often have conversations about games’ cover images here. For books, consider the “A Note about the Type” paragraph one sometimes finds at the end, or simply how paper choice can impact our view—I can see and feel a self-published Amazon book, for better or worse.

POV. The fundamental premise of LAKE Adventure is rather plain: two people are playing a game via Zoom. The question was how to make that interesting. My answer was to give both characters multiple points of reference. In the game, we are at the same time learning about Eddie, age 13; Ed(die), age 18; and Ed, age 40. Perhaps more importantly, you (the person in 2023 playing the game) are actually playing as You (in 2020). And who are You? Why, You’re a person sitting at a computer playing interactive fiction. That isn’t exactly you (in 2023), but it’s awfully close. Games choose on a continuum about how much detail to give to their PCs, ranging from rather generic (you’re a spelunker, and that’s it) to very specific (you are Bonnie Noodleman in Brain Guzzlers from Beyond!). I wanted this game to make the actual player playing the game and the fictional player to be as similar as possible.

Time. As a result of playing as a person playing interactive fiction, the actual time elapsed in the game is almost a perfect correspondence to the actual time elapsed in real life. In most parser games, we assume it takes a little time to perform even simple tasks (at least longer than it took to type the command): a few seconds go by when we walk west from the kitchen to the dining room; a few more go pass when we open a toolbox, revealing a wrench. Here, the gameplay is playing the fictional game, typing commands, reading responses, and listening to Ed’s comments, and it all happens in near real time. Perhaps it reinforces the reality of the otherwise metafictional premise.

Punctuation. Inventing punctuation is weird, way weirder than figuring out a character’s verbal fillers (Ed’s are “heh” and “I guess”). I had to find a way to convey the close-but-not-quite, high-pass-filter effect of a person talking through a laptop’s speakers. I didn’t want quotation marks, since those are occasionally used in the game. Eventually I settled on ### because I thought that stood out sufficiently in DOS. No beta tester or reviewer remarked upon it. So I guess that’s now the official punctuation for such speech? I’ll write the Chicago Manual of Style people and let them know.

Title. I worried that the all-caps title of LAKE would annoy people. It’s intended to be mimetic of the all-caps file listing in DOS, and I think people either got it and approved or otherwise just ignored it. Again I got no negative comments. A net win overall, I think.

Feelies. People mentioned and liked the hand-drawn maps which also had some other clues about Eddie’s life. Another thesis (though one I feel less strongly about than styling Web versions of games): parser games should have a virtual feelie if possible, something beyond a basic walkthrough. They’re compelling and add enjoyment to the game, even if it’s extratextual.

Description. As a result of the story’s frame—Ed is narrating his memories of the game—there’s very little physical description of the contemporary world. All we know of You is that you’re playing interactive fiction on a computer. We don’t know much about Ed beyond that he’s forty, he’s got a Mac, he’s got a daughter, and he needs reader glasses. It’s March 2020 at the dawn of COVID. The two of you are on Zoom. And that’s pretty much it. Ideally, as you play the game, you begin to imagine a little bit more about what Ed might look like or what kind of room he’s in and the other things within it.

Monologue. Instead, most of what we learn that matters in the story are Ed’s recollections and realizations. This is yielded entirely in a monologue. There are often implications that You have said something to which Ed responds, but Your dialogue is never revealed, and the game never offers you (the 2023 player) the option to TALK TO ED. Instead, that command gives you a cheeky in-game response about how You (playing as Eddie) shouldn’t talk to yourself. These two choices eliminate a lot of traditional narrative tools, for better or worse—there are no physical gestures or reactions, no brief mentions of the rooms in which You and Ed play. Even the Zoom conceit is dropped until the end. The real story is just Ed talking. A lot. But a good monologue should reveal a lot about the character’s personality, and I think who Ed is as a person comes through reasonably clearly.

The ending. It certainly seems bleak. And going in, I knew it ran contrary to the conventional wisdom that light-hearted / witty / comedic parser games do well in the Comp. But in my read of the ending, Ed is stunned, which is different than being broken. (The two, of course, are not mutually exclusive.) Ed knows he’s just experienced something important, but he’s unable to articulate what that is. It’s the same way we immediately know something we’ve gone through is cataclysmic—say the day we learn a friend has died in a car crash. But we won’t truly know for months or years how that event has impacted our life and the lives of everyone else who had to go on living. Ed tries to have an exploratory conversation with his daughter at the very end of the story, but he doesn’t do a great job with it, and she doesn’t know why he’s acting oddly. The story can’t reveal more, because of the choices it’s made with time, as noted up above.

Being stunned is the strongest feeling I associate with those initial COVID days. Before things became too politicized, it was simply … uncanny for me to go to the grocery store wearing a mask, for example, and only find one loaf of bread on the shelf (which I promptly bought). And I remember a general esprit de corps in those early days, because my family, friends, and coworkers were all trying to figure out what on earth the world looked like in quarantine and how it was supposed to operate. (Your own COVID experiences might differ wildly, of course.)

I do think it’s possible in some cases that the initial inability to apprehend what we’ve gone through can resolve itself into a positive outcome, even if the triggering event was traumatic. But I leave it to readers to imagine Ed’s fate the next day, month, year. I’ve got my own imagined outcomes, of course, but I didn’t want to force them into the story.

Thanks. I was very grateful for the reviews and reviewers of the game. In particular, I really like and appreciate Drew Cook’s exploration of the game and its form. In terms of approach, I also really like Mike Russo’s coining of the term New Sincerity—it’s something that’s given me clarity about my own games and also why I’m drawn to some recent games more strongly than others. And thanks, of course, to my wonderful beta testers and everyone who played the game. You look like Eddie Hughes looks, which is very handsome.


Thanks for this interesting write-up. It seems I’ve missed a lot by playing all parser games locally in gargoyle!

I’m actually a bit surprised that you intended the player to identify with the unnamed ‘player’. I identified much more with Ed or Eddie. I don’t think there’s anything automatic or obvious about the player being fictionally(?) the same person as the ‘player’. I wonder how other people experienced this.


I’ll be honest, I thought the narration was Ed talking to himself (and/or his imagined audience). I didn’t think the “player character” actually existed (maybe because of the daughter’s comments at the end), so I thought we were just playing as Ed.


I’m not sure how much is genuinely, substantially different. It’s probably not much; the text, after all, still drives the experience. But seeing as most parser games are released online in some form in addition to being downloadable, I feel it’s incumbent upon us to give a modicum of thought to the graphic design of the online component. (This is a developing belief for me; I’ve certainly released games that don’t account for this at all.) I think this is especially important for welcoming new potential players of parser IF. They likely aren’t going to download an interpreter. And if they view the visual design of an online game as boring, they might be predisposed to think the game itself–or perhaps the entire genre–is likewise boring. Maybe that’s speculation. But I think engaging websites, with their attendant cadres of graphic and UI designers, are a reality of the current age with which we have to reckon.

Part of the trouble with dabbling in the online design of an Inform game (at least for me) is that editing the default Quixe stylesheet isn’t as easy or as intuitive as styling things in Twine, for example.

The POV issue is probably the one I struggled with most in terms of clarity, and I think the ###s can also be read as demarking interior monologue vs. what occurs in the game as it’s played. Another interpretation a few people have had is that You are the IT worker who helped get the game off of Ed’s found disks. Either of these interpretations make sense to me. I don’t know how much they change the narrative experience / meaning, but oddly the changes might not be significant? I do think the story would benefit from being clearer about its intended POV, but I never found a good solution.


I agree. I loved the retro aesthetic you chose for presenting the game in; without it, this game wouldn’t have felt as believable as it did. For ex: I don’t think this game’s story would have worked as well if it was implemented in Inform 7.

Hell, I just switched up the colors and changed the font for the last Inform game I made and it already felt different to play than when I used the default template. This is before I included a graphic logo I threw together on the fly.

I’d go one step further and say that parser tools should make it easier to customize basic elements of the presentation layer for the games made in them, ideally without having to learn CSS in the first place (but still having the option). The effort will still have to be invested to make a nice looking game but it could at least be less of a chore.

(Also thanks for making LAKE Adventure! I liked it so much that I played And then you come to a house not unlike the previous one right after)


Funny, I’ve been thinking a lot about this recently, and you’re totally right.

I used to be a fan of the idea of the pureness and agnosticism of classic parser games – that it’s really just text, dude! – but after actually releasing one, I feel differently. Maybe “pureness and agnosticism” just translates to “Boy, I’m sure glad all that finicky, art-in-itself ‘presentation’ stuff is the user’s problem!”. Fact is, no matter who’s your game’s target audience, if you have a “Play Online” button, most people playing your game are going to use it. Even if it’s just to get a first impression.

Using Parchment to make my game even halfway presentable and give it at least some kind of “look” was a pain in the butt, and I wasn’t exactly over the moon with the result. (Personally, I play the game in Glulxe and make it look like it’s from the 80s.) For my next project, I’m making heavy eye-contact with Vorple. Like you, I’m surprised that it isn’t used more widely, and I’m curious as to what the catch is. I suspect it’s the fact that – as far as I understand – making heavy use of its features basically turns it into a browser-only game (that may cease to exist if Vorple ever shuts down its servers).


Always here for academic craft discussion. Some scattered thoughts in response:

  • Changing the presentation can help make the game more attractive or distinctive, but typography can also be really helpful as a way to clarify or communicate things to the reader. (I suspect everyone knows this, but I think it’s a helpful antidote to the “aesthetics shouldn’t matter” idea that floats around.)
    • To take LAKE Adventure as an example, you could imagine experimenting with more standard typographic tools to mark dialogue instead of the ###, or using font or positioning to distinguish modern-Ed’s text from the retro bits.
  • The stock Z-machine/GLULX paradigm doesn’t make this stuff easy. One horrifying example: to get an appropriately-themed status bar, Assembly used a non-monospace font for the status line. (Don’t tell anyone!) And I had a lot more I would have liked to do with the styling if the platform had made it more accessible or I had more time.
    • Here we are writing text games and putting them on a medium specifically designed for presenting text, and we only use a tiny fraction of what web typography supports, and it doesn’t even look great half the time. Opportunity for improvement!
  • That said: I thought Parchment’s support for customization was Pretty Good, given the restrictions it has to work with. I’d be curious to hear where folks on this thread had a hard time with it. Maybe there’s room for better templates or something…
  • Loved the feelie. Are you familiar with / were you inspired by the game Tunic? It has an in-game manual with hand-drawn annotations, and I was reminded of it very strongly.

For players wishing to learn some CSS styling, w3schools is terrific. CSS is much easier to learn than, say, JavaScript. That said, if someone wants to develop a GUI WYSIWYG interface for styling text in interactive fiction, I’m sure a lot of people would welcome it.


I’ll be using Vorple for my next project. But you’re exactly right–if you’re using Vorple for any of its interesting capabilities, you’re essentially eliminating the possibility of a downloadable file. (Vorple does allow you to play its story files offline, and you can render different text if Vorple is / isn’t available, but noncompatible features like hyperlinks simply won’t work in a non-Vorple terp.) Vorple is also kind of a pain because you can’t run the webpages locally for testing without installing a local server. Otherwise you can put the whole thing up on an external website. Neither is insurmountable, but it’s an extra step. (I don’t think there are Vorple servers, though; the website it generates through Inform is self-contained.)

And if I’m remembering correctly, the stylesheets get overwritten every time you Release the game. So, to update the game and play a new version, you can Go! but not Release. It’s not a big deal if you’ve got a backup of your stylesheets somewhere, but I’m pretty sure I’ve destroyed mine more than once.

I definitely agree, and I’m going to be experimenting with this more in the future. But the problem–and here I’m basically arguing against myself–is that for accessibility, I’d prefer for there to also be a plain-text version of the game for those who use screen readers or would prefer to play offline, and typography and other UI elements wouldn’t come through. (I ran LAKE through the default screen reader on a Mac in Spatterlight, and while the ### was read as “numbernumbernumber”, I decided the irritation was minor enough that it wouldn’t ruin the game.) I don’t know if there’s a way to get both a very well-designed game, graphically speaking, and have it give the same experience as a downloadable version. It’s interesting to think about, and maybe ultimately an author just needs to make a choice about how much value a downloadable version may have. (I’m thinking about this a lot for my next project, which might have to live entirely online due to its Vorpleness.)

I think the issue is that the CSS just isn’t as easily accessible as it is in Twine. When releasing a Glulx / Quixe game, there are three different stylesheets that are generated. It takes a while (for me, at least) to wade through them and figure out the correspondences between the stylesheets and the generated web pages. It’s all certainly possible, but I think it’s opaque at times (again, at least for me, with limited CSS skills). And maybe the reason more people don’t spend time on this aspect is partially that writing a good Inform game is already hard enough, and partially that the parser community doesn’t expect anything (yet) beyond the default template–which, of course, is functional and pleasant.

I wonder if just a clearer guide to Quixe for folks like me who are CSS-curious but not necessarily proficient would be a start. “Change this item to change the main font”; “change this item to change the background color”; etc. It’s not hard to change a hex code when you clearly know what element(s) it will change. Perhaps such a guide exists, but I can’t immediately find one. And I know there are already a lot of comments in the Quixe stylesheets, but sometimes some of the names and descriptions are cryptic to me.

Maybe it’d be as simple as creating updated stylesheets with clearer descriptions in the comments of the main values to tweak, then uploading them here.


I recently learned how to make my own Quixe-based interpreter that acts like an extension you can download when making games, and can do whatever Javascript etc. you like without setting up a local server. So people could download a zipped folder and play just fine.

However, if I make it a ‘thing’, it would be much more basic than Vorple, which had to move to the ‘web files’ method because it does so many complex things. I’d basically request 10 opcodes from Zarf et. al that would each do a different thing in the web interpreter (and nothing at all in other interpreters).

So, I could make a bare-bones web friendly interpreter that can do exactly 10 things (each with string inputs). Maybe ‘change background color’, ‘change font’, ‘play track A’, ‘stop track A’, etc.

Does this sound useful, and if so, what 10 things would be good? It would always be much more limited than Vorple, but could be good for basic CSS styling and such. If it becomes a ‘thing’, I could work out a guide for the Quixe css stuff.


I think this could be super cool. I do think the “install and run nginx” part of Vorple is a significant barrier to anyone who just wants to download and run a Vorple game on their own machine. Maybe this should be split into its own topic?

I’m not 100% sure what would be controlled by the terp and what would be CSS. And I’m thinking a bit about how this might be different than trying to get Adventuron do the same thing. (And while I love Adventuron, obviously Inform’s maturity / power / widespread adoption is a huge plus. Adventuron does do some of the below pretty easily, though.)

Some things I think it would be cool to easily do, on par with the Twine level of “easily do”:

  • Hyperlinks–at a minimum, hyperlinks to other local or WWW HTML files. But perhaps hyperlinks to travel between rooms, or links that execute commands, too?

  • The ability to change colors of the page background, page text, prompt text, and status bar text and background.

  • The ability to change the fonts for the status bar, game text, and prompt, using Google fonts.

  • Probably a simple way to display images? I’ve never done this, so I don’t know how easy it is in Inform or if Vorple changes it appreciably.

  • An easy way to inject custom HTML or JS into the game? For example, in the project I’m working on, I’m creating and placing an HTML table via Vorple. (It sounds like JS might already be covered elsewhere, but there may also be a use for script tags within the page?)

  • Other CSS stuff: text decoration, transitions, borders, etc.

The first three would be my absolute top requests. I think they could be relatively simple and that authors could do a lot with those options to make games more styled without doing a lot of heavy lifting.

The final two could be fun but seem a little more niche. I’m realizing that ultimately what I think I’m asking is for an Inform game to be possibly a little more Twine-y in feel. I have no idea how easy any of it would be to accomplish, of course, so take the suggestions for whatever they’re worth. Very curious what others think!


I’d love to make my games prettier, but I am extremely intimidated by Vorple. I think anyone who has ever cringed while reading through one of my tech meltdowns here might agree that this would be challenging for me. I’ve looked at some of the basic tutorial stuff, but, er, there needs to be one for dummies.