The texture of a game ===================== For the most part, textual interactive fiction is divided into two camps: parser-based, where the player carries a dialog with the computer via pseudo-English commands, and hypertext or CYOA, where they can only follow links. In the middle lies a no writer's land that few have dared, or indeed cared, to explore as yet. Among the first to do so were Jim Munroe and Juhana "Nitku" Leinonen, who first announced Texture in 2014 (see chapter 12). The public release two years later was met with critical acclaim, but it wasn't long until the fruit of their work sort of faded into the background again. What is Texture, exactly? I mentioned it many times since then, but never got into details. Texture is an interactive fiction authoring system with a unique selling point: its control scheme consists of verbs you *drag* on top of nouns to form commands. This is the case for both players and authors: Texture is one of the most visual authoring tools I know. It also runs in a web browser, and exports games as stand-alone web pages you can just upload anywhere. The only downside is that you have to make an account on [texturewriter.com](https://texturewriter.com/), the official website. But hey, you get a nice interactive tutorial for free! There are other unique qualities to the system: the user interface is designed for touchscreens first. Curiously, instead of scrolling, the text shrinks to make room for more. That means you can't have too much of it on a page: maybe 250 words, tops (not 300 as its creators claim). Preferably less. Take into account whatever new text appears as a result of player input, too. Yes, a big part of it is that text can change in response to input: new paragraphs appear, or parts of them are replaced. Their state resets if you leave and later revisit the page, but you can always send the player to slightly different pages depending on a flag. Speaking of which: the only logic supported by Texture is simple true/false flags that you can manipulate in equally simple ways. But in my experience it's possible to make fairly complex games even so, as long as you don't try counting to ten in the code or some such. On the plus side, that makes authoring exceptionally simple. The only other kind of logic you can have is forcing the action to move on after a certain number of inputs on the same page. In fact, that's what originally sold me on it, as you'll see below. Since I mentioned pages, let's talk a bit about structure: a game is divided into pages, and since the ideal size for a page is comparable to that in a paperback, you can easily estimate its length, and figure out the pacing. You can move to a new page in response to player input, with or without requiring them to confirm, possibly in addition to a text transformation. Exactly what a given input does can change depending on a combination of flags, and you can layer sets of conditions to arbitrary depth. Beware of getting lost. And because I keep mentioning inputs, the big advantage the drag&drop system has over hyperlinks is that a handful of verbs and a handful of nouns can yield a fair number of combinations without overwhelming the player. You can't even see which nouns a verb can interact with until you start dragging it from the bottom. It's not nearly as open-ended as a parser-based game, but tries to recapture some of that spirit without confusing the player. As a minus, many players complain that it works kind of poorly with mouse and touchscreen alike. My only Texture game so far is _[City of Dead Leaves](https://felix.plesoianu.ro/intfic/dead-leaves/)_, a conversion from the original Alan 3 edition. I already knew the geography itself worked well in hypertext. More of a challenge was going to be trimming down the set of available verbs to only three per page on average. As it turned out, few of them were at all meaningful, so that was a no-brainer. More tricky was managing state, and the solution I found was borrowed from a source that shouldn't have been surprising in retrospect. You know how in _Myst_, when you click a machine, you're often taken to a close-up view where you can actually manipulate it? Turns out that works just as well in text. It just requires shifting one's mindset from geography to *context*: a generalization that could probably help with the design of situation-based CYOA games as well. Mostly positives, then, except for having to trim down the text in many places, often to its detriment. That's perhaps the system's biggest flaw. Oh well, it's just a matter of better arranging it next time, knowing the limits. Not that authors have been pushing those limits much. So far, most games on the Texture website appear to be little experimental pieces focusing on the system's text transformation features, and I'm yet to see any such games in the wild, apart from my own. Or for that matter hear about any, except when people happen to be talking about the system itself. Not that 139 games is a small library; in fact, I'm pretty sure that's more than were ever made with the aforementioned Alan 3. It seems, then, that most people just want to keep making the same kinds of interactive fiction they grew up playing, and that's either parser works or else gamebooks. Which just condemns anything the least different, like Texture, to undeserved obscurity. And the least I can do is let people know alternatives exist. We desperately need diversity in the modern world. Especially of thought. So please expand your horizons.