Planet Interactive Fiction

April 26, 2015

Wade's Important Astrolab

Accessibility observations part 1

by Wade ( at April 26, 2015 02:25 AM

This is the first of a number of posts I will be making about figuring and programming accessibility into your interactive fiction game project.

I speak not as an expert, but as a game author who has now spent a fair bit of time trying to do this. I just released a large Inform 7-programmed game (Leadlight Gamma) which I tried to make fully and explicitly accessible, so my goal here is to share what I've learned about the issues and technology involved along the way. The game is fresh so I'm still learning. In other words, I'm still getting feedback about this aspect of it from the real world.

When I say accessibility, I refer primarily to making the content of your game available to players who have various degrees of visual impairment. This is because formatting game material in a way that maximises its compatibility with screen reading software (the software that reads text aloud to a player) is something you can have a significant degree of control over as an author or programmer. Solutions to some accessibility problems are entirely beyond your control, but IF has always had this gaming strength for players with limited or no sight because the content is essentially text and the games don't depend on reflexes.

The subject of accessibility came to my attention last year when I set out to program a new, more modern menu-generating extension for Inform 7. Right now I'm trying to update it for the latest version of Inform. When I asked about people's needs and wants in such an extension, Neil Butters on the forum described some of the quirks of the way his screen reading software interacts with IF. I then sought to program the extension to cooperate with screen readers. In programming Leadlight Gamma, I sought to extend accessibility principles across the whole game.

This kind of accessibility work doesn't just apply to a game itself, but to related materials, too. Here is an example from the 'learning from my mistakes' department: I drew attention to my game's accessibility upon its release, but the homepage I'd built for it was not as accessible as the game, something a blind journalist quickly pointed out to me. In real terms, this means my website content did not play nice with screen-reading software.

The world of IF technology remains querulous (will this or that interpreter run my game? Will there be pictures? Will there be sound? Will things change colour when I want them to? Can I control the fonts? Will it run online? Will it run on Macs and PCs? etc etc) and I've learned that life with screen-reading software can be as querulous in general. There is no perfect software which can interpret all websites in some idealised fashion because there is infinite variety in website design, programming methods and presentation. Screen reader users have to develop habits and nouse which allow them to find the information they want when online, and some sites don't cooperate with their software at all.

In the case of the Leadlight Gamma website, I had just spent a lot of time redesigning it and my other websites using responsive technology. That is, website code which strives to produce a fluid, attractive and logically presented website on the fly, no matter how big or small or oddly proportioned a user's screen is, or whether they're using a desktop or mobile device. The Rapidweaver themes I'd invested in to get this done did not consider accessibility. My solution was to code a plain text version of the site with screen reader-friendly navigation. I put a link allowing a visitor to switch to the text version of the site at the head of the graphic version.

In a future post I will talk about presentation issues within a game. That is, what you can do to present content helpfully within an IF interpreter screen.

Something you may be interested to watch is journalist Robert Kingett's video how blind people use the web. You can see/hear a screen reader in action and look at some examples of websites which work with one and websites which don't.

April 25, 2015


Squiffy 3 – a new web-based editor for interactive fiction

by Alex Warren at April 25, 2015 08:00 PM

The third release of Squiffy is now available. The big new feature in this version is you no longer have to download anything!

Previously, the only way to use Squiffy was by creating a file in a text editor and compiling it from the command line. You can still do that, but you can now just use your web browser instead.

In-keeping with the philosophy of trying not to do too many new things in any one release, this first iteration of the editor is intentionally very simple. It’s pretty much a text editor in the cloud, with a few Squiffy-specific bells and whistles to make editing a game easier.

Squiffy Editor

You can use the editor without logging in, in which case all changes are automatically saved to your browser (and are automatically re-loaded the next time you come back). Or if you’re logged in, you can hit the Save button to sync your game to your account, so you can access it from anywhere.

You can publish your game directly to, or you can export it as HTML and JavaScript to upload to any website (or even wrap with something like PhoneGap to turn it into a mobile app).

As you create sections and passages, the drop-down lists above the editor automatically update. These provide an easy way for you to find your way around your game.

When you run your game, it appears on the right-hand side of the screen, so you don’t need to switch between tabs or windows.

If you set attributes in your game, you can keep track of them by looking at the pane at the bottom of the screen, which logs all attribute changes.

Try it out now at

Open source, of course…

Both Squiffy and the editor are open source and on GitHub:

For Squiffy 4, I’m planning to wrap this HTML-based editor with Electron (formerly Atom Shell), to create an offline downloadable app that will work on Windows, Mac and Linux. After that, we can start fleshing out the editor with more features – a graphical overview of your game’s sections would be an important feature, I think. I’m open to more suggestions!

Enjoy! If you have any questions, post in the forum or ask at IF Answers.

April 24, 2015

The Digital Antiquarian

On S.D.I. (Just a Little) and King of Chicago (Quite a Lot)

by Jimmy Maher at April 24, 2015 03:00 PM

In addition to Defender of the Crown, Bob Jacob and Cinemaware were able to deliver two more of their planned four launch titles to Mindscape before the end of 1986. Only Bill Williams’s Sinbad and the Throne of the Falcon fell hopelessly behind schedule, getting pushed well into the following year. Of the games that did make it, Sculptured Software’s Atari ST game S.D.I. is mildly interesting as a time capsule of its era, Doug Sharp’s Macintosh game King of Chicago much more so as an important experiment in interactive narrative. Today I’ll endeavor to give each game its just desserts.


The scenario of S.D.I. is almost hilariously of its time, a weird stew of science fiction and contemporary geopolitics that quotes Ronald Reagan’s speeches in its manual and could never have emerged more than a year or so earlier or later. It’s 2017, the Cold War has gone on business-as-usual for another thirty years, and Ronald Reagan’s vaunted Strategic Defense Initiative is approaching completion at last. In response, a large group of hardliners in the Soviet military have siezed control of many of their country’s ICBM sites to launch a preemptive first strike, while also — this being 2017 and all — flooding Earth orbit with fighter planes to blow up those S.D.I satellites that are already online. This being a computer game, the nascent trillion-dollar S.D.I. program comes down to one guy with the square-jawed name of Sloan McCormick, who’s expected to jump into his spaceship to shoot down the Soviet fighters in between manually shooting Soviet ICBMs out of the sky using the S.D.I. satellites. He’s of course played by you. If you succeed in holding the hardliners’ attacks at bay for long enough, you’ll get a distress call from the legitimate Soviet government’s central command station, whereupon — just in case anyone was thinking you hadn’t done enough for the cause already — you’ll have to singlehandedly enter the station and rescue it from a final assault by the hardliners. Succeed and you’ll get your trademark Cinemaware reward in the form of Natalya, the sultry commander of the station who’s inexplicably in love/lust with you. Who said glasnost was dead?


Like Defender of the Crown, S.D.I. very nearly missed its planned launch. It took John Cutter stepping in and riding herd over a Sculptured Software that seemed to be just a little out of their depth to push the project along to completion. It isn’t a terrible game, but it is the Cinemaware game that feels least like a Cinemaware game, well earning its status as the forgotten black sheep of the family. Natalya aside, its cinematic influences are minimal. The manual tries heroically to draw a line of concordance through heroes like Flash Gordon and Han Solo to end up at Sloan McCormick, but even it must admit to an important difference: “This time the danger comes, not from an alien invasion, but from a force here on Earth.” Likewise, S.D.I. doesn’t conform to the normal Cinemaware ethos of (in Jacob’s words) “no typing, get you right into the game, no manual.” Flying around in space blasting Soviets requires memorizing a number of keyboard commands that can be found nowhere other than the ideally unnecessary manual. What with its demanding, non-stop action broken down into distinct stages, S.D.I. reminds me of nothing so much as Access Software’s successful line of Commodore 64 action games that included Beach-Head and Raid Over Moscow; S.D.I. also shares something of a theme with the latter game, although it didn’t provoke anything like the same controversy. Unfortunately, S.D.I. just isn’t executed as well. The “flight simulator” where you spend the majority of your time is a particular disappointment; your enemies follow a few distressingly predictable flight patterns, while your control over your own ship is nonsensically limited to gentle turns, climbs, and dives. And the Elite-inspired docking mini-game you have to go through every time you return to your base is just infuriating. But perhaps most distressing, especially to the Amiga owners who finally got their hands on the game when it was ported to their platform almost a year later, were the workmanlike graphics, created in-house by Sculptured Software. One could normally count on great graphics even from Cinemaware games whose gameplay was a bit questionable, but not so much this time. Even Natalya, well-endowed as she was, couldn’t compete with those fetching Saxon lasses from Defender of the Crown.

King of Chicago

King of Chicago makes for both a more interesting game to play and a more interesting game to write about. This interactive gangster flick stars you as Pinky Callahan, an ambitious young hoodlum in 1931 Chicago. Al Capone has just been sent away for tax evasion, creating an opening for you and your North Side gang of Irishmen, principal rivals of Capone’s Chicago Outfit. But to unite the Chicago underworld under your personal leadership you’ll first have to oust the Old Man who currently runs your own gang. Only then you can start on the Chicago Outfit — or, as the game calls them, the “South Siders.” Swap out medieval England for Prohibition-era Chicago and the scenario isn’t all that far removed from Defender of the Crown: conquer all of the territory on the map that’s held by your ethnic rivals. The experience of playing the two games, however, could hardly be more different.

Like Defender of the Crown, King of Chicago isn’t so interested in the actual history it references as it is in movie history. It doesn’t even bother to get the dates right; the game begins months before the real Capone was sentenced and sent away. Victory in King of Chicago must mean the North Siders rising again to take over the whole city, a scenario as ahistorical as the Saxons defeating the Normans to regain control of England. (Cinemaware did seem to have a thing for historical lost causes, didn’t they?) Prohibition-era Chicago is just a stage set for King of Chicago, Al Capone just a name to drop. The only place where the game notably departs from gangster-movie clichés is in making you and your gang a bunch of Irishmen rather than Italians — and if you don’t pay attention to one or two last names it’s easy to miss even that, given that there’s no voice acting and thus no accents to spot. Otherwise all of the expected tropes are there, from Pinky’s weeping mother who gives all the money he sends her to the church to his devious, high-maintenance girlfriend Lola. But then, as Bob Jacob so memorably put it, all Cinemaware really had to do was “rise to the level of copycat, and we’d be considered a breakthrough.” Fair enough. As homages go — and you’ll find very few computer-game fictions of the 1980s that aren’t a homage to more established media of one sort of another — King of Chicago is one of the better of its era.

Indeed, some may find it a bit too true to its inspirations. King of Chicago is notable for just how hardcore a take on the gangster genre it is. Pinky is a punk. You can play him as a devious sneak or a violent, impulsive psychopath, but he remains a punk. There’s no redemption to be found amongst King of Chicago‘s many possible story arcs, just crime and bloody murder and revenge and, if all goes well, control of the whole of Chicago. While the ledger quietly omits the brothels that provided so much of the real Chicago mob’s income, that’s about the only place where the game soft-pedals. Even Pinky’s interactions with Lola are peppered with crude remarks about how her skills in bed make up for her other failings. Bob Jacob’s original conception of Cinemaware as games for adults finds its fullest expression here, at least if what constitutes “adult” in your view is jaded sex and casual violence.

King of Chicago

More interestingly, King of Chicago represents one of Cinemaware’s most earnest and ambitious attempt at creating an interactive narrative with at least a modicum of depth. You could convert a play-through into a screenplay and have it read as, if not precisely a good screenplay, at least one that wasn’t totally ridiculous. Not coincidentally, King of Chicago contains far more text than the average Cinemaware game. Its formal approach is also unique: it’s essentially a hypertext narrative, years before that term came into common usage. You control Pinky through a bewildering thicket of story branches by clicking on multiple-choice thought bubbles above his head. Occasionally a little action game emerges to provide a change of pace, but these are relatively deemphasized in comparison with most Cinemaware games. If S.D.I. stands at the purely reactive, action-oriented end of the Cinemaware scale, King of Chicago stands at the opposite pole of cerebral storymaking. It has a certain — and I know Bob Jacob would hate this description — literary quality about it in comparison to its stablemates. You can see its unusual narrative sophistication not least in its female cast. While not exactly what you’d call progressive in its handling of women, King of Chicago does give them actual personalities and roles to enact in the drama, rather than regarding them strictly as prizes for a job well done. In this respect it once again stands out as almost unique in the Cinemaware catalog.

Doug Sharp dressed as a gangster for a King of Chicago promotional shoot.

Doug Sharp dressed as a gangster for a King of Chicago promotional photo shoot.

King of Chicago was the creation of a thirty-something former fifth-grade teacher named Doug Sharp, another of Jacob’s old contacts from his days as a software agent that were serving him so well now as a software entrepreneur in his own right. Sharp had first been exposed to microcomputers during the late 1970s, when he was teaching school in the educational-computing hotbed of Minnesota, home of the Minnesota Educational Computing Consortium and their seminal edutainment game The Oregon Trail amongst other innovations. His habit of taking his school’s Apple IIs home with him on weekends soon led to a job writing educational software for Control Data and Science Research Associates. In 1984 he and a partner, Mike Johnson, started working on a spiritual successor to Silas Warner’s Robot War that they called ChipWits. Programmable robots remained the theme, but they were now programmed using a visual, icon-based language instead of Robot Wars‘s cryptic assembly-language-style code. ChipWits represented a kindler, gentler approach to recreational robot programming all the way around. Instead of focusing on free-form robot-against-robot combat, the game was built as a series of missions, a collection of discrete challenges that the cute little robot had to overcome in the course of a grand and non-violent adventure. Written initially for the Commodore 64, ChipWits became one of the breakout stars of the January 1985 Winter Consumer Electronics Show, and did moderately well once released by Epyx shortly thereafter. The agent who brokered that publishing deal was, you guessed it, Bob Jacob, while Kellyn Beeck, soon to become Cinemaware’s most prolific game designer but then in charge of software acquisitions at Epyx, was the latter company’s signatory to the contract.

Sharp’s next game King of Chicago became the first of the eventual Cinemaware titles to go into development, several months before Jacob would even officially form his company. Sharp threw himself into the project with a will. He “collected all the classic gangster films. I picked apart what I enjoyed most about them and used this information to come up with my characters and storyline.” He worked with a graduate student in the University of Toronto’s drama department named Paul Walsh to learn the subtle nuances of pacing and dialog that make a good play or movie. Walsh became quite taken with the project for a while there in his own right. He had a blast coming up with new episodes for Sharp to sort through, chop up, and, truth be told, often discard. “When you work on a play,” Walsh said, “you have to cut out so much good stuff. With this, all your good ideas get thrown in.” True as ever to Cinemaware’s theme, Jacob would wind up giving Walsh a credit as “Dialog Coach” in the finished product. (Walsh would go on to a long and still-ongoing career as a professor, playwright, dramaturg, and translator of Ibsen.)

King of ChicagoApart from Walsh and some music contributed by Eric Rosser, that original Macintosh King of Chicago was the work of Doug Sharp alone. When the coding and writing got to be too much, he would retreat into his workshop to mold the heads of his various characters out of clay. Once crudely digitized and imported into the game, their grotesque shapes — some of the gangsters seem to have been afflicted with whatever strange illness led to Elephant Man Joseph Merrick — certainly gave the game a unique look, if one perhaps more appropriate to a horror movie than a gangster flick.

But no matter. What’s most interesting about King of Chicago is what’s going on beneath its surface. What might first appear to be a simple branching narrative in the tradition of Choose Your Own Adventure turns out to be something much more sophisticated. It is in fact a hugely innovative leap into uncharted waters in the fraught field of ludic narrative. I want to take some time here to talk about what King of Chicago does and how it does it because these qualities make it, so much less splashy than Defender of the Crown though its surface appearance and commercial debut may have been, of equal importance in its own way. More hypertext narrative than traditional adventure game, King of Chicago does its level best to make a story with you rather than merely tell you a story. This distinction is a very important one.

The story in a storytelling game lies waiting to be discovered — but not written — by you as you make your way through the game. Storytelling games can offer strong, interesting stories, but do so at the expense of player freedom. You generally have local agency only, meaning that you may have some options about the order in which you explore the storyworld and even how you cause events to progress, but you’re nevertheless tightly bound to the overall plot created by the game’s designer. The canonical example of a storytelling game, a perpetual touchstone of scholars from Janet Murray to Chris Crawford, is Infocom’s Planetfall, particularly the death therein of your poor little robot companion Floyd. Every player who completes Planetfall will have experienced the same basic story. She may have seen that story in a slightly different order than another player and even solved its problems in slightly different ways, but Floyd will always sacrifice himself at the climactic moment, and all of the other major plot events will always play out in the same way. Storytelling games are Calvinist in philosophy: free will is just an illusion, your destiny foreordained before you even get started. Still, fixed as their overall plots may be, they allow plenty of space for puzzle solving, independent investigation of the environment, and all those other things we tend to wrap up under the convenient term of “gameplay.” I’m of the opinion that experiencing a story through the eyes of a person who represents you the player, whom you control, can do wonders to immerse you in that story and deepen the impact it has on you. Some folks, however, take interactive fiction’s explicit promise of an interactivity that turns out to exist only at the most granular level as a betrayal of the medium’s potential. This has led them to chase after an alternative in the form of the storymaking game.

The idealized storymaking game is one that turns you loose in a robustly simulated storyworld and allows you to create your own story in conjunction with the inhabits of that world.1 Unfortunately, it remains an unsolved and possibly unsolvable problem, for we lack a computerized intelligence capable of responding to the player when the scope of action allowed to the player includes literally anything she can dream of doing. Since an infinite number of possibilities cannot be anticipated and coded for by a human, the computer would need to be able to improvise on the fly, and that’s not something computers are notably good at doing. If we somehow could find a way around this problem, we’d just ram up against another: stories of any depth almost universally require words to tell, and computers are terrible at generating natural language. In a presentation on King of Chicago for the 1989 Game Developers Conference, Sharp guessed that artificial intelligence would reach a point around 2030 where what he calls “fat and deep,” AI-driven storymaking games would become possible. As of today, though, it doesn’t look like we’ll get there within the next fifteen years. We may never get there at all. Strong AI remains, at it always has, a chimera lurking a few decades out there in some murky future.

That said, there’s a large middle ground between the fixed, unalterable story arc of a Planetfall and the complete freedom of our idealized storymaking game. Somewhere inside that middle ground rests the field of choice-based or hypertext literature, which generally gives the player a great deal of control over where the story goes in comparison to a traditional adventure game of the Infocom stripe, if nothing close to the freedom promised by a true storymaking game. The hypertext author figures out all of the different ways that she is willing to allow the story to go beforehand and then hand-crafts lots and lots of text to correspond with all of her various narrative tributaries. The player still isn’t really making her own story, since she can’t possibly do anything that hasn’t been anticipated by the story’s author. Yet if the choices are varied and interesting enough it almost doesn’t matter.

The adventure game and the hypertext are two very distinct forms; fans of one are by no means guaranteed to be fans of the other. Each is in some sense an exploration of story, but in very different ways. If the adventure game is concerned with the immersive experience of story, the hypertext is concerned with possibilities, with that question we all ask ourselves all the time, even when we know we should know better: what would have happened if I had done something else? The nature of the two forms dictates the ways that we approach them. Most adventure games are long-form works which players are expected to experience just once. Most hypertexts by contrast are written under the assumption that the player will want to engage with them multiple times, making difference choices and exploring the different possible outcomes. This makes up for the fact that the average playthrough of the average hypertext, with its bird’s-eye view of the story, takes a small fraction of the time of the average playthrough of the average adventure game, with its worm’s-eye view. It also, not incidentally for Doug Sharp’s purposes, dovetails nicely with the Cinemaware concept of games that play out in no more time than it takes to watch a film, but that, unlike (most) films, can be revisited many times.

Narrative-oriented computer games in the early days hewed almost uniformly to the adventure-game model. Partly this was a matter of tradition; parsers and puzzles had become so established in the wake of Adventure and Scott Adams that it was seemingly hard for many authors to even conceive of alternative models of interaction (witness Nine Princes in Amber, a game that founders on the rocks between text adventure and hypertext). And partly this was a matter of technical constraints; those early machines were so starved for memory that the idea of a complex branching narrative, most of which the player would never see in any given playthrough, was a luxury authors could barely even conceive of affording. Thus during the early 1980s hypertexts were commonly found not on computers but in the hugely popular Choose Your Own Adventure line of children’s books and the many spin-offs and competitors it spawned.

The firewall began to come down at last in 1986, after designers began to realize that it was okay to dump parsers and puzzles if their design goals leaned in another direction, and after microcomputers had progressed enough from the days of 16 K and cassette tapes to crack open the door to more narrative experimentation. We’ve already looked closely at a couple of the works that resulted. Portal and Alter Ego each had the courage to abandon the parser, but neither takes full advantage of the new possibilities that come with placing a computer program — a real simulated storyworld — behind the multiple choices of Choose Your Own AdventurePortal is an exploration of a fixed, immutable story that has already happened rather than an exercise in making a new one. Alter Ego is more ambitious in its way, keeping track of your level of psychological, interpersonal, and economic achievement via various metrics, but doesn’t adapt the story it tells all that well to either your evolving personality or your evolving life situation, forcing you to power through largely the same set of vignettes every single time you play. King of Chicago, on the other hand, pushes the envelope of narratogicial possibility harder than any game that had yet appeared on a PC at the time of its release.

Here’s how Sharp, hewing closely as always to Cinemaware’s theme, describes his conception of his game:

A guy in a projection booth with hours and hours of film about a group of gangsters. The film is not on reels but in short clips of from a few seconds to a few minutes long. The clips hang all over the walls of the projection room. The projectionist knows exactly what’s on each clip and can grab a new one and thread it into the projector instantly. The audience is out there in the theater shouting out suggestions and the projectionist is listening and taking the suggestions into account but also factoring in what clips he’s already shown, because he wants to put together a real story with a beginning, middle, and end, subplots, introduction and development of characters and the whole narrative works. I wanted to minimize hard branches, to keep the cuts between clips as unpredictable as possible. Yet the story had to make sense, guys couldn’t die and reappear later, you couldn’t treat the gangster’s moll like dirt and expect her to cover your back later.

The second-to-last sentence is key. Hypertexts prior to King of Chicago had almost all been built out of predictable hard branches: “If you decide to do A, turn to page X; if you decide to do B, turn to page Y.” Such an approach all too often devolves after a play or two into a process of methodically lawn-mowering through the branches, looking for the path not yet taken until branches or patience is exhausted. Sharp, however, wanted a story that could feel fresh and surprising over many plays. In short, he wanted to deliver an exciting new gangster movie to his player each time. To do so, he would have to avoid the predictability of hard branches. He dubbed the system he came up with to do so Dramaton.

Like real life, Dramaton deals in probabilities and happenstance as much as cause and effect. The game as a whole can be thought of as a big bag of potential scenes, each described and “shot” much like a single scene from a movie, with the important difference that each offers Pinky one or more choices to make as it plays out. These choices can lead to a limited amount of the dreaded hard branching within each scene. Where Dramaton mixes things up, though, is in the way it chooses the next scene. Rather than inflexibly dictating what comes next via a hard branch, each episode alters a variety of variables reflecting the state of the storyworld and Pinky’s place within it. Some of these are true/false flags. (Has Pinky bumped off the Old Man to assume control of the gang? Has the eminently bribeable Alderman Burke been elected mayor?) Others are numeric measurements. (How happy is his girl Lola is with her beau? How does the rest of the gang feel about him? How well are the North Siders doing in Chicago at large? How agitated are the police by the gangsters’ activities?)

After an episode is complete, a narrative generator — what Sharp calls the Narraton — looks at all of these factors, then adds a healthy dose of good old randomness to choose an appropriate next episode that fits with what has come before but that is impossible for the player to predict. The player’s specific choices in an episode can also have a direct impact on what happens next, but with rare exceptions such choices are used more to whittle down the field of possibilities than to force a single, pre-determined follow-up episode. For example, if the player has just decided it might be a good idea to go see what’s up with Lola, the following episode will be restricted to those involving her.

To facilitate choosing an appropriate episode, each is assigned “keys,” amounting to the state of affairs in the storyworld that would ideally hold sway for it to fit perfectly into the overall context of the current story. For instance, an episode in which Lola goads Pinky, Lady Macbeth-style, for his failings and lack of ambition might require a low “Lola Happiness” number and a low “Pinky Reputation” score. An episode in which Pinky hears some other gangsters grumbling about the Old Man and must decide how to respond might require a relatively low “Old Man Reputation” number but a high “Gang Confidence” score (thus leading them to feel empowered to speak up). The closer the current reality of the storyworld corresponds with a given episode’s indexes, the more likely that episode is to be chosen.

This method of weaving scenes together had some interesting implications for Sharp himself as he wrote the game, turning the process into something more akin to guiding a child’s growth than constructing a dead piece of technology. He could “improvise” as an author: “If I got a great idea for a new episode, I could set it up in its own sequence, assign it keys, and trust that it would be selected appropriately.” Thus he was actually approaching the storymaking ideal despite being forced to work with fixed chunks of story rather than being able to cause the computer to improvise its own story; he was creating a narrative capable of surprising even him, the author. He notes that there are quite likely episodes in King of Chicago that have never been seen by any player ever because the indexes assigned to them can never be matched closely enough to trigger them — dead ends left behind as the storyworld organically grew and evolved under his careful stewardship.

For the ordinary player of the finished product, there must obviously come a point where episodes begin to repeat themselves and King of Chicago loses its interest. Sharp did his best, however, to delay that point as long as possible. He estimates that all of the episodes in the game played one after another would take about eight hours to get through, while the player is likely to see no more than 20 percent of them in any given playthrough. For a while anyway each of the gangster movies you and King of Chicago generate together really does feel unique. Even the opening scene that kicks off the movie varies with the vicissitudes of the random-number generator. The storyworld of King of Chicago, where your actions have an effect on your own fate and that of those around you but aren’t the whole of the story, can feel shockingly real in contrast to both the canned fictions of adventure games and the hard branches of those less ambitious hypertext narratives that still dominate the genre even today.

Managing a criminal empire by the twenty-question method.

Managing a criminal empire by the twenty-question method.

Unfortunately less effective is the simple economic simulator that’s grafted onto the interpersonal stories. Here you control how much effort you put into your various criminal endeavors — speakeasies, gambling, and rackets — as well as how much you pay Lola, your right-hand man and bean counter Ben, the various officials you bribe, the foot soldiers in the gang, and of course yourself. In the original Macintosh version of the game this process is almost unbelievably tedious. You’re forced to learn about and control your empire via a question-and-answer session with Ben that takes absolutely forever and that has to be repeated over and over as the months pass. You can easily end up spending more total time having these inane dialogs with Ben then you do with the entire rest of the game.

King of Chicago on the Amiga.

King of Chicago on the Amiga.

Thankfully, the Macintosh version is not the final or definitive one. Over a year after the original release the game finally appeared on the Amiga in a version that isn’t so much a port as a complete remake. While Sharp still acted as programmer and narratologist, Cinemaware’s in-house team completely redid the graphics, ditching Sharp’s Potato Heads in favor of hand-drawn portraits of tough mugs and pouting dames that could be dropped easily into any vintage James Cagney flick. Sharp, meanwhile, took the opportunity to tighten up the narrative, removing some wordy exposition and pointless scenes, rewriting others. The occasional action games were also vastly improved to reflect the Amiga’s capabilities. Best of all, the endless question-and-answer sessions with Ben were replaced with a simple interactive ledger giving an easily adjustable overview of the state of your criminal empire. The strategy angle is still a bit undercooked — the numbers never quite add up from month to month, and cause and effect is far from consistently clear — but it goes from being a tedious time sink to an occasional distraction. The Amiga version plays out in about half the time of the original, with a corresponding additional dramatic thrust.

The Amiga's much-improved economic interface.

The Amiga version’s much-improved economic interface.

Of S.D.I. and King of Chicago, the latter would turn out to be the more successful in the long run, managing to sell more than 50,000 copies — albeit most of them in its vastly improved version for the Amiga and (eventually) the Atari ST and IBM PC rather than its original Macintosh incarnation. Despite its relative commercial success, it’s always been amongst the most polarizing of the Cinemaware games, dismissed by some — unfairly in my opinion, for all the reasons I’ve just so copiously documented — as little more than a computerized Choose Your Own Adventure book. Future Cinemaware games would take their cue from Defender of the Crown rather than its companions on the label’s debut marquee. I wish I could say I expect to be revisiting the ideas behind Doug Sharp’s Dramaton soon, whether via a game from Cinemaware or anyone else, but such bold experiments in interactive narrative have unfortunately been much less common than one might wish in the history of computer gaming. This just makes it all the more important to credit them when we find them.

(The sources listed in the previous article apply to this one as well. In addition: Commodore Power Play of August/September 1985; Doug Sharp’s blog; and two presentations given by Sharp, one from the 1989 Game Developers Conference and the other from 1995 American Association of Artificial Intelligence Symposium on Interactive Story Systems.

King of Chicago is available in the emulated Amiga version for iOS and Android for those of you interested in experiencing it today.)

  1. I should note at this point that the terms “storytelling game” and “storymaking game” are hardly set in stone. Some prefer to talk of “canned narratives” and “emergent narratives.” Some, such as Brian Moriarty, have even flipped the terms around, considering the stories in storymaking games to be stories made beforehand by a human designer, and the stories in storytelling games to be stories made up and told on the fly by the computer. Doug Sharp himself seems to favor Moriarty’s usage, but I find my approach more intuitive. Regardless, it’s best not to get too hung-up on ever-shifting terminology in this area, and just try to understand the concepts. 

Mike Berlyn Could Use a Little Helping Hand

by Jimmy Maher at April 24, 2015 07:01 AM

Mike Berlyn

As some of you who read this blog are doubtless already aware, Mike Berlyn was diagnosed with cancer last September. Whilst undergoing chemotherapy and radiation treatment, he’s also been accumulating medical bills not covered by Medicare. In short, he needs at least $36,000 to put him in the clear again and let him concentrate on dealing with his illness rather than worrying about money. If one of Berlyn’s many games touched you or made you laugh at a time when you needed a little boost in your own life, or if you just feel like I do that everyone should have a right to the medical care they need regardless of money, please think about going to the donation page set up by Berlyn’s fellow Infocom alum Dan Horn and contributing whatever feels appropriate and manageable.

And please help to spread the word further via all that “social media” stuff the kids are always talking about these days!


Renga in Blue

Wander (1974) release, and questions answered

by Jason Dyer at April 24, 2015 04:00 AM

(For the opening of this saga, you might want to read Anthony’s post first.)

There is a text adventure creation system that dates back to before Crowther wrote ADVENT.

I’ve been stalking a copy of Wander for months now; I made a blog post about it and some other games I’ve been tracking down. Anthony read my post and reached out to the author Peter Langston, who has been enormously helpful and managed to find a friend (Lou Katz) who had an archived copy in email, but it only contained a demo version of one of the games.

I had the vague suspicion it might be in a public place if I knew where to look. Indeed: Doug Merritt has found a copy of Wander buried in a software distribution from the Usenix 1980 conference. It includes all four games mentioned in my “lost mainframe games” post.

NEW: This is an update archive which includes all worlds (except advent) and should compile out of the box. Saving and restoring are fixed. Also now fixes a one-line typo that prevented compiling.

Here’s a binary for Windows 32-bit, made by Jayson Smith.

Here is the advent “world” as a separate file which is a Wander version of the Crowther and Woods Adventure. It seems more like a demo than the other games; Peter only made a partial conversion.

Part of the “castle” world for Wander.

These are by Peter:
castle (1974): you explore a rural area and a castle searching for a beautiful damsel.
a3 (1977-1978): you are the diplomat Retief (A sf character written by Keith Laumer) assigned to save earthmen on Aldebaran III
tut (1978): the player receives a tutorial in binary arithmetic.

One of the games is by Nat Howard:
library (somewhere between 1974-1978): You explore a library after civilization has been destroyed.

Also, Peter himself did a very incomplete port of Crowther and Woods Adventure called advent dated at 1981.

There’s one “missing” game. Lou Katz (who I mentioned earlier) wrote “a department store world, trying to make a computer game that would appeal to girls.”

Now to address some questions (note to Peter: please let me know if anything is off!) —

Was it really from 1974?

To quote Peter:

As I remember I came up with the idea for Wander and wrote an early version in HP Basic while I was still teaching at the Evergreen State College in Olympia, WA (that system limited names to six letters, so: WANDER, EMPIRE, CONVOY, SDRECK, GALAXY, etc.). Then I rewrote Wander in C on Harvard’s Unix V5 system shortly after our band moved to Boston in 1974. I got around to putting a copyright notice on it in 1978.

The early version in HP Basic was possibly from 1973; Peter isn’t sure. The move to Boston is a distinct event, though, so 1974 as a start date is is definite.

Note: Peter Langston’s legendary Empire was from 1971.

Did it look like its current form in 1974?

Peter says “the concept didn’t change, but implementation got better and the worlds got easier to create”. He doesn’t have a good recollection, though, so he can’t answer questions like “which features got added first” and “did anything get tweaked after the release of Adventure”.

Probably the best way to verify the early state would be to somehow track down the HP BASIC version, which was never revised post-1974.

Do we have to rewrite the history books?

Er, sort of. Wander never really had the same impact as Adventure; Peter notes that in his games distribution Empire, StarDrek and the Oracle attracted all the interest.

What else is there to do?

There’s a need for modernization and ports. (People have been mentioning Github; if someone wants to start one, feel free to do so and toss a note in the comments section.)

Finding the original BASIC version would be huge; we’d know exactly what things were like at the earliest stage of the development of the adventure game.

For my part, I’m going to play the games and blog about them in my All the Adventures project.

What about other mainframe games?

Ok, this is my question. If you’re interested in this sort of thing, you can refer to my lost mainframe games post and see if you can find any of the others. LORD is particularly tantalizing but I don’t know where to even start searching for an archive from Finland.

Stupid Parser Tricks

Source code of a work of IF older than ADVENT recovered

by Aric ( at April 24, 2015 12:30 AM

Just wanted to share what I thought was an exciting bit of IF-archeology conducted by "Ant" of Retroactive Fiction.  The author claims to have the source-code for a game called Wander, that's supposed to predate Crowther and Woods' ADVENT. The story, which is more complex than my summary does justice, is told nicely in his blog -- I'm just sharing here because I noticed it isn't listed on

April 23, 2015

Z-Machine Matter

Mike Berlyn Needs Our Help

by Zack Urlocker at April 23, 2015 05:49 PM

Mark Blank Michael Berlyn 1985

Michael Berlyn, one of Infocom's more prolific authors (Suspended, Cuththroats, Infidel, Fooblitsky, Zork - The-Undiscovered Underground) is raising $36k for cancer treatment. His games touched a lot of peoples lives. Lets do the right thing and help Mike out. Go to GoFundMe to make a donation.


Review: Freshman Year

by Amanda Wallace at April 23, 2015 05:01 PM

freshman year

You’re sitting on your laptop in bed. You live in a dorm with your best friend Jenna.

Games like Freshman Year are inherently personal. An autobiographical vignette by Nina Freeman, Freshman Year follows a night in the world of Nina as she goes out to a bar.

Like many up and coming interactive experiences, your choices don’t truly effect the outcome — you cannot stop what is to come, a commentary on the nature of assault. You trade texts with your friend Jenna, you choose different narrative beats. But in the end, it all comes out the same. It reminds me of the Day the Laughter Stopped, a game that attempted to have much the same effect.

The success of Freshman Year vs. The Day the Laughter Stopped is in the complicity you feel towards your characters own assault. With an adults eyes, looking towards the world of The Day, you can sense the oncoming dread. You know that your character is going towards a bad experience. You want to throw the brakes as you start your inexorable slide towards the “bad ending,” in that case the only ending. The structure of The Day made me feel like an angry God holding a magnifying glass on an ant, needing the sacrifice of another young girls assault to sate my blood lust.

One of the strengths of Freshman Year is that it doesn’t seem inevitable. Looking through the experience after the fact, even playing it again, you realize that your choices are topical decisions. You are not in charge of what happens that night — the same as real life in these instances. But while you are playing, you don’t feel that way. You choose what you’re going to wear. You pick the texts you send your friend. You wait outside the bar in the cold. These choices feel naturalistic, not inexorable. The choices make the game an exercise in personal experience, a reflective pool through which your own past choices are illuminated.

I mention personal experience because I think that may be one of Freshman Year’s strengths as well as its weaknesses. Instead of sympathy for Nina’s character, you experience empathy and relate the struggle of the character to your own history: the stalker I had in middle school, the man who groped my friend at a college bar when he was too drunk to protest, the guy who followed me home from a University event to tell me that he wanted to “break me in.” This feeling of connected-ness is fantastic. But as a tool for communication for those unaffected, it doesn’t quite work.

My own personal history aside, the suddenness of the final climatic scene is effective but also alienating to people whose experiences do not include that level of discomfort. It’s difficult to fully critique a persons personal story, because it feels a bit like telling someone that they way they lived was wrong, but in the case of game design it’s important.

All the parts of Freshman Year are beautiful pieces of a whole. The art style is distinctive and lovely — a watercolor of dreamlike intensity that captures the light of youth in all its innocent glory. The music is melodic and simple. The writing is stand-out — nothing feels out of place, the perspective spot on. Freshman Year is important, with a capital “I.” It is the kind of game that people should play at least once, for its unique perspective and for its ability to characterize futility in a human manner.

Freshman Year is now available, for free, on Steam.

The post Review: Freshman Year appeared first on .

Sibyl Moon Games

Seeing Spring

by Carolyn VanEseltine at April 23, 2015 04:01 PM

We had a truly horrible winter in Boston (the worst in recorded history, actually), mostly compacted into the month of February. It seemed like spring would never come, and when I went on vacation last week, the snow was gone but the world was bare.

But I came back from vacation and discovered that the grass had turned green, and all the bare branches had sprouted green buds, and crocuses were pushing up green and purple. I might not have noticed it if I’d been here every day, but since I was gone, the effect was glorious.

green things

And I thought: this reminds me of game dev.

(Okay, everything does. But bear with me.)

For the purposes of this post, I’m thinking about traditional game dev rather than interactive fiction. Interactive fiction is great because (generally speaking) progress is extremely visible. When you can’t go west at the top of the day, and you have three new, fully implemented rooms in that direction at the end, then it’s easy to see what you’ve accomplished.


tetraminosTraditional game dev is different. To paint with a very broad brush, the heart of traditional game dev is mechanical. There’s no game before the gameplay works, regardless of whether that gameplay revolves around jumping between platforms or dropping tetronimos.

In a situation like this, you can’t start from room one and just keep going. You need rooms – or the equivalent coding structures for your game mechanics. Without those structures, you have a pile of design notes and art and sound, but you don’t have anything that’s recognizable as a game.

Once that initial infrastructure exists, then you can build upward and outward. Once you have the concept of tetronimos, then you can give the player the ability to drop them. Once you have physics in place, then you can give the player the ability to jump.

initial infrastructure (physics engine) –> basic mechanics (player can jump) –> gameplay mechanics (player can jump on enemies to destroy them)

But in the trenches, it’s very hard to see progress – especially in those early gray days, when the snow’s barely melted and there’s no green in sight. You work all day, and at the end, you can maybe push a ball with the arrow keys, even though the final design calls for hundreds of bullets flying through the air as your protagonist avoids them by somersaulting off the walls.

In game dev, you’re both the gardener and the garden. The seeds sprout underground, and the branches put out buds, and little by little, green pushes its way to the surface. A single day’s progress might be invisible – but over time, all those invisible days add up.

tree branches

This is why I keep a weekly dev log. It’s one of the most powerful motivational tools in my arsenal. No matter how slow my progress may seem on a day-to-day basis, it’s spectacular when viewed a week at a time. I can’t go away on vacation and expect the game to grow itself, but I can take a snapshot at the top of each week and watch the world bloom.

(There are a lot of other lessons you could take from this post, like “never code your own physics library” and “rapid prototyping makes the snow melt faster” and “game jams are like kudzu, in a good way”. But one post at a time!)


April 22, 2015

The XYZZY Awards

Awards ceremony this weekend

by Sam Kabo Ashwell at April 22, 2015 01:01 PM

The winners of the 2014 XYZZY Awards will be announced in the usual ifMUD ceremony, held in the Grand Auditorium on April 26th at 12 noon US-Pacific / 3 PM US-Eastern / 8 PM UK. (The results will also be announced over Twitter: @XYZZYawards.) Please join us to celebrate the best IF of the past year.

To get to the Auditorium, go south, then east from the Long Hall. (The Long Hall is east of the Lounge.) The Auditorium doors don’t open until just before the ceremony.

You can vote through April 24. The XYZZYs use the same login system as the IF Comp, and the Comp site has changed around. Your IF Comp account will still work fine for voting, but if you want to make a new account you’ll have to register over at the IF Comp site.

You can also log in with an existing account, and then vote over here.

April 21, 2015

Renga in Blue

Adventure II: Changes

by Jason Dyer at April 21, 2015 03:00 AM

I assumed, mainly, that Adventure II would add extra rooms and treasures. That part, certainly, is true.


Click on the map to enlarge; rooms marked in blue are new to this version. Please note it is likely incomplete. The new rooms (perhaps inspired by greater storage capacity on whatever computer they were using) include longer descriptions than most of 350-point Adventure.




I’m not sure if the longer descriptions are a feature, really. Nothing mentioned in either of the rooms above can be interacted with. The rule that “interesting scenery objects will at least let you refer to them” was not established yet.

The map also includes some instant-death which seems more along the lines of Acheton than Adventure.






There’s more new features than just extra rooms.


Yes, it appears Adventure II has the honor of including the first “hunger puzzle” — thirst puzzle, mind, but functionally equivalent. After enough time without water the player dies. There are a few water sources but it is important to keep the bottle on hand and filled at all times. The message seems to indicate the thirst timer can be slowed down by dropping inventory, but I haven’t experimented enough to know exactly what’s going on.

In a way, the reuse of an object from original Adventure for a totally different type of puzzle is want intrigues me most about playing this mod. I just wish it wasn’t a reuse that added a logistical nightmare.

The enemies are also somewhat enhanced. The dwarf, for instance, is capable of dropping a “little horn” after death. Blowing the horn doesn’t end well.




There’s also someone who mentions a chalice that I haven’t seen


an owl which is scared by light


and a possible extra character only indicated by a shadow. I suspect a thief. (Also possible: random atmosphere message.) The reason why I suspect a thief is the existence of a “Thieves Den” room.

By the time I report back I expect I’ll have solved one of the new puzzles. I hope?


Writing IF with Raconteur, part 3: adapting some text

April 21, 2015 02:22 AM

This is the third part of a series walking step-by-step through developing a game with Raconteur. In this post, I’ll explain Raconteur’s adaptive text features.

Let’s get right to it. I’ll be starting from the complete example from the last tutorial. So far, we’ve only seen situations that have a long String as their content property:

situation 'go_right',
  content: """
    The tunnel opens up into a wide chamber, dominated by a bright
    reflecting pool.
  optionText: 'Go right'

Until now, I’ve been hiding one of the key features of Raconteur: The fact that content can not only be a simple string but also a function that returns a string. So we could rewrite this situation:

situation 'go_right',
  content: () ->
      The tunnel opens up into a wide chamber, dominated by a bright
      reflecting pool.
  optionText: 'Go right'

As we know, () -> is CoffeeScript for a function declaration, with no named arguments. Everything indented right of that declaration is part of the function body, which in this case includes only the string. In CoffeeScript, the last expression in a function is taken as its return value, so that the function simply returns that string.

You can make that change to the full example from the last tutorial and run it, and you will find that nothing has changed. But it’s important to note the difference between using a function as a content property, and using a String.

goldPieces = 500

situation 'count_gold',
  content: """
    You count your gold and find that you have #{goldPieces}gp.

situation 'count_gold2',
  content: () ->
      You count your gold and find that you have #{goldPieces}gp.

On first glance those two situations may seem functionally identical, but they are actually doing quite different things. count_gold is looking at the value of goldPieces when the situation is created, and “baking” that value into its content. Remember, the #{} syntax in CoffeeScript is equivalent to evaluating the expression inside the brackets, converting it to a String, and then concatenating it inside the parent string. So the first situation will always say “500gp” no matter what happens to the value of goldPieces.

The other situation will work as you might intuit that it should: Because the string has been wrapped in a function, it gets evaluated only when that function is run. So it will print the current value of goldPieces, whatever it may be at the time when the situation is entered.

A content function can do anything – including have side-effects – but the most common use of them is to construct text procedurally based on the story state. In the last tutorial, we blocked a path from the player if they didn’t pick up the lamp outside the cave; let’s say we wanted to acknowledge that they had the lamp in the other branch, too, without blocking it:

situation 'go_right',
  content: (character) ->
    poolAdj =
      if character.sandbox.hasLamp then "bright reflecting" else "dark" 
      The tunnel opens up into a wide chamber, dominated by a #{poolAdj}
      pool. #{if character.sandbox.hasLamp then 'Flickering light from your
      lamp bounces off the slick walls.' else 'It is very dark, and you all
      but fall into the pool.'}
  optionText: 'Go right'

content, as a function, gets passed the same Character and System objects that we saw previously, as well as the name of the previous expression.

Note how if statements in CoffeeScript are themselves expressions, so they can be used inline inside a string interpolation, or as the left hand of an assignment statement. Note that an if-expression can evaluate to undefined if there’s no else branch:

day.beautiful = false

"Hello!#{if day.beautiful then ' What a beautiful day!'}"
# -> "Hello!undefined"

"Hello!#{if day.beautiful then ' What a beautiful day!' else ''}"
# -> "Hello!"

Another important thing about content: Inside that function, the value of this is set to the situation object itself. Situations can have custom defined own properties, so you can use this behaviour to encapsulate something about a situation:

situation 'examine_dog',
  breed: 'dalmatian'
  size: 'large'
  colours: 'spotted'
  content: () ->
      The dog is a #{this.size} #{this.breed}, covered in #{this.colours} fur.
    # -> The dog is a large dalmatian, covered in spotted fur.

This will prove useful when we start dealing with text iterators.

Text Iterators

Text iterators are one of Raconteur’s convenience features, and the first one we’ll talk about that comes in a separate module from the main situation module.

oneOf = require('raconteur/lib/oneOf.js')

oneOf() is a factory, a function that builds a certain kind of object. Unlike a constructor, it’s not meant to be invoked with new. And we’re only really interested in oneOf objects for their particular methods. All this is to say that oneOf implements a way of creating variable text snippet that should be familiar to Inform 7 users. An example:

ring = oneOf('The phone rings.',
  'The phone rings a second time.',
  'The phone rings again.').stopping()

situation 'phone_rings',
  content: () -> "#{ring()}"
  choices: ['ignore_phone']

situation 'ignore_phone',
  content: () -> "#{ring()}"
  optionText: 'Ignore the phone'
  choices: ['ignore_phone_again']

situation 'ignore_phone_again',
  content: () -> "#{ring()}"
  optionText: 'Let it ring'

This is a toy example, but it shows how oneOf works. We create a oneOf object with by passing any number of strings as arguments to oneOf(). Then we call the stopping() method on that object to get a special function, a closure.

Each time you call that function, it’ll return one of your strings – until it runs out; then it’ll keep repeating that last one. The advantage of writing adaptive text this way is that you don’t have to separately keep track of state – the closure contains the text and tracks how many times it’s been invoked. oneOf supplies five methods currently:

  • cycling: The closure iterates over the list of snippets and returns each one in order, then goes back to the start when it runs out.
  • stopping: The closure iterates over the list of snippets and returns each one in order, then repeats the last item when it runs out.
  • randomly: The closure returns a random item from the list each time it’s called, except it will never return the same one twice in a row.
  • trulyAtRandom: Similar to randomly, except it can return the same item twice in a row.
  • inRandomOrder: Works like cycling, except the list is shuffled first. This guarantees that every item will be shown exactly once before the list repeats.

Execution time

Keep in mind: When you call one of the object methods, like cycling(), you are creating a new function. So you should declare your snippets once and bind them to a name. And, similarly to the caveat above about function versus string content, you should use them inside functions, unless you intend to run them once and then keep the result indefinitely:

poolColor = oneOf('blue', 'green', 'red').trulyAtRandom()

# This pool will always be the same colour...
situation 'mystic_pool',
    The pool shimmers with #{poolColor} light.

# ...this one will vary each time it's visited.
situation 'mystic_pool',
  content: () ->
    The pool shimmers with #{poolColor} light.

Randomness, and saves

Undum uses a particular way of retaining save games: It saves every player input, and then when a save is restored it essentially replays them in order to rebuild their game. This works perfectly well… as long as the results of every input are always the same, ie if the game is deterministic.

Of course, if you want to incorporate randomness into your game, then your game isn’t deterministic. To square that circle, Undum supplies the System.rnd object. This object is a pseudorandom number generator which Undum itself initialises. Because the save game includes the random seed, save games can work. However, this architecture requires a bit of care on the part of the author to only use the Random object supplied by Undum.

oneOf is built ot use that object, but that means you have to initialise oneOf objects that use randomness inside your function, by passing system into the factory methods:

snippets = {} = (character, system) ->
  snippets.randomColour = oneOf('green', 'red', 'blue').randomly(system)

We bind the closure to a name we can reach from our situations – here I’m making a snippets object (local to and binding my snippet to that, but I could just as well attach them to character.sandbox.

randomly, trulyAtRandom, and inRandomOrder all take a System object as an argument. If you don’t initialise them with one, they’ll work – they’ll simply use the general Math.random() pseudorandom number generator that JavaScript supplies. This means that every time a save is loaded, they’ll produce different results. This might be okay for testing, prototyping, or inconsequential text variations, but almost all of the time you want to initialise them properly with system.

Text variations are a really powerful tool, and they give you a lot of flexibility in structuring your story. With text variations, you can ensure that the story is always calling back to previous story events; allow the player to return to previous situations without repetition; and have the same situation present itself differently depending on the state of the story.

One major use of this is to merge branches in a way that flows naturally with previous story events; the “bottleneck” will look different depending on what has happened previously in the story. Another use is to insert variations into a situation that gets revisited, such as a “hub” that the player might see several times over the course of the game.

In the next part of this tutorial, we will look at qualities and what they’re good for. But first, a few parting notes:

  • oneOf isn’t just good for text; in fact, it’ll take arguments of any type. Mere Anarchy, for example, uses a similar technique to oneOf in various places, including to randomise the “sigil” images that show up at various points in the narrative.
  • The Undum documentation details how to use System.rnd, which you can use to randomise things in your own functions.
  • Are you using Raconteur or reading this tutorial? I’d love to hear about it; I can be reached on Twitter or through the forums.
  • Are you failing to use Raconteur because it’s broken in some way? I’d appreciate bug reports and issues at the Github page for the project.

Lautz of IF

Trizbort – released

by jasonlautzenheiser at April 21, 2015 01:01 AM

Released version tonight.  This released focused on a few new features and some bug fixes, but the other nice thing is it now includes bundled in the release (as well as in the main repository on GitHub), the documentation that Andrew Schultz has been working hard on.

New features in this release:

  1. Individual rooms can now have their own border style (including no border at all)….this allows for  creating rooms that might have special meaning based on their border styles.
  2. Individual connections can now have their own color.  Helps to distinguish special connections by their color.
  3. The automapper now handles UNDO a little better thanks to GitHub user matthiaswatkins.  I hope to see some more submissions from him!

Release can be found at: – note links from earlier posts may not work, this link will get you the latest version.

Source code can be found at: – don’t forget here you can submit issues or feature requests.

Hope you enjoy this release.  We have more features and improvements lined up to be developed soon.  Also be on the lookout for a new website dedicated to Trizbort (I hope to get that in the works here soon).  Enjoy!

Of course you can find the original Trizbort at  I’ve had a few chats with him and he has been very supportive and excited that some work is being done and people are continuing to use his creation.  Thanks to him for the original!


Filed under: Announcements, Trizbort

April 20, 2015

Emily Short

That Embarrassed Silence Thread

by Emily Short at April 20, 2015 08:00 PM

Pippin Barr and Robert Yang write about how they’re able to be indie game creators — and are open about how much of that depends on the support of partners who earn more.

I found both posts pretty interesting. And I get where this is coming from, this encouragement for people with creative careers to be open about how those careers are funded because it clarifies the situation for anyone thinking about entering the discipline. At the same time, sharing this kind of information runs against my established practice.

Well before I was doing anything that could qualify as professional work in games, back in the early 2000s, I was getting occasional interview requests about my hobby work, as well as some threats and romantic propositions by email, and some persistent aggression on internet forums. There was also an occasion when someone started asking my acquaintances in the IF community about how to find me because they’d decided I was the love of their life if only I could be gotten to meet them. At the time I was living with an often-absent roommate in a crime-heavy neighborhood with terrible police response times, and I wasn’t too sanguine about how I would protect myself if any of these people did show up to “meet” me.

So I was uncomfortable talking about myself because I didn’t want to help anyone find me unless I’d agreed to see them. I also didn’t care to provide more fodder for personal commentary about Why I Sucked, and I had discovered that basically any piece of information about me could be used in that way. For a long time I worked hard to keep images of me off the internet, though later that became simply impossible while also having a career where I speak in public. I now try to mitigate the effects where possible by having as non-comment-worthy a personal appearance as I’m able to achieve for myself. It still feels like ice-cream-tooth seeing my own face on a web page, even when I’ve cooperated with putting it there myself.

Most of the people I talked to about this situation said, essentially, “this is the cost of being visible and female on the internet, so you’ll just have to deal.” And back in the day, I was dealing, but that involved a fair amount of defensive silence. There were some additional people who either made fun of or chastised me for doing this, calling me paranoid or stand-off-ish, or speculating about what psychological damage might make me not want to talk about myself more in public, or that I was acting mysterious in order to make myself seem more interesting. Someone wrote a tirade about how my use of a pseudonym put him off liking my work because it “seemed sexual somehow”, which I still really really don’t get. I suppose for people who haven’t been afraid of being stalked or attacked, it’s easy to write off someone’s fear as self-aggrandizement. And even I had to admit that I didn’t think it was very likely that one of my poison penpals would escalate to showing up on my doorstep with a weapon, but it’s about expectation values, right? A low probability of assault or death still multiplies out to a risk you really want to avoid.

The second uncomfortable (if less threatening) thing I noticed was that interviewers asked me questions that I never saw being asked of men working in the same area. Was I married? Did I have children, and if so, how many, and if not, did I want them? And then some weirder, more squirrelly stuff speculating about how my (wholly invented by the questioner) romantic history probably affected the nature of the characters I was writing. There was a degree of interest in my personal life that seemed irrelevant to what I was working on, and I decided to resist this as a matter of principle. If it was a question that I didn’t think would be asked of a man who’d done the same work, then I would often refuse to answer. Once or twice people wrote to me to ask about other female members of the IF community, specifically about whether I’d met them and whether they were pretty, and I refused to get into that, too, because !?!!?.

But a lot of my reasons for silence apply to ten years ago, not to today, and questions about lifestyle are now being asked in a different context.

So, if you’re curious, for the last five years I’ve been a freelance consultant in interactive narrative, interspersed with stints working for ArenaNet and Linden Lab as an actual employee. Some of the work I do consists of writing games, or writing content for games, or giving other people advice about the games that they are writing. Some consists of giving talks about specific work I’ve done or about the uses of interactivity in general. Some involves R&D work, designing new tools and systems for game writing. The scale varies as much as the content: I’ve had client projects that took me an afternoon, and others that lasted for more than a year.

As with most consulting careers, that means that my hours and my income are variable, so sometimes I have time between jobs and sometimes I’m working nights and weekends to hit client deadlines or deal with unexpected collisions between multiple client projects. There’s a fair amount of guesswork. You do your best to keep your schedule full but without overlaps, but you can’t always control when a client is going to change parameters on a project or extend its deadline. If you’re a freelancer, what you make in a year isn’t what you happen to be charging per week times 50; it depends also on how much downtime you have, which can be hard to predict. Early in the process I set my hourly rate way too low and I had to learn that that just wasn’t viable.

There are expenses no one pays for, and time commitments you have to work in on your own. I consider blog maintenance part of my job. Going to conferences, meeting people, and building a professional network is a vital part of the process, so speaking helps a lot: conferences are expensive if you don’t hold a speaker pass, even aside from the other advantages of speaking. I now live in the UK, which means NHS and not having to self-fund insurance, which is welcome; it also means fancy accountants who specialize in ex-pat tax regulations to sort out my US and UK tax obligations, which is less fun. (If you are a US citizen, you still have to pay income tax even if you’re living full time overseas and paying income tax to the other government.)

Frankly, I enjoy this life a lot. I’ve been fortunate to work on some really interesting projects, and have been able to pay off my student loans and accrue some savings. I get to learn about a lot of different kinds of things, which for me is more nourishing — emotionally and intellectually — than working on one project for three years straight. This would be viable (at least for now) even if I weren’t married — and I was doing this work while I was still single — but being in a household that consists of two employed adults makes the whole business a lot less stressful. It would not be viable if I had young kids, I think: I travel too often, on too little notice, for it to be compatible with a lifestyle with toddlers.

I’m not trying to support myself by selling games directly. (Blood & Laurels is for sale, but it is not a primary income source for me.) Games that I write by myself I usually distribute for free, which puts me outside the “indie game author” category according to some definitions. But I do consider the work I do by myself to be part of my career, in that I’m acquiring skills or exploring design spaces that I can bring back to clients. Right now I’m working on experimental projects in multiplayer IF and in text generation. These build on research we started for Versu, or needs I ran into in past client projects, and if I have paid work in those areas in the future, what I’ve learned from those experiments should come in handy.

There might be ways to monetize some other things that I currently don’t — I’ve looked at Patreon, and considered whether it would be a good way to support some of my blog content — but at least for now I feel that it’s not a good idea. For one thing, I don’t really need it, and there are a lot of people who do. If there’s a finite supply of money that can go into supporting Patreon-funding IF and related games criticism, then that money should go to other people; I feel more of an obligation to put resources into that system, rather than take resources out.

Indie authors semi-frequently ask me how I feel about working on projects that might not be to my artistic tastes. The question is more or less tactful depending on the asker but generally comes down to “have you sold your soul? did it hurt?”

It’s true that I’ve turned a few things down, and set a few hard boundaries on projects I took, because I wasn’t interested in working on certain kinds of material. I’ve also had some clients who gave me a lot of freedom to build what I liked. But not everything has to be an expression of my own deepest Me-ness. There’s honorable and good work to be done in executing well what someone else wants or needs, assuming that thing doesn’t actually run counter to my own values. Sometimes doing commission work provides interesting challenges that I would never have encountered on my own, or gives me access to resources I wouldn’t otherwise have; sometimes a client’s surprising request becomes the sand in the oyster. The Twitter tie-in for Ultimate Quest was something a lot of my own fans weren’t keen on — and I totally understand why — but for me it resulted in some interesting design choices and player interactions that I would never have gotten to explore in another context.

I can’t say that this does or should work for everyone, but I personally have always been interested in craftsmanship and experimentation — when I’m making something, it’s not just about what I’m expressing, but also about discovering how it can be expressed — and client work is often absolutely true to that impulse in me, even if it’s telling a story that isn’t my story. There’s still room to do more personal projects on my own time, sometimes.

Finally, people sometimes ask me how they can do what I do. And here I just have to shrug, because I don’t know. I was very fortunate on multiple occasions. “Nonsense, you worked hard for a long time,” my husband says, and I grant that that was probably a necessary precondition, but it wasn’t sufficient. The other necessity was that people decided to invite me to participate where I would never have considered applying on my own. I started writing for GameSetWatch because Simon Carless asked me to. I started speaking at GDC because Dave Mark and the AI summit reached out to me. I got my first jobs and my first commissions because people who knew my name decided to take a chance on me.

It’s not exactly luck, no, but it’s nothing I did, either: it was the outreach of people who wanted to hear from someone new. So maybe my current situation won’t last, but in the meantime I intend to enjoy it, and to do what I can to amplify other voices.

April 19, 2015

Renga in Blue

Adventure II (aka Adventure 440) (1978)

by Jason Dyer at April 19, 2015 04:00 AM

There are so many variants of the 350-point Crowther and Woods Adventure that it might be consider the first heavily “modded” game.

I even have to preface by saying the 350-point version; Don Woods himself made a 430-point version in the mid-90s. The number of points possible in a particular port is the “identifying marker” for an entire family tree.

I’m not trying every version — especially since some really are just straight ports — but I think it’s worthwhile to dive into Peter Luckett and Jack Pike’s version, because the original source code is dated 31 Dec 1978. Other sources indicate it was worked on until 1981. However, the 1978 source seems complete, and the availability date makes it the earliest mod of the 350-point version of Adventure.

I’m using this port from the original source although there is a z-code version. Some comparison indicates the versions are identical except for normalizing the old-school ALL CAPS style.


Replaying when I have truly detailed notes in the form of my old posts about 350-point Adventure feels like I’m playing a find-the-difference puzzle. I’ve taken my original maps as a reference and will poke carefully at each nook and cranny for extra rooms.

Outside. This map is preserved all the way back to Crowther's version of Adventure, before Woods came along.

Outside. This map goes all the way back to Crowther’s version of Adventure, before Woods came along.

The time to a map break seems to be one step…





…but other than that description being elongated, I haven’t found any changes yet.

April 18, 2015

Choice of Games

New Hosted Game! “No Proper Thief” by Russell J. Dorn

by Dan Fabulich at April 18, 2015 01:02 AM

There’s a new game in our Hosted Games program ready for you to play! Attempt to survive your first bank heist! Befriend or betray your team of bank robbers, make difficult choices, survive, go insane, fall in love, and get rich if you can in No Proper Thief, where every choice you make has a consequence. You never wanted a life of crime, but it’s all you know. That doesn’t mean transitioning from a life as a cocky con artist to a greenhorn bank robber, on your first bank heist, doesn’t scare you. In No Proper Thief you are Clyde

Continue Reading...

April 17, 2015

Emily Short

Beneath Floes (Bravemule, Pinnguaq)

by Emily Short at April 17, 2015 10:00 PM


Beneath Floes is a folk tale of Inuit culture, created in collaboration with Inuit contributors. (There’s a browser-based play option as well, but at the time of writing, that version wasn’t serving audio well, so you may prefer the download.) Recently a Kickstarter raised the funds to have Beneath Floes translated into Inuktitut (an indigenous language of the eastern Arctic) and Anishinaabemowin.

It is both a story and a meditation on story-telling, one which starts by explaining to the reader how much is going to be under the reader’s control. Not a lot, as it turns out: you mostly get to change small details, details that explicitly don’t branch the plot, while the horrible core story is beyond the player’s capacity to change. But the effect is very different from, say, the also very linear interaction in My Father’s Long, Long Legs, or the fact-mingled-with-fiction of Coming Out Simulator 2014.

Nonetheless the small details that you’re allowed to affect are not selected arbitrarily. Does evil, in your mind, have a hooked nose or a button nose? Do you associate yourself with an indigenous hero or with Superman? Perhaps we’re allowed to make these choices because we inevitably see reflections of ourselves in the stories we’re told, no matter who the teller is. Elsewhere — a dark sort of joke — you can pick which of two strings of gibberish numbers and letters the qallunaat, the white people, have assigned you as your identifying marker; or, in another place, you can change (by one year) the date associated with an anthropological recording. History is slippery, but the fundamentals hold.

I appreciated, too, the passages where material that relies on cultural context is presented just clearly enough for someone not native to the Arctic to understand, but yet not overly explained. A favorite passage:

It’s said that your father shot a caribou and failed to kill it, but that’s one person’s belief—not a well-liked individual, either.

From context, it’s clearly a scandalous thing to fail to kill a caribou. A whole ethos is implied but not explained.

Beneath Floes is not completely linear, however. There are at least two endings that I found, and as far as I can tell, what makes the difference is what you decide about the protagonist’s willingness to do violence.

Wade's Important Astrolab

Presenting Leadlight Gamma

by Wade ( at April 17, 2015 10:16 AM

Last week I released Leadlight Gamma, a new Glulx incarnation of my 2010 Apple II-coded interactive fiction-survival horror-CRPG hybrid, Leadlight (here's Leadlight on IFDB). You can buy Leadlight Gamma for MacOS, Windows, Linux or iOS at for US$4. The game file is cross platform compatible and I offer various configurations of installer or interpreter+game bundles on the site:

15-year-old Belinda Nettle is studying at Linville Girls High School in Australia's Blue Mountains. After falling asleep in the library one afternoon, she wakes from her mundane existence into a nightmare. Her classmates are transformed, nameless terrors seek her out across the schoolgrounds, and traps and tricks threaten her life at every turn. 
Can you help Belinda survive this terror-filled night and solve its mysteries? And will there be a new day?
The game also has a standalone site at

At the core of Leadlight Gamma is a faithful port of the original game, now enhanced for modern platforms with graphic automap, tutorial mode, unlockable extra content, behind-the-scenes tour mode and easter eggs, original soundtrack, artwork gallery and an accessibility mode for vision-impaired players.

Unfortunately the accessibility mode isn't a go on Macs yet because the only Mac interpreter that can run LLG is Gargoyle, and Gargoyle doesn't work with screen readers. I plan to talk about this and the various other technical challenges to accessibility programming I've been running into and learning about in another post in the near future.


You might wonder what motivates someone to spend a long time remaking one of their games instead of moving onto the next one. I can summarise what happened like this:

A few years ago I was tossing about ideas for a sequel to the original Leadlight. It would have been all modern. No two-word parser, no Apple IIs in sight – just a brand new game. While these ideas weren't coalescing, I opened Inform up one evening and copy-pasted the description of Leadlight's first room into it to see how it looked. Before long I'd pasted some more rooms in, and I was experiencing a degree of pleasure and narcissism in being able to walk around in this world again in a new context. I got hooked on building the whole thing anew after overcoming the first engineering challenge I encountered (though I don't remember exactly what it was, now). I also realised the port would bring the game to more players, and just make it easier to get at.

So I've ended up doing a 180 on the idea I previously expressed that I had no interest in porting the game to Inform. I'd thought the 'building a ship in a bottle' feel of the original 8-bit project (for me) might be rendered invisible or pointless-feeling by taking it to a platform which could, relatively speaking, do anything. I didn't realise it would end up being another interesting permutation of the same experience. It was like building a scale model of the ship in the bottle, partly by squinting through the glass at the original ship, and partly by studying the microscopically scaled plans used to build the original ship.

April 16, 2015


Writing IF with Raconteur, part 2: choices, choices

April 16, 2015 07:00 PM

Last we left off, I had explained setting up Raconteur and writing a very basic Situation: Enough to make simple stories. This tutorial is going to delve a little deeper into using Undum and Raconteur to write more complex stories.

Background information on Raconteur.

The choices property

The situation factory that Raconteur uses will actually create a situation object that has all of the properties you pass on to it in your spec, but a good number of them are special. Today we’re going to look at four of them: before, choices, optionText, and canView. Let’s start with choices.

Last time, I showed how you could use explicit links to connect one situation to another. But there’s another way:

situation 'start',
  content: """
    You stand at the mouth of a damp, dark limestone cave. Two passages,
    left and right, stretch out into the darkness.
  choices: ['go_left', 'go_right']

situation 'go_left',
  content: """
    The tunnel narrows dramatically as you enter it, forcing you to
    squeeze in sideways between the slick limestone walls.
  optionText: 'Go left'

situation 'go_right',
content: """
    The tunnel opens up into a wide chamber, dominated by a bright
    reflecting pool.
  optionText: 'Go right'

Use this as the situations in a Raconteur story and run it, and you’ll see what happens:

A screenshot of the example game

What happened here? Raconteur and Undum have taken the list of situations you supplied in the choices property of start and used it to build a list of options that follows your situation’s content. So far, this is only a different presentation from just writing direct links. To find out what more we can do with this approach, we have to look into canView and Undum’s implicit choice feature.


Let’s make a simple edit to one of our situations:

situation 'go_left',
  content: """
    The tunnel narrows dramatically as you enter it, forcing you to
    squeeze in sideways between the slick limestone walls.
  optionText: 'Go left'
  canView: () -> false

() -> is CoffeeScript syntax for a function definition; canView is our first function. For those of you who come directly from JavaScript or other programming languages, here’s a quick refresher on CS functions:

hello_world = () -> # The parens are mandatory even if there's no arguments
  console.log "Hello, world!" # Function calls in CoffeeScript only need
                              # parens if they have 0 arguments.

hello_world() # -> Prints "Hello, world!" to the console.

echo = (argument) -> # The argument list goes inside the parens
  # Like in Python, indentation defines blocks in CoffeeScript
  argument  # CS is expression-based, so the last statement of a function
            # is also its return value.

echo "Hello!" # -> returns "Hello!"

CoffeeScript’s cleaner function syntax is one of its selling points for writing IF stories. Add the line:

canView: () -> false

To the ‘go_left’ situation, and watch what happens when you run the game. Your list of options should only show the other option – “Go right”.

Whenever Undum is building a list of choices from a situation’s choices array, it consults each situation listed to see how it should appear. It calls their optionText property to get what text it should display. And it calls their canView method, to find if it should display that option at all.

canView should return true or false. If it returns true (Or any “truthy” value), then the situation is displayed as an option.

canView, like most situation methods, is passed three arguments: The Character object, the System object, and the name of the current situation. In our previous example, we didn’t bother to define arguments for our canView method because it didn’t use any – it just returns false, always.

Character and System

Character and System are two objects that are never created or accessed directly in your code; instead, Undum passes it as an argument to various methods you define. System holds most of the methods we use to interact with Undum’s low-level API, and will be the subject of another tutorial.

Character holds most of your game state – qualities (the subject of another tutorial), and the “sandbox”. The sandbox is a general-purpose area for storing game state; initially, it’s just an empty object. We can safely modify the sandbox however we like:

situation 'start',
  before: (character) ->
    character.sandbox.hasLamp = false
  content: """
    You are standing at the mouth of a deep, dark cavern. There is a
    brass lamp here.
  choices: ['brass_lamp', 'enter_cave']

before is another property of Raconteur situations; in this case, it’s a function that gets called before content is output. It’s a good place to put any initialisation code or side-effects of entering a situation. Normally, we would set the initial values of sandbox properties inside our function – but for the sake of this example, it’s fine to put it in before. The function gets passed our usual three arguments – Character, System, and the name of the previous situation; but since we are only using the first one, we only need to define the first one – JavaScript doesn’t check that a function is called with the right number of arguments, so instead it just discards the other two.

Here are the other situations for this second example:

situation 'brass_lamp',
  before: (character) ->
    character.sandbox.hasLamp = true
  content: """
    You pick up the brass lamp and light it.
  choices: ['enter_cave']
  optionText: 'Pick up the lamp'

situation 'enter_cave',
  content: """
    You walk into the dark cave. There are two passages, to the right and 
    left; the right one glows with a strange shimmer.
  optionText: 'Enter the cave'
  choices: ['go_left', 'go_right']

situation 'go_left',
  content: """
    The tunnel narrows dramatically as you enter it, forcing you to
    squeeze in sideways between the slick limestone walls.
  optionText: 'Go left'
  canView: (character) -> character.sandbox.hasLamp

situation 'go_right',
  content: """
    The tunnel opens up into a wide chamber, dominated by a bright
    reflecting pool.
  optionText: 'Go right'

If you run the complete example, you’ll note that you can only get to the left passage if you previously picked up the lamp. “go_left” has a canView method that returns the value of character.sandbox.hasLamp, which is normally false, but gets set to true if you visit the “pick up the lamp” passage. This simple mechanic – referencing whether a previous story event happened to shut off or open up passages of the story – is the basis of what Dan Fabulich calls delayed branching.

If you’ve gotten this far, congratulations: You can now use Raconteur and Undum to write games with complex branching stories similar to ChoiceScript stories, where events earlier in the narrative can impact events later even if the branches in between were “merged”.

In fact, you can use sandbox to track more complex things than true/false conditions such as whether the lamp was picked up; you can store any value in a sandbox property. Consider the example of a dating sim: You can use the sandbox to track the feelings of the various love interests towards the player character, to decide which interactions will be available later on. You’ve officially gone beyond the point of what a pure CYOA book can do.

Before we wrap up, a few notes:

  • Situations can also provide a canChoose method; if that method returns false, then the option will be visible on an option list, but greyed out, and the player won’t be able to click on it.
  • Situations can have an after method. As the name implies, that method is just like before, but it gets called after content is printed.
  • optionText is an exception to a number of things in Raconteur: It’s not Markdown, and it can’t be a function. In fact, it’s not even html; the optionText on your situations has to be just plain text. This is an underlying limitation of Undum.
  • Sam Kabo Ashwell had a very helpful post earlier this year about hypertext IF structure, and it’s worth reading. Particularly the part about branch-and-bottleneck structures: You’re now equipped to write games with that kind of structure.
  • Join me in a few days when I’ll write about adaptive text and varying what is written to the player.

The Digital Antiquarian

Defender of the Crown

by Jimmy Maher at April 16, 2015 05:00 PM

Defender of the Crown

If you rushed out excitedly to buy an Amiga in the early days because it looked about to revolutionize gaming, you could be excused if you felt just a little bit disappointed and underwhelmed as the platform neared its first anniversary in shops. There was a reasonable amount of entertainment software available — much of it from the Amiga’s staunchest supporter, Electronic Arts — but nothing that felt quite as groundbreaking as EA’s early rhetoric about the Amiga would imply. Even the games from EA were mostly ports of popular 8-bit titles, modestly enhanced but hardly transformed. More disappointing in their way were the smattering of original titles. Games like Arcticfox and Marble Madness had their charms, but there was nothing conceptually new about them. Degrade the graphics and sound just slightly and they too could easily pass for 8-bit games. But then, timed to neatly correspond with that one-year anniversary, along came Defender of the Crown, the Amiga’s first blockbuster and to this day the game many old-timers think of first when you mention the platform.

Digital gaming in general was a medium in flux in the mid-1980s, still trying to understand what it was and where it fit on the cultural landscape. The preferred metaphor for pundits and developers alike immediately before the Amiga era was the book; the bookware movement brought with it Interactive Fiction, Electronic Novels, Living Literature, and many other forthrightly literary branded appellations. Yet in the big picture bookware had proved to be something of a commercial dud. Defender of the Crown gave the world a new metaphorical frame, one that seemed much better suit to the spectacular audiovisual capabilities of the Amiga. Cinemaware, the company that made it, had done just what their name would imply: replaced the interactive book with the interactive movie. In the process, they blew the doors of possibility wide open. In its way Defender of the Crown was as revolutionary as the Amiga itself — or, if you like, it was the long-awaited proof of concept for the Amiga as a revolutionary technology for gaming. All this, and it wasn’t even a very good game.

The Cinemaware story begins with Bob Jacob, a serial entrepreneur and lifelong movie buff who fulfilled a dream in 1982 by selling his business in Chicago and moving along with his wife Phyllis to Los Angeles, cradle of Hollywood. With time to kill while he figured out his next move, he became fascinated with another, newer form of media: arcade and computer games. He was soon immersing himself in the thriving Southern California hacker scene. Entrepreneur that he was, he smelled opportunity there. Most of the programmers writing games around him were “not very articulate” and clueless about business. Jacob realized that he could become a go-between, a bridge between hackers and publishers who assured that the former didn’t get ripped off and that the latter had ready access to talent. He could become, in other words, a classic Hollywood agent transplanted to the brave new world of software. Jacob did indeed became a modest behind-the-scenes player over the next couple of years, brokering deals with the big players like Epyx, Activision, Spinnaker, and Mindscape for individuals and small development houses like Ultrasoft, Synergistic, Interactive Arts, and Sculptured Software. And then came the day when he saw the Amiga for the first time.

Jacob had gotten a call from a developer called Island Graphics, who had been contracted by Commodore to write a paint program to be available on Day One for the Amiga. But the two companies had had a falling out. Now Island wanted Jacob to see if he could place the project with another publisher. This he succeeded in doing, signing Island with a new would-be Amiga publisher called Aegis; Island’s program would be released as Aegis Images. (Commodore would commission R.J. Mical to write an alternate paint program in-house; it hit the shelves under Commodore’s own imprint as GraphiCraft.) Much more important to Jacob’s future, however, was his visit to Island’s tiny office and his first glimpse of the prototype Amigas they had there. Like Trip Hawkins and a handful of others, Jacob immediately understood what the Amiga could mean for the future of gaming. He understood so well, in fact, that he made a life-changing decision. He decided he wanted to be more than just an agent. Rather than ride shotgun for the revolution, he wanted to drive it. He therefore wound down his little agency practice in favor of spearheading a new gaming concept he dubbed “Cinemaware.”

Jacob has recounted on a number of occasions the deductions that led him to the Cinemaware concept. A complete Amiga system was projected to cost in the neighborhood of $2000. Few of the teenagers who currently dominated amongst gamers could be expected to have parents indulgent enough to spend that kind of money on them. Jacob therefore expected the demographic that purchased Amigas to skew upward in age — toward people like him, a comfortably well-off professional in his mid-thirties. And people like him would not only want, as EA would soon be putting it, “the visual and aural quality our sophisticated eyes and ears demand,” but also more varied and nuanced fictional experiences. They would, in other words, like to get beyond Dungeons and Dragons, The Lord of the Rings, Star Wars, and Star Trek as the sum total of their games’ cultural antecedents. At the same time, though, their preference for more varied and interesting ludic fictions didn’t necessarily imply that they wanted games that were all that demanding on their time or even their brainpower. This is the point where Jacob diverged radically from Infocom, the most prominent extant purveyor of sophisticated interactive fictions. The very first computer game that Jacob had ever bought had been Infocom’s Deadline. He hadn’t been all that taken with the experience even at the time. Now, what with its parser-based interface and all the typing that that entailed, its complete lack of audiovisual flash, its extensive manual and evidence reports that the player was expected to read before even putting the disk in the drive, and the huge demands it placed on the player hoping to actually solve its case, it served as a veritable model for what Jacob didn’t want his games to be. Other forms of entertainment favored by busy adults weren’t so demanding. Quite the opposite, in fact. His conception of adult gaming would have it be as easy-going and accessible as television. Thus one might characterize Jacob’s vision as essentially Trip Hawkins’s old dictum of “simple, hot, and deep,” albeit with a bit more emphasis on the “hot” and a bit less on the “deep.” The next important question was where to find those more varied and nuanced fictional experiences. For a movie buff living on the very doorstep of Tinsel Town, the answer must have all but announced itself of its own accord.

Bookware aside, the game industry had to some extent been aping the older, more established art form of film for a while already. The first attempt that I’m aware of to portray a computer game as an interactive movie came with Sierra’s 1982 text-adventure epic Time Zone, the advertising for which was drawn as a movie poster, complete with “Starring: You,” “Admission: $99.95,” and a rating of “UA” for “Ultimate Adventure.” It was also the first game that I’m aware of to give a credit for “Producer” and “Executive Producer.” Once adopted and popularized by Electronic Arts the following year, such movie-making terminology spread quickly all over the game industry. Now Bob Jacob was about to drive the association home with a jackhammer.

Each Cinemaware game would be an interactive version of some genre of movies, drawn from the rich Hollywood past that Jacob knew so well. If nothing else, Hollywood provided the perfect remedy for writer’s block: “Creatively it was great because we had all kinds of genres of movies to shoot for.” Many of the movie genres in which Cinemaware would work felt long-since played-out creatively by the mid-1980s, but most gaming fictions were still so crude by comparison with even the most hackneyed Hollywood productions that it really didn’t matter: “I was smart enough and cynical enough to realize that all we had to do was reach the level of copycat, and we’d be considered a breakthrough.”

Cynicism notwithstanding, the real, obvious love that Jacob and a number of his eventual collaborators had for the movies they so self-consciously evoked would always remain one of the purest, most appealing things about Cinemaware. Their manuals, scant and often almost unnecessary as they would be, would always make room for an affectionate retrospective on each game’s celluloid inspirations. At the same time, though, we should understand something else about the person Jacob was and is. He’s not an idealist or an artist, and certainly not someone who spends a lot of time fretting over games in terms of anything other than commercial entertainment. He’s someone for whom phrases like “mass-market appeal” — and such phrases tend to come up frequently in his discourse — hold nary a hint of irony or condescension. Even his love of movies, genuine as it may be, reflects his orientation toward mainstream entertainment. You’ll not find him waiting for the latest Criterion Collection release of Bergman or Truffaut. No, he favors big popcorn flicks with, well, mass-market appeal. Like so much else about Jacob, this sensibility would be reflected in Cinemaware.

Financing for a new developer wasn’t an easy thing to secure in the uncertain industry of 1985. Perhaps in response, Jacob initially conceived of his venture as a very minimalist operation, employing only himself and his wife Phyllis on a full-time basis. The other founding member of the inner circle was Kellyn Beeck, a friend, software acquisitions manager at Epyx, fellow movie buff, and frustrated game designer. The plan was to give him a chance to exorcise the latter demon with Cinemaware. Often working from Jacob’s initial inspiration, he would provide outside developers with design briefs for Cinemaware games, written in greater or lesser detail depending on the creativity and competency of said developers. When the games were finished, Jacob would pass them on to Mindscape for publication as part of the Cinemaware line. One might say that it wasn’t conceptually all that far removed from the sort of facilitation Jacob had been doing for a couple of years already as a software agent. It would keep the non-technical Jacob well-removed from the uninteresting (to him) nuts and bolts of software development. Jacob initially called his company Master Designer Software, reflecting both an attempt to “appeal to the ego of game designers” and a hope that, should the Cinemaware stuff turn out well, he might eventually launch other themed lines. Cinemaware would, however, become such a strong brand in its own right in the next year or two that Jacob would end up making it the name of his company. I’ll just call Jacob’s operation “Cinemaware” from now on, as that’s the popular name everyone would quickly come to know it under even well before the official name change.

After nearly a year of preparation, Jacob pulled the trigger on Cinemaware at last in January of 1986, when in a manner of a few days he legally formed his new company, signed a distribution contract with Mindscape, and signed contracts with outsiders to develop the first four Cinemaware games, to be delivered by October 15, 1986 — just in time for Christmas. Two quite detailed design briefs went to Sculptured Software of Salt Lake City, a programming house that had made a name for themselves as a porter of games between platforms. Of Sculptured’s Cinemaware projects, Defender of the Crown, the title about which Jacob and Beeck were most excited, was inspired by costume epics of yesteryear featuring legendary heroes like Ivanhoe and Robin Hood, while SDI was to be a game involving Ronald Reagan’s favorite defense program and drawing its more tenuous cinematic inspiration from science-fiction classics ranging from the Flash Gordon serials of the 1930s to the recent blockbuster Star Trek II: The Wrath of Khan. The other two games went to proven lone-wolf designer/programmers, last of a slowly dying breed, and were outlined in much broader strokes. King of Chicago, given to a programmer named Doug Sharp who had earlier written a game called ChipWits, an interesting spiritual successor to Silas Warner’s classic Robot War, was to be an homage to gangster movies. And Sinbad and the Throne of the Falcon was given to one Bill Williams, who had earlier written such Atari 8-bit hits as Necromancer and Alley Cat and had just finished the first commercial game ever released for the Amiga, Mind Walker. His game would be an homage to Hollywood’s various takes on the Arabian Nights. Excited though he was by the Amiga, Jacob hedged his bets on his platforms just as he did on his developers, planning to get at least one title onto every antagonist in the 68000 Wars before 1986 was out. Only Defender of the Crown and Sinbad were to be developed and released first on the Amiga; King of Chicago would be written on the Macintosh, SDI on the Atari ST. If all went well, ports could follow.

All of this first wave of Cinemaware games as well as the ones that would follow will get their greater or lesser due around here in articles to come. Today, though, I want to concentrate on the most historically important if certainly not the best of Cinemaware’s works, Defender of the Crown.

Our noble Saxon hero on the job

Our noble Saxon hero on the job.

Defender of the Crown, then, takes place in a version of medieval England that owes far more to cinema than it does to history. As in romantic depictions of Merry Olde England dating back at least to Walter Scott’s Ivanhoe, the stolid English Saxons are the heroes here, the effete French Normans — despite being the historical victors in the struggle for control of England — the villains. Thus you play a brave Saxon lord struggling against his Norman oppressors. Defender of the Crown really doesn’t make a whole lot of sense as history, fiction, or legend. A number of its characters are drawn from Ivanhoe, which might lead one to conclude that it’s meant to be a sequel to that book, taking place after Richard I’s death has thrown his kingdom into turmoil once again. But if that’s the case then why is Reginald Front-de-Boeuf, who was killed in Ivanhoe, running around alive and well again? Should you win Defender of the Crown, you’ll be creating what amounts to an alternate history in which the Saxons throw off the Norman yoke and regain control of England. Suffice to say that the only history that Defender of the Crown is really interested in is the history of Hollywood. What it wants to evoke is not the England of myth or reality, but the England of the movies so lovingly described in its manual. It has no idea where it stands in relation to Ivanhoe or much of anything else beyond the confines of a Hollywood sound stage, nor does it care. Given that, why should we? So, let’s agree to just go with it.

The core of Defender of the Crown: Risk in Merry Olde England

The core of Defender of the Crown: Risk played in Merry Olde England

Defender of the Crown is essentially Risk played on a map of England. The other players in the game include three of the hated Normans and two other Saxon lords, who generally try to avoid attacking their ethnic fellows unless space starts getting really tight. Your goal is of course to wipe the Normans from the map and make of England a Saxon kingdom again. Woven into the simple Risk-like strategy game are a handful of action-oriented minigames that can be triggered by your own actions or those of the other lords: a grand jousting tournament, a midnight raid on an enemy castle, a full-on siege complete with a catapult that you use to knock down a beleaguered castle’s walls. In keeping with Jacob’s vision of Cinemaware games as engaging but light entertainments, a full game usually takes well under an hour to play, and there is no provision for saving or restoring.

From the beginning, it was Jacob’s intention to really pull out all the stops for Defender of the Crown in particular amongst his launch titles, to make of it an audiovisual showcase the likes of which had never been seen before. Shortly after signing Sculptured Software to do the programming, he therefore signed Jim Sachs to work with them, giving him a title familiar to Hollywood but new to the world of games: Art Director.

A Jim Sachs self-portrait

A Jim Sachs self-portrait, one of his early Amiga pictures that won him the job of Art Director for Defender of the Crown.

A self-taught artist from childhood and a programmer since he’d purchased a Commodore 64 just a few years before, Sachs had made quite a name for himself in quite a short time in Commodore circles. He’d written and released a game of his own for the Commodore 64, Saucer Attack, that mixed spectacular graphics with questionable gameplay (an accusation soon to be leveled against Defender of the Crown as well). He’d then spent a year working on another game, to be called Time Crystal, that never got beyond a jawdropping demo that made the rounds of Commodore 64 BBSs for years. He’d been able to use this demo and Saucer Attack to convince Commodore to give him developer’s status for the Amiga, allowing him access to pre-release hardware. Sach’s lovely early pictures were amongst the first to be widely distributed amongst Amiga users, making him the most well-known of the Amiga’s early hacker artists prior to Eric Graham flooring everyone with his Juggler animation in mid-1986. Indeed, Sachs was quite possibly the best Amiga painter in the world when Jacob signed him up to do Defender of the Crown — Andy Warhol included. He would become the most important single individual to work on the game. If it was unusual for an artist to become the key figure behind a game, that itself was an illustration of what made Cinemaware — and particularly Defender of the Crown — so different from what had come before. As he himself was always quick to point out, Sachs by no means personally drew every single one of the many lush scenes that make up the game. At least seven others contributed art, an absolutely huge number by the standards of the time, and another sign of what made Defender of the Crown so different from everything that had come before. It is fair to say, however, that Sachs’s virtual brush swept over every single one of the game’s scenes, tweaking a shadow here, harmonizing differing styles there. His title of Art Director was very well-earned.

This knight, first distributed by Jim Sachs as a picture file, would find his way into Defender of the Crown almost unaltered.

This knight, first distributed by Jim Sachs as a standalone picture, would find his way into Defender of the Crown almost unaltered.

By June of 1986 Sachs and company had provided Sculptured Software with a big pile of mouth-watering art, but Sculptured had yet to demonstrate to Jacob even the smallest piece of a game incorporating any of it. Growing concerned, Jacob flew out to Salt Lake City to check on their progress. What he found was a disaster: “Those guys were like nowhere. Literally nowhere.” Their other game for Cinemaware, SDI, was relatively speaking further along, but also far behind schedule. It seemed that this new generation of 68000-based computers had proved to be more than Sculptured had bargained for.

Desperate to meet his deadline with Mindscape, Jacob took the first steps toward his eventual abandonment of his original concept of Cinemaware as little more than a creative director and broker between developer and publisher. He hired his first actual employee beyond himself and Phyllis, a fellow named John Cutter who had been working on Activision’s GameStar line of sports simulations. Cutter, more technical and more analytical than Jacob, would become his right-hand man and organizer-in-chief for Cinemaware’s many projects to come. His first task was to remove Sculptured Software entirely from Defender of the CrownS.D.I. they were allowed to keep, but from now on they’d work on it under close supervision from Cutter. Realizing he needed someone who knew the Amiga intimately to have a prayer of completing Defender of the Crown by October 15, Jacob called up none other than R.J. Mical, developer of Intuition and GraphiCraft, and made him an offer: $26,000 if he could take Sachs’s pile of art and Jacob and Beeck’s design, plus a bunch of music Jacob had commissioned from a composer named Jim Cuomo, and turn it all into a finished game within three months. Mical simply said — according to Jacob — “I’m your man.”

Defender of the Crown

He got it done, even if it did nearly kill him. Mical insists to this day that Jacob wasn’t straight with him about the project, that the amount of work it ended up demanding of him was far greater than what he had been led to expect when he agreed to do the job. He was left so unhappy by his rushed final product that he purged his own name from the in-game credits. Sachs also is left with what he calls a “bitter taste,” feeling Jacob ended up demanding far, far more work from him than was really fair for the money he was paid. Many extra graphical flourishes and entire additional scenes that Mical simply didn’t have time or space to incorporate into the finished product were left on the cutting-room floor. Countless 20-hour days put in by Sachs and his artists thus went to infuriating waste in the name of meeting an arbitrary deadline. Sachs claims that five man-weeks work worth of graphics were thrown out for the jousting scenes alone. Neither Sachs nor Mical would ever work with Cinemaware again.

Jousting, otherwise known as occasionally knocking the other guy off his horse but mostly getting unhorsed yourself for no discernible reason

Jousting, otherwise known as occasionally knocking the other guy off his horse for no discernible reason but mostly getting unhorsed yourself.

Many gameplay elements were also cut, while even much of what did make it in has an unfinished feel about it. Defender of the Crown manages the neat trick of being both too hard and too easy. What happens on the screen in the various action minigames feels peculiarly disconnected from what you actually do with the mouse. I’m not sure anyone has ever entirely figured out how the jousting or swordfighting games are even supposed to work; random mouse twiddling and praying would seem to be the only viable tactics. And yet the Risk-style strategic game is almost absurdly easy. Most players win it — and thus Defender of the Crown as a whole — on their second if not their first try, and then never lose again.

Given this, it would be very easy to dismiss Defender of the Crown entirely. And indeed, plenty of critics have done just that, whilst often tossing the rest of Cinemaware’s considerable catalog into the trash can of history alongside it. But, as the length of this article would imply, I’m not quite willing to do that. I recognize that Defender of the Crown isn’t really up to much as a piece of game design, yet even today that doesn’t seem to matter quite as much as it ought to. Simplistic and kind of broken as it is, it’s still a more entertaining experience today than it ought to be — certainly enough so to be worth a play or two. And back in 1986… well, I united England under the Saxon banner a ridiculous number of times as a kid, long after doing so became rote. In thinking about Defender of the Crown‘s appeal, I’ve come to see it as representing an important shift not just in the way that games are made but also in the way that we experience them. To explain what I mean I need to get a bit theoretical with you, just for a moment.

Whilst indulging in a bit of theory in an earlier article, I broke down a game into three component parts: its system of rules and mechanics, its “surface” or user interface, and its fictional context. I want to set aside the middle entry in that trio and just think about rules and context today. As I also wrote in that earlier article, the rise in earnest of what I call “experiential games” from the 1950s onward is marked by an increased interest in the latter in comparison to the former, as games became coherent fictional experiences to be lived rather than mere abstract systems to be manipulated in pursuit of a favorable outcome. I see Defender of the Crown and the other Cinemaware games as the logical endpoint of that tendency. In designing the game, Bob Jacob and Kellyn Beeck started not with a mechanical concept — grand strategy, text adventure, arcade action, etc. — but with a fictional context: a recreation of those swashbuckling Hollywood epics of yore. That the mechanical system they came up with to underlie that fiction — a simplified game of Risk peppered by equally simplistic action games — is loaded with imperfections is too bad but also almost ancillary to Defender of the Crown the experience. The mechanics do the job just well enough to make themselves irrelevant. No one comes to Defender of the Crown to play a great strategy game. They come to immerse themselves in the Merry Olde England of bygone Hollywood.

For many years now there have been voices stridently opposed to the emphasis a game like Defender of the Crown places on its its fictional context, with the accompanying emphasis on foreground aesthetics necessary to bring that context to life. Chris Crawford, for instance, dismisses not just this game but Cinemaware as a whole in one paragraph in On Game Design as “lots of pretty pictures and animated sequences” coupled to “weak” gameplay. Gameplay is king, we’re told, and graphics and music and all the rest don’t — or shouldn’t — matter a whit. Crawford all but critically ranks games based entirely on what he calls their “process intensity”: their ratio of dynamic, interactive code — i.e., gameplay —  to static art, sound, music, even text. If one accepts this point of view in whole or in part, as many of the more prominent voices in game design and criticism tend to do, it does indeed become very easy to dismiss the entire oeuvre of Cinemaware as a fundamentally flawed concept and, worse, a dangerous one, a harbinger of further design degradations to come.

Speaking here as someone with an unusual tolerance for ugly graphics — how else could I have written for years now about all those ugly 8-bit games? — I find that point of view needlessly reductive and rather unfair. Leaving aside that beauty for its own sake, whether found in a game or in an art museum, is hardly worthy of our scorn, the reality is that very few modern games are strictly about their mechanics. Many have joined Defender of the Crown as embodied fictional experiences. This is the main reason that many people play them today. If beautiful graphics help us to feel embodied in a ludic world, bully for them. I’d argue that the rich graphics in Defender of the Crown carry much the same water as the rich prose in, say, Mindwheel or Trinity. Personally — and I understand that mileages vary here — I’m more interested in becoming someone else or experiencing — there’s that word again! — something new to me for a while than I am in puzzles, strategy, or reflex responses in the abstract. I’d venture to guess that most gamers are similar. In some sense modern games have transcended games — i.e., a system of rules and mechanics — as we used to know them. Commercial and kind of crass as it sometimes is, we can see Defender of the Crown straining toward becoming an embodied, interactive, moving, beautiful, fictional experience rather than being just the really bad take on Risk it unquestionably also is.

A fetching lass. Those partial to redheads or brunettes have other options.

A fetching lass gives you the old come-hither stare. Those partial to redheads or brunettes also have options.

A good illustration of Defender of the Crown‘s appeal as an experiential fiction as well as perhaps a bit of that aforementioned crassness is provided by the game’s much-discussed romantic angle. No Hollywood epic being complete without a love interest for the dashing hero, you’ll likely at some point during your personal epic get the opportunity to rescue a Saxon damsel in distress from the clutches of a dastardly Norman. We all know what’s bound to happen next: “During the weeks that follow, gratitude turns to love. Then, late one night…”

Consummating the affair. Those shadows around waist-level are... unfortunate. I don't actually think they're supposed to look like what they look like...

Consummating the affair. Those shadows around waist-level are… unfortunate. I don’t think they’re actually supposed to look like what they look like, although they do give a new perspective to the name of “Geoffrey Longsword.”

After the affair is consummated, your new gal accompanies you through the rest of the game. It’s important to note here that she has no effect one way or the other on your actual success in reconquering England, and that rescuing her is actually one of the more difficult things to do in Defender of the Crown, as it requires that you engage with the pretty terrible swordfighting game; I can only pull it off if I pick as my character Geoffrey Longsword, appropriately enough the hero with “Strong” swordfighting skills. Yet your game — your story — somehow feels incomplete if you don’t manage it. What good is a hero without a damsel to walk off into the sunset with him? There are several different versions of the virgin (sorry!) that show up, just to add a bit of replay value for the lovelorn.

As I’ve written earlier, 1986 was something of a banner year for sex in videogames. The love scene in Defender of the Crown, being much more, um, graphic than the others, attracted particular attention. Many a youngster over the years to come would have his dreams delightfully haunted by those damsels. Shortly after the game’s release, Amazing Computing published an unconfirmed report from an “insider” that the love scene was originally intended to be interactive, requiring “certain mouse actions to coax the fair woman, who reacted accordingly. After consulting with game designers and project management, the programmer supposedly destroyed all copies of the source code to that scene.” Take that with what grains of salt you will. At any rate, a sultry love interest would soon become a staple of Cinemaware games, for the very good reason that the customers loved them. And anyway, Jacob himself, as he later admitted in a revelation bordering on Too Much Information, “always liked chesty women.” It was all horribly sexist, of course, something Amazing Computing pointed out by declaring Defender of the Crown the “most anti-woman game of the year.” On the other hand, it really wasn’t any more sexist than its cinematic inspirations, so I suppose it’s fair enough when taken in the spirit of homage.

Defender of the Crown

Cinemaware wasn’t shy about highlighting one of Defender of the Crown‘s core appeals. Did someone mention sexism?

The buzz about Defender of the Crown started inside Amiga circles even before the game was done. An early build was demonstrated publicly for the first time at the Los Angeles Commodore Show in September of 1986; it attracted a huge, rapt crowd. Released right on schedule that November through Mindscape, Defender of the Crown caused a sensation. Amiga owners treated it as something like a prophecy fulfilled; this was the game they’d all known the Amiga was capable of, the one they’d been waiting for, tangible proof of their chosen platform’s superiority over all others. And it became an object of lust — literally, when the gorgeously rendered Saxon maidens showed up — for those who weren’t lucky enough to own Commodore’s wunderkind.  You could spend lots of time talking about all of the Amiga’s revolutionary capabilities — or you could just pop Defender of the Crown in the drive, sit back, and watch the jaws drop. The game sold 20,000 copies before the end of 1986 alone, astounding numbers considering that the total pool of Amiga owners at that point probably didn’t number much more than 100,000. I feel pretty confident in saying that just about every one of those 80,000 or so Amiga owners who didn’t buy the game right away probably had a pirated copy soon enough. It would go on to sell 250,000 copies, the “gift that kept on giving” for Jacob and Cinemaware for years to come. While later Cinemaware games would be almost as beautiful and usually much better designed — not to mention having the virtue of actually being finished — no other would come close to matching Defender of the Crown‘s sales numbers or its public impact.

Laying seige to a castle. The Greek fire lying to the left of the catapault can't be used. It was cut from the game but not the graphics, only to be added back in in later ports.

Laying siege to a castle. The Greek fire lying to the left of the catapult can’t be used. It was cut from the game but not the graphics, only to be added back in in later ports.

Cinemaware ported Defender of the Crown to a plethora of other platforms over the next couple of years. Ironically, virtually all of the ports were much better game games than the Amiga version, fixing the minigames to make them comprehensible and reasonably entertaining and tightening up the design to make it at least somewhat more difficult to sleepwalk to victory. In a sense, it was Atari ST users who got the last laugh. That, anyway, is the version that some aficionados name as the best overall: the graphics and sound aren’t quite as good, but the game behind them has been reworked with considerable aplomb. Even so, it remained and remains the Amiga version that most people find most alluring. Without those beautiful graphics, there just doesn’t seem to be all that much point to Defender of the Crown. Does this make it a gorgeous atmospheric experience that transcends its game mechanics or just a broken, shallow game gussied up with lots of pretty pictures? Perhaps it’s both, or neither. Artistic truth is always in the eye of the beholder. But one thing is clear: we’ll be having these sorts of discussions a lot as we look at games to come. That’s the real legacy of Defender of the Crown — for better or for worse.

Defender of the Crown

(Sources: On the Edge by Brian Bagnall; Computer Gaming World of January/February 1985, March 1987 and August/September 1987; Amazing Computing #1.9, February 1987, April 1987, and July 1987; Commodore Magazine of October 1987 and November 1988; AmigaWorld of November/December 1986. Jim Sachs has been interviewed in more recent years by Kamil Niescioruk and The Personal Computer Museum. Matt Barton and Tristan Donovan have each interviewed Bob Jacob for Gamasutra.

Defender of the Crown is available for purchase for Windows and Mac from, in the Apple Store for iOS, and on Google Play for Android for those of you wanting to visit Merry Olde England for yourselves. All emulate the historically definitive if somewhat broken Amiga version, featuring the original Amiga graphics and sound.)



SPAG Specifics: Creating, inverting and making good the detective genre

by Mark Ricard at April 16, 2015 11:00 AM

The plot and style of Jon Ingold’s Make It Good owes a lot to the Infocom classic Deadline, the game which really defined the genre. In this article we will compare these two games to see how this genre has been shaped over the last three decades.

SPAG Specifics are in-depth discussions of IF works and can contain frequent spoilers. We recommend that you first play the works discussed if you are bothered by spoilers.


Deadline coverIn 198l, Infocom had a major hit on its hand with the first two games of the Zork trilogy. Zork, however, was an adaptation of the mainframe game Dungeon. It was not an original commercial game. Wanting to see if they could repeat the success of Zork, players were surprised when they came out with Deadline. Deadline was an original game in many respects. While the original Zork games were a collaboration between Marc Blank and Dave Lebling, Deadline was the first solo game for Marc Blank. It was also the first game Infocom made outside of the fantasy genre. Perhaps most importantly, Deadline was the first game to come with “feelies”. Feelies are physical objects, articles, or papers that give background information about the story and characters. Deadline came bundled in a portfolio with a letter and an autopsy report of the victim, amongst others.

In Deadline a wealthy businessman has died in his home by an overdose. The official verdict of the police and coroner is that his death was a suicide. Others, however, are not so sure. The player character is a police detective who is assigned to go to the house of the deceased and look for signs of foul play. The player also encounters other characters who knew the deceased. The detective has only twelve hours of story time to find evidence and accuse a possible suspect, hence the name Deadline. The player of course will discover that the victim’s death was not a suicide. To win, however, you must must find motive, means, and opportunity to arrest the right suspect.

For a game from the early days of the interactive fiction format, Deadline holds up rather well. The NPCs are well developed but not deep as characters. They were innovative at the time for being able to follow their own schedule. The parser is not as good as later Infocom releases, and it lacks abbreviations for commands, such as x and z. It still contains a few guess-the-verb problems. The story for the most part is logical, and finding and analyzing evidence is straightforward. Any time you wish for an object to be analyzed, your assistant, Sergeant Duffy, will take the evidence to the lab. As a mystery, the story holds together without any major plot holes. One thing that makes Infocom’s mystery games interesting is that, unlike most puzzle games, both then and today, the puzzles rarely involve manipulating objects in a MacGyver-like fashion. Problem solving involves analyzing evidence and questioning suspects. Traditional adventure games puzzles are less common. This was a pattern that Infocom mysteries kept through Witness and Suspect. In each game, the player had to find both motive and means in order to arrest a suspect. In each game, there was an assistant who would analyze evidence for the player. And, in each game you were allowed to arrest the character when you thought there was enough evidence to convict him or her. This structure was unique for Infocom and, even more surprisingly, has rarely been used since.

The design of Deadline does have one major flaw that makes the game not only hard but unfair by modern standards: it requires the player character to be in the right place and at the right time to find important information. One has to play many times to know where and when to go, unless you use hints or a walkthrough. There is one trigger event in particular that is extremely unfair, because the timing is so tight that you can easily not know you missed the necessary event — let alone know it is necessary. Being a mystery, the solution should rely less on events outside out of the player character’s control, and more with the player’s ability to make inferences from the evidence given. Despite its flaws, Deadline is a good game and an important part of IF history.

Make It Good

Make It Good coverJon Ingold’s Make It Good clearly shows its inspiration from Deadline. The situations are similar: both involve a murder in the house of a wealthy man. In both, you have a limited amount of time to solve the mystery. There are a small group of suspects in both games that require being questioned. Both games give you an assistant who will analyze evidence for you. Despite these similarities, the styles of these two games are quite different. The player character in this game is a detective with a drinking problem who is in danger of getting kicked off the force. As in Deadline you have an assistant who will analyze evidence for you. Unlike Deadline, he treats you with contempt. In Deadline, your assistant would run any evidence you asked for into the lab. Here, if you give him an object that cannot be analyzed, he will refuse to help you. The puzzles also require a certain amount of timing. Make It Good is tough game, but it is more fair to the player than is Deadline. There are a few places were non-obvious actions are called for that may be hard for the player to think of, however it does not require any events that are so precise that one could overlook them.

The most significant distinctive of Make It Good is how it plays with what the player knows compared to the player character, who initially knows far more than the player. This is a somewhat modern gimmick that goes back to Andrew Plotkin’s Spider and Web. Ingold himself used this in his earlier games Fail-Safe and Insight. The player has to learn not only what the other characters know, but what their own character does too. It is not obvious at first, but there are certain hints early in the game. The character you play is also much more morally ambiguous than the detective in Deadline. It requires the player to do a number of things that are unethical. In many ways, this shows the modern IF community’s interest in the art of storytelling. Modern authors are more interested in exploring techniques in narrative than many of those from the early days of IF; they are also more interested in characterization. It is hard to imagine Infocom ever having a player character like the one in this game. Infidel came closer than any of their games in having a morally questionable character as a protagonist. In many ways, the story is an inversion of the typical mystery game. I believe this is intentional on Ingold’s part. It often works. In some ways it does not.

The weakest part of the story is the endgame. Having yet another surprise within the original plot twist is clever, but when you think about the facts, they do not quite fit what was discovered earlier in regards to a crucial piece of evidence. What perhaps is weakest about the ending is the fact that it leaves the plot dangling. This is perhaps intentional on Ingold’s part. The player is left to guess what would happen next — and then the game ends. Perhaps there will be a sequel someday.

What Ingold has done is take the assumptions of the mystery game genre and turned them on their head. Like most modern day interactive fiction, storytelling is as important as puzzle solving. And, similar to some modern-day designers, he tries to use different narrative techniques to experiment with the medium. But despite the unusual nature of the story, the puzzle structure is a throwback to old IF, especially Deadline. Make It Good takes the puzzle style of Deadline while at the same time trying more modern storytelling experiments of new IF. In both terms it succeeds — but also sometimes fails. Oddly enough, the part of the game that I found the weakest came from the tension between the narrative technique and the nature of the puzzles themselves, showing that sometimes these two objectives can cause problems for each other. Regardless of its flaws, Make It Good is still entertaining both as clever game and as a story.

SPAGreads: April 2015

by katherinestasaph at April 16, 2015 11:00 AM

Hi folks! Spring is always a busy time in IF, and this year is no exception:

  • Spring Thing 2015 has sprung, with a bounty of works from IF authors new and veteran.
  • The 2014 XYZZY Award finalists have been announced; you can vote until April 25, the awards ceremony is on the 26th, and we encourage you to get involved with both!
  • Speaking of late April: issue 62 of SPAG will come out the week of April 26th. Expect coverage of the XYZZYs, reviews of ParserComp and Spring Thing, features on translation, IF and music videos, and more! We’re very proud of all our contributors and their work. (Want to join them? Email us! Full submission guidelines will run next issue, but if you have an idea you want to happen, let’s talk and make it happen.)

In the meantime, please check out some of the IF-related reads I’ve enjoyed most over the past month.



Andrew Plotkin, “Various World Models in IF,” The Gameshelf

I’ll assert that 75% of the game mechanics in today’s parser IF can be found in Adventure… in rudimentary form, sure, but present. And 75% of the rest can be found in Zork.

That’s the form I grew up playing, and then writing. Not the only form, but the closest to my heart. But — when I build a different kind of game, I’m not trying to approximate parser IF in a different-shaped bottle.

Are you ready for some technical IF talk? Of course you are. This article takes aim at one common IF myth — that parser games are uniquely suited to geography, “rooms” with “objects” and “inventories” and that non-parser games are not — and blasts them to little bitty objects scattered through lots of different rooms located somewhere outside a parser game. Specifically, Plotkin discusses Bigger Than You Think and Seltani, both of which approach the problem of the world model in novel ways.

Laura Hudson on Twiny Jam

I’ve enjoyed what I’ve read on Offworld, which largely covers small, quirky, outre and largely independent games — a field that intersects with IF quite often and quite wonderfully. Here, we have a roundup of Porpentine’s Twiny Jam, a festival for Twine games written with 300 words or left. The IF world has a long tradition of jams and minicomps with such constraints — I’m an admirer of Jack Welch’s TWIFcomp, which restricted authors to 140 characters they gobbled up with aplomb — and it’s a method that wrenches remarkable creativity out of the right writer. In fact, it wrenched creative work out of about 250(!) writers. Where to start? Hudson’s curated seven of her favorites, including takes on Tarot, haiku and escape-the-room.

(Also worth reading on Offworld: Hudson’s feature on interactive-comic-gamebook author Jason Shiga, a name that might be familiar to some of you.)

Atari Podcast, “Interview with Scott Adams

Scott Adams, the author of AdventureLand and several other home-rolled games, is perhaps as responsible for getting the ’80s generation into IF as Infocom. (He’s also responsible for my favorite IF-related anecdote that’s hard to explain to outsiders.) This may not be a read, per se, but it’s great listening for those in the know.

Various, collected by David Fisher: IF Gems

The 2015 Interactive Fiction Competition deadline is… let’s call it looming. If you’re reading this, there’s a moderate chance that you’re working on your own piece, and given human nature and the nature of creativity, there’s a moderate chance that you are horribly, wall-bangingly, paper-crumplingly STUCK. Following are a few pieces, recent and old, to get you unstuck. Though this one’s not a piece per se, rather a scattering of pertinent comments from IF reviews — much like IFwiki’s Past RAIF Comments repository, minus the spam and bones of old Usenet flamewars. For those who find inspiration by serendipity — or engineered serendipity — this could be just the thing.

Danielle Goudeau, “Jump-Starting the Stalled Game,” Choice Of Games

Perhaps you’re the sort of person who best regains inspiration by working on the “inner game,” so to speak — that swamp of inner personal stuff that can either ferment or impossibly mire a creative work. Here’s how one writer overcame it; it has the benefit of an actual published work on the other side as proof.


Emily Short, “WIP Rescue

Then there are the people who best regain inspiration by concrete, practical, carved-from rock if-then solutions. (You might have surmised by the description that I’m one of them.) This piece, by one of IF’s most accomplished and prolific authors, is for you: it presents several reasons — some of which might surprise you — why pieces get stuck, and several solutions for each. Partway through, Short mentions (to dismiss) a “Swiss Army Knife of Universal Puzzle Solving”; this is the Swiss Army Knife of Universal Writer’s Block Disemboweling. It is perhaps the single most helpful IF-writing resource in existence.

SPAGreads: March 2015

by katherinestasaph at April 16, 2015 11:00 AM

Hello everyone! April’s issue is coming along nicely, and while we’ve got a lot of great content in the works, there is still room for you! We are especially seeking out reviewers for ParserComp, and artists. If this is you, please get in touch. If this isn’t you, get in touch anyway! Submission guidelines are here.

In the meantime, I’d like to kick off a new feature I’m tentatively calling SPAGreads! This will be a monthly feature, between issues, highlighting the best IF-related writing I’ve come across in the interim. Part of SPAG’S mission — the P for Preservation, if you will — is to perpetuate the tradition of IF criticism. It’s particularly important nowadays, as IF is receiving more attention than it has in years, yet attention so diffuse it’s easy to encounter only slivers of it. The bulk of these links will be new, but I’ll also include a section for older pieces worth your time, as part of “preservation” is keeping alive work from the past. Each piece will come with some commentary, as not to be a straight-up linkdump.

If you have a suggestion for a piece you think we should feature, email us! As always, we particularly welcome pieces from outside the mainstream IF press, on undercovered topics or by underrepresented authors. We accept everything from a Serious Longform Piece in the New York Times to a blurt on your blog written mostly in emoji, from the beginnings of IF to a piece so cutting-edge IT HASN’T EVEN BEEN RELEASED YET (good luck pulling that one off). Format is irrelevant, venue is irrelevant; all we care about is that it is worth our readers time.


New Reads:

Andrew Plotkin, “Trinity Design Ruminations,” The Gameshelf, February 28, 2015

It’s generally agreed that the plot logic of the ending doesn’t really hold together. In fact, my teenage self was moved to write a letter of complaint to Infocom! I received a gracious response — I think it was written by Moriarty himself — which basically said “The game ends the way we felt it had to end.” Which is unarguable. (This letter is in my father’s basement somewhere, and one day I will dig it out and scan it with great glee.)

But today I am moved to be argumentative. If I were the author of Trinity, what would Ihave done?


An exploration of the ending of Trinity and how else it might have ended, with tangents on speculative fiction, alternate history, whimsy, and all that good stuff. For obvious reasons, contains spoilers. (Also worth reading are Jimmy Maher’s deep, deep dives on the game.)

Carolyn VanEseltine, “Writing Graceful Parser NPCs,” February 9, 2015

IF authors have been struggling with NPC implementation for decades. People are complicated. They take actions and they have reactions. They have opinions and memories. They can hold conversations and have emotional responses. They are spectacularly difficult to emulate in games – especially parser games, where the core conceit is that the player can do anything and the game world will respond appropriately.


Most IF authors who want to write stories (as opposed to anything else in the can o’ worms the term comes from) run up against the problem that the most compelling thing about a story — the people — are the hardest things to implement without breaking somehow. This piece is all about elaborate ways to dodge the issue — which, in a way, is the story of programming. A follow-up, on the NPCs in Beet the Devil, is also included.

Zack Kotzer, on Rob Dubbin’s Football for Amateurs

(Vice-y clickbait title excised. Our site, our rules.)

Dubbin speaks highly of football’s ebbs and flows, and it’s one of the sport’s aspects that figures prominently in his game as well. Most of the game consists of trying to second-guess your artificial opponent—like computer chess, but with only two moves. Do you pass or do you run? Do you defend against a pass or a run? After you make your decision, a little bouncy synthetic bongo rhythm plays as two sportscasters dictate everything happening that you cannot see (which is most of the game).


Is this IF? Who knows? Dubbin co-wrote Earl Grey, which did quote well in its comp. Back in the day Z-abuse was a thing: twisting the programming of the Z-machine to implement all types of nonsense, like Tetris or golf. Some of these entered the IF Competition. But what it makes me think of is narrative: how sports, as an enterprise, is about the art of spinning a story around what’s essentially generated numbers and plays. This is what sportswriters do every day (at least, they aspire to, when they’re not churning out sports scores at 12:56 a.m. while the copy editors weep for bed), what they do at even greater scale during Big Sports Events (until they give up and talk about deflated balls), and it’s striking — to me, at least — how easily this kind of narrative dissolves.

(I guess a disclaimer should go here: this isn’t out yet, but I’ve played it — at the IF  meetup, in fact. It is unusually compelling.)

Emily Short, “Choose Your Erotica,” February 18, 2015

Parser-based AIF — “adult interactive fiction” — has been around for a long time, though it has generally had its own forums and meeting places; every once in a while someone would turn up on with a coding question about layered clothing, or submit an adult game to a competition, but for the most part AIF didn’t overlap much with the main IF community. I did play a few pieces, but they were usually aimed unambiguously at heterosexual men. A common structure was to have a series of puzzles that would “unlock” sex scenes with assorted partners. (Here’s a review I did back in 2006 of Ron Weasley and the Quest for Hermione, for instance.) Sometimes these were cut-scenes, but sometimes you could use parser commands to do a play-by-play of which parts went where.

As choice-based IF has become more prevalent, so has choice-based, female-POV erotica. Here I take a look at several.

If writing characters in IF is difficult, writing characters in IF who have sex in IF would seem near-impossibly; even in static fiction, take one misstep and you’re up for a Bad Sex Award. Nevertheless, people are still (ahem) doing it, and often, doing it in Twine. There’s something to this; as Short argues, erotica is not particularly well-suited to parser IF without judicious fades to black or, conversely, full-on leaps into Stiffy Makane satire.

Flourish Klink, “Notes Toward Text Pad,” March 1, 2015

Steve Zultanski, who is a generally hoopy frood, wrote a book called Pad that (asDerek Beaulieu says) “foregrounds the masculinist tendencies of experimental writing.”

That is, it’s a book in which Steve lifts, or tries to lift, every item in his apartment with his dick. (His word.) You can watch a recording of him reading from it at the Bowery Poetry Club.

Of course I had the brilliant idea that this should be a text adventure.

Speaking of Stiffy Makane leaps, how’s this for a game idea? Text Pad is not a text adventure, but it is a transcript, and I am posting it because I want you to go read it right now. (I guess it’s time for another disclaimer: I saw her at a talk the other day, she mentioned this, and I spent the next five minutes or so giggling because I am secretly ten years old and some days this is my favorite album.) For any aspiring programmers: A) Please do this. B) Please send me the beta testers’ notes so I can publish them.

(NOTE: This piece is, unquestionably, NSFW. For obvious reasons.)

Old Reads:

Tobias Carroll, “The Only Thing Worse Than Bad Memories: Playing and Reading Thomas M. Disch’s Amnesia,” Hazlitt, Oct. 22, 2013

One of Amnesia’s most challenging aspects—or one of its most frustrating ones—is Hollings’s own stamina. Go too long without food or rest and he’ll find himself passing out; pass out and he’ll soon be arrested, tried, and convicted. But as he’s awaiting execution, Hollings will suddenly have an epiphany: a memory returns that could exonerate him, and which casts much of the ambiguity he’d previously encountered in a new light. This newfound knowledge did nothing to prevent Hollings’s execution from going forward. It was a devilish choice, as storytelling goes; it was also the sort of narrative moment that is most effective in the context of a video game. Perhaps most of all, though, it was a deeply literary choice—the kind of moment that could only come from a novelist working in a different type of media, helping push it towards new realms of possibility. For all that gaming today has expanded to include a wider variety of narratives, from ones where roaming a landscape is eminently rewarding to those where taking a step outside of a preordained path can end a game, Amnesia’s legacy points to a different sort of satisfaction: the kind that can come from a more controlled, authorial experience.


A nice exploration, from a literary perspective (this ran on Penguin Random House’s blog), on an older detective adventure (its successors include Make It Good, among others). It’s hard to overstate just how expansive this is; recently I was working on a piece, stopped in despair as I realized I’d have to implement all of Manhattan, and then despaired some more when I realize someone else already did it! To acclaim!

Carmen Maria Machado, “Why Alice Munro Should Play Gone Home: The Video Game as Story and Experience,” Los Angeles Review of Books

The way that detail is used in Gone Home is utterly masterful. Even dyed-in-the-wool book-based writers and readers can learn and be enriched by the way that each new piece of information recasts the story again and again. There’s little place for straight exposition — nowhere except the occasional note from the sister to keep you on track. You are almost entirely required to read the story in the spaces between the details. This is not an experience for an unsubtle or impatient gamer/reader. Every movement brings about a new revelation of character, of story, of atmosphere. At times, truth intersects above the characters’ heads: unseen to them, but not to you. The found artifacts feel and look real. You struggle to read the ancient, spidery handwriting of Uncle Oscar, you laugh out loud at the irreverent wit of Sam and Lonnie. The notes between them don’t feel like an adult’s conception of teenage girls swapping notes—they feel like an actual teenage exchange you’ve stumbled across by accident, evidence of their spark and smarts and pain. The story plucks emotional triplines, carefully takes your heart apart brick by brick.


I’m a huge fan of LARB, particularly when they use their space to go beyond the churn of new fiction into obsessive luxuriant digressions in all directions, one of which is IF. As the title implies, this piece is largely about Gone Home, which is juuuuuust on the border of what’s IF and what’s not (as I draw that border, rather); but crucially, it’s about Gone Home as a piece of interactive fiction, referencing pieces as canonical as Photopia and Curses to more outre, more hypertext works like Geoff Ryman’s 253 and Judy Malloy’s l0ve0ne (like most early experiments of its sort, so adrift in today’s Web that it has under 3,000 Google hits!) Some of the IF-particular stuff might strike enthusiasts as 101-level, but nevertheless this is the sort of thing I’d give my teeth to publish (hint hint, aspiring pitchers).

Andrew Plotkin, Adam Cadre and Lucian P. Smith, “Roundtable: The Art of the Puzzle,” XYZZYnews, issue 14

I make no secret of admiring XYZZYnews, and their archive is crucial for anyone interested in the history of IF. (As, ahem, is ours. But I digress.) One of the all-time classics: three IF designers at their peak, and designers known for their expertise in designing puzzles, sharing thoughts on it. A must-read for anyone interested in puzzle design.

The Year that Was

by katherinestasaph at April 16, 2015 11:00 AM

Sentiment on the Internet seems to be that 2014 was a bad year. Perhaps so. In IF-land, however, 2014 was one of the most exciting years in a decade that’s been full of them. Simply put, IF’s hasn’t had this large an audience and this vibrant a field of creators since the 1980s. A brief rundown of The Year that Was:

February 14: IndieCade East enters its second year at the Museum of the Moving Image in Astoria, Queens. (The author, who lived in Astoria for years, takes a perverse sort of pride in the fact that New York’s IF events these days, largely take place in Manhattan and Queens, and not in Brooklyn.) While not an IF-only event, interactive fiction or IF-adjacent works showcased included Elegy for a Dead World, Ice-Bound and the excellently titled Sext Adventure.

April 6: The 18th annual XYZZY Awards ceremony was held, as always, on ifMUD! Some facts about the 2013 XYZZYs:

2013 is the second year in a row, after 2012, in which the majority of XYZZY Award winners were women. Part of this can be attributed to the rise of Twine – but not all; Coloratura and Olly Olly Oxen Free are both traditional parser works.

2013 is the year of the coolest thing ever: the acceptance speech for Trapped in Time, a PDF CYOA, was also a PDF CYOA. This is a fact. It is in no way opinion.

2013 has the best out-of-context Best Individual Puzzle, dethroning Violet’s  “disconnecting the Internet” (oh, how puzzling):  “creating the meat monster,” from Coloratura. This also is a fact. Indisputable, cold fact. Nothing about it is opinion.

May 11: Results came in for Spring Thing, an annual competition traditionally intended for longer, more experimental, critically meaty works – a preview of Aaron Reed’s epic Blue Lacuna lived there, as did Victor Gijsbers’ The Baron. 2014 was no exception: winner The Price of Freedom was polished, expansive in story, and part one of an ambitious trilogy — something surprisingly rare in the IF world. Spring Thing’s returning next year as a festival and showcase; and if you are reading this, there’s still time for you to concoct an idea!

July 6: Interactive fiction, according to The New York Times, has a moment. As we all know, interactive fiction has had a lot of moments! You’ve read about several here. But this year, IF was so presumably momentous to merit a mention in the Grey Lady; despite a baffling swipe at one author’s prose from a writer who thunk the clunker “Interactive fiction, which once went by the name ‘text adventure’,” it was a hard-won piece of visibility for IF in one of the most prestigious outlets in the world. And it wasn’t the NYT’s only time this year covering IF; the New York Times Magazine ran a full-length piece on Twine in November.

July 31: 80 Days, a piece by Inkle, is released for iOS (its Android counterpart arrived in December); it’s one of the rare IF works to receive widespread critical acclaim, even being praised by The Telegraph as one of the best novels of the year. (That’s novels. As in, DeFoe, James, Austen stuff.)

September 13: Boston’s Festival of Independent Games has traditionally been a haven for IF enthusiasts (who tend to be independent and into games); this year featured a live playthrough of IFcomp winner Coloratura and tutorials in Inform and Twine.

October 30: Hadean Lands, Andrew Plotkin’s five-years-in-the-making magnum opus, is finally released. It’s by far the most expansive piece of interactive fiction the scene’s seen in years, and the sort of alchemy of worldbuilding and puzzlecrafting that’s not just difficult, but Zarfian-difficult, to get this right.

November 8: WordPlay, run by the Hand Eye Society, enters its second year in Toronto. Every year the IF community has something like a summit, and this year Canada was it; the event featured a live reading of Aisle, premieres of works by Deirdra “Squinky” Kiai and Porpentine, a talk by Plotkin on the aforementioned Hadean Lands and an entire, usually-packed room showcasing IF and IF-adjacent works, of all kinds.

November 16: The Interactive Fiction Competition announces its winners. 42 authors entered – historically, a high-water mark – and the top five was remarkably diverse: Hunger Daemon, a traditional Lovecraftian-lampoon parser work; Creatures Such as We, a space dating sim using ChoiceScript; Jacqueline, Jungle Queen!, a parser romp made in Quest; AlethiCorp, a surveillance satire with an entire Web interface; and With Those We Love Alive, a multimedia-enhanced Twine piece. They’re all beyond worth your time.

December 22: Twine 2.0, the long-awaited second release of the hypertext tool, is released. Long in the works – it was previewed at No Show Conference in 2013 – the new system notably adds browser-based support for creating Twine pieces.

Issue 61.5: Letter from the Editor, Masthead, and Call for Submissions!

by katherinestasaph at April 16, 2015 11:00 AM

Today is Groundhog Day. I’ve been holed up in a coffee shop in New York all day, and for the past several hours all that’s been visible out the window is static-thick snow; I can’t imagine what a groundhog, with its slush-eye view, would see. Now Groundhog Day, the movie, is a rather IF-like conceit: if at first you don’t succeed, try, try forever until you win the story; perhaps no movie except Run Lola Run has been the source of more IF comparisons. So really there was no better day to officially relaunch SPAG!

We’re biased at SPAG, in that we’ve worked for several decades(!) now toward the preservation of IF; but we believe that interactive fiction is one of the most dynamic artforms out there now. Never before have there been so many authors working in so many different forms, pushing the limits of what IF can be and how it can reach people. The medium truly is, in the perhaps regrettable words of the New York Times, “having a moment”; and we want to be there to help shape and document it.

For our relaunch, we’re bringing you a mini-issue, containing:

a SPAG Specifics entry by the ever-thoughtful Victor Gijsbers!

a brief review of the Year that Was by your editor-in-chief!

– The letter from the editor you’re currently reading. Mathematically speaking, that means my verbiage takes up a whopping two-thirds of this issue, so without further editorial ado I’ll turn it over to the part you’re really here for.


SPAG has been a one-man show for most of its existence, an era that ends today. If you’d like to get involved in SPAG on the editorial level, please get in touch! Here’s who you’ll be working with, either way:

Editor-in-Chief: Katherine Morayati

Katherine Morayati is an IF author and critic; her credits include Broken Legs (second place, 2009 IF Competition) and a swath of other, smaller works and reviews. In her other life, she’s a music critic who writes as Katherine St. Asaph and helps run a mini-constellation of blogs.

Managing Editor: Matt Carey

Matt Carey is a longtime IF follower and the author of a number of acclaimed (pseudonymous) works, both parser and Twine; he’s also the former editor of the science-fiction zine Labyrinth Inhabitant.

Senior Editor/Webmaster: Dannii Willis

Dannii Willis is the previous editor of SPAG, the maintainer of Parchment and the developer of Kerkerkruip. He hopes to one day produce a work of IF himself, but for now his creativity is directed toward the ones and zeros of technology.


The next full issue of SPAG will come out in April! and its theme will be: Society/Preservation/Text/Adventure. Interpret this theme as strictly or as loosely as you’d like, and feel free to deviate, or not, as you will. Some ideas, to guide you — perhaps you’ll think of more:

SOCIETY: Interviews with IF figures, prominent, niche or otherwise interesting; guides to setting up IF-related events in your city; outreach; coverage of local events; parts or whole of the IF community, whether writing or dev communities; compelling personal essays if you’ve got those sort of chops.

PRESERVATION: The storage and rediscovery of older IF works, either within the IF community or Internet archival efforts; the canon, and everything surrounding; efforts to re-release adventure and/or IF works; replayability/rereadability.

TEXT: IF’s crossover into other literary forms, such as poetry, flash fiction, scriptwriting or traditional hypertext; the art and science of writing IF prose; IF in translation; books and IF; static fiction authors’ involvement, hypothetical or not, in IF.

ADVENTURE: Puzzle design; design tutorials; IF and the graphic adventure community; experimental IF; adventures in the still-largely-uncharted land that is commercial IF; generally, a catch-all for whatever weird, niche or enthusiast ideas you may have.

OTHER, NON-THEME STUFF: Did I mention “design tutorials”? We want those. Another thing we want: traditionally, since its inception in 1996, SPAG has run reviews of interactive fiction, particularly the entrants in the annual IF Competition. It’s never been the only contender in this arena; Usenet gave way to IFDB gave way to forums and blogs. So to avoid spewing into a flood of spew, we are going to look for two specific kinds of reviews:

  • SPAG Specifics. In-depth reviews of a piece, preferably about one salient aspect. Why is this good? How does it work? Victor’s piece, in this mini-issue, is a nice guide.
  • Super-brief capsule reviews of the comp field. Fun is good, irreverent is good, supportive is good. Christopher Huang’s Breakfast Review is the crème de la crème (in coffee, with a pastry) of this sort of thing; while I don’t advise you rip off his gimmick, that’s what we’re looking for here.

Send all pitches to, along with a brief bio of yourself, and writing samples if you prefer. Also appreciated: a rough sense of word count (we’re an online publication and flexible, but we’re probably not gonna run 50,000-word novellas, nor 140-character tweets, unless stated above) and an estimated time of completion (aim for February or March, leave time for line edits, follow your gut.)

We highly encourage submissions from experienced IF critics as well as newcomers, and we are particularly interested in applicants who are under-represented in IF writing. However, all are welcome, including those who have previously expressed interest in writing for the website. To paraphrase a call for submissions from one of my old haunts: We are not so interested in anything you have ever written anywhere ever. All we care about is how well you can play our game.


There’s really no place to plug social media links while maintaining the flow of an article, so I’ll put it here: we are on Twitter, at @spagazine! Follow us, retweet us, swell our numbers to the trending heavens.

Emily Short

Interactive Narrative GDC Talks (Part 3)

by Emily Short at April 16, 2015 11:00 AM

Previously 1 and 2. Here are a few more — the last set, for now, though I note that the GDC Vault has made a lot of past years’ material free, so I may go back and dig out some recommendations from those as well.


Microtalks 2015, Richard Lemarchand, Emily Short, Lisa Brown, Matt Boch, Naomi Clark, Tim Rogers, Holly Gramazio, Celia Pearce, Cara Ellison, Rami Ismail. (Recorded talk.) This includes me talking about why everyone should play tabletop storygames. It also contains hilarious microgame concepts, some beautiful reflections on intimacy in play, art in games, recommendations about workflow, and reflections about how badly games reach out to non-English speakers. This was an enormously fun session to be part of.

The Design in Narrative Design, Jurie Horneman. (Slideshow only.) Jurie makes the case for how systems design and narrative design must be integrated, which is something of a hobby-horse of mine as well.

Computers Are Terrible Storytellers — Let’s Give Humans a Shot, Stephen Hood. (Slideshow with notes.) Addresses limitations in computer-based story-telling, and looks at card-based storytelling games, tabletop RPGS and (yay) storygames again. Gets into more detail about Fiasco than I had time to in my microtalk, and talks about how these relate to their game project Storium.

Sibyl Moon Games

SPAG (and a vacation announcement)

by Carolyn VanEseltine at April 16, 2015 10:01 AM

I’m going on vacation for the next week. If you’d like something IF-related to occupy you in the meantime, how about checking out the current and back issues of SPAG?

SPAG Magazine is an old and honorable publication focused on promoting interactive fiction. It’s been around in one form or another since 1994 (that counts as old around these parts!) and though it was on hiatus from 2011 to 2015, it’s now starting up again under a more formal structure, with Katherine Morayati (Broken Legs, 2009) as the editor-in-chief.

Also, SPAG is looking for submissions. To quote from their about page:

In the past SPAG had a big focus on reviews, but as there are now many websites hosting reviews (such as the IFDB), we want to focus on articles that analyse and synthesise the ideas of the IF world. If you like the sound of that and would like to write for SPAG, please contact us, we’re always looking for more authors!

See you next Thursday!

April 15, 2015

Renga in Blue

Places related to the All the Adventures project

by Jason Dyer at April 15, 2015 11:00 PM

All the Adventures has been continuing apace, but I thought I’d take a moment to mention other places that are useful to visit because they have similar goals.


Gaming After 40

This blog is probably the closest in terms of games played to what I’m doing now — the author has plowed through nearly every TRS-80 game out there. Walkthroughs are included. Oddly, it means I haven’t read it much because I’ve been avoiding spoilers, but I did find their How To Emulate the TRS-80 Model I/III post helpful.

The Adventure Gamer

This isn’t “ALL the adventures” because it’s skipping text adventures. It has a fairly thorough treatment of graphical adventure games that’s sort of a blog version of a Let’s Play. There’s also a rating system, so if you dislike my allergy to applying numerical scores to things you can get your fix over there.

The Stack

This blog is probably the closest cousin to mine in my attempted writing style (small, trenchant observations rather than replication of everything that happened in a particular game) and also covers some very old adventures, like Time Zone.

The Digital Antiquarian

No computer gaming blog anywhere matches Jimmy Maher’s depth of historical research; he’s also surveyed quite a few adventure games through his blog’s history.


The Classic Adventures Solution Archive

The folks over here seem to be determined to play (and write walkthroughs for) every classic adventure game, no matter how obscure.

Interactive Fiction Database

This is a mindboggling comprehensive and well-organized catalog of interactive fiction, with plenty of helpful links. Some of the commercial work from the 1980s seems to be missing, but combined with The Classic Adventures Solution Archive nearly everything is covered.

Museum of Computer Adventure Game History

This site has a plethora of original cover art and documentation (both useful in my own quest).

The Internet Archive

The Internet Archive seems to have everything about everything, but I’ve found it most useful for finding old books and computer magazines of the time (including type-in adventures).


Any sites I’m missing?

In a related question, often my writing leans towards short posts like The Stack but occasionally I go a bit longer, like The Adventure Gamer. What do people prefer?


Announcing Raconteur

April 15, 2015 07:01 PM

Raconteur is “Undum with batteries included.” Historically, developing for Undum has meant doing a lot of your own tooling; writing tools to enable you to write your game. Undum’s flexibility and power have made it the engine that drove some of the most significant works in IF (The Play, Almost Goodbye). But it has always been relatively inaccessible. Undum is not the system of choice for writing straightforward hypertext games; it’s a challenging system to learn and use that demands the author build their own engine on top of it to drive their game logic.

Raconteur is a descendant of a library I wrote for my own use to write Mere Anarchy. I’ve polished it up (a bit; there is still work to be done) and given it a name, because I want there to be more Undum stories out there.

Raconteur is a library of Undum tools that can get someone writing their story quickly. It tries to push Undum in the direction of Inform 7 and Twine, a system that puts the prose front and center.

Undum will never be quite as easy to use as Twine – Raconteur itself introduces some complications for the less technically-minded (It depends on Node.js, for one thing). But it’s an attempt at averaging out the power and flexibility of Undum with the ease of other systems. And for IF authors (or aspiring IF authors) who know a bit of web development, it’ll be a very familiar set of tools.

What it Does

Raconteur’s heart is a new way of defining situations, Undum’s equivalent of Twine’s passages or ChoiceScript’s scenes. This new situation prototype is paired with a new API to allow writing Undum games in a style that resembles Twee/ChoiceScript more:

situation 'pulpit-shop',
    content: """
    # Summer: Mr Pulpit & Co, Purveyors

    A profusion of odd junk lines the shelves, high up and out of reach. The
    room is narrow like a spite house, bisected by a hardwood counter. An
    antique cash register, set aside for a real one. Mr Pulpit, himself narrow,
    has a shopkeeper's smile from behind the counter.

    [Tell him what you need.](tell_him)

You write content in Markdown, not html. Using CoffeeScript (Or ECMAScript 6, if you’re into that) instead of plain JavaScript, you get cleaner syntax and Ruby-style text interpolations that let you insert arbitrary expressions into your text:

situation 'counting_money',
    content: (character, system) -> 
        [gp, sp, cp] = calculateCoins(
        You count your money. You find that you have #{cp} copper pieces,
        #{sp} silver pieces, and #{gp} gold pieces.
    choices: ['#continue_adventure']

Wherever possible, Raconteur treats code that produces text as text. There’s no separation between situations that just print some static text, and situations that print dynamic text.

Added to that is a set of tools for generating adaptive text (Similar to Inform’s [one of] functionality), defining html elements with specific attributes to reuse in text, and some common hypertext functions.

state_statement = 
    oneOf('The machine is quiet.', 'The machine hums.').cycling()

situation 'laboratory',
    content: """
        #{span('The machine hums.').id('machine_state')} It has a big red
        #{a('switch').replacer('machine_state')} on the side of it.
        machine_state: (character) ->
            character.sandbox.machineOn = !character.sandbox.machineOn

What’s Included

Raconteur’s actual source distribution, on Github, is really only meant for people who want to develop Raconteur itself. For now, the way to get Raconteur is through the game scaffold which contains the following pieces:

  • A set of scaffold files that you can edit to start building your game right away; unlike the example game that shipped with Undum, they are mostly blank and more explanatory.
  • A Gulpfile (Which is similar to a Makefile or a Rakefile), which configures the gulp build system to automagically build and package your game, and even start a server so you can view it and test it on your local machine or anything else on the same wi-fi network.
  • A package.json file which lists dependencies. This allows you to do npm install from the scaffold and have everything you need in place.

Where it’s Going

Raconteur is still in an experimental state. It’s usable, however; you can download the scaffold right now and start playing with it or even building games.

Over the next few weeks, I’m going to be posting a series of tutorials on writing Undum games with Raconteur, as well as a more navel-gazing explanation of why Raconteur exists, on my own IF blog. You can reach me through Twitter, Github, or

Emily Short

Inform extension updating

by Emily Short at April 15, 2015 05:00 PM

I’ve set aside a couple of days this week to work on a problem that I understand to be a concern for a number of authors, namely that there are various very useful Inform extensions that have never been updated to be compatible with 6L38.

I’ve already made updates to the following, so that they either already have been or soon will be submitted to the Inform Public Library (the repository that holds 6L38-compatible extensions and allows them to be installed and managed directly within the IDE, though you can also browse it less attractively online):

Simple Graphical Window
Title Screen
Scheduled Activities
Consolidated Multiple Actions (being beta-tested before submission, as it’s complex)
Hypothetical Questions (also being beta-tested)

I’ve also done some minor tweaks to Postures and Approaches, both of which had been updated but were presenting difficulties for some users.

It’s hardly practical to try to address all extensions that aren’t yet converted, but if people have particular requests that are serious stumbling blocks for them, then please let me know and I’ll try to fold these into my schedule. I’d like to direct my attention especially towards things that either a) someone is using and the need for that extension is preventing them from updating to the current Inform version or b) someone would really like to use in a current 6L38 project, but can’t. (As opposed to “I was browsing the extensions website and this old extension looked kind of interesting in theory even though I have no actual plans to run it at the moment and so far as I know neither does anyone else.”)

If it helps, the older extensions site is here. You may also like to look at a description of how to do basic updates for 6L02 (which usually also works for the current version 6L38) or forum thread explaining how extension filing works.

I should also add that we have volunteers working on a system for a more systematic storage of multiple extension versions, etc.