Text Games That Aren’t Parser IF

I know I’ve posted about this a bunch already, but I continue to be addicted to Echo Bazaar, especially as more people I know have taken it up — which means that there are more people with whom to share the social actions and (more importantly) to compare notes about what’s really going on with the setting.

If you’re interested in reading more about the game from a couple of other perspectives, Pissy Little Sausages gives a wonderfully entertaining overview; Dan Shiovitz talks in detail about the game design, with a bunch of suggestions about balancing it for better gameplay (1, 2, 3, 4; possibly more to come). Edited to add: and Sam Kabo Ashwell’s take, too.

As is often the case when I become interested in a game, I wish I had access to a version of the underlying system so I could experiment with telling my own stor(ies) in it.

It is possibly just as well that I don’t right now, though, as I am also still poking around with ChoiceScript. This is something of an experiment (how much of a world model can I fit in there? how does a CYOA interface work with puzzles and a somewhat more game-like feel? if there is a world model of some depth, and the individual choices are more predictable in effect, is the CYOA interface still a bit distancing, a bit unimmersive?).


I’ve gotten to the point now where I acknowledge that the system is remarkably flexible for a CYOA system, but I miss having a full-powered programming language at my disposal. There keep being all these loops, and variables, and it would be nice if I could have some lists to keep track of things.

At the same time, because ChoiceScript works are presented in the browser but in a very bare-bones layout and style, I keep wanting to stop working on the game and start working on CSS to make it look prettier. For straight text in IF I am mostly forced to trust the player to have gotten and be using an interpreter that suits his personal typographical preferences. Once I can publish my Glulx works online, I’ll probably fuss a lot more about the presentation side of things. (Speaking of which, Wei-ju Wu has made some more progress on his browser-based Glulx interpreter. There are rough edges — most annoyingly, to my mind, the fact that the text jumps up to the top before scrolling down at each command entry — but I am impressed by how much of the functionality does work, with graphical windows and whatnot.)

The ChoiceScript project is focusing me a lot on exactly what I do and do not like about IF as an expressive medium.

I miss the groundedness and texture of an IF world. I miss the sense of creating a place. I miss being able to tuck odd details into the scenery, details that aren’t that important (and that the player knows aren’t that important) but that contribute to the worldbuilding nonetheless. I don’t have to implement all the furniture by hand in a ChoiceScript scene, which is a mercy and makes the project a lot faster than it otherwise would be, but also removes a lot of visceral appeal.

Good IF often has some quality of thereness that cannot be described as a purely writerly virtue. This is a point that seasoned static-fiction writers coming (or being brought) to IF do not always grasp; it’s easy to focus on the transcript of a playthrough because that represents the closest thing to the pages of a novel, and say “This prose isn’t very good! It keeps repeating itself! The player has knocked on the wood paneling three times in the last five minutes, and his character isn’t meant to be an idiot!” But this misses something fundamental. Perhaps a tactile fixation is, in some sense, out of character; but the player character is both protagonist of the story and the player’s proxy within the sculptural space of the game world. In graphical videogames it’s impossible to miss that you’re playing inside architecture and alongside sculpture. This is still true of many text games. That’s not necessarily a bad thing: the created space can be aesthetically pleasing and convey meaning in itself.

CYOA doesn’t feel like it has the sculptural/architectural quality, because it doesn’t let me engage directly with things.


At the same time, I’m savoring the freedom to include actions that would be quite hard to hint fairly to a player if we were in parser-land. The story I’m writing up now is one I’ve tried to code three or four times in conventional IF, and each time I’ve been overwhelmed by the scope of what I was trying to produce: it’s a piece very much about large social actions (bribery, betrayal, learning and keeping and giving away secrets, manipulating characters and groups of characters), played out in a very sizable physical space. When I went about this in a conventional way, each scene took so much effort to construct that I gave up on completing the whole. On the other hand, when I tried to kick the interaction up a level to something more abstract (using commands like BLACKMAIL), it was too difficult to keep the player aware of what all his options were.

After running through several disappointing IF prototypes, I started thinking about vastly different interfaces for the piece — like, say, a Flash game with pictures of the various characters, where you’d click on someone to bring up a Sims-like radial menu of things you could do to him at the moment. (Poison? Betray?) But the output has always wanted to be primarily text, and that seemed like a bad fit for a GUI. Moreover, my imagined interface would mean ditching a lot of elements of the original concept, which involved getting certain people together in the same place at the same time in order to do actions that involved both of them. I could never quite convince myself that that extra work and expense (implementing my world model anew in ActionScript, hiring an artist to help with the character portraits and graphic design) would be worthwhile for the awkward hybrid I suspected would result.

The CYOA version is less granular, and more forgiving if I decide I want to summarize something in order to move ahead to the next interesting choice. Something about the command line suggests that you ought to be offering the player control over every snippet of dialogue if he has control over any. But it also takes harder work on the writing to make things feel present and alive, because the level of attention required to click a button is so much lower than the level of attention required to analyze a situation and then type in a fully-formed new instruction that responds to it.

Game-writing from the pros

I had the privilege of participating in the AI Summit at GDC 2010, which also bought me an All Access pass to the rest of the conference. I went to some of the other AI sessions — all very interesting, though many of them focused on aspects of game design that have little to do with interactive fiction — but I also hit a number of other tracks, taking in panels on independent and serious games, on art and design and writing. Especially writing.

I went to a writers’ round table session run by Richard Dansky, and lectures/panels given by Dansky, Susan O’Connor, and Marianne Krawcyzk; and I chatted informally with several people going that route professionally.

Several things in the writing track resonated with me as being potentially useful to revisit here for IF authors. In all the talk about work practices, there was a certain brutal pragmatism: the perfect is the enemy of the finished; projects have to end sometime; it’s better to write down something mediocre than to write down nothing. You can revise later.

One of my most popular posts (judging by my site stats, anyway) is the one where I talk about ways to get from idea to implementation on a project. But there is more to that process than planning. I find that even in my hobby work, I’ve moved toward treating my game writing like a job — and that sometimes means taking on both the role of writer and the role of the lead designer, creative director, or other project lead, and consciously managing myself.

Here’s what that tends to mean, for me:

Continue reading “Game-writing from the pros”

Coding Puzzles

Recently on the intfiction forum someone asked me how to code puzzles in I7. I found that a bit of a stumper, but I cobbled something together, and he liked the answer enough that he suggested I post the reply more permanently on my blog. So I’m doing that, with a little bit of editing and fleshing out.
Continue reading “Coding Puzzles”

Moods in conversation

Question from Conrad Cook:

I’m wondering how you mesh variable tracking with conversation.
You’ve mentioned _Alabaster_ tracks a lot of variables, and I can
conceptualize how that would be reflected in, for example, the
artwork. But I’ve been wrestling for a while with how to use the
conversation to move the NPC’s variables, and how to have those
variables be reflected in the course of the conversation, and so far
I’m not winning that wrestling match.

Alabaster’s source is available, so it’s possible just to look at what’s going on there — but possibly more difficult to suss out exactly what the plan is throughout the source. A technical discussion follows.

Continue reading “Moods in conversation”

Blogs of the Round Table: Denouement

Blogs of the Round Table is a group that writes on various game design issues, each month working from a new prompt provided by Corvus Elrod. This month the prompt is on a topic that’s come up several times for me, and that I’m thinking about again as I rework the ending of my WIP:

How can the denouement be incorporated into gameplay? In literary forms, it is most often the events that take place after the plot’s climax that form your lasting opinion of the story. A well constructed denouement acts almost as a payoff, where protagonists and antagonists alike realize and adjust to the consequences of their actions…

But the denouement is most neglected in video games where it is often relegated to a short congratulatory cut scene, or at most–a slide show of consequences. This month’s topic challenges you to explore how the denouement can be expressed as gameplay.

Continue reading “Blogs of the Round Table: Denouement”

Idea to Implementation

One of the most tricky aspects of amateur game development is just working out what workflow you’re going to use to get from point A, your germ of a premise, to point B, the finished game you can release. (This is not always as much of a solved problem in commercial game development as one might expect, either, but a commercial project tends to have some people with prior experience shaping a game who have a plan — whether or not it’s a good plan — about what needs to happen in what order.)

Lately I’ve adopted a new approach to this, and it’s made me look back on how I’ve done such things in the past, and the whole gory evolution (which is probably not over yet) of my implementation strategy.

StartingImplement first! Design later!: You open up your IF tool of choice and you just go. Implement a room or two, some stuff to go in it, maybe a character. Write whatever comes into your head, then seek out the connections that come out of it.

In my experience, it’s really hard to finish this kind of game. I’ve started lots this way, especially when I was new to IF writing, and that was all useful experience because it familiarized me with my tools and was a kind of play. But sooner or later you hit a wall where you realize that your doodlings aren’t going anywhere and you have no particular end in mind; or you do, but there’s not a coherent plot, the backstory doesn’t work consistently, the pacing is off. No design intentionality has gone into the project, and sooner or later that becomes obviously a problem. At that point you can either ditch the project and start a new one, or step back and do some intentional design work on the project, then come back to implementing.

There’s a real risk, though, that if you’re alternating implementation with incremental design you’ll let yourself consistently avoid the really difficult pieces. “Ending goes here.” “Something interesting happens, I’m not sure what, and the player winds up at Alpha Centauri.” “A coding miracle occurs because I have no idea how to do this.” You may not even realize that you’re doing it… until sooner or later you realize that thing is just not getting done. And isn’t ever going to.

Continue reading “Idea to Implementation”