Sunday, May 24, 2020

Subcutanean and variations thereof

I have now finished reading two of Aaron Reed's Subcutanean. This is not a game; it is a novel generated from an algorithmic framework that allows every printed copy to be a different text. Thus it partakes of some aspects of game design (procedural generation, unique reader experience) but not others (no interactivity or player agency). This is interesting!
(I've read recensions 10881 and 10966, in case you're keeping track.)
Before I go winding off down corridors of theory, I should say that Subcutanean is an excellent short horror novel. Orion (or Ryan, or Ry) lives in an amorphous post-college group house, trying to figure out his crush-or-friendship with-or-on his housemate Niko. Then the two of them discover a hidden stairway leading down into the house's basement. The house shouldn't have a basement and "amorphous" shouldn't be this literal. Doors lead out into corridors, corridors lead to more doors, a sense of unreality begins to grow. And then the two start to catch glimpses of other explorers -- people who look like alternate versions of themselves.
The world of Downstairs starts creepy and gets creepier, and it reflects the uncertainty of Orion's headspace. The social world of queer-and-out is as hard to navigate as any psychogeographic underworld; Niko is the partner Orion doesn't know how to explore with. Then it all goes wrong -- wronger -- and I'll let you find out how it wraps up. Which may not, of course, be exactly how it wrapped up for me.
When I (or Aaron) says "a novel where no two copies are the same", you might imagine two structures. Either:
  • A branching story with two or four or sixteen different outcomes. Like a classic CYOA book except that the choices have been pre-selected for you at random. Or:
  • A traditional novel with a set storyline, but a lot of incidental details chosen at random. They turned left or right, they were startled by a screech or a burst of sparks, the carpet was beige or brown.
Subcutanean is neither of those. Or rather, it has bits of both: some details are randomized, and the story has a couple of significant variations of the climactic scene. (I saw two, anyhow.) But the overall shape of the story is under fairly firm control, and the details that vary aren't always the incidental ones.
The work is more interested in how the narrator can vary. Orion may be more laconic or more voluble; he may be an optimist or a pessimist; he may prefer slang or avoid it. He may be the sort of person who gets awkwardly drunk at parties or the sort who stays awkwardly sober. These choices are maintained throughout the text. Particular events may be inserted or omitted, or key details changed; but the system tracks these so that later scenes can reflect them back. Perhaps with an added sentence, perhaps with just a well-placed "again".
Aaron has documented this design and its hiccups in a development blog -- well worth a look either before or after you read the book. No spoilers.
The goal, obviously, is to create a text that reads as a coherent narrative, with all the large-and-small-scale push-and-flow that a traditional novel would provide. It doesn't always work perfectly; I ran into an obviously repeated anecdote in version 10966. But on the whole it's successful. (Aaron has done at least one round of bug fixes since then, so the problem I found may have been eradicated from future versions.)
I have to admit my bias here: I have a lifelong obsession with the Unbounded House of Many Doors. If you've played any amount of my work you realize this! Subcutanean is exactly what I want, except with an accelerating curve of wrongness and decay, which is not where I usually take it. Also, of course, the ramifying underground space calls back to a long history of much-loved games, from Wumpus and Adventure through to KR0 and the future.
As I said, the book shares some aspects of game design in a non-interactive context. Really, most narrative games have pieces that work like Subcutanean. A single NPC response is a non-interactive text -- a sentence or paragraph -- whose content varies depending on the prior history of your session. It's easy to focus on your immediate interactive choices: choose a dialogue option, get a response. But really, that response could be influenced by lots of factors, overt or invisible, random or contingent.
Subcutanean is that experience with the "invisible" and "random" knobs turned up and scaled to novel-length. You never make a choice; the text is printed and fixed. But then, in Heaven's Vault, not much of the narrative variation depends on choices you know you're making. And of course the book involves all the game-design problems of keeping a variable narrative experience within the intended bounds.
Subcutanean also produces that quintessentially game-ish response which I mentioned in my Heaven's Vault post. When you finish, you immediately want to start again and see how different it could have been. "I've seen the covers, now I can open the book." Happily (though also through necessity), the book is short enough to do this without feeling bogged down. Maybe I'll read a third copy pretty soon.
We are left with the question of whether Subcutanean is the only procgen novel that could be written. Sometimes an experimental narrative so perfectly marries form and content that it's hard to imagine what else could be done with the idea. The Monster at the End of This Book, for example. Or take Jason Shiga's Meanwhile. If you're going to iterate through variations of a narrative, learning more each time, you almost need time machines, memory loops, and the threat of total narrative collapse. (Outer Wilds is an interesting comparison here -- a very different story which is nonetheless drawn into many of the same tropes.)
So if you're going to write about variations of a narrator, do you need to set it in an infinite branching space with the growing threat of utter alienation? Surely not, but some of the choices do feel kind of inevitable.
Others were unexpected. Subcutanean plays with the idea of playing by its own rules. You want to believe that every version of the book is narrated by an Orion, one of the infinite number exploring the interconnected Downstairs. If I were writing such a story, that's absolutely what I'd do! But Aaron's book doesn't. Or maybe some subset of the texts do, but not the two I read: the rules of Downstairs aren't quite consistent between them. It's upsetting.
But then, it's horror. Your certainties are supposed to come unmoored.
It doesn't have to be horror. I hope more authors take on this sort of structure. Subcutanean doesn't have to be the only one. Narrative design is no longer an abstruse mysterious field; lots of writers have dabbled in both static and dynamic prose. I'd like to see the variation-novel become an established form. Get on it, folks.

Friday, May 22, 2020

Compiling for the Z-machine version 3

The Inform 6 compiler has been pretty stable for the past several years. It's still in active use as part of the Inform 7 toolset, but the I6 compiler hasn't changed much.
However, I've put in a few I6 updates over the past week. Exciting news? Maybe not for most of us, but these changes are important to people who are trying to write really old-fashioned Inform games.
Let me go back to the old days. (Jangly harp transition...) In 1979, when Infocom ported Zork to personal computers, they designed the famous Z-machine platform. It went through a couple of iterations, but by 1982 the "version 3" Z-machine was firmly established as Infocom's workhorse.
The V3 machine was tightly constrained in some ways. For example, it could only support 255 objects (counting rooms, items, scenery, NPCs, and the player!) But this was deliberate; it was intended to run on some really tiny computers like the TRS-80 and Commodore 64.
Infocom games got larger and more sophisticated, but they kept on stuffing them into V3. The Zork trilogy, Enchanter trilogy, Hitchhiker's, Planetfall... it wasn't until AMFV in 1985 that they had to design a V4 Z-machine. And even then they kept using V3 for any game that fit.
Mind you, the Infocom people didn't say "V3" and "V4" back in the day. They referred to V3 as "ZIP". V4 was "EZIP", for "Extended ZIP". Then "XZIP" (V5) came along in 1987, and "YZIP" (V6) in 1989. These updates allowed more objects and more content. They also added a parade of new features: bold/italic text, expanded status window, sound, timed input, and finally graphics.
But this only underlines that V3 was Infocom's standard technology. You used V3 unless you had some specific need for one of the larger, fancier platforms.

Jump forward (jangle jingle) to the "modern" era of 1993. The Z-machine has been reverse-engineered; we have open-source interpreters that support all versions. Graham Nelson releases Inform, a compiler which can generate Z-machine game files.
Inform let you write games for any version, but in practice, your choice was between V3 and V5. (V1/2 were too antiquated to bother with. V6 was a headache for reasons I won't get into here. And V4 was like V5 minus a few features; if your game outgrew V3, you might as well go straight to V5.)
But among Inform users, unlike Infocom, it was V5 that emerged as the "standard platform". If you look at the games/zcode directory on the IF Archive, there are over 300 .z5 games and just five .z3 games!
The reasons are obvious. Everybody had modern Mac/PC machines which could run the largest Z-code games with ease. Authors felt free to put more scenery, more detail, more responses into their games. In that atmosphere, the V3 limit of 255 objects really pinched. And the other V5 features were nice to have around. Most games didn't need sound or timed input, but bold and italic text always look good. Why not build your game on V5 and have all the amenities available, just in case?
(Then, in 1995, Graham Nelson's Jigsaw overflowed V5 and he had to invent V7 and V8 in a hurry. But never mind that.)
So Inform's V3 compiler code was barely ever tested after the mid-90s. And we know what happens to untested code: it breaks. A couple of bugs crept in and nobody noticed.
That is, not until 2020 (jingle bloop). A couple of projects are now working on Z-machine tools for retro machines. MetroCenter '84 and PunyInform are Inform libraries optimized for size; Ozmoo and Pitch Dark are Z-machine interpreters which run on the C-64 and Apple 2.
Running on that classic metal means embracing all the memory limitations which we forgot about in the 90s. Every object and every byte counts. V3 is once again the order of the day. And presto -- the bug reports started rolling in.
Okay, only two bug reports. The fixes were a couple of lines each. Now Inform 6 can compile V3 games again!
While I was in there, I added a feature which could be of additional help. I6 games can now contain "static arrays", whose data goes into ROM rather than RAM. (Yeah, the Z-machine has ROM and RAM. I'm simplifying a bit but that's the idea.)
Static arrays may not be a lot of help. I first considered this idea when I was working on Hadean Lands -- a game which was originally planned for the "limited hardware" of the iPhone. (This was back when mobile phones didn't have gigabytes of memory.) I knew HL's alchemy system would require a lot of data and I thought that putting it into ROM might be worthwhile. But, long story short, it turned out not to be. So I didn't do it. Until now.
(Before you ask: yes, Hadean Lands is written in Inform 7, and it uses the Glulx VM rather than the Z-machine. The I6 compiler is still part of the toolchain and the concept of static arrays applies equally well to Glulx ROM and RAM.)
So there's your history lesson of the week. I could have tweeted "Inform 6 bugs fixed", but this is more fun to read, I hope.