Hacking The Web With Interactive Stories

I recently made The Parable of The Hackasaurus, which is a game-like attempt to make web-hacking easy to learn through a series of simple puzzles in the context of a story.

The parable is really more of a proof-of-concept that combines a bunch of different ideas than an actual attempt at interactive narrative, though. The puzzles don’t actually have anything to do with the story, for instance. But I wanted an excuse to do something fun with the vibrant art that Jessica Klein has made for the project, while also exploring possibilities for the Hack This Game sprint and giving self-directed learners a path to understanding how the Hackasaurus tools work.

If you know HTML and CSS, you’re welcome to remix this and make your own “web hacking puzzle” where the goggles are the controller. Just fork the repository on GitHub and modify index.html and bugs.js as you see fit. Almost all the puzzles, achievements, and hints are data-driven and explained in documentation, so you don’t actually need to know much JavaScript.

For more information on my motivations in creating the parable, check out the experiment’s README. Jess is also thinking about making an interactive comic that teaches web-hacking, which I’m looking forward to.

My Minecraft Adventure

I did not expect to enjoy this game.

My friend Mike was completely obsessed with Minecraft, sick and Dave Humphrey blogged a bit about all the amazing things people had done with it: creating replicas of the German Reichstag, ampoule the U.S.S. Enterprise, viagra working CPUs. All creative uses of cognitive surplus. But I still didn’t think that it was for me.

When visiting Washington, D.C. in the last days of December 2010, I finally sat down with Mike and he showed me how to play.

I then played it for a few minutes in single-player mode and found it interesting in a very detached, academic way. I even bought it, just because I wanted to be a good customer and support such innovation. But I honestly doubted that I’d play it much.

The next day, I set up a multiplayer server for Mike and I, which changed everything.

I think it was the shared experience of being part of a team in a survival scenario that did it for me. The story of The Swiss Family Robinson had always fascinated me as a child, and Minecraft’s multiplayer survival mode had some of its core elements: you’re stranded on an unfamiliar landscape with friends, and need to build a shelter before sundown, because that’s when the zombies come out.

So I guess it was more like a cross between The Swiss Family Robinson and 28 Days Later.

Home Sweet Home

Our first shelter was built from stone and wood into the base of an enormous sand dune. In the world of Minecraft, monsters are created from darkness, so we had to craft torches and mount them inside to keep the darkness out.

It wasn’t the Reichstag, but it was home.

That first night, as zombies and spiders groaned and hissed outside our walls, Mike taught me how to create glass by heating sand in a furnace. I forged some sheets of it and built windows into the walls the next day.

Soon we’d built out a second story, and then a third, and then a lookout tower at the very top of the dune. One day Mike went out east in search of more trees to chop into wood, and built a home on a waterfall there that reminded me of Fallingwater.

Over the next several days we explored the unknown and built more. Structures built into the cliffs of canyons, shelters made from caves, treehouses, watch-towers, fortresses of solitude. We carved safe passageways into mountains and built stairways down cliff-faces.

We’d also had our share of misfortune. One of the monsters that comes from the darkness is called a creeper: unlike zombies and skeletons, it doesn’t burn in sunlight, so danger doesn’t depart with the arrival of dawn. It also explodes when it gets close to you. One morning a stealthy creeper surprised me as I left our first home, which nearly killed me and tore our entrance asunder.


Markus Persson, the creator of Minecraft, writes the following about the game’s philosophy:

I strongly believe that all good stories have a conflict, and that all good games tell a good story regardless of if it’s pre-written or emergent.

I’ve always thought of a game designer as a kind of storyteller, as most of my favorite games have rich stories whose potential outcomes were decided and built into the game’s design well before I started playing. In this way, a lot of my favorite games are like “interactive storybooks”, where the primary author is the game’s designer.

Minecraft, on the other hand, is more like scaffolding for a story. The world is randomly generated and has no history; there’s no personalities that populate it. What the game really provides is a setting, a catalyst of conflict, and some incredibly simple yet flexible tools for changing the setting and reacting to the conflict. Beyond that, it’s the players who are the real storytellers, and that’s part of what’s made it endlessly fascinating for me so far.


The New York Times recently wrote that The Web Means The End of Forgetting. I never kept a copy of my first public software project with me—yet because I put it on the internet, it eventually made its way into an FTP archive, many mirrors of which still host the files sixteen years later, when a casual conversation with a friend prompted me to search for them.

In 1994, I didn’t like Macintosh computers, so I decided to replace the explosive barrels in DOOM with them.

Following are the two frames used as the idle animation for the sprite:

When fired upon, a Mac-barrel slid backward a few inches and exploded using this three-frame animation:

An accompanying WAV file combined the Mac’s classic “boing” error sound with the traditional Doom explosion effect; scripted DOS batch files were used to install and uninstall the addon.

I also wrote documentation for the package, which included an introductory narrative about the role of the Macintosh in the post-apocalyptic setting of the video game:

                      DOOM Mac Barrels v1.0
                           Atul Varma

  The wound from that demon scrape is killing you!! You  try
  to look around at the scenery to divert your attention for 
  a bit. All around you is barren wasteland. There is  some-
  thing that catches your attention, however. To your  right
  is an  old Macintosh Classic,  the  UAC's  general-purpose
  torture device  which also, ironically, doubles as  a poor
  excuse  for an abacus... er, computer. It was  invented in
  the late twentieth century, but the Apple corporation that
  made it apparently couldn't stand up to the competition of
  the other superpowerful PC companies, so their  technology
  never progressed. AAACH! Suddenly, an Imp comes out of the
  shadows, roaring its  Satanic battle-cry  as  it sees you.
  Thinking quickly, you let out a blast from  your  shotgun,
  but because of your terrible aim, the shell  hits  the old
  Mac. The  thing rattles, the screen cracks, and  the  damn
  thing EXPLODES into a  ball of  red fire  with  a  distant
  system  beep  in  the background, killing  the  Imp!! Holy
  shit! Maybe these things CAN be useful...!

The original formatting is preserved. I didn’t know it was called justified text, but I knew what it was, and I knew that I wanted my README to be typographically elegant, insofar as 80-character wide DOS screens allowed them to be.

According to the rest of the documentation, I either had a ridiculous level of hatred towards Macs and their users, or I was secretly in love with them.

While the Web doesn’t forget things, I never told it much else in those days, so I can’t use it to inform me of other thoughts I had when I was younger. Despite the angst directed towards Macs in this project, I actually owned a Macintosh LC in the preceding years, and I still have very fond memories of creating things using HyperCard, investigating the composition of my favorite programs with ResEdit, and gleaning from the learnings preserved in Apple’s impeccably-crafted Inside Macintosh manuals.

That Empowerment Thing

One of the really interesting things about the social-network-oriented website for the Obama campaign, my.barackobama.com, was the fact that it was essentially an online nexus that connected people who were interested in political and social change. And as Henry Jenkins mentioned in February, what Obama has created over the past year has not been a campaign, but a movement that would have lived on even if he’d lost the election.

Skeptics have wondered how exactly this “change” Mr. Obama has been talking about will happen. But what’s really interesting is that it’s already going on, and actually may have been going on for quite some time. As today’s MyBO blog post states, the online campaign headquarters for Obama’s movement has now effectively transformed into a social networking site that provides individuals with the tools they need to effect social change: already, people are using the site to organize book-club meetings, pet adoption events, and all kinds of community service meetings.

The word “empowerment” seems to be surfacing itself more and more lately, and not just in relation to Obama’s campaign. At yesterday’s Labs Meetup, Alex Peake gave a lightning talk on his new site Empower Thyself. Suneel Gupta’s been writing an excellent series of blog posts about how Mozilla can help give individuals the tools they need to start movements. The Mozilla mission at its core is about empowering individuals with the tools they need to shape their own internet experience and make the web the way they want it to be. In a lot of ways the Open Web itself is a social movement.

So empowerment has been on my mind a lot lately. The three main things I’ve involved myself in over the past few months have been a political movement, an organic software movement, and a World of Warcraft community that seeks to empower people to make the game what they want it to be. The extent to which these three things have informed each other is impressive to me, and I guess what I like most about them is the common attitudes that the participants of these communities tend to share: a sense of transparency, openness, and curiosity that lends itself to trust, solidarity, and learning.

It’s pretty awesome to see.

Parchment on the iPhone

I recently spent time making Parchment work properly on my new iPhone 3G.

The iPhone has been my first foray into the world of the mobile web, and getting Parchment to work well on it was an interesting experience. Some of the challenges I faced involved getting the iPhone’s on-screen keyboard to display properly—Parchment doesn’t actually have any text input fields on it, so by default the iPhone didn’t think that users had to enter text—and modifying some processor-intensive JavaScript code so that the iPhone didn’t think that Parchment had gone into an infinite loop.

Another interesting challenge was figuring out how best to display content so that it would be viewable in a way that didn’t require the end-user to perform unnecessary panning and zooming. By default, the iPhone assumes that pages it views were made to look good on a page that’s about 980 pixels wide, so that’s how big the “virtual viewport” is; this default seems to make sense, since most pages were made with desktop screens in mind, and the ability to zoom and pan makes it relatively usable. However, when a developer is creating a rendering of a site specifically for smaller screens, they can force a particular viewport size—thus minimizing or entirely obviating the need to pan and zoom—by inserting a viewport meta tag in the HTML and using some iPhone-specific CSS properties like -webkit-text-size-adjust. All of these sorts of issues were documented nicely in Apple’s Safari Web Content Guide for iPhone. Though they’re not “standards” per se (at least as far as I know), nonetheless I think that tailoring pages for an incredibly small, zoomable screen could be viewed as little different from tailoring them for print—something CSS already supports—so I hope that these extensions can eventually be turned into standards and supported by other mobile browsers like Fennec.

Right now my biggest criticism of the iPhone, despite all its enormous benefits, is the fact that its native platform is quite sterile, or at best contingently generative. I was hoping that the open web would be one way to get around this, and getting Parchment to work on the device was my way of testing these waters.

Parchment’s ultimate goal, as outlined on its Google Code project page, is to serve as a compelling replacement for desktop-based Z-machine interpreters. Among other things, this implies that it should work fine when disconnected from the internet, and it does: once you’ve started a game, it’s entirely loaded into the browser and no further network connections are made. In Firefox 2 or above, selecting “Work Offline” from the “File” menu will allow you to still access the game and play it even if you don’t currently have it loaded in a tab (why Firefox can’t automatically detect whether you’re offline is being worked on). You can even save and load games while offline because the game state is appended to the URL hash—put in DOM Storage too, if support is detected—and Damien Neil has a patch that uses PersistJS to provide even better support.

The thing is, Safari on the iPhone doesn’t seem to have any kind of “offline mode” like Firefox does. Further, it only keeps one web page loaded at a time, even though it has something resembling tabbed browsing; so if you switch from Parchment to another website and back to Parchment, the entire page is reloaded—something that not only consumes network bandwidth but also processor time. This hugely limits Parchment from becoming a compelling replacement for a native iPhone app that does the same thing. And thanks to Apple’s gate-keeping, there’s serious doubt as to whether the latter is even a possibility.

I also have no idea if Apple is even likely to introduce an offline mode for the iPhone, because there appears to be a clear conflict of interest between their closed platform and the open web: it makes sense for Apple to “gimp” the web as much as it can so that application developers are forced to develop for the platform that Apple controls. So I’m really looking forward to both Fennec and Android supporting generativity in the mobile space.

In any case, if you have an iPhone, feel free to play a story on Parchment and let me know what you think.

Introducing Parchment

A few weeks ago, I started a small project to create a user interface for something called a Z-Machine: a virtual machine created by Infocom in the late 1970’s to run their text adventure games—the most famous among them being Zork, which is apparently what the “Z” in Z-Machine stands for. These games, as their name suggests, are completely text-based; Infocom’s 1984 masterpiece The Hitchhiker’s Guide to the Galaxy, for instance, opens with this passage:

    You wake up. The room is spinning very gently round your head. Or at
    least it would be if you could see it which you can't.
    It is pitch black.

At this point, the player is presented with a prompt, where they can type what they want to do using natural english sentences; entering turn on light, for instance, would attempt to make the player turn on the room’s lights. For the most part, these games were like literary puzzles; at the beginning of Hitchhiker, for instance, the first “puzzle” is to figure out how to see things, and the next is to get over your morning migraine.

The interesting thing is that the virtual machine powering Infocom’s games lived past the company’s demise, which occurred in the late 1980’s: in the early 90’s, it was reverse-engineered by a clever mathematician-poet named Graham Nelson. A small but vibrant community rose up around this time, at first with the intent to create their own Infocom-style text adventures; but some of their works eventually surpassed anything Infocom had ever published. Because of the fact that some of these “games” were really more like interactive versions of novels or short stories rather than traditional puzzle-based adventures, the community decided to call them “interactive fiction”.

If modern video games like Halo and Grand Theft Auto are like movies, then interactive fiction is the literary equivalent. And in-line with this analogy, one of the many practical advantages of creating IF is that—unlike most video games that require programming and music and graphics—it’s eminently possible for a lone author to create something enduring.

Perhaps due to this low barrier, one of the things that I find particularly inspiring about the interactive fiction community is its diversity, especially in comparison to the modern industry of video game development. Unlike the video game industry, authors aren’t expected to have a technical background, and so the tools the community has created generally don’t assume any: one of the most popular programming languages for IF, called Inform 7, was actually designed by some of the most talented authors in the field, and the result is a fascinating rule-based language that reads much like literature.

Curiously, though, actually experiencing interactive fiction could be a bit cumbersome, as I found when trying to introduce friends to the genre: first, a user would have to download and install an interpreter application which was capable of decoding and providing a user interface for the work itself, which was contained in a story file that the user would have to download separately. Then, the user would have to open the story file with the interpreter. The amount of work involved in playing such a seemingly “low-tech” game seemed a bit out of proportion in comparison to the more multimedia-rich offerings available on the web through sites like Kongregate, which allow games to be shared and played with the click of a hyperlink.

Aside from that, though, there was another issue I had with most of the interpreters I’d used, which was that they didn’t seem to pay much attention to typography—for instance, they didn’t offer any mechanism for the author of a game to specify its typographic design, so as to let the typesetting honor the content in the best possible way.

The more I thought about it, the more the web actually seemed like an ideal place for interactive fiction to be experienced, rather than merely a more convenient one. HTML and CSS, for instance, provide far more flexibility for typography and layout than any desktop technology I know of, and the notion of a page with constantly-increasing length is much more suited to the medium than a computer terminal. Furthermore, recent advances in browser technology set forth by HTML 5 and implemented by standards-compliant browsers like Firefox, Safari, and Opera make it possible to save and restore games just like desktop interpreters, as well as play them while offline, all without the need of any special plugins like Flash or Java.

I actually found a Z-Machine interpreter already written in JavaScript, in the form of Thomas Thurman’s open-source Gnusto; the only problem with Gnusto was that it was a Firefox extension instead of a web application. So I took a look at its source code, removed the engine from the rest of the XUL-based user interface and decoupled it from its XPCOM dependencies, and used John Resig’s excellent jQuery library to make my own web-based user interface for it.

I called the result Parchment, because I wanted playing interactive fiction titles to feel as natural as reading from and writing to a sheet of paper.

Parchment, like Gnusto, is open-source; its Google Code project page is at http://code.google.com/p/parchment. It still has a number of bugs and missing features. One of the most rewarding parts of creating Parchment has been the feedback I’ve received from the interactive fiction community; the kind and enthusiastic people at rec.arts.int-fiction have been extremely helpful by providing me with encouragement, suggestions, advice, bug reports, and even code contributions.

While I’ve learned a great deal about web development from writing Parchment—it’s my first “real” web application, at least since the days when CSS was too cutting-edge to be useful across browser implementations—I’d like to focus on such things in later posts and conclude this one by linking to Parchment-powered versions of some of my favorite interactive fiction titles. These should work if you’re using at least Firefox 2, Safari 3, Opera 9, or Internet Explorer 6.

  • Wishbringer, written by Brian Moriarty and published by Infocom in 1985, was the first text adventure game I ever won, when I played it in 2004. Yes, 2004: unlike a lot of interactive fiction afficionados, I didn’t play many of the genre’s classics as a child, and certainly never completed any of them. This game was designed to provide a pleasant introduction to the genre, so the puzzles aren’t particularly hard, but they’re not trivial either. If you’d like more information, check out my Wishbringer review and see the Wishbringer Infocom Gallery page, which contains images of some of the great “feelies” that came included with the game’s packaging.
  • Plundered Hearts, written by Amy Briggs and published by Infocom in 1987, was Infocom’s first and only foray into the romance genre. It’s also the only game of this genre that I’ve ever played or heard of, period. Set in the Carribean during the 1600’s, it features one of the earliest examples of a strong female lead in a computer game. It’s also a little harder than Wishbringer; see my Plundered Hearts review and the Plundered Hearts Infocom Gallery page for more information.
  • The Hitchhiker’s Guide to the Galaxy, written by Douglas Adams and Steve Meretzky and published by Infocom in 1984, is one of the most infamous text adventure games ever made. It’s also one of the hardest, in part because of the clever use of puns and wordplay required to solve its puzzles.
  • Photopia is the first of my selections that wasn’t a published commercial game, but was a product of the modern era of interactive fiction. Written in by Adam Cadre in 1998 and winner of that year’s community-wide Interactive Fiction Competition, this title is a touching interactive story that doesn’t actually feature any puzzles. See Cadre’s website for more information about this and other works of his.
  • Galatea, written by Emily Short in 2000, received the Best of Show prize in the community’s Interactive Fiction Art Show of that year. Like Photopia, it’s not a traditional adventure game; rather, it’s like an interactive portrait, in which the player can converse with Galatea, the mythical statue-come-to-life created by Pygmalion. There is no “win condition” for the game and no real puzzles per se, but the plot is highly multilinear in that the player’s conversation with Galatea can end in a wide variety of ways, some of which are more satisfying than others. See Short’s website for more information about this and other works of hers.

If you liked any of these, you can actually play any game created by the interactive fiction community at http://parchment.toolness.com. Enjoy!

Information Complexity and the Downfall of the Adventure Game

Back in 2005, I wrote a tentative article for The Game Chair titled Information Complexity and the Downfall of the Adventure Game, but due to some annoying legal issues, it never got published there.

A little under a year ago, I contacted my favorite gaming magazine, The Escapist, to see if they’d be interested in publishing it, and they were. It was subsequently featured in issue 116 last September, but I just realized that I never mentioned it here.

If you’d like to read it, you can check it out here.

Slightly Old Stuff

The following is a summary of stuff I worked on before the new Toolness was created, but after I stopped maintaining any of my old sites.


Narrowcaster – During the summer of 2004, I realized how great RSS syndication was and decided to get an aggregator. Unfortunately, all of them were horribly complicated: highly modal interfaces, tons of tabs and controls and buttons to mess around with and what have you. Taking some inspiration from the design of Google News, I whipped up my own aggregator using Python and MySQL. The interface is relatively humane, and the aggregator features some built-in filtering of certain feeds: for instance, stories from Slashdot that I’m not interested in–e.g., anything under their “Linux” category–are automatically filtered out. Since this was created solely for personal use, it’s still rather buggy in some rarely-used places; nonetheless, one year later, I (and at least one other person I know) still use this aggregator multiple times per day. The name “narrowcaster” refers to the concept of narrowcasting, which I first encountered in Nicholas Negroponte’s book Being Digital.

SWKOTOR2 Secret Tomb Bugfix – In June 2005, I played through Star Wars – Knights of the Old Republic II: The Sith Lords, which ended up being a terrific game. However, there were also a number of major scripting-related bugs in the game, a few of which tripped me up while I was playing it. After finding out about some of the restoration projects going on to fix the game’s bugs and restore some of its cut content, I decided to contribute.


A Farewell to Jef Raskin – This is something I wrote in remembrance of the death of Jef Raskin, commonly credited as the inventor of the Macintosh computer, in February 2005. Jef was a professor of mine in graduate school and later became my employer.

Plundered Hearts review – During the spring of 2004, I played through a slew of old Infocom interactive fiction titles and wrote reviews for three of them. The other two were for Planetfall and Wishbringer.

Food Force reviewFood Force was a ridiculous little edutainment game that the UN World Food Programme released in the spring of 2005. Having a particular interest in the oft-neglected genres of video gaming–especially edutainment–I decided to review this title.

Façade progressive review, prologue – This is the beginning of my first progressive review for The Game Chair, of the interactive drama Façade. Also see parts one and two.