Planet Interactive Fiction

June 24, 2016

Sibyl Moon Games

Design notes for Always Dog and Not-Your-Person

by Carolyn VanEseltine at June 24, 2016 05:01 AM

Like Five Gods Exiled, Always Dog and Not-Your-Person is a backburnered WIP that I’m bringing out for the Bring Out Your Dead semi-jam.

Always Dog and Not-Your-Person was an attempt to capture the inner spirit of being a dog. It is a game with 7 commands that all mean “vomit” (not to mention a variety of other biological necessities), so I am confident that I accomplished that goal.

Skip to the chase: Always Dog and Not-Your-Person



I started working on this game in January 2016 as a submission to the Ryan Veeder Exposition for Good Interactive Fiction. But time got short, and when I realized I couldn’t get it done, I felt so embarrassed about the state of its completion that I didn’t want to submit it (even though an email update assured us that unfinished games were okay.)


The premise: you are a dog, and for the first time ever, you have a dogsitter. Your goal is to have a fun, enjoyable time during the three days your person is gone (just like it is every day, even when your person is there – because after all, you’re a dog.)

Always Dog is a resource management game rather than a puzzle game, so “fun” and “enjoyable” are technical terms. “Fun” is a measurement of things you do that make you happy, such as squeaking a squeak toy or chasing a rabbit, while “enjoyment” is a measurement of things others do that make you happy, such as giving you pats or giving you a dog treat.

It is possible for things that are not enjoyable to happen, such as getting yelled at or having to go to the vet. These things are (distressingly enough) occasionally linked to fun things. For example, if you eat a dead bird (fun!) while the dogsitter is watching, you will likely get yelled at (unenjoyable) and you might throw up (value-neutral) which could result in a trip to the vet (unenjoyable).

The lesson here: only eat dead birds when the dogsitter isn’t watching.

Other stats in the game include health, hydration, bladder, satiation, and bowels. They all work about like you would expect, but if you’re super curious, I’ve posted the source code.


This game contains 12 rooms and 50+ dog-specific verbs, all implemented to one degree or another. Of particular note, the map is rebuilt to represent dog awareness (no compass rose here!) and EXAMINE is, of course, a synonym for SMELL.

You can bark to summon Not-Your-Person from room to room, and Not-Your-Person will occasionally comment on your behavior. In the original plan, you would receive a translated, timestamped list of Not-Your-Person’s commentary at the end of the game. The debug command COMMENTARY will give you a sneak peek at those results while the game is running.

Major things unimplemented: Time progression. NPC reactions (based on the stats Concern, Affection, and Trust). Events and plot. The big things.

But you can SQUEAK a fuzzy toy, should you find one. Because that is the true meaning of Being A Dog.

Here it is, Ryan! Happy belated birthday.

June 23, 2016

Choice of Games

All of our games are 25% off or more in Steam’s 2016 Summer Sale

by Dan Fabulich at June 23, 2016 07:01 PM


All of our Steam apps are 25% off or more until July 4!

We’ve also introduced a bunch of new bundles on Steam. Buy our games in a bundle and you can get them for an additional 25% off or more, on top of the discounts available in Steam’s Summer Sale!

All of these bundles are “Complete the Set” bundles, which means if you’ve purchased some of the games in the bundle, you can still complete the bundle at a discounted price.

The “Every Game” bundle is especially interesting because as we add new games on Steam, we’ll add them to the bundle, allowing you to complete and re-complete the bundle each time a new game comes out, rewarding our most loyal customers with our best possible savings.

Hosted Games has a few bundles, too, including an “Every Game” bundle:

(Note that we can’t create bundles including games from both Hosted Games and Choice of Games, so if you want all of Paul Wang’s games, you’ll need to buy both the “Paul Wang” bundle and the “Infinity Series” bundle.)

Affairs of the Court: Choice of Romance on Steam

by Dan Fabulich at June 23, 2016 07:01 PM

Affairs of the Court: Choice of Romance

We’re happy to announce that one of our bestselling games, Affairs of the Court: Choice of Romance, is now available on Steam for Windows, Mac, and Linux. (It’s still available on iOS and Android, too.) It’s 17% off on Steam until July 4th!

Plunge into court politics and change the course of history, or pursue a love affair that rocks the kingdom to its foundations!

Affairs of the Court is an epic interactive fantasy novel by Heather Albano and Adam Strong-Morse. It’s a tale of romance, deception and court intrigue, where your choices control the story. The game is entirely text-based–223,000 words, without graphics or sound effects–and fueled by the vast, unstoppable power of your imagination.

Will you play as male or female? Gay, straight, or bi? Match wits with the schemers of the court, or play your suitors off each other? Will you find true love? Gain a crown? Lose your head?

Buy it today!

The Digital Antiquarian

Acorn and Amstrad

by Jimmy Maher at June 23, 2016 06:00 PM

…he explains to her that Sinclair, the British inventor, had a way of getting things right, but also exactly wrong. Foreseeing the market for affordable personal computers, Sinclair decided that what people would want to do with them was to learn programming. The ZX81, marketed in the United States as the Timex 1000, cost less than the equivalent of a hundred dollars, but required the user to key in programs, tapping away on that little motel keyboard-sticker. This had resulted both in the short market-life of the product and, in Voytek’s opinion, twenty years on, in the relative preponderance of skilled programmers in the United Kingdom. They had had their heads turned by these little boxes, he believes, and by the need to program them. “Like hackers in Bulgaria,” he adds, obscurely.

“But if Timex sold it in the United States,” she asks him, “why didn’t we get the programmers?”

“You have programmers, but America is different. America wanted Nintendo. Nintendo gives you no programmers…”

— William Gibson, Pattern Recognition

A couple of years ago I ventured out of the man cave to give a talk about the Amiga at a small game-development conference in Oslo. I blazed through as much of the platform’s history as I could in 45 minutes or so, emphasizing for my audience of mostly young students from a nearby university the Amiga’s status as the preeminent gaming platform in Europe for a fair number of years. They didn’t take much convincing; even this crowd, young as they were, had their share of childhood memories involving Amiga 500s and 1200s. Mostly they seemed surprised that the Amiga hadn’t ever been all that terribly popular in the United States. During the question-and-answer session, someone asked a question that stopped me short: if American kids hadn’t been playing games on their Amigas, just what the hell had they been playing on?

The answer itself wasn’t hard to arrive at: the sorts of kids who migrated from 8-bit Sinclairs, Acorns, Amstrads, and Commodores to 16-bit Amigas and Atari STs in Britain made a much more lateral move in the United States, migrating to the 8-bit Nintendo Entertainment System.

More complex and interesting are the ramifications of these trends. Because the Atari VCS console was never a major presence in Britain and the rest of Europe during its heyday, and because Nintendo arrived only very belatedly, for many years videogames played in the home there meant games played on home computers. One could say much about how having a device useful for creation as well as consumption as the favored platform of most people affected the market across Europe. The magazines were filled with stories of bedroom gamers who had become bedroom coders and finally Software Stars. Such stories make a marked contrast to an American console-gaming magazine like Nintendo Power, all about consumption without the accompanying ethos of creation.

But most importantly for our purposes today, the relative neglect of Britain in particular by the big computing powers in the United States and Japan — for many years, Commodore was the only company of either nation to make a serious effort to sell their machines into British homes — gave space for a flourishing domestic trade in homegrown machines. When Britain became the nation with the most computers per capita on the planet at mid-decade, most of the computers in question bore the logo of either Acorn or Sinclair, the two great rivals at the heart of the young British microcomputer industry.

Acorn, co-founded by Clive Sinclair’s former right-hand man Chris Curry and an Austrian academic named Hermann Hauser, was an archetypal example of an engineering-driven company. Their machines were a little more baroque, a little better built, and consequently a little more expensive than they needed to be, while their public persona was reserved and just a little condescending, much like that of the BBC that had given its official imprimatur to Acorn’s most popular machine, the BBC Micro. Despite “Uncle Clive’s” public reputation as the British Inspector Gadget, Sinclair was just the opposite; cheap and cheerful, they had the common touch. Acorns sold to the educators, to the serious hobbyists, and to the posh, while Sinclairs dominated with the masses.

Yet Acorn and Sinclair were similar in one important respect: they were both in their own ways very poorly managed companies. When the British home-computer market hit an iceberg in 1985, both were caught in untenable positions, drowning in excess inventory. Acorn — quintessentially British, based in the storied heart of Britain’s “Silicon Fen” of Cambridge — was faced with a choice between dissolution and selling themselves to the Italian typewriter manufacturer Olivetti; after some hand-wringing, they chose the latter course. Sinclair also sold out: to the new kid on the block of British computing, Amstrad, owned by a gruff Cockney with a penchant for controversy named Alan Sugar who was well on his way to becoming the British Donald Trump.

Ever practical in their approach to technology, Amstrad made much of the CPC's bundled monitor in their advertising, noting that with the CPC Junior could play on the computer while the rest of the family watched television.

Ever mindful of the practical concerns of their largely working-class customers, Amstrad made much of the CPC’s bundled monitor in their advertising, noting that Junior could play on the CPC without tying up the family television.

Amstrad had already been well-established as a maker of inexpensive stereo equipment and other consumer electronics when their first computers, the CPC (“Colour Personal Computer”) line, debuted in June of 1984. The CPC range was created and sold as a somewhat more capable Sinclair Spectrum. It consisted of well-built and smartly priced if technically unimaginative computers that were fine choices for gaming, boasting as they did reasonably good if hardly revolutionary graphics and sound. Like most Amstrad products, they strained to be as easy to use as possible, shipping as complete units — tape or disk drive and monitor included — at a time when virtually all of their rivals had to be assembled piece by piece via separate purchases.

The CPC line did very well from the outset, even as Acorn and Sinclair were soon watching their own sales implode. Pundits attributed the line’s success to what they called “the Amstrad Effect”: Alan Sugar’s instinct for delivering practical products at a good price at the precise instant when the technology behind them was ready for the mass market — i.e., was about to become desirable to his oft-stated target demographic of “the truck driver and his wife.” Sugar preferred to let others advance the technical state of the art, then swoop in to reap the rewards of their innovations when the time was right. The CPC line was a great example of him doing just that.

But the most dramatic and surprising iteration of the Amstrad Effect didn’t just feed the existing market for colorful game machines; it found an entirely new market segment, one that Amstrad’s competitors had completely missed until now. The story of the creation of the Amstrad PCW line is a classic tale of Alan Sugar, a man who knew almost nothing about computers but knew all he needed to about the people who bought them.

One day just a few months after the release of the first CPC machines, Sugar found himself in an airplane over Asia with Bob Watkins, one of his most trusted executives. A restless Sugar asked Watkins for a piece of paper, and proceeded to draw on it a contraption that included a computer, a monitor, a disk drive, and a printer, all in one unit. Looking at the market during the run-up to the CPC launch, Sugar had recognized that the only true mainstream uses for the current generation of computers in the home were as game machines and word processors. With the CPC, he had the former application covered. But what about the latter? All of the inexpensive machines currently on the market, like the Sinclair Spectrum, were oriented toward playing games rather than word processing, trading the possibility of displaying crisp 80-column text for colorful graphics in lower resolutions. Meanwhile all of the more expensive ones, like the BBC Micro, were created by and for hardcore techies rather than Sugar’s truck drivers. If they could apply their patented technology-for-the-masses approach to a word processor for the home and small business — making a cheap, well-built, all-in-one design emphasizing ease of use for the common person — Amstrad might just have another hit on their hands, this time in a market of their own utterly without competition. Internally, the project was named after Sugar’s secretary Joyce, since it would hopefully make her job and those of many like her much easier. It would eventually come to market as the “PCW,” or “Personal Computer Word Processor.”

The first Amstrad PCW machine, complete with bundled printer.

The first Amstrad PCW machine, complete with bundled printer. Note how the disk drive and the computer itself are built into the same case as the monitor, a very unusual design for the period.

Even more so than the CPC, the PCW was a thoroughly underwhelming package for technophiles. It was build around the tried-and-true Z80 8-bit CPU and ran CP/M, an operating system already considered obsolete by big business, MS-DOS having become the standard in the wake of the IBM PC. The bundled word-processing software, contracted out to a company called Locomotive Software, wasn’t likely to impress power users of WordStar or WordPerfect overmuch — but it was, in keeping with the Amstrad philosophy, unusually friendly and easy to use. Sugar knew his target customers, knew that they “didn’t give a shit whether there was an elastic band or an 8086 or a 286 driving the thing. They wouldn’t know what you were talking about.”

As usual, most of Amstrad’s hardware-engineering efforts went into packaging and cost-cutting. It was decided that the printer would have to be housed separately from the system unit for technical reasons, but otherwise the finished machine conformed remarkably well to Sugar’s original vision. Best of all, it had a price of just £399. By way of comparison, Acorn’s most recent BBC Micro Model B+ had half as much memory and no disk drive, monitor, or printer included — and was priced at £499.

Nervous as ever about intimidating potential customers, Amstrad was at pains to market the PCW first and foremost as a turnkey word-processing solution for homes and small businesses, as a general-purpose computer only secondarily if at all. “It’s more than a word processor for less than most typewriters,” ran their tagline. At the launch event in the heart of the City in August of 1985, three female secretaries paraded across the stage: a snooty one who demanded one of the competition’s expensive computer systems; a tarty one who said a typewriter was more than good enough; and a smart, reasonable one who naturally preferred the PCW. Man-of-the-people Sugar crowed extravagantly that Amstrad had “brought word-processing within the reach of every small business, one-man band, home-worker, and two-finger typist in the country.” Harping on one of his favorite themes, he noted that once again Amstrad had “produced what the customer wants and not a boffin’s ego trip.”

Sugar’s aggressive manner may have grated with many buttoned-down trade journalists, but few could deny that he might just open up a whole new market for computers with the PCW. Electrical Retailer and Trader was typical, calling the PCW “a grown-up computer that does something people want, packaged and sold in a way they can understand, at a price they’ll accept.” But even that note of optimism proved far too mild for the reality of the machine’s success. The PCW exploded out of the gate, selling 350,000 units in the first eight months. It probably could have sold a lot more than that, but Amstrad, caught off-guard by the sales numbers despite their founder’s own bullishness on the product, couldn’t make and ship them fast enough.

Level 9's Time and Magic text adventure running on a PCW.

Level 9’s Time and Magik text adventure running on a PCW.

Surprisingly for such a utilitarian package, the PCW garnered considerable loyalty and even love among the millions in Britain and all across Europe who eventually bought one. Their enthusiasm was enough to sustain a big, glossy newsstand magazine dedicated to the PCW alone — an odd development indeed for this machine that seemed on the face of it to be anything but a hacker’s darling. A thriving software ecosystem that reached well beyond word processing sprung up around the machine. Despite the PCW’s monochrome display and virtually nonexistent animation and sound capabilities, even games were far from unheard of on the platform. For obvious reasons, text adventures in particular became big favorites of PCW owners; with its comfortable full-travel keyboard, its fast disk drive, its relatively cavernous 256 K of memory, and its 80-column text display, a PCW was actually a far better fit for the genre than the likes of a Sinclair Spectrum. The PCW market for text adventures was strong enough to quite possibly allow companies like Magnetic Scrolls and Level 9 to hang on a year or two longer than they might otherwise have managed.

So, Amstrad was already soaring on the strength of the CPC and especially the PCW when they shocked the nation and cemented their position as the dominant force in mainstream British computing with the acquisition of Sinclair in April of 1986. Eminently practical man of business that he was, Sugar bought Sinclair partly to eliminate a rival, but also because he realized that, home-computer slump or no, the market for a machine as popular as the Sinclair Spectrum wasn’t likely to just disappear overnight. He could pick up right where Uncle Clive had left off, selling the existing machine just as it was to new buyers who wanted access to the staggering number of cheap games available for the platform. Sugar thought he could make a hell of a lot of money this way while needing to expend very little effort.

Once again, time proved him more correct than even he had ever imagined. Driven by that huge base of games, demand for new Spectrums persisted into the 1990s. Amstrad repackaged the technology from time to time and, perhaps most importantly, dramatically improved on Sinclair’s infamously shoddy quality control. But they never seriously re-imagined the Spectrum. It was now what Sugar liked to call “a commodity product.” He compared it to suntan lotion of all things: the department stores “put it in their window in July and August and they take it away in the winter.” The Spectrum’s version of July and August was of course November and December; every Christmas sparked a new rush of sales to the parents of a new group of youngsters just coming of age and discovering the magic of videogames.

A battered and uncertain Acorn, now a subsidiary of Olivetti, faced a formidable rival indeed in Alan Sugar’s organization. In a sense, the fundamental dichotomies hadn’t changed that much since Amstrad took Sinclair’s place as the yin to Acorn’s yang. Acorn remained as technology-driven as ever, while Amstrad was all about giving the masses what they craved in the form of cheap computers that were technically just good enough. Amstrad, however, was a much more dangerous form of people’s computer company than had been their predecessor in the role. After releasing some notoriously shoddy stereo equipment under the Amstrad banner in the 1970s and paying the price in returns and reputation, Alan Sugar had learned a lesson that continued to elude Clive Sinclair: that selling well-built, reliable products, even at a price of a few more quid on the final price tag and/or a few less in the profit margin, pays off more than corner-cutting in the long run. Unlike Uncle Clive, who had bumbled and stumbled his way to huge success and just as quickly back to failure, Sugar was a seasoned businessman and a master marketer. The diffident boffins of Acorn looked destined to have a hard time against a seasoned brawler like Sugar, raised on the mean streets of the cutthroat Tottenham Court Road electronics trade. It hardly seemed a fair fight at all.

But then, in the immediate wake of their acquisition by Olivetti nothing at all boded all that well for Acorn. New hardware releases were limited to enhanced versions of the 1981-vintage, 8-bit BBC Micro line that were little more ambitious than Amstrad’s re-packagings of the Spectrum. It was an open secret that Acorn was putting much effort into designing a new CPU in-house to serve as the heart of their eventual next-generation machine, an unprecedented step in an industry where CPU-makers and computer-makers had always been separate entities. For many, it seemed yet one more example of Acorn’s boffinish tendencies getting the best of them, causing them to laboriously reinvent the wheel rather than do what the rest of the microcomputer world was doing: grabbing a 68000 from Motorola or an 80286 from Intel and just getting on with the 16-bit machine their customers were clamoring for. While Acorn dithered with their new chip, they continued to fall further and further behind Amstrad, who in the wake of the Sinclair acquisition had now gone from a British home-computer market share of 0 to 60 percent in less than two years. Acorn was beginning to look downright irrelevant to many Britons in the market for the sorts of affordable, practical computer systems Amstrad was happily providing them with by the bucketful.

Measured in terms of public prominence, Acorn’s best days were indeed already behind them; they would never recapture those high-profile halcyon days of the early 1980s, when the BBC Micro had first been anointed as the British establishment’s officially designated choice for those looking to get in on the ground floor of the computer revolution. Yet the new CPU they were now in the midst of creating, far from being a pointless boondoggle, would ultimately have a far greater impact than anything they’d done before — and not just in Britain but over the entire world. For the CPU architecture Acorn was creating in those uncertain mid-1980s was the one that has gone on to be become the most popular ever: the ubiquitous ARM. Since retrofitted into “Advanced RISC Machine,” “ARM” originally stood for “Acorn RISC Machine.” Needless to say, no one at Acorn had any idea of the monster they were creating. How could they?

ARM, the chip that changed the world.

ARM, the chip that changed the world.

“RISC” stands for “Reduced Instruction Set Computer.” The idea didn’t originate with Acorn, but had already been kicking around American university and corporate engineering departments for some time. (As Hermann Hauser later wryly noted, “Normally British people invent something, and the exploitation is in America. But this is a counterexample.”) Still, the philosophy behind ARM was adhered to by only a strident minority before Acorn first picked it up in 1983.

The overwhelming trend in commercial microprocessor design up to that point had been for chips to offer ever larger and more complex instruction sets. By making “opcodes” — single instructions issued directly to the CPU — capable of doing more in a single step, machine-level code could be made more comprehensible for programmers and the programs themselves more compact. RISC advocates came to call this traditional approach to CPU architecture “CISC,” or “Complex Instruction Set Computing.” They believed that CISC was becoming increasingly counterproductive with each new generation of microprocessors. Seeing how the price and size of memory chips continued to drop significantly almost every year, they judged — in the long term, correctly — that memory usage would become much less important than raw speed in future computers. They therefore also judged that it would be more than acceptable in the future to trade smaller programs for faster ones. And they judged that they could accomplish exactly that trade-off by traveling directly against the prevailing winds in CPU design — by making a CPU that offered a radically reduced instruction set of extremely simple opcodes that were each ruthlessly optimized to execute very, very quickly.

A program written for a RISC processor might need to execute far more opcodes than the same program written for a CISC processor, but those opcodes would execute so quickly that the end result would still be a dramatic increase in throughput. Yes, it would use more memory, and, yes, it would be harder to read as machine code — but already fewer and fewer people were programming computers at such a low level anyway. The trend, which they judged likely only to accelerate, was toward high-level languages that abstracted away the details of processor design. In this prediction again, time would prove the RISC advocates correct. Programs may not even need to be as much larger as one might think; RISC advocates argued, with some evidence to back up their claims, that few programs really took full advantage of the more esoteric opcodes of the CISC chips, that the CISC chips were in effect being programed as if they were RISC chips much of the time anyway. In short, then, a definite but not insubstantial minority of academic and corporate researchers were beginning to believe that the time was ripe to replace CISC with RISC.

And now Acorn was about to act on their belief. In typical boffinish fashion, their ARM project was begun as essentially a personal passion project by Roger Wilson1 and Steve Furber, two key engineers behind the original BBC Micro. Hermann Hauser admits that for quite some time he gave them “no people” and “no money” to help with the work, making ARM “the only microprocessor ever to be designed by just two people.” When talks began with Olivetti in early 1985, ARM remained such a back-burner long-shot that Acorn never even bothered to tell their potential saviors about it. But as time went on the ARM chip came more and more to the fore as potentially the best thing Acorn had ever done. Having, almost perversely in the view of many, refused to produce a 16-bit replacement for the BBC Micro line for so long, Acorn now proposed to leapfrog that generation entirely; the ARM, you see, was a 32-bit chip. Early tests of the first prototype in April of 1985 showed that at 8 MHz it yielded an average throughput of about 3.5 MIPS, compared to 2.5 MIPS at 10 MHz for the 68020, the first 32-bit entry in Motorola’s popular 68000 line of CISC processors. And the ARM was much, much cheaper and simpler to produce than the 68020. It appeared that Wilson and Furber’s shoestring project had yielded a world-class microprocessor.

ARM made its public bow via a series of little-noticed blurbs that appeared in the British trade press around October of 1985, even as the stockbrokers in the City and BBC Micro owners in their homes were still trying to digest the news of Acorn’s acquisition by Olivetti. Acorn was testing a new “super-fast chip,” announced the magazine Acorn User, which had “worked the first time”: “It is designed to do a limited set of tasks very quickly, and is the result of the latest thinking in chip design.” From such small seeds are great empires sown.

The Acorn Archimedes

The Acorn Archimedes

The machine that Acorn designed as a home for the new chip was called the Acorn Archimedes — or at times, because Acorn at been able to retain the official imprimatur of the BBC, the BBC Archimedes. It was on the whole a magnificent piece of kit, in a different league entirely from the competition in terms of pure performance. It was, for instance, several times faster than a 68000-based Amiga, Macintosh, or Atari ST in many benchmarks despite running at a clock speed of just 8 MHz, roughly the same as all of the aforementioned competitors. Its graphic capabilities were almost as impressive, offering 256 colors onscreen at once from a palette of 4096 at resolutions as high as 640 X 512. So, Acorn had the hardware side of the house well in hand. The problem was the software.

Graphical user interfaces being all the rage in the wake of the Apple Macintosh’s 1984 debut, Acorn judged that the Archimedes as well had to be so equipped. Deciding to go to the source of the world’s very first GUI, they opened a new office for operating-system development a long, long way from their Cambridge home: right next door to Xerox’s famed Palo Alto Research Center, in the heart of California’s Silicon Valley. But the operating-system team’s progress was slow. Communication and coordination were difficult over such a distance, and the team seemed to be infected with the same preference for abstract research over practical product development that had always marked Xerox’s own facility in Palo Alto. The new operating system, to be called ARX, lagged far behind hardware development. “It became a black hole into which we poured effort,” remembers Wilson.

At last, with the completed Archimedes hardware waiting only on some software to make it run, Acorn decided to replace ARX with something they called Arthur, a BASIC-based operating environment very similar to the old BBC BASIC with a rudimentary GUI stuck on top. “All operating-system geniuses were firmly working on ARX,” says Wilson, “so we couldn’t actually spare any of the experts to work on Arthur.” The end result did indeed look like something put together by Acorn’s B team. Parts of Arthur were actually written in interpreted BASIC, which Acorn was able to get away with thanks to the blazing speed of the Archimedes hardware. Still, running Arthur on hardware designed for a cutting-edge Unix-like operating system with preemptive multitasking and the whole lot was rather like dropping a two-speed gearbox into a Lamborghini; it got the job done, after a fashion, but felt rather against the spirit of the thing.

When the Archimedes debuted in August of 1987, its price tag of £975 and up along with all of its infelicities on the software side gave little hope to those not blinded with loyalty to Acorn that this extraordinary machine would be able to compete with Amstrad’s good-enough models. The Archimedes was yet another Acorn machine for the boffins and the posh. Most of all, though, it would be bought by educators who were looking to replace aging BBC Micros and might still be attracted by the BBC branding and the partial compatibility of the new machine with the old, thanks to software emulators and the much-loved BBC BASIC still found as the heart of Arthur.

Even as Amstrad continued to dominate the mass market, a small but loyal ecosystem sprang up around the Archimedes, enough to support a software scene strong on educational software and technical tools for programming and engineering, all a natural fit for the typical Acorn user. And, while the Archimedes was never likely to become the first choice for pure game lovers, a fair number of popular games did get ported. After all, even boffins and educators — or, perhaps more likely, their students — liked to indulge in a bit of pure fun sometimes.

In April of 1989, after almost two long, frustrating years of delays, Acorn released a revision of Arthur comprehensive enough to be given a whole new name. The new RISC OS incorporated many if not all of the original ambitions for ARX, at last providing the Archimedes with an attractive modern operating system worthy of its hardware. But by then, of course, it was far too late to capture the buzz a more complete Archimedes package might have garnered at its launch back in 1987.

Much to the frustration of many of their most loyal customers, Acorn still seemed not so much inept at marketing their wares to the common person as completely disinterested in doing so. It was as if they felt themselves somehow above it all. Perhaps they had taken a lesson from their one earlier attempt to climb down from their ivory tower and sell a computer for the masses. That attempt had taken the form of the Acorn Electron, a cut-down version of the BBC Micro released in 1983 as a direct competitor to the Sinclair Spectrum. Poor sales and overproduction of the Electron had been the biggest single contributor to Acorn’s mid-decade financial collapse and the loss of their independence to Olivetti. Having survived that trauma (after a fashion), Acorn seemed content to tinker away with technology for its own sake and to let the chips fall where they would when it came to actually selling the stuff that resulted.

Alan Sugar shows off the first of his new line of PC clones.

Alan Sugar shows off the first of his new line of PC clones.

If it provided any comfort to frustrated Acorn loyalists, Amstrad also began to seem more and more at sea after their triumphant first couple of years in the computer market. In September of 1986, they added a fourth line of computers to their catalog with the release of the PC — as opposed to PCW — range. The first IBM clones targeted at the British mass market, the Amstrad PC line might have played a role in its homeland similar to that of the Tandy 1000 in the United States, popularizing these heretofore business-centric machines among home users. As usual with Amstrad, the price certainly looked right for the task. The cheapest Amstrad PC model, with a generous 512 K of memory but no hard drive, cost £399; the most expensive, which included a 20 Mb hard drive, £949. Before the Amstrad PC’s release, the cheapest IBM clone on the British market had retailed for £1429.

But, while not a flop, the PC range never took off quite as meteorically as some had expected. For months the line was dogged by reports of overheating brought on by the machine’s lack of a fan (shades of the Apple III fiasco) that may or may not have had a firm basis in fact. Alan Sugar himself was convinced that the reports could be traced back to skulduggery by IBM and other clone manufacturers trying to torpedo his cheaper machines. When he finally bowed to the pressure to add a fan, he did so as gracelessly as imaginable.

I’m a realistic person and we are a marketing organization, so if it’s the difference between people buying the machine or not, I’ll stick a bloody fan in it. And if they say they want bright pink spots on it, I’ll do that too. What is the use of me banging my head against a brick wall and saying, “You don’t need the damn fan, sunshine?”

But there were other problems as well, problems that were less easily fixed. Amstrad struggled to source hard disks, which had proved a far more popular option than expected, resulting in huge production backlogs on many models. And, worst of all, they found that they had finally overreached themselves by setting the prices too low to be realistically sustainable; prices began to creep upward almost immediately.

For that matter, prices were creeping upward across Amstrad’s entire range of computers. In 1986, after years of controversy over the alleged dumping of memory chips into the international market on the part of the Japanese semiconductor industry, the United States pressured Japan into signing a trade pact that would force them to throttle back their production and increase their prices. Absent the Japanese deluge, however, there simply weren’t enough memory chips being made in the world to fill an ever more voracious demand. By 1988, the situation had escalated into a full-blown crisis for volume computer manufacturers like Amstrad, who couldn’t find enough memory chips to build all the computers their customers wanted — and certainly not at the prices their customers were used to paying for them. Amstrad’s annual sales declined for the first time in a long time in 1988 after they were forced to raise prices and cut production dramatically due to the memory shortage. Desperate to secure a steady supply of chips so he could ramp up production again, Sugar bought into Micron Technology, one of only two American firms making memory chips, in October of 1988 to the tune of £45 million. But within a year the memory-chip crisis, anticipated by virtually everyone at the time of the Micron buy-in to go on for years yet, petered out when factories in other parts of Asia began to come online with new technologies to produce memory chips more cheaply and quickly than ever. Micron’s stock plummeted, another major loss for Amstrad. The buy-in hadn’t been “the greatest deal I’ve ever done,” admitted Sugar.

Many saw in the Amstrad of these final years of the 1980s an all too typical story in business: that of a company that had been born and grown wildly as a cult of personality around its founder, until one day it got too big for any one man to oversee. The founder’s vision seemed to bleed away as the middle managers and the layers of bureaucracy moved in. Seduced by the higher profits margins enjoyed by business computers, Amstrad strayed ever further from Sugar’s old target demographic. New models in the PC range crept north of £1000, even £2000 for the top-of-the-line machines, while the more truck-driver-focused PCW and CPC lines were increasingly neglected. The CPC line would be discontinued entirely in 1990, leaving only the antique Spectrum to soldier on for a couple more years for Amstrad in the role of general-purpose home computer. It seemed that Amstrad at some fundamental level didn’t really know how to go about producing a brand new machine in the spirit of the CPC in this era when making a new home computer was much more complicated than plugging together some off-the-shelf chips and hiring a few hackers to knock out a BASIC for the thing. Amstrad would continue to make computers for many years to come, but by the time the 1990s dawned their brief-lived glory days of 60 percent market share were already fading into the rosy glow of nostalgia.

For all their very real achievements over the course of a very remarkable decade in British computing, Acorn and Amstrad each had their own unique blind spot that kept them from achieving even more. In the Archimedes, Acorn had a machine that was a match for any other microcomputer in the world in any application you cared to name, from games to business to education. Yet they released it in half-baked form at too high a price, then failed to market it properly. In their various ranges, Amstrad had the most comprehensive lineup of computers of anyone in Britain during the mid- to late-1980s. Yet they lacked the corporate culture to imagine what people would want five years from now in addition to what they wanted today. The world needs visionaries and commodifiers alike. What British computing lacked in the 1980s was a company capable of integrating the two.

That lack left wide open a huge gap in the market: space for a next-generation home computer with a lot more power and much better graphics and sound than the likes of the old Sinclair Spectrum, but that still wouldn’t cost a fortune. Packaged, priced, and marketed differently, the Archimedes might have been that machine. As it was, buyers looked to foreign companies to provide. Neglected as Europe still was by the console makers of Japan, the British punters’ choice largely came down to one of two American imports, the Commodore Amiga and the Atari ST. Both — especially the former — would live very well in this gap that neither Acorn nor Amstrad deigned to fill for too long. Acorn did belatedly try with the release of the Archimedes A3000 model in mid-1989 — laid out in the all-in-one-case, disk-drive-on-the-side fashion of an Amiga 500, styled to resemble the old BBC Micro, and priced at a more reasonable if still not quite reasonable enough £745. But by that time the Archimedes’s fate as a boutique computer for the wealthy, the dedicated, and the well-connected was already decided. As the decade ended, an astute observer could already detect that the wild and woolly days of British computing as a unique culture unto itself were numbered.

The Archimedes A3000 marked the end of an era, the last Acorn machine to also bear the BBC logo.

The Archimedes A3000 marked the end of an era, the last Acorn machine to bear the BBC logo.

And that would be that, but for one detail: the fairly earth-shattering detail of ARM. The ARM CPU’s ability to get extraordinary performance out of a relatively low clock speed had a huge unintended benefit that was barely even noticed by Acorn when they were in the process of designing it. In the world of computer engineering, higher clock speeds translate quite directly into higher power usage. Thus the ARM chip could do more with less power, a quality that, along with its cheapness and simplicity, made it the ideal choice for an emerging new breed of mobile computing devices. In 1990 Apple Computer, hard at work on a revolutionary “personal digital assistant” called the Newton, came calling on Acorn. A new spinoff was formed in November of 1990, a partnership among Acorn, Apple, and the semiconductor firm VLSI Technology, who had been fabricating Acorn’s ARM chips from the start. Called simply ARM Holdings, it was intended as a way to popularize the ARM architecture, particularly in the emerging mobile space, among end-user computer manufacturers like Apple who might be leery of buying ARM chips directly from a direct competitor like Acorn.

And popularize it has. To date about ten ARM CPUs have been made for every man, woman, and child on the planet, and the numbers look likely to continue to soar almost exponentially for many years to come. ARM CPUs are found today in more than 95 percent of all mobile phones. Throw in laptops (even laptops built around Intel processors usually boost several ARM chips as well), tablets, music players, cameras, GPS units… well, you get the picture. If it’s portable and it’s vaguely computery, chances are there’s an ARM inside. ARM, the most successful CPU architecture the world has ever known, looks likely to continue to thrive for many, many years to come, a classic example of unintended consequences and unintended benefits in engineering. Not a bad legacy for an era, is it?

(Sources: the book Sugar: The Amstrad Story by David Thomas; Acorn User of July 1985, October 1985, March 1986, September 1986, November 1986, June 1987, August 1987, September 1987, October 1988, November 1988, December 1988, February 1989, June 1989, and December 1989; Byte of November 1984; 8000 Plus of October 1986; Amstrad Action of November 1985; interviews with Hermann Hauser, Sophie Wilson, and Steve Furber at the Computer History Museum.)

  1. Roger Wilson now lives as Sophie Wilson. As per my usual editorial policy on these matters, I refer to her as “he” and by her original name only to avoid historical anachronisms and to stay true to the context of the times. 

Sibyl Moon Games

Design notes for Five Gods Exiled

by Carolyn VanEseltine at June 23, 2016 05:01 PM

This week is Emily Short’s Bring Out Your Dead semijam, described as “an event for sharing dead WIPs and experiments that you don’t expect to finish, but that you’d like to show to someone anyway”.

In that spirit, I present Five Gods Exiled, my successful procedural generation experiment that completely failed at becoming a game.

This game will run in a browser – I tested it on Firefox and Chrome – but your browser will report a freeze while the game is loading. (I received two “Continue the script?” checks in Firefox, and one in Chrome.) If you’d prefer to download the game instead, here’s the gblorb link and here are some interpreters that can run a glulxe file (I personally use Windows Glulxe.)

Skip to the chase: Five Gods Exiled

Some history

In November of 2010, fresh off the success of my first complete IF release (One Eye Open, with Caelyn Sandel), I wanted to make the most replayable IF game ever. And I wanted to release it just five months later.

As I described it to Greg Boettcher, the 2011 Spring Thing organizer:

“The working title of my current project is Five and Five. It’s a game about a world where part of reality has been divided away from itself, leaving neither plane of reality whole. The PC can move between the two halves of reality under certain circumstances, and the PC’s goal is to save reality by reuniting the Blight and the Exile. This game will be an experiment in replayability. Almost everything in it (map layouts, terrain, major NPCs, the PC’s history, etc.) will be randomly generated, and any given playthrough will give you only a fraction of the content available. Winning the game will rely not on puzzle-solving, but on tactics (there is a combat system) and a certain amount of luck. Instead of being a crossword at war with a narrative, it’s a board game at war with a narrative.”

In the letter above here, you can see the vagueness of my pitch. After I withdrew from Spring Thing (having bitten off far more than I could chew), I set the project aside. I was learning more about game design, which forced me to see all the project’s problems. I was very excited about my procedural generation tech, but as for the actual story – or the player experience, or what made any of this fun – I didn’t have any good answers. (More about this in “Recognizing Fun Through Elevator Pitches”.)

Lacking answers, I moved on to other projects. Five Gods Exiled went first to a temp backburner, and then to the permanent backburner, where it has remained until now.

Bring Out Your Dead header

Procedural generation

To learn about the procedurally generated landscape, see “A Procedurally Generated Wilderness”. Alternately, see volumes 2 through 4 (and subheadings) in the source.

The second-most-complex procedural generation system is the one used to build NPCs. While your birth nation is never identified in game, the characteristics used to build characters were intended to be generically appropriate to random Americans. I wanted to create procedurally generated characters that would seem visually believable. I wanted players to look at the name and physical description and think, “Yeah, I could imagine that person walking past on the street.”

I won’t go into detail about how it works – see Volume 5 (and subheadings) in the source – but in retrospect, while the system works, it’s not so great behind the scenes. In the source code, the entire system hinges on ethnicities (the ethnicity categories used at Mongabay – Non-Hispanic White, Non-Hispanic Black, Hispanic, Native American/Alaskan, Asian/Pacific Islander). While those ethnicities are never mentioned in game, they are used to adjust the names and traits available to various characters, and I made some poor choices in setting up that system. Aside from that, there’s some weight shaming in the source code, and gender is treated as a binary. I’m leaving all of this code as-is, but that doesn’t mean I stand by it now. I think it’s a good idea to illustrate mistakes.

If I were going to complete this game, I would revisit procedural character generation and look for ways to accomplish the overarching goal (believable random people) in a way that avoids drawing artificial lines or conveying hurtful things. I’d also discuss the system with other game devs (particularly people of color) and listen to their feedback. These things matter, even when the player can’t see them.


My primary inspiration was the board game Arkham Horror. My play group uses every expansion there is simultaneously, which means that I’ve seen a bare fraction of the content available. I wanted players to have that kind of experience, and I understood in advance that a procedurally generated game would involve a certain amount of stylization. The plot could contort within certain boundaries, but coming up with an entirely new plot each time was out of the question. And fully fleshed NPCs were out of the question, too.

The actual plot (and associated gameplay) metamorphosed significantly during development, but here’s the last incarnation of the plot and associated gameplay.


In a near-future world, scientists discover definitive proof of the Gods. They are absolutely terrifying, and their powers can be drawn upon by anyone who knows how to do it. Their existence is like handing a firebomb to every person in the world.

There’s a worldwide scientific and religious effort to take that firebomb away, which means shunting the Gods into another part of existence. Somewhere humans can’t reach them.

The effort is successful, but unfortunately misguided. These are the Gods. It’s not possible to push the Gods out of existence without pushing everyone else out of existence. Which is exactly what has happened.

The human race has Exiled itself into a different plane of reality. It is not stable.

You were recruited into a circle of people seeking to return humanity to the real world. The Gods may be dangerous, but they’re still less dangerous than this dream world and its disintegrating laws of physics and society.

As a group, you are damaged, confused and frightened. One of your group is murdered, threatening your mission, but through meditation, prayer, and ritual, your circle successfully opens a portal back to the real world.

Only one person can cross back. You are the one chosen.

The information is revealed to the player through flashbacks and memories. These memories are custom-tailored to the procedurally generated identity of the player and the other people in the player’s circle.


There are ten shrines in the Blight, each belonging to a different God.

Five of these shrines belong to the exiled Gods. These shrines can be invoked to phrase the player temporarily into the Exile. The player needs to invoke all five shrines to summon the Gods home, but monsters are created whenever the exiled Gods connect with the real world (also referred to as the Blight).

The other five Gods are still connected to the Blight. Their shrines can be invoked for special powers: restoring the player’s health, restoring the player’s attunement, removing debuffs, identifying items, and locating monsters.

Health indicates the shadow self’s health. If a monster enters combat with the shadow self, the shadow self may lose health. If the health drops to zero, the shadow self will be destroyed.

Attunement indicates whether the player is correctly attuned to the Blight, or whether the player’s consciousness is torn across the worlds. It indicates how long the player can stay in the Exile on any given visit, and if the player’s attunement is too low, the player becomes disoriented (reflected by receiving location-appropriate messaging from the Exile while in the Blight, or vice versa). If a monster enters combat with the player, the player may lose attunement. If the attunement drops to zero, the player will be destroyed and the game will end.

After the player’s first trip to the Exile, the player will be joined by the shadow self, which is an echo of the player’s former reality within the Blight. The shadow self handles all combat, which is carried out deterministically.

Under some circumstances, the player can receive mementos upon phasing back into the Blight. Mementos are projections of Exiled energy upon the Blight, and they provide temporary or permanent boosts to the player’s stats (strength, stamina, will, and knowledge) or derived stats (attack, speed, defense, health, attunement, awareness, and stealth). As more shrines are invoked, the monsters created will be more numerous and powerful, and mementos help even up the playing field.

After the player invokes all five shrines, a portal appears in the first room of the game. The portal leads Between Worlds, where the player’s mentor (the person who assembled their circle) gives the player a talisman, which cannot be dropped. As long as the player carries the talisman, they lose permanent health (in the Blight) or permanent attunement (in the Exile) every turn.

To finish the game, the player must enter the Exile and give the talisman to someone. It’s a lethal gift, but if the player chooses someone from their circle, then the worlds will be reunited (the good ending). If the player has pieced together enough memories to find the murderer, that would be an excellent person to choose (the very good ending). If the player gives the talisman to someone who isn’t from the circle, that person will die and humanity will remain Exiled for now (the bad ending). And if the player fails to give the talisman away before dying, then their consciousness will be torn across the worlds and humanity will be permanently Exiled (the very bad ending).

Significant chunks of the gameplay described above are still unimplemented or include placeholder messaging only. It’s possible to die to a monster, but none of the true endings are available.


My primary inspiration was the board game Arkham Horror, and… the game still behaves like a board game. Apart from the text-based procedural generation systems, there’s no reason why IF is the correct medium for this game. The narrative is vague and gigantic at the same time, while the gameplay focuses on movement through space (a particularly poor choice for IF) and RPG-style combat.

At a rough guess, this game is two-thirds implemented and one-quarter written. It won’t see daylight as a finished project, but I don’t regret the time I spent on it. I learned Inform while working on One Eye Open and Beet the Devil, but I learned the sheer power of Inform while I worked on Five Gods Exiled.

Source code

How the sausage was made: Five Gods Exiled source code

Please note the source code only compiles under Inform 7 6G60. Also, it’s essentially uncommented. Sorry about that.

June 22, 2016

Emily Short


by Emily Short at June 22, 2016 06:00 PM

In which I talk about something personal and political; skip if that’s not your thing.

I am an immigrant. I moved to the UK to live with my husband, after seven years of trans-Atlantic relationship. By the time that happened, our relationship had survived a lot of circumstantial challenge and a lot of time. Moving was, to put it mildly, not something I did on a whim.

Lots of people assume that if you marry a citizen of the UK, you immediately have the right to live and work here. This is false. Getting (and then repeatedly renewing) a spousal visa is a time-consuming, expensive process involving hundreds of pages of documentation, letters of support from everyone from your family to your landlord to your bank, and a hefty intervention from lawyers. If you are too young, or if you can’t provide evidence of the sponsoring partner having a stable, fairly comfortable income, you can’t do it at all. My being able to immigrate is a huge marker of privilege.

My immigration story is an animated fairytale compared with the reasons my ancestors immigrated. Like most Americans, I inherited many stories of why you might leave behind your homeland and everything you know. Such as: my Cherokee ancestors who were forcibly moved to Oklahoma. My Irish ancestors who were part of the Irish diaspora. My German ancestors who had been living in an area under Russian control until the Russians decided to do some ethnic cleansing.

That history was written in the character of my grandparents, even if I didn’t know how to read it as a child. The covert grief of my grandmother and her siblings, who chose not to speak about their memories because they didn’t want to pass those sorrows to the next generation. The capacity for work. The courage to take necessary risks. The disciplined pragmatism. The ability to triage, to recognize the important needs and not waste energy on stupid fights. My great-grandmother was famously uncomplaining, and when the homesickness and loneliness got too much for her, she would go into the pantry to cry where the family would not have to see. The worst of her experiences are known now only because her descendants chose to keep and translate her diary rather than discarding it.

Why am I mentioning this? Not as evidence. My anecdotes aren’t justification for a policy decision. There are all sorts of genuinely evidence-based reasons for why I think both the US and the UK benefit culturally and politically and economically from immigration, and I hope they/we vote accordingly over the next few months.

Still, I’m impatient with narratives about how immigrants are lazy or dishonest, and even more impatient with the implication that I’m a “good” immigrant purely because I have more money and have faced less trauma than “bad” immigrants. In my experience, immigrants are brave and hard-working; and, also in my experience, immigration itself is something you do in response to a compelling life circumstance.

My other point is this: I see a lot of aggressive posturing in response to fear. If only we all had guns, gun massacres would be a thing of the past! If we closed our borders, we’d exclude terrorism, disease, and meddling EU regulations! Hey, who’s up for a really big wall?

But the surviving-est people I know — the people who did what they needed to do to get through the Great Depression and the potato famine and the Trail of Tears and Russian purges, the people who crossed borders and broke new farmland because they had no other option — they left me the impression that that kind of bluster is purest nonsense. You don’t know what the universe is going to throw at you. You can never brace against it. There is no level of aggression that will keep you safe. There is no power or vengeance fantasy that will keep mortality at bay.

Instead, you pay attention to the evidence and make your best rational provision for the future. If you have a chance, you make friends. If you’re lucky, when something comes — whatever that is — you’re not facing it alone.

Interactive Fables

Worldsmith - An Interactive Fable

June 22, 2016 02:31 PM

CLEVELAND -- June 22nd, 2016 : Interactive Fables announced today that "Worldsmith", the first game in their interactive fables series will be released in September 2016, available from "The Tagides Rings, holding the Septem tower steady in the Manifold, are approaching perfect aphelion. Four apprentices remain but only one Worldsmith will be given the robes of the craft. It all comes to this. The Workshops are prepared. Come, apprentice. It is time to create your masterspiece. It is

Welcome to our Blog - Interactive Fables

June 22, 2016 02:31 PM

Welcome to the first of our semi-regular updates about the progress of Worldsmith and Interactive Fables. It's kind of an exciting time. Our first game is moving towards completion and we hope to release it in September 2016. Or, maybe, October 2016. Hey, we're a small team.  Worldsmith is being written by Mike Preston, the author of Interactive fiction games Map and Fifteen Minutes. Oh, and the *cough* Hard Puzzle games - but the less said about those, the better. We are developing the game in

June 21, 2016

These Heterogenous Tasks

Bring Out Your Dead: Matchmaker

by Sam Kabo Ashwell at June 21, 2016 07:01 PM


My final Bring Out Your Dead entry is Matchmaker (other working title: The Sheep Hook Up). It was my Giant Procedural Folly.

Premise: there’s a city-state somewhere handwavily in Europe. (I never settled on a name for it. Characters are fun to name; cities are tough.) It has long been ruled by a noble class,  but they’re getting decadent, over-fond of refined culture and elaborate entertainments. Meanwhile, a middle class of artisans and merchants has established itself and is looking to climb. Combine this with the tendency of rich, leisured teenagers to act out, and the barriers of class are in peril.

The king re-institutes an old office, the King’s Witness. It’s a job for a sorceror. Sorcery, in this world, is closely linked to spycraft, and it slowly, fundamentally erodes you. Experienced sorcerors have no permanent form, having become constantly-shifting mosaics of identity. Very experienced sorcerors…

Your job is to take this year’s set of marriageable young nobles and make sure that they pair off with one another in suitable ways. No elopements, no secret pregnancies, no triads, no marrying foreign nobles and moving away, no serious homosexuality, and absolutely no love-matches with commoners.

Here’s the introduction. Needs work.

‘ – some of them very useful fellows in their own way, and if it were to remain an occasional occurrence… but it seems as if there are more of them every year. Or else the girls marry outside, and we lose them. If this continues, within a generation our noble Houses will be quite declined; I need not spell out the consequences for my own line, and for the State.’

He has moved over to the slit-window, and stares down through ivy and lead. ‘There is, politically, not much I can do; the privy rights of the Houses, quite properly… privy rights first and always, and the realm be damned. So be it.’  The last time a monarch made free and easy with the Tolybroke Charter, the result was thirty years of bitter war, culminating in the public torture and death of his great-granduncle; for a few heady days there was even talk of a republic.

‘There is a precedent, however,’ he continues, shaking off the ghosts and turning briskly towards you. ‘The old office of King’s Witness has, for some time, been allowed to lapse into an appointment to accustom bright young things to courtly forms without the embarrassment of actual duties. I have complete personal oversight of the appointment, which, happily, is not one to which the Houses will pay overmuch attention. Nor need I make any proclamations if I reinstate ancient privileges to an inconsequential office, or supplement them with a few unofficial discretionary powers necessary to modern challenges.

‘I will be blunt. Courting-season has arrived. There are, in my estimation, nine really suitable young people in society this year. Have them married off to each other, or bring in foreign noblewomen, as you please. I would like four matches by marriage-season, young and noble. Undersecretary Bundle will apprise you of the details. Good day.’

The PC would mostly operate through spycraft and subterfuge. They had a set of sinister minions to do their bidding:

Smokehouse is a person. The description of Smokehouse is “Relaxed, Smokehouse has the constantly shifting form universal to veteran spies, which draws attention to her static features: full, smirking lips, deliberate hands, a common sensibility to the hairstyles. A slim majority of the shapes are female, and most of the male ones are somewhat feminine.”
Whitegrit is a person. “Whitegrit’s shapes reflect little of gender or aesthetic tastes; he has doubtless retained more abstract, private features instead. A deeper liability; but his superficial flexibility is a great asset. Even relaxed, in your presence his shapes unconsciously guess (poorly) at something that might ingratiate.”
Sputtercusp is a person. “Although it is probably not the original, Sputtercusp’s shape does not vary as much as her seniority might suggest. Her tastes are too definite, one suspects; all her forms are female and share a dancing quality of movement. Her faces are all from the same stable; her voices always confident, melodic and perfectly grammatical. No crones or children. Most spies pass through this stage, but those who remain in it are rarely promoted far. Sputtercusp’s rank owes a great deal to her ability at other forms of sorcery.”
Catwrench is a person. “Catwrench has an entirely military background, and the only theme of his forms is a vague flavour of the corps. A man with one eye-socket crushed; another whose speech, though sonorous, is blunt and obfuscating; a woman whose unoccupied hands move automatically to at-ease.”

You would mostly be operating through spycraft: here’s a draft of the major verbs and their tutorial-explanations:

arrest: “So one of the simplest things we can do is arrest someone one a fabricated charge. Doing this to gentry is a risky business if we can’t pin anything on them; that’d bring Tolybroke into play, and if our legal situation looked dodgy the Prince would throw us all to the wolves. You first. Commoners, now, there’s not so much scrutiny; we should be able to get away with it if we don’t go overboard. Either way, it’s a good way of getting someone out of the way for a few days, and maybe make ’em reconsider a few choices.”

assassinate: “Now, the Prince hasn’t sanctioned this or nothing, but, if things start to look really bad somehow and there’s no other way… well, we could, after a manner of speaking, have a person taken care of. If it’s genuinely needed and we keep our hands nice and clean, the Prince will look the other way. These things are like carting powder, though: sometimes it all goes along without a hitch and everyone’s happy, sometimes it goes to hell for no reason and you’re picking teeth out of the gutters for months.”

sorcery: “Some of our folks have a hand for the sorcerous arts. Not proud of it, but we’re not in this for our own pride’s sake. Set ’em to it and they’ll… well, they’ll come up with something or other, no doubt about it, but damned if I could guess what. Sputtercusp is our specialist, but any spy can handle it in a pinch.”

distract: “One of the simplest ways we can tweak a situation is to hold up someone. Let’s say you don’t want someone to be at a certain party, or to make a certain appointment. So you send someone round. Maybe his servant doesn’t wake him up and he sleeps in half the day; maybe there’s a minor carriage accident; maybe an old drinking buddy reappears from nowhere and the whole evening gets diverted. If you do it too often there’s a chance that a smart fellow will start to smell a rat, but otherwise it’s a reliable tactic.”

shadow: “We can put a tail on someone if you so care. You’ll get regular reports on where they go, what they do, who they see; if they send a message, you’ll see it first; if they go to a private party or meet a lover secretly, we’ll alert you. And the shadow acts as a bodyguard, too, just in case some young idiot decides to take up duels or amateur racketeering. But it doesn’t pay to shadow someone forever; even the worst fool will twig eventually. I’d say our best tail is Whitegrit.”

stakeout: “The most basic job we ever do is staking out a place. Place an agent – any idiot can do it – and you’ll get reports on who visits, what goes on, any letters that happen to pass that way. Just like placing a shadow, except we get to put our feet up and eat pastries.”

forge: “Once we’ve got a decent sample of someone’s writing, we can replicate their fist, style idioms, the works. If you need, we can send love-letters, breakup-letters, proposals of marriage, invitations to trysts or duels… whatever you need. Just be warned that this sort of thing makes people ever so suspicious if they catch on.”

investigate: “If you worry that somebody’s hiding something, we can snoop around, open some desks, bribe some servants; maybe scratch up a dirty past, maybe catch on to a current affair. This is only a little risky if done right, but it takes time.”

You’ll note that these mostly happen in between parties and so on, rather than during them. I was going to simulate acts at parties and trysts in a fairly abstract, Sims-like style – the King’s Witness doesn’t care much about the particulars of speech, just the information. I really didn’t have this part nailed down at all; I thought you could push people into interacting with one another a bit, but not infallibly.

The actual subjects of all this intrigue, the young lovers, were the focus of most of the fiddly mechanics. Oh, boy, were they going to be complicated.

Every character had a set of personality and appearance traits. Every character also had a list of personality and appearance traits that they found attractive, partially created from stereotyped templates; the combination of these established baseline attraction. They would then develop their relationships and passions through parties, trysts, correspondence by letters, and (if they got annoyed enough with one another) duels. They would be members of noble families, possibly meaning that some of them were related to one another and share traits as a result. (The families would have auto-generated coats of arms which might reflect family traits.) They would form cliques based on commonly-held traits and try to become more like people in their cliques, and they would follow, and try to influence, seasonally-changing fashions. Traits, particularly popular traits, would determine the kinds of party that were held, but there would also be a fixed list of seasonal festivals.

And then there would be visiting nobility and unscrupulous social climbers, who would try to lure the young gentlefolk into foreign ways and delightfully low-class environs. Young gentlemen falling in love with their mistresses, young ladies running off with their dance tutors. Rumours and accusations. Gender-disguise and lovers’ quarrels. All that good stuff. You can probably see why it never got very far.

Since I was doing this long before Prom Week, I hadn’t really thought at all about how the player would be able to process and use all of this complicated, incremental information. If anything, I was probably inclined to hide most of it from the player and force them to uncover it. I totally designed this the wrong way around – I spent most of my energies on very fiddly generation of characters and figuring out whether they were initially attracted to one another, when the first things to figure out should really have been: what do they do, and how does the player affect it?

Mercifully, I7 – which was then relatively young – began to bog down on my extraordinarily inefficient code, which made very heavy use of many-to-many relations.

The main thing I salvaged from this was the code which created the utterly-ghastly family backgrounds of the ignoble suitors – avaricious strumpets and picaresque rogues, the lot of ’em. It got repurposed and slightly expanded for the orphans of Olivia’s Orphanorium. I got another chance to put a dancing-lime in a game in Invisible Parties (really they’re a German thing, but too good not to steal).

I kind of like the setting. I really want to write a big, detailed, setting-oriented urban piece at some point. I want to do a lot of this stuff, honestly. Just maybe not all in the same game.



Response-based IF

by Jay Nabonne at June 21, 2016 04:09 PM

This will be a quick overview of what I’m calling “response-based” IF, which is what the ResponsIF engine is designed to do. It won’t get too in-depth into the nuances of the engine itself but will strive more to give the overall design considerations.

In general terms, a “response” is a unit of behavior. A response can output text (or other elements), change variables in the world state, move objects around, invoke other responses, etc. or any combination of the above. Anything that occurs in the course of interaction is done through some sort of response.

Responses are triggered by “topics”. A topic is anything you can think of. Nouns, verbs, ideas, emotions, pretty much anything you can think of can be a topic. If you can express it, then it can be a topic. A topic is “called” to generate responses.

Responses do not exist on their own. Rather, responses are provided by “responders”. A responder provides one type of context for when a response can be triggered – a response can only trigger when its responder is part of the active scene. (There are other sorts of context for responses as well, including the topic(s) to match and any necessary world state conditions.)

Let’s give a simple example of a response: the ubiquitous “Hello world” response.

.responses player
    .response START
        .does .says Hello, world!

The key elements are here. The first line (“.responses player”) states that we are defining the responses for the “player” responder. The “player” responder is the only built-in responder in ResponsIF, and it is active in any response context. It is meant to correspond to the person playing (or reading or whatever) the current IF piece.

The next line (“.response START”) begins a definition for a response, responding to the topic “START”. The “START” topic is called by default when a ResponsIF piece begins.

The subsequent line defines what the response does: it outputs the string “Hello, world!”

Finally, “.end” terminates the set of responses for the player.

This is just a single response, and it doesn’t do much. But it should give an idea about how a ResponsIF game or work (termed a “riff”) is structured. An entire riff contains statements to set up the game world along with a collection of responders and their responses which will occur when various topics are called. Responders can be arranged in a hierarchical structure (parent/child) to establish the necessary contexts or even model “world” structures like rooms, hallways, caverns, etc.

How are topics called? Sometimes they’re called internally, as the “START” example shows. They can also be called by other responses. The vast majority of topics will be called due to player action, typically through UI elements such as buttons, hyper-links and textual input.

For example, the following rather pointless example shows how hyper-links can be created to call topics.

.responses player
    .response START
        .does .says Once upon a time, there was a {!princess!} who lived in a tall {!tower!}.
    .response princess
        .does .says She had long luxurious hair.
    .response tower
        .does .says The tower had smooth, stone walls that not even ivy could scale.

The notation “{!princess!}” is called “link markup”. It creates a link that will call the specified topic (“princess”) when clicked.

The exact ResponsIF details are not terribly relevant here, beyond showing the basic concepts. (More details can be found at the ResponsIF github site:

A key part of ResponsIF is its use of HTML, CSS and JavaScript, which provides great freedom in how a work looks and feels. Due to this, ResponsIF can be used to create a large number of possible works. As a general-purpose engine, it is not restricted to any particular form of IF. Of course, being a general-purpose engine, it’s also not specialized for any particular form of IF, which means it may make more sense to use other tools more dedicated to a particular form, depending on what end result is desired. As always, choose the tool that best matches the task at hand!

In upcoming posts, I will go over my own personal goals and design choices for my IF work(s).


by Jay Nabonne at June 21, 2016 04:09 PM

(These are a series of postings I made in the (Quest) forums almost three years ago. The ideas put forth here eventually led to my Quest “Response Library”, which was then rewritten in JavaScript as ResponsIF. Not everything in it is still relevant for me, but I’m including here because it has some nascent ideas I think are worth preserving as well as including in this sequence of blog posts. I’m concatenating the posts together, as they’re all related.)


I wanted to start a dialogue (no pun intended) about conversations. Part of this is philosophical/theoretical, which can be fun on its own, but I also wanted to possibly work toward the creation of something new – a Quest conversation engine.

First, the idea bantering phase… So, what exactly do I mean by a conversation?

Part of that should be fairly obvious: the player having communication with other characters (also known as “non-player characters” or “NPCs”). There is already code in Quest – plus an extended such library written by The Pixie in the “Libraries and Code Samples” forum – which supports basic “ask” and “tell”. This takes the form of something like “ask Mary about George” or “tell janitor about fire”. You have a target character and what’s known as a “topic”. Typically, this basic implementation responds with a fixed response (e.g. look up string “topic” in character’s “ask” string table), with an occasional implementation of selecting randomly from a set of fixed responses.

But we usually want more…

There have always been questions, wishes, requests for NPCs to be more interactive. Now, this is black art at this point, and I don’t propose to have a definitive answer (maybe we can move toward that through this), but the point is, game author’s want more dynamic responses, based on any number of variables including previous topics, the time of day, what has occurred in the game, the state of play, and possibly even the emotional state of the character.

My own (limited) game design and wishes took me further.

Consider related desires. It has often come up that author’s want, say, room descriptions to change based on, well, more or less the same things listed above (though emotions come into it less). Similar design choices could be made for object descriptions, NPC descriptions, etc.

I had this revelation one day, as I began to see patterns in this. It finally occurred to me:

In a text adventure (or “interactive fiction”), everything is a conversation.

Let’s list some examples.

1) NPC conversation. The player wishes to ask characters in the game about things, requesting responses to topics. The character responds with information (or some non-committal shrugs or “I don’t know”, if not).
2) Room descriptions. The player makes queries to the game about the room. We ask the room, “Tell me about yourself,” and it responds. This extends as well to scenery. We often will put scenery objects into a room just to hang descriptions off of. These are not interactive objects as such – they exist in the game framework just so the user can type something like “x carpeting” and get a response. In the mindset of conversations, this could be thought of as asking the room about its carpeting. (In other words, the room is the character we’re conversing with, and the “carpeting” is the topic.)
3) Object descriptions. Similarly, when we “x” an object, we are asking it to describe itself.
4) NPC descriptions. Sort of like object descriptions but with a different feel.
5) Hints. Hints are really a bit of a one-way conversation, a running commentary by the game on what you’re doing. Certainly, there could be a “hint” command that forces a response, but there is also the system whereby hints are offered unbidden at the appropriate times. This, in a real sense, is the game conversing with you based on the state of play.

So you might be wondering why I’m trying to lump everything into conversation. The reason why was mentioned before: because we want all of the above things to have a certain dynamic to them, and that dynamic is common across them. We want them to not be static. We want them to change over time, not only randomly but in response to the game world. In a very real sense, as we are playing a game, we are in a conversation with the game itself, and we want this conversation to be alive and engaging.

Currently in Quest, the above areas are handled separately. Room, character and object descriptions (well, rooms and NPCs are objects, after all) are handled via a “description” attribute, which can be a string or a script. Ask/tell are handled via string dictionaries. And hints are basically “roll your own.” Which means that if you wanted to add dynamic responses for all of them, you’d need to implement separate code in separate places.

I’d like to change that. I know in my games (largely contemplated and only minimally implemented, mainly due to wanting too much), I have made stabs at implementing the above pieces.

One example: I wanted my rooms to have “directional descriptions”. By that, I mean that you would get a different description depending on which way you came into a room (or “area”). As an example, let’s say you’re outside in a clearing and you see a path to the north, so you type “n”. A stock description once you get there would be “You’re on a path. To the north, you can see a pond. A clearing lies to the south.” That bugged me a bit. Of course a clearing lies to the south – I was just there. I have walked north. In my head, I’m facing north.

What I wanted was that if you came north onto the path, it would say something like, “The path continues north. You can see a pond in the distance.” Whereas, if you came onto the path from the north, heading south, it would say, “The path winds further south, leading to a clearing.” Now, we can get into debates about where the full set of exits is listed. My option was to have a ubiquitous “exits” command that would dump the out (e.g. “You can go north and south.”) There are other ways to do it. But the point is: the game responds in context. To me, that is much more immersive than “push level B and get response Q”.

Now even if directional descriptions don’t make sense to you, other things undoubtedly will. For example, if you have a game that spans days within the same environment, you might want the descriptions to change based time of day or what the weather is. A whole host of possibilities come up. The same might be true even of NPC descriptions: in the beginning, the sidekick is immaculately dressed in blue. After the flight from the enemy agents, her top is torn and her hair is askew. The next day, having changed, she’s in black jeans, and she has donned a graying wig and wrinkled skin prosthetics like in “Mission Impossible.”

How would you do all that? Lots of “if” statements? I must confess – I love writing code, but it makes my skin crawl to write lots of special-case code, because it’s incredibly brittle and requires all sorts of mental gymnastics to keep straight. I’d rather write some nice general, data-driven code that seemingly by magic does the right thing.

So now we’re down to the proposal part – I’d like to begin working on a community Quest “conversation” engine. Not a library. Not “ask/tell”. I mean a full-on, topic-based, evolving over time sort of engine that anyone can use and enjoy. To that end, I’d like to get any thoughts that people have on the subject, any design considerations, possibly even any code designs that you’ve tried yourself. For anyone who’s interested, let’s put our heads together (and chickens are welcome as well as pigs – if you don’t know what that means, either skip it or look it up).

There are different approaches to NPC conversation, but I want this engine to be something that can be used universally in a game as well as (on some level) for all those things listed above. Perhaps that’s too big an ask, but I want to set the bar high going in. Then we can see where we get to.

I’m going to follow this post up with some of my own (soon), but I wanted to get this started.

(First of several parts)

What we will call “conversing” (I’m going to stick with that, as perhaps it will someday become more like that) is in reality selecting text to display to the user – choosing something for a character to “say” – either in response to a query (direct trigger) or based on conditions (indirect trigger).The trigger might have a topic or topics associated with it (e.g. a query about a topic), or the trigger might be neutral (e.g. a hint engine that runs on each turn searching for phrases to present, or a particularly chatty NPC who offers up information in his/her own when the time is right).

How do you select what to say? For things like object/room/character descriptions, the standard is either a hard-coded string or some code which typically selects and assembles the output based on whatever specific logic is programmed in. For something like ask/tell, the implementation is a string lookup in a dictionary.

That is the current state-of-the-art in Quest. There’s any number of ways to go as far as how we can implement string selection. I’ll cover a couple of directions I have explored.

Boolean Logic

The most straightforward is to implement some sort of hard “yes or no” selection. That is, we look through the available phrases and see which ones match. Either a phrase matches or it doesn’t. What to do if more than one matches depends on the situation (and so complicates things a little bit). For interactions with an NPC, you’d probably want it to spit out a phrase at a time in response. You could randomly select one, for example. Another possibility is to show all matching phrases.

The latter is what I did in my room description implementation. Each room could have various “topics”. A topic would then have conditions. Standard topics included “base” (the base description), “first” (text to show the first time), “later” (text to show when not the first time), “north”/”south”/”west”, etc (text to show based on arrival direction), etc. Custom topics could also be added, depending on conditions and needs.

A sample room might have text like:

<baseDescription>"This is the second floor landing."</baseDescription>
<westDescription>"Further to the west you can see an archway leading to another hallway. A broad staircase leads up and down."</westDescription>
<eastDescription>"The hallway continues east. A broad staircase leads up and down."</eastDescription>
<upDescription>"The stairs continue up. A hallway heads off to the east, and through an archway to the west, you can see another hallway."</upDescription>
<downDescription>"The stairs continue down. A hallway heads off to the east, and through an archway to the west, you can see another hallway."</downDescription>

The description would be a combination of the base description and any directional ones. So, for example, if you move west to get the landing it will show:

This is the second floor landing. Further to the west you can see an archway leading to another hallway. A broad staircase leads up and down.

which is a combination of the “base” and “west” descriptions. (The fact that strings are surrounded by quotes is due to the fact that I would “eval” the attribute to get its real value. This allowed me to put expressions in the strings.)

Here are some of the conditions (in the base room type) that trigger the various pieces:

<firstCondition>not GetBoolean(room, "visited")</firstCondition>
<laterCondition>GetBoolean(room, "visited")</laterCondition>

Now, this is all well and good and works fine for rooms. The conditions can vary, and the text shown will vary accordingly. But it is very static. What it’s missing is any sense of history, any inclusion of what has been shown (to some extent, what has been “discussed”). For NPC interactions, I wanted more.

Fuzzy Logic

Moving beyond the yes/no, hot/cold, show/don’t show of binary, Boolean logic, we arrive at another alternative – that of fuzzy logic. I have only toyed with a test implementation of this; with no real world uses, it might end up needing some more design to make it all work properly. I’ll describe what I have considered so far.

The basic idea behind this is the notion of a current “conversation context”. This context holds information about the current set of topics. This set of topics changes over time as different topics are explored.

Each NPC would have its own conversation context. Each possible phrase would also have related topics. Triggering a phrase will update the conversation context, which will then influence subsequent phrase selection. Let’s see how this might work with an example.

Here are the phrases. The first part is the string. After that is a list of topic weights associated with that phrase. Weights range from 0 to 100. (There might be a use for negative weights as well.) I hope this isn’t too contrived…

[id=1] “My father was a farmer.”, father=100, farming=100, family=50, history=80
[id=2] “I grew up on a farm.”, farming=100,history=80,home=100
[id=3] “My brother’s name is John”, brother=100, family=50, john=100

Let’s look at these a bit. For the first one (“My father was a farmer.”), we have the topics “father” and “farming” being a strong match. The topic “family” matches 50%. The weights have two purposes:

1) They help in matching by showing how much a topic matches the phrase.
2) They are used in modifying the conversation context when they are used. (More on this below.)

The idea behind 2) is that our minds are very associative – when we discuss topic “A”, it brings in other related topics (“B”, “C”, and “F”). We want to have a similar behavior in our phrase selection.

Initially, the conversation context is empty. Nothing has been discussed.

Context = {}
Let’s say the player enters “ask about father”. Due to this, the “father” topic gets injected into the current conversation context:

{ father = 100 }

Now, we search. The search is done by generating scores for each phrase via a sort of “dot product”. (If you don’t know what that is, don’t worry.) Basically, we multiply the context with each phrase’s topics and generate a score. In the following, the first number multiplied is the value in the context; the second number is the number in the phrase weights. A missing weight has value 0.

[id=1] score = (father) 100*100 + (farming) 0*100 + (family) 0*50 + (history) 0*80 = 10000
[id=2] score = (father) 100*0 + (farming) 0*100 + (history) 0*80 + (home) 0*100 = 0
[id=3] score = (father) 100*0 + (brother) 0*100 + (family) 0*50 + (John) 0*100 = 0

In this case, phrase 1 is the clear winner. If the topic were “brother”, I hope it’s clear that phrase 3 would be the winner.

Let’s see what happens if we have “ask about family” as the topic. In this case, the context would be {family=100}. Running scores, we get:

[id=1] score = (family) 100*50 + (father) 0*100 + (farming) 0*100 + (history) 0*80 = 5000
[id=2] score = (family) 0*0 + (farming) 0*100 + (history) 0*80 + (home) 0*100 = 0
[id=3] score = (father) 100*50 + (brother) 0*100 + (John) 0*100 = 5000

In this case, both phrases 1 and 3 match “family” about the same. What happens is to be defined. Either it could spit out one phrase (chosen randomly perhaps, or in order), or it could spit the both out (“My father was a farmer. My brother’s name is John.”).

Let’s go back to the “father” case. In that case, we would have a result of phrase 1. So the NPC would say, “My father was a farmer.” Based on standard human conversational associations, we would want to update the conversation context with any related topics brought in due to that phrase. I’m not sure of the ideal algorithm for that. For this case, let’s assume we generate averages. (A better weighting scheme might make more sense.)

Context = {father = 100}
Phrase = {father = 100, farming = 100, family=50, history = 80 }

new “father” = (100 + 100)/2 = 100
new “farming” = (0 + 100)/2 = 50
new “family” = (0 + 50)/2 = 25
new “history = (0 + 80)/2 = 40

New Context = {father = 100, farming = 50, family = 25, history = 40)

This is now the current conversation state. What I had wanted was for NPCs to be able to initiate conversation as well, not just respond to player queries. If the player were idle in this case, the NPC might decide to come back with its own search for something to say. Performing the search again with the current conversation context (let’s assume we won’t repeat a phrase), we get these weights:
[id=2] score = (father) 100*0 + (farming) 50*100 + (family) 25*0 + (history) 80*40 + (home) 0*100 = 8200
[id=3] score = (father) 100*0 + (farming) 50*0 + (brother) 0*100 + (family) 25*50 + (John) 0*100 + (history) 40*0 = 1250

In this case, phrase 2 matches, so the NPC will follow up with: “I grew up on a farm.” After this phrase is uttered, the conversation context will be updated to:

New Context = {father = 50, farming = 75, family = 12.5, history = 60, home = 50)

Note that we didn’t discuss “father” again, and so its weight has decreased. Also note that farming has been emphasized. And we now have a new topic (“home”) which may trigger additional, subsequent phrases.

There are many variants to this, possibilities for manipulating the parameters. Perhaps the new conversation context should not be a simple average but a weighted one. Perhaps the conversation context should “decay” over time, if there is no conversation (that is, if you cease talking, the weights gradually move to 0 and disappear with each command). Perhaps a new topic injected should enter into the context with some lower weight than 100. As far as not repeating phrases, perhaps the “memory” of a phrase being spoken decreases over time (possibly at a rate determined by the age of the NPC), such that it will eventually be repeated. There would also need to be some determination of what to do if either no phrases match (“I don’t know about that”), or all matching phrases have already been spoken (“I don’t have any more to say about that.”)

There is one downside to these weights which needs to be addressed. A queried subject might want to be searched more forcefully than one where the NPC follows up on its own. For example, after “ask about father”, if the player enters “ask about the moon”, it wouldn’t make sense for the NPC to come back with “I grew up on a farm” (which it would if straight weights were used and the priority of the topic wasn’t taken into account). One way to work that out is that a new query from the player generates a new temporary search context with just that topic, with the weights from any chosen phrase adding into the current context afterwards.

Next: Bringing in the world state, the best of both worlds, and some emotions.


(Note – this article is referenced below:

Assuming what we have been discussing so far actually works, then we now have some sort of scheme for modeling an evolving conversation. It does mean that you as the author have to actually go in and create all the response phrases – and decide all the topic weights. While the thought of having NPCs actually generating utterances on their own (putting words together to form coherent sentences) is a wild pipe dream, that is not what we’re talking about here.

(Aside: In Emily Short’s article listed above and in her other ones, she uses the word “quip” for what a character says. While that is a bit of a fun word, it had a connotation to me of levity which I didn’t think was generally applicable. So, being the programmer that I am, I am going with the more generic “phrase”. Even that might not be entirely accurate, but we need something.)

What we have gone over attempts to address selecting phrases based on topics, but it’s fairly self-contained. The only inputs are topics. We also want to interact with the game world, to somehow have the world state influence phrase selection.

By “world state,” I mean pretty much anything of interest in the game world. It can be things like:
– where the player is
– where they have been
– what they possess
– what they have possessed
– whether a murder (or some other significant event) has occurred
– the time of day
– the presence or absence of other NPCs
– the emotions of the various NPCs
– who has just walked past in the corridor
– choices the player has made in the past
– anything else relevant to the story being told (or the puzzles therein)

You could, in theory, use weights for that, and inject state in as topics. I tried that for my room descriptions at first but quickly abandoned it. There are two problems:
1) You need to create a topic for each piece of world state (“has_stake”, “visited_crypt”, “saw_vampire”, “killed_vampire”, etc or, in my case, “east”, “west”, “north”, etc ), which can quickly become unwieldy.
2) Such state is typically binary – we only want certain phrases to be eligible when certain conditions are true. In order to do binary in a weighted scheme, you have to not only add weights for what you want but also (short of some notation which I tried and gave up on) add negative weights for what you don’t want, to prevent the phrase from being selected when those topics are present. It’s possible but, again, quickly becomes painful.

What I have come to is that we want to somehow utilize both schemes, “binary” and “fuzzy”. The “binary” part would be used for phrase eligibility, based on world state; the “fuzzy” part would be used for selecting from among the eligible phrases, based on topic or other fuzzy considerations. This is the next area of thought for me, so I don’t have any ready answers yet. Perhaps some sort of uniform notation could be adopted. I’m open to that if it would work; in fact, I’ll probably revisit it myself, as I like to unify things.

One piece of “world state” we might want to consider is the emotions of the NPC. For example, if I ask a character about her father, if she loves me, she might respond, “I can’t wait for you to meet Papa!” whereas if she is feeling antagonistic towards me, such queries might be met with, “That’s none of your business!” or something even more venomous. Whether such state is “hard” (binary) or “fuzzy” is really a question of design, depending on how the emotions are modeled. That’s another discussion to be had. It could be implemented as simply (but crudely) as a boolean “inLove”, if that’s all you care about, or as a variable “loveState” ranging from 0 to some upper number, or as a scale ranging from hate to love. You can also have different ranges for different kinds of emotions. The point is: you will need to determine how that is going to be modeled before you can decide how to integrate it with a conversation model. Hopefully, if this all comes together, you’ll have plenty of flexibility to do it the way you want.


A random, somewhat related thought: this one’s about room descriptions.

Typically, room descriptions are centralized. When I say “look”, it goes to the room object (in Quest) and says, “Give me your description”, and that description is either a string or a script. And there is boilerplate code that dumps out the objects in the room, the exits, etc.

Now, let’s say that conditions can change in the room. Maybe a chair is there sometimes and other times not. How do you handle it?

The typical way in Quest is via an “if”. You make your room description a script, you dump out the stock part of the room description, and then you put in an “if”: “if the chair is in the room, also print *this*”. It’s all a bit clunky, and it’s also rather centralized. The room has to know about the possibility of the chair. It’s all very static, very hard-wired, very brittle.

Let’s turn the notion on its head a bit. What if we look at the command “look” as an invitation from the player for description, which goes not just to the room but to all within it. Now, instead of the room having to know that a chair is possibly there in order to add in custom text, we will have the room respond with its description and we’ll let the chair chime in as well with its own description (with such description being the minimal “There is a chair in the corner” sort of thing, with a full description forthcoming if the player directly queries the chair further). And if the chair isn’t present, well, then nothing is there to say it. Imagine the room saying in a booming voice, “You’re in the library” and then you hear a small voice from the corner say, “There’s a plush chair in the corner.” They get written out together in one block of text. Now, instead of a single voice, we have mutiple voices all responding together. Instead of having to put “To the east, there is a foyer”, the east exit will itself add in the text to alert the player to its presence – if it wishes. “Hey look! You can go this way.”

A bit bizarre on first thought, perhaps, but I really like this sort of thing…


I’m in the process of working on a general “response” library, which I’m using in a fledgling game. The game is forcing me to actually use it in a real-world way, and it’s helping to point out where the design has flaws or can be expanded. Lots of uses cases being folded in…

To back up, I had a bit of turn of thought, based on (what else?) terminology. I came to realize that the word “phrase” was not very good, as it just didn’t fit with what it actually was, since a phrase is a piece of a sentence. So I went in search of a better word. I came across “response” and it stuck. But that word opened up new directions in thought. A response need not be verbal. It could be a reply, but it could also be a shrug, a smile, or even a punch in the face.


by Jay Nabonne at June 21, 2016 04:09 PM

ResponsIF supports associations among topics, which is something I consider important. What does this mean? Let’s give an example from real life.

Say it’s morning, and you go out for a walk with the dog. The sky is gray, but your mind is pondering the day ahead of you. There’s a problem you’ve been assigned to solve, and it’s important that it be done soon. You walk absently, your mind exploring possibilities.

As you approach the corner shop, the sight triggers a memory – you need bread. For a moment, your thoughts of the problem at work have been displaced. You think about when you might be able to get some bread as you continue on, and soon that thought fades. Re-gathering, you return to your original pressing thought.

Waiting to cross the road, your thoughts are displaced again by the need to be aware of the traffic and the proximity to your dog. An old fashioned car cruises by, and you’re reminded of that film that you saw when you were younger, about the car that could fly.You think about the actor who was in it, and of how you used to like to watch his TV show. It was quite an old-fashioned TV show, black and white, but your parents liked to have it on in the evenings in the living room.

That living room was what you entered when you were done playing with your friends outside. You remember the cool evening air when you used to ride your bike and play ball. You remember the time you went off that insanely high jump on your bike, and that time you fell. You also remember that time you feel off your skateboard and fractured a rib.You can almost feel the pain, and how you almost couldn’t breathe.

You register that the traffic has cleared, and you head across, alert to any oncoming cars you may not have seen coming or that may be coming quickly.

Having crossed the road, you follow a path beside the grass. There are flowers growing there, and delicate purple ones remind you of – you almost can’t even bear the name, you miss the person so. Suddenly, you feel the loss all over again. You can’t help but recall images of the last time you were together, of the words spoken, of the tears shed. The heartbreak has faded to a dull ache, but it doesn’t take much to flare it up.

An elderly man approaches you along the path. He smiles and waves as he passes. He told you his name once, but it didn’t stick.

For a moment, you’re in tune with what’s going on around you. You hear birds chatting in the trees. You hear cars drifting by. You smell the remnants of last night’s rain, which you remember made the windows shake and the dog jump. It was impossible sleeping during the downpour, but it was ok, because you like the sound of rain.

The smell of fresh, hot food greets you as you approach a small shop. You remember you need bread. You’re not sure when you’ll be able to get it, because of the time pressure at work…

And you’re back to  your original thoughts.

I’m not sure if that seems familiar or not, but it certainly is for me. I find my head is an ongoing stream of thoughts, steered left and right and up and down by ongoing associations, either to other thoughts or to external stimuli.

Assuming that is how a human mind works, on some level, the obvious question is whether or not you’d actually want that going in your NPC’s “minds”. The interesting thing about what happened above is that there was no external indication of what was happening. There was no speaking or obvious signs of emotion. It was all internal. Does it make sense for NPCs to have an inner life? Traditionally, IF has been about what the character does: what it says, where it moves, whether it attacks you , etc. The invisible inner workings have taken a back seat or not been bothered with at all. After all, does the player care?

I can only say that I’m interested in giving it a try. The reason why is that the inner state influences the outer. Let’s say that someone were to approach you along your walk and attempt to engage you in conversation. The response you give might well be determined to some extent by what’s happening inside. If you’re thinking about what you have to do and how you have no time and how you don’t know what to do and how you really have to work out the problem, your response might be annoyance at any intrusion. If you are forced to respond while you’re contemplating your lost love, the response might be considerably different.

Having this sort of NPC inner turmoil (or at least ongoing inner state fluctuations) could help provide a more varied response during game play, depending on what’s happening or has happened in the past.

One thing you may have noticed in the narrative above was the continual return to thinking about the pressing long term goal. Little distractions came in, some even causing ripples that lasted a while, but eventually, when the water calmed again, the long-term goal came to the fore again. This points to several key things:

  1. Long vs short term topics. Short-term topics have a short lifespan. They are the introduction of topics into the thought stream that cause ripples or even a splash, but they have no sustaining energy. They’re fleeting, disappearing as quickly as they come, replaced by either their own descendants or simply fading away unless sustained. Long-term goals, on the other hand, are constantly there, although perhaps at a lower level.
  2. Higher and lower priorities to topics. Thoughts of work took precedence over thoughts of buying bread, ultimately. But external stimuli were able to temporarily overpower long-term thinking. Responses occurred or not depending on which topics had current weight, and those weights changed over time.
  3. The internal topic patterns oscillated or could oscillate. This is a powerful concept for me, one I’d like to explore further in a separate blog post.

Without delving too deeply into it, there are two primary mechanisms ResponsIF uses to associate topics. First, a response can trigger via multiple topics. This allows topics to be grouped in terms of the effect they have. Second, topics can trigger responses which can then add possibly different (but related) topics either back into the responder or out to other responders via suggestions. And the topics can be weighted appropriately. So, for example, the topic “family” might introduce topics for “mother”, “father”, and “Sarah” with relative strong weights, but it might also introduce the topic “farm” and “Pine Valley” with lesser, but still existent, weights. And if the discussion just prior also had weights for one of those lesser topics, it might be enough to push it up enough in priority to cause a response.

Topics are the glue that link response together. Responses tell you what happens in a riff. Topics tell you what the riff is all about.

Explorations in Interactive Fiction

by Jay Nabonne at June 21, 2016 04:09 PM

This is my first post before diving deeper into both my thoughts and efforts around interactive fiction. It will provide an overview of where I am and where I’d like to go.

Let me begin by saying that my definition of “interactive fiction” may or may not be the same as anyone else’s. The term has been applied to such disparate concepts as parser-based “text adventures” and hyperlink-based “choose your own adventure” or “gamebook” creations. In fact, if you look at the Wikipedia entry for “Interactive Fiction”, it begins with the definition that IF “use[s] text commands to control characters and influence the environment.” It states later that the term “can also be used to refer to” gamebooks. There has always been a bit of a divide between those two camps.

For my own purposes, I consider “interactive fiction” as hewing closely to the name – fiction that is interactive. That’s it. It can include all of the above and more – where “more” can include new ways to make fiction interactive that might not even have been conceived yet. If it’s not clear yet, I have my own ideas about the types of IF works (“games”? “pieces”?) that I’d like to create.

I won’t define IF for you, but I hope the things explored under this umbrella can provide food for thought, if nothing else. The majority of ideas discussed here will be in relation to my “ResponsIF” system, a response-based interactive fiction engine written in JavaScript, but that doesn’t mean that they can’t be applied to other systems or just considered in general. You don’t have to use ResponsIF or even have a desire to do so in order to take something from all of this.

With that, I’ll end this general overview, and we can get down to business.

(For those interested, the latest version of “ResponsIF” can be found here:


by Jay Nabonne at June 21, 2016 04:09 PM

I’ve been learning about and experimenting a bit of late with fuzzy logic. In fact, I decided to implement a variant of it in ResponsIF. For those who don’t know, unlike in “crisp” logic where you have only two values (“true” or “false”), in fuzzy logic you have a continuum of values ranging from 0 (“false”) to 1 (“true”). A value represents a level of certainty or degree of something. For example, if you’re happy, your “happy” value might be 1. If you’re almost perfectly happy, but not quite, your “happy” value might be only 0.85. If you’re only a little bit happy, you might be down to 0.1.

Such variability comes in handy for attributes that don’t have hard edges. A person who is six feet tall would be considered tall, but how about someone only five-nine? And how about down to five-seven or five-five? As you can see, there is no clear line for “tall”, where you can say everyone above this value is tall and those below are not. There is not “you must be this tall” in life. The “tallness” attribute tapers of as height decreases. As it decreases, there is less certainty. Things become iffy. Things become fuzzy.

This blog entry came to be because I happened upon something interesting in relation to that.

In normal logic, you have certain tautologies. One of them is that “A and not A” is always false. This is so because “A” and “not A” can never both be true at the same time, and “and” requires both arguments to be true for it to be true. Similarly, “B or not B” is always true, as either “B” or “not B” will always be true, which makes the “or” true as well.

In fuzzy logic, things aren’t quite so simple.

Fuzzy logic uses “min” for “and” and “max” for “or”. That is, to compute “A and B”, you take the smaller value of “A” and “B”. To compute “A or B”, you take the larger value of “A” and “B”. These fuzzy operations happen to have the same behavior as the standard logic ones when “A” and “B” have extreme values (0 or 1). Check out the numerous truth tables on the web if you’re unsure.

In between the extremes, things aren’t so clear.

I came to think about this because, in ResponsIF, a “need” was initially considered met if the final value evaluated to 0.5 or greater. I began to think about the 0.5 case. Should 0.5 be considered met or not?

First, it occurred to me that “A and not A” when A is 0.5 evaluates to 0.5 So that means that an expression like that would actually satisfy the need at 0.5. That seemed wrong to me. “A and not A” is always false! (Or should be.)

But then I thought of “A or not A” when A is 0.5, and I realized it too is 0.5. Hmm. But “A or not A” should always be a true value. Or should it?

So when A is 0.5, both “A and not A” and “A or not A” have the same middling value.

I had a choice to make: do I consider 0.5 satisfying a need or not? I was getting no help from “and” and “or”. They were both ambiguous at 0.5. And that’s what led to my final decision: 0.5 does not satisfy a need. That’s the 50-50 case, the “it could be or it couldn’t be”. It’s just shy of a preponderance of the evidence. It isn’t anything definite.

I made the change. It might seem a bit strange to someone reading this that I pondered such a small thing at all, or for any length of time, but such tiny decisions are what go into designs like this. You have to work out the minutiae. You have to make the little decisions that sometimes end up to having large ramifications.

Sometimes pondering this level of things brings unexpected thoughts: if 0.5 is on that edge between false and true, if it’s a no-mans land, perhaps it becomes a coin toss. Perhaps when evaluating a need, if it’s 0.5, then it generates a random 50-50 result, sometimes true, sometimes false. That has some interesting ramifications which I might explore someday. In particular, I began thinking perhaps it should always be evaluated that way, as a chance. Not an “above or below this limit” but a random coin toss, where the coin is weighted by the need expression result. For example, if it evaluates to 0.8, you’d have an 80% chance of the need being considered met. Similarly, 0.1 would only give you a 10% chance. The extremes would still work as expected.

I don’t know if that makes sense at all. But it is fun to think about. It did have the result of making me start to consider whether “needs” should stop being a crisp choice at all, whether the “needs” value should just be an additional weight. That goes against its original emphasis, which is that a response allows you to configure it in both crisp and fuzzy ways. But I have to have these design crises on occasion to make sure I’m doing the right thing. Sometimes “the right thing” only becomes clear after doing something else for a while.

Like having 0.5 satisfy a need. It did and now it doesn’t.

Though sometimes I wonder if I made the right choice. It could have gone either way, really…

Oh, I don’t know.

Wade's Important Astrolab

Tunnel Runner on Wade-Memoir

by Wade ( at June 21, 2016 03:42 PM

I lost June to what doctors think was viral meningitis. It wasn't easy to diagnose, but I had two overnight stays in hospital and have been spending the rest of the time at home. I also developed double vision. The vision is expected to self-correct over time and it does seem to be improving a little each day. Today I tested my computing abilities (with a patch over one eye) by writing this and updating one of my websites, Wade-Memoir, with a parser/shoot-em-up (?!) bit of game, Tunnel Runner, from when I was ten. You can go to the Tunnel Runner post by clicking this sentence.

Why I thought of Tunnel Runner today: While my vision was really messed up, I couldn't read and I couldn't watch anything, so I listened to a lot of podcasts. One of them, No Quarter (about classic coin-ops) mentioned that the hosts were supporting the crowdfunding for some turn-based shoot-em-up. This sent my mind back – way back – to Tunnel Runner. It was meant to be a sideways shooter like Star Blazer or Scramble. How it came out is that you use a parser to enter commands to move your ship. Today I wrote this game up in my blog Wade-Memoir, making it my first post there in half a year.

I was having motivation troubles writing the last example for my WIP Inform CYOA extension before I got sick, probably because I've already written a good number of examples that interest me more. This last one needs to be the most fundamental, in a way, and is intended to be the first one for a user.

Soon I hope to be reconstituted enough that I should be able to recommence using my will to force myself to do certain things. Or a day may come when the sun is especially bright (it's winter here) and a particular shaft will hit me in a particular way and inspire me to do it without me having to kick myself.

Sibyl Moon Games

Beet the Devil on Clash of the Type-Ins

by Carolyn VanEseltine at June 21, 2016 06:01 AM

I spent a wonderful afternoon hanging out on Skype with Jenni Polodna and Ryan Veeder for their podcast Clash of the Type-Ins. It’s a rather unusual podcast in which IF authors read through their games out loud while the hosts play them.

In Episode 33, they played (and I read aloud) Beet the Devil, my religious comedy involving vegetables and a puppy.

The recording is the longest podcast I’ve ever been on (a good 145 minutes!) but we had ridiculous amounts of fun. If you have a long session of folding laundry or cleaning or driving ahead, give it a listen. I don’t recall the game ever having boss music before, but it does add a certain something.


Two Quick BOYD Discoveries

by Hanon Ondricek ( at June 21, 2016 05:48 AM

I didn't think I'd be interested in the non IF stuff, but some of it has been eye-opening.

First is How to Kill a Project by Wertle, a game designer named Lisa, who has created a biographical Twine which explains some of her experience with creating and abandoning games.  A few of these are actually embedded in the Twine and playable.  Favorites are Death Jeopardy and Imperfection.

It's interesting to see how certain game systems can be embedded in a choice-based story and inspires ideas such an interactive game map or a small physical puzzle or a graphical inventory.  The author's backstory is also interesting and this is an amazing use of Twine.

Watch your ankles on those stairs.
The second is not IF related at all, but has a very cool Portal vibe and an interesting concept.  Conflux's conceit is that certain 3D physical structures are incomplete until you view them from the correct perspective.  There isn't any documentation, but standard 3D controls, WASD-space-mouselook work, and left click will pick up an object.  This is obviously unpolished as there isn't a lot of feedback until you find the right precise spot to solidify a structure, and it is sometimes hard to tell if what you're seeing is "right" or not.

This is still a unique concept, a step on the way to the non-euclidean game I've always wanted that allows physical exploration of Escher-esque spaces.  This isn't it, but I liked it.  It's Mac only.
I use WYSIWYG to make it look like I know how to make a website at

June 20, 2016

The Gameshelf: IF

June 18, 2016


Bring Out Your Dead Jam

by Hanon Ondricek ( at June 18, 2016 05:31 PM

Lots of popular IF heavy-hitters have posted unfinished works to Emily Short's unusual Bring out Your Dead jam which lets authors put unfinished and "dead" projects on display.

The jam is only on for about a week, so I don't know if these titles will be available or disappear afterward, so be sure go check out early experiments by your favorite IF figures such as Emily Short, Andrew Plotkin, Sam Kabo Ashwell, Caleb Wilson, A. Deniro, Carl Muckenhoupt, David Cornelson, Mathbrush, Laura Michet, Bruno Dias, Catacalypto, and possibly more as the six days of the jam progress.

The jam is not restricted to IF so there are some other interesting game experiences on display.  Many other people are blogging about this, so I won't go on in detail.

Interactive Fables

Welcome to our Blog

June 18, 2016 03:57 PM

Welcome to the first of our semi-regular updates about the progress of Worldsmith and Interactive Fables. It's kind of an exciting time. Our first game is moving towards completion and we hope to release it in September 2016. Or, maybe, October 2016. Hey, we're a small team.  Worldsmith is being written by Mike Preston, the author of Interactive fiction games Map and Fifteen Minutes. Oh, and the *cough* Hard Puzzle games - but the less said about those, the better. We are developing the game in

These Heterogenous Tasks

Bring Out Your Dead: The Shotgun Adagio

by Sam Kabo Ashwell at June 18, 2016 03:01 PM

OK. The next Bring Out Your Dead game I am way more conflicted about: The Shotgun Adagio.


I missed a trick by not rendering the subtitle as che l’aura nera sì gastiga.

It’s much more ancient than IFDB2, and I am in a much more conflicted state about whether to publish it, because it is such egregious garbage in such a wide variety of ways that I have long been intensely grateful for the hard-drive crash that scrambled my source code and saved me the retrospective embarrassment of inflicting it on the world. I was a not-very-mature seventeen when I started writing it, and effectively abandoned it at some point early in my first year of university, after a merciful hard-drive crash wiped the most recent version of my source. (What there was of it had already been through a few rounds of testing. I still feel kind of guilty about wasting their time.)

So, OK, it’s juvenilia, which means that it’s excusable but I am nonetheless pretty embarrassed by it. Let’s briefly survey its sins.

It’s angsty; I was sliding into a prolonged stage of major depression as I wrote it. It’s pretentious; I was desperately in need of a creative community, and I really really wanted the IF world to see me as a Serious Writer. And it aims at a sort of gritty muscular swagger which, y’know, kiiind of suggests that maybe I wasn’t feeling as though I was taken seriously As A Man.

The general tone can be summarised as an attempt to conjoin the moods and aesthetics of The Matrix with Crouching Tiger, Hidden Dragon, only as a vampire epic spanning centuries. So, y’know, ideal material for a text adventure. (I planned it to be my second release, and considered myself awfully mature and pragmatic for not going straight to the Epic Piece.) I don’t think I had seen Blade yet when I started, but when I did I was very annoyed that they had pre-emptively plagiarised my vampire-with-a-black-leather-trenchcoat-and-katana thing.

The prose is crap. That I can deal with; vanishingly few people can write worth shit at seventeen. The utterly crap dialogue is a little harder for me to stand. The fractured structure isn’t great design, but it’s largely down to being excessively influenced by Worlds Apart and Photopia, and to the naive idea that obscurantism looks profound. The atrocious puzzle design is understandable – at the time I wasn’t very good at puzzles and assumed that everyone in IF was way better at puzzles than me, so I figured that it was fine if stuff was difficult – but it does kind of stop me from getting very far my own game even when I look at the source code. I’m not sure if the stoned dream-sequence has a killer bug, or what. There are probably some testing verbs which would get you past it. (Technically the game should be largely complete well into Act 3.)

It uses some fucking awful tropes. I distinctly remember looking at my story, thinking ‘none of the people I care about die, but this is meant to be a world of brutality and death. Who can I kill off? Oh, wow, I could have the girlfriend get murdered. Whoa. That’s uncompromising.*‘ The protagonist vampire is a white dude who somehow rises to become the most important and powerful figure in a predominantly Sino-Japanese vampire-nobility underground, but he is also a brooding loner, but he also is surrounded by cool, diverse, highly competent allies with whom he is super buds. Many of them are from non-Anglo cultures, and, uh, my level of understanding of those can be signified by my habit of basically just making up names that I thought sounded about right. Go on, GUESS THE NATIONAL ORIGINS:

  • Filivek Angharis
  • Ayesha Chiariesku
  • Danio Lapacha
  • Tyan Skaschii
  • Aluka Kiitake

How do you wear paired swords with a black leather trenchcoat? Wesley Snipes strapped his katana to his back, but he was a quitter. My protagonist has his black leather trenchcoats made with special katana holes.

Obviously as a seventeen-year-old you do shit that you’re terrible at and write about stuff you don’t understand. I mean, writers always write about stuff that they don’t fully understand, but at seventeen you’re enthusiastically interested in a ton of stuff, understand almost none of it, and are very very bad at not exposing the fact. The second scene of the game is set in an edgy underground nightclub, which, having grown up in a sleepy rural English town, I mostly pieced together from movie depictions of edgy underground nightclubs. Then there’s a scene which is sort of about crime scene investigation, which I didn’t know anything about either; thus also for the I Ching. There are bits in there that I (and probably nobody else) can recognise as halting early attempts to render female characters in a non-sexist way, but it ends up being super male-gazey and awful.

I wasn’t really familiar with most of the the genre touchstones I was aiming for, either; I had read basically no vampire fiction, barely any cyberpunk (Shadowrun and Cryptonomicon were basically it), precisely three wuxia movies. Even the fucking title is clueless: I came up with the title first because it seemed badass as hell, while not really knowing what an adagio was.(I retroactively stuck in something to justify the title after I looked it up.) A lot of what I got came from tabletop RPGs. Von Richten’s Guide to Vampires was a pretty big influence. Also, I’m pretty sure that I originally invented Aluka as a way of getting around the limits of Shadowrun‘s magical martial-arts – like, the number of powers was limited by your Essence, but vampires were one of the very few beings that could have higher than normal Essence, so I made this martial-arts vampire NPC and got sliiightly overinvested in him.

OK. I haven’t fully tapped into the vast reservoirs of things that are shit about this. There are shit things that I’m not going to talk about because they are too cringe-inducing. There are shit things about this that I don’t even remember are in there. There are shit things you will, if you are very lucky, discover for yourselves.

And yet. Since then I’ve found myself doing a ton of things with the, uh, extended universe of Adagio. Technically Invisible Parties is out somewhere in the penumbra of that world. I still kind of want to do a game about Akiel Stone, Pythian freelancer, and one about what happens when the wainscot-society-elite genuinely can’t sustain its secrets, and so on. Point is: green things can grow from shit.

* I think that ‘I want all my favourite characters to be safe and happy and virtuous all the time!’ is almost as bad as ‘I want to torment my favourite characters just to show how raw and edgy I am!’ Still.

The Gameshelf: IF

Bring Out Your Dead: Flashpaper

by Andrew Plotkin at June 18, 2016 03:53 AM

A few weeks ago Emily Short declared the Bring Out Your Dead game jam, an event dedicated to sharing our abandoned projects and failed experiments.

The jam opened this evening; submissions remain open until the 24th. I see 31 entries already, including works from Alan DeNiro, Bruno Dias, Adri, Cat Manning, Sam Ashwell, and this honorable blogger.

I posted... the first prototype of The Flashpaper War! And the second prototype too. (Playable on web pages. I've also done iPad prototypes of the game, but posting those isn't really possible. You're missing some cute animations, is all.)

I said a year ago that Flashpaper would be my next IF project. And I still intend that to be true! I built these prototypes last year and demoed them in private; I showed a version at Boston FIG as well. But they just didn't work out, so I scrapped them and started from scratch.

(And then I had to spend some time on paying work, and some more time working on the Steam release of Hadean Lands... which is this Monday, by the way. Just thought I'd say.)

The start-from-scratch plan is still marinating. I have plans. They may even see daylight this year... but for the moment, enjoy these Flashpaper prototypes.

These Heterogenous Tasks

Bring Out Your Dead: IFDB Spelunking 2

by Sam Kabo Ashwell at June 18, 2016 01:01 AM

ifdb1My first contribution to this bonfire is IFDB Spelunking 2. (, personal site.)

So, bear with me. In 2012 I ran Cover Stories, a game jam where people supplied cover art, and then other people made games based off the cover art. One of the images I supplied for it got picked up by Joey Jones, who wrote IFDB Spelunking. Joey used IFDB’s ten random games feature, played the games and recorded his experience.
IFDB Spelunking was part of a long, if sparse tradition. In the 90s they employed the framing of Mystery Science Theater 3000, along with its basic technique: pick a truly atrocious work, then offer a snarky commentary to go alongside it.

CoverI loved the idea. One of the things which came through particularly in Joey’s run was that it seemed as though he’d had a fun time in the process, despite or even because of mild frustrations. And it was such a straightforward template! It virtually invited you to make your own.

With some re-rolls to eliminate games I had already played, I picked ten. Seven of these were available and playable – Mountains of Ket, Samhain, Sweet Sixteen, Dracula Episode 2: The Arrival, Down and Out at the Big Creepy House on the Poison Lake, Take One and ARGH’s Great Escape.

I got pretty far into emulating them, at least on the surface. I sunk a great deal of effort into it. Why didn’t I finish it?

  1. Making it playable was rough. In particular, the largest of the games, Mountains of Ket, is a spectacularly unfair early-80s cave-crawl. I started out working with the principle that players would be strongly encouraged to use walkthroughs, but many of my testers wanted in-game contextual hints instead. They were right, but the thought of implementing all that was kind of overwhelming.
  2. Inconsistent voice. I wasn’t quite clear all the way through if the narration was meant to be a) me, as I first encountered the games, b) me, with the experience of hindsight, or c) a metafiction character whose job was exploring old games for loot. I could fix this but it’d be a slog.
  3. Cloning IF, particularly punishingly hard old-school IF on legacy platforms, is tedious work, especially if you don’t have access to the source. Playing deeply-unfair games on emulators to figure out what they do under specific circumstances is fun detective work at first, but it gets old.
  4. IP. I’m really not enamoured with the current state of intellectual property law, but I’m equally unimpressed by people who think that all data should be open-source and artists should have no special rights to their own work. Basically, if one of the authors came along and said ‘hey, I’m not all that comfortable with you using my game in this way,’ my response would basically be ‘yeah, fair enough.’ It’s kind of hard to commit to the laborious process of polishing up a game if there’s a chance you may end up withdrawing it.
  5. Meta-game. I wanted there to be lots of interactions between objects from different games, and special behaviours that relied on things changing across multiple worlds. I wanted there to be enough of this that the average player would run into a few of them. Given that there’s no way of knowing what order a player will play the games in, this looked to be a lot of work, and what I did implement was fairly trivial.
  6. The major difference between MST3K and its IF descendant is that movies have a higher bar to entry. Even C-list trash like The Killer Shrews required a budget, a cast, crew, distribution; if you’ve been able to manage all that, you should be put-together enough to take your knocks. IF shitgames, on the other hand, are likely to have been produced by enthusiastic fourteen-year-olds, and snarking about them is a somewhat different matter.
  7. Content. Several of the games are creepy towards women, ranging from lacklustre damseling to rape-fantasy, and Sweet Sixteen ranks among the most unpleasant porn games I’ve ever played. I tried to address this appropriately – thus the subtitle – but I’m not convinced that I succeeded.
  8. I ended up feeling as though this wanted to be a work of criticism, and I don’t really know how to do that in a game format yet. Snark and sniping, that’s easy; building a sustained line of argument through a discursive medium is a lot trickier.

ketOK, so why did I want it to see the light of day?

  1. It represents a great deal of work.
  2. Joey Jones really wanted to see it published. Joey was the person I really made this for, and that’s a tough thing to get past.
  3. There were some legitimate points that I felt came out of it – the importance of archiving, the creepy legacy of misogyny that games in general, and IF no differently, have to contend with. I didn’t specifically go hunting for sexism; I did a random search through obscure corners, and it showed up.
  4. I did a bunch of small, silly things that entertained me no end, and which hopefully might entertain other people too. Footnotes are the best thing. Customising I7’s default behaviours to mimic different games was fun. I have far more love for the mistranslated-Spanish section than it really deserves.


Emily Short

Bring Out Your Dead is Open!

by Emily Short at June 18, 2016 01:00 AM


Would you like to share your unfinished and/or experimental pieces in a friendly, curious, and non-judgy environment? Here is Bring Out Your Dead. Submissions run through June 25th 2016. (There’s a countdown clock on if you need exact times.)

These Heterogenous Tasks

Bring Out Your Dead

by Sam Kabo Ashwell at June 18, 2016 12:01 AM


Over this Solstice week, Emily Short is running the Bring Out Your Dead event:

Bring Out Your Dead is an event for sharing dead WIPs and experiments that you don’t expect to finish, but that you’d like to show to someone anyway. It’s a chance to cleanse your hard drive, move on from old ideas, and salvage some learning from things that didn’t work out. It’s also an opportunity for your community to learn from your mistakes — which can be just as useful as learning from a success. Ambitious follies, bizarre experiments, toys, and notions that in retrospect never had a chance — all are welcome.

I love this idea. Unfinished works are by default a private sadness, a pile of ideas and hopes and hard work that died quietly, slowly, alone. They’re often laden with feelings of inadequacy or guilt. Under normal circumstances, it seems extraordinarily self-indulgent to dump them on a general audience; when one releases unfinished works there’s generally an implicit understanding that you intend to continue developing them, that people playing the incomplete version are making an investment in a complete version.

Midsummer seems, on the face of it, like a strange time for this. To me this feels like a midwinter ritual, or a Samhain / Day of the Dead kind of thing: darkness festivals, communal acknowledgements of fear, loss, disappointment, pain. Fires to keep out the dark. Times to burn offerings to end a chapter, or to remember. Midsummer is light, celebration, dance, short nights full of stars; it is still very important that you get drunk, but for joy rather than solace.

…and this odd placement is just right, in fact.  Things out of season. This is an ill star, a party for when your mood ill-fits the party. There was a midsummer night, under the hop-vines, when the beer sat bitter and, for you, the firelight and laughter only made shadows and silence. That’s failed work, misplaced hopes, the thing whose festival is never marked in the calendar because it is never born. (The best bonfires are lit with down-and-dead wood, or else accumulated garden rubbish.) At our other festivals we celebrate work that we’re happy about, that we’re proud to show off, that are successes insofar as we got the damn things out of the door.

And this is as it should be: but it obscures the other side of things, which probably represents at least as much of our creative efforts. It is important to show that all of us, even the best of us, have false starts and failures. It is healing to feel able to bring private sorrows into the light, to be seen, even as the fire takes them.



June 17, 2016

Emily Short

IF and Other Media

by Emily Short at June 17, 2016 05:00 PM

Screen Shot 2016-04-06 at 9.41.33 AM

June 14, the Oxford/London IF Meetup had talks from three speakers. First up was Tory Hoke of Sub-Q Magazine, who Skyped in from Los Angeles to talk about the process of founding and edition for Sub-Q. She gave us some background on how she got started, how she decided on the pay rate they currently use at Sub-Q, and a bit about the collaborative process.

Next we heard from Derek Moody, whose whodunnitmanor project is designed to facilitate multi-player mystery games, where the author has created clues and information for each player to discover at each turn. Different characters have different expertise, as one might expect in a mystery dinner party set-up, and they can decide what to share with one another during any given turn. When the players think they’ve figured out who is guilty, they can vote — which makes this partly a game of persuasion, like Werewolf, in which the guilty party is trying to pass off attention to everyone else.

Moody also talked about how his system is designed to support players who might not feel sure what they want to do, and how automated features take over if a player disconnects or skips out on the game — always issues in a multiplayer IF context.

Both Derek and Tory are currently seeking writers.

Finally, we heard from Nathan Penlington about his Choose Your Own Documentary project. Penlington is a collector of CYOA-style books — his blog documents many choice-based artifacts of all kinds — and at one point he bought numbers 1-106 of the original CYOA series in a single lot on eBay. When his set arrived, he found that the books contained notes from a Terence Prendergast, and several handwritten diary pages. He became fascinated with the question of what had happened to Terence and where he was now, so he made a documentary about the process of trying to track Terence down. The documentary itself was then performed in front of a live audience equipped with voting clickers so that they could respond to choice points in the story. So, to recap: Choose Your Own Documentary is a choice-based performance that is itself about the Choose Your Own Adventure series, as well as several people who became fascinated with them.

Penlington is a really entertaining speaker, and his topic was both touching and hilarious. He has also published The Boy in the Book about the process of looking for Terence. (I was sufficiently curious that after the meetup I went home and ordered a copy.) Apparently a digital version of Choose Your Own Documentary is in the works. There may even be a revival of the live show. I know I’m not the only person to come away from his talk eager to go to the show if I get a chance.

This Meetup also gave me a chance to ask some questions about the choice-based performance process. I’ve always suspected that choice-based live performances might be rather unsatisfying: if the vote goes against you too much, you might feel frustrated; when it goes the way you want, you might still not feel all that great a sense of agency or complicity.

Penlington agreed that the process might be frustrating for some participants, but that he had audience members who came back multiple times to find other parts of the story with a new audience mix. He also mentioned that, during delays for choice, he could often hear couples and groups in the audience whispering together about what their decision should be. I hadn’t considered that possibility, and it does seem like it would add something to the experience — you’d get a chance at a reflective choice in your friend group, whether or not your votes actually prevailed.

Tagged: choose your own documentary, derek moody, nathan penlington, sub-Q, tory hoke, whodunnit manor


Voyageur Devlog #1: Welcome

by e (Bruno Dias (comms@voyageur.spac) at June 17, 2016 03:00 PM

Now that Voyageur has been announced, I can get into more detail about what the game is like. Also: More procedurally-generated content, what's with the name, and what to expect in the coming weeks.

Voyageur Devlog #4: Storytelling

by e (Bruno Dias (comms@voyageur.spac) at June 17, 2016 03:00 PM

In this dev diary, I talk about the way Voyageur presents story. Also: The first in-game screenshot.

Voyageur Devlog #2: Procedural Worlds

by e (Bruno Dias (comms@voyageur.spac) at June 17, 2016 03:00 PM

Voyageur is set in a procedurally-generated galaxy filled with distinct places. In this dev diary, I explain in more detail how those worlds are generated.

Voyageur Devlog #3: Alignments

by e (Bruno Dias (comms@voyageur.spac) at June 17, 2016 03:00 PM

In which I explain the alignments, the system of symbols and ideologies in Voyageur.