Archive for category Computers

My review of Google Glass

Posted by on Tuesday, 10 December, 2013

Disclaimer: despite being a Google engineer, this review DOES NOT represent the opinion of Google or reveal any interesting gossip about Google Glass. I obtained a “public invitation” from a non-Googler friend to beta-test the product, and I was treated like any other random citizen when I went to pick up the device. I have no special inside information about Glass, and this review is nothing but my own observations as a techie trying out an early-stage product. The fact that I happen to work for Google is entirely coincidental. Some of my observations and assertions are very likely incorrect — please don’t quote this blog post as authoritative!

After 2 weeks of using Google Glass, I thought I’d share my experience. It’s been incredibly fun and exciting for me. I’m not so much giving a deep philosophical opinion on the meaning or viability of the technology in this review, but rather a quick summary of what it currently does and doesn’t do, as a reference for folks who are curious or thinking about joining the beta-test program themselves.

What is Google Glass?

In a nutshell, it’s a smartphone you wear on your face like glasses. Usually it’s turned off and you see nothing; sometimes it’s awake and you see a ‘heads up display’ floating above your field of view.

It’s a full Android device, with a deliberately locked-down and restricted user interface. It has wi-fi, but no cellular connection or GPS ability. When you’re out and about, you have to tether to your phone for data and GPS.

Assumptions & Requirements

For the “maximum” Google Glass experience, a number of assumptions are made:

  • You’re somewhat extroverted, and ready to attract attention and questions from strangers. :-)
  • You’re already vested in the Google Cloud ecosystem: Gmail, GCalendar, Google Now, Google Plus (for photo backup), Google Music, etc.
  • You already own Android phone or tablet. Though not strictly required, the “my glass” app (used for configuring the device) works better as a native Android app than as a web app.
  • Your smartphone is ready to be tethered:
    • If you have an Android phone, then Glass tethers to it via bluetooth (yes, TCP/IP over bluetooth!), and Glass doubles as a bluetooth phone headset. You can do SMS via Glass too, and Glass “borrows” the phone’s GPS in order to do maps navigation.
    • If you have an iPhone, you have to turn it into a wi-fi hotspot when you’re out and about — otherwise Glass has no internet connection. Also, you won’t be able to do SMS over Glass, due to limitations in iOS. :-(

General things it can do

Imagine trying to use your smartphone without ever activating the virtual keyboard. :-) Many things are possible, but some things are awkward. For example, there’s no fundamental way to type in specific website names, or specific passwords for wi-fi or websites.

Basic information displayed as incoming “information cards”, much like Google Now: { clock, weather, stocks, travel times, news headlines}. But it also does cooler interactive things:

  • Google searches
  • Read incoming Gmail, and respond by voice dictation
  • Read incoming SMS text messages, respond by voice dictation
  • Take photos and record videos (from 1st person point of view!)
  • Video conferencing via G+ hangouts (!)
  • Take voice-dictated notes (which are then uploaded to Google Keep or Evernote)
  • Share/post things (text and photos) to Twitter, Facebook, and G+
  • Heads-up display for running & biking (speed, time, etc.)
  • Stream your cloud music from Google Play
  • Playback or record recipes when your hands are dirty in the kitchen

What’s awesome and works well

  • Surreptitiously checking messages. When in a meeting, or our to dinner…
  • Hands-free text messaging — both incoming and responses!
  • Voice dictation in a quiet environment
  • Amazing for candid photography, if you’re into that sort of thing. Great for making videos of your kids too — they’re not self conscious that they’re “live” on recording.
  • Instantly posting photos to social networks.
  • Great for Evernote people — dictate a note anytime, poof into your cloud inbox to deal with later. Visual notes are great too — e.g. taking a photo of a sign or piece of paper with instructions, to deal with later. (All photos, like notes, back up automatically into the G+ cloud.)
  • “Guest mode” for demonstrating to friends works pretty well… it prevents them from accidentally posting things as you.
  • Visual translation! Point Glass as a foreign-language sign, and watch it translate to english by replacing words on the sign in real time. The photo below is really what I saw!

What doesn’t work so well

  • It’s not safer than a smartphone. Instead of staring down at little glass rectangles in your hand, you now just stare into space, with eyes slightly to the upper right. It’s still rude in the middle of a conversation. You can still walk into things while using it (and I have!)
  • Voice dictation in a noisy environment. I’m still not sure what I said yesterday when the train passed overheard, but somehow the note got transcribed as “teach Kansas City to talk dirty.”
  • Visiting most websites: too tiny to read and scan around, for the most part. Each “card” is only 640×360.
  • You can’t yet read update-streams from your friends on social networks — you can only see comments on things you posted via Glass.
  • Every one of your posts is auto-tagged with #throughglass. Yes, yes, marketing and all. But it gets kinda old.
  • Battery life about half that of a smartphone. I get about 4 hours of use, assuming I “wake it up” about as often as a smartphone. But it charges in only 40 minutes or so.

Public reaction

I’ve worn it out in public quite a bit — in the subway, into businesses and restaurants. 95% of the time the response has been popular. People are curious and want demonstrations. In particular, adults are typically wondering what the heck they are, while teenagers ALL seem to know what it is (“OMG, is that Google Glass?!?”). People sometimes quietly point at it from a distance. The only one negative reaction I had was a vendor asked if she was being recorded.

Using with existing eyeglasses…

I don’t recommend it. I tried shoving them over my eyeglasses for two weeks; while it works, it’s really awkward and uncomfortable. I can’t go more than an hour or so that way. I finally gave up and just bought some daily-disposable contact lenses. It means when I wake up in the morning, I can choose between wearing normal eyeglasses or popping in some contacts to wear Google Glass.

If you search the web, you’ll find all sorts of articles about how Google is going to have a “prescription option” available in early 2014. Somehow you’ll be able to order prescription lenses for your device, turning it into an independent pair of eyeglasses. I wasn’t able to wait that long. :-)

Your Community is NOT Your Tools.

Posted by on Wednesday, 30 November, 2011

(Disclaimer: I’m one of the ‘old guard’ open source guys. I co-founded the Subversion project back in 2000 and am a proud member of the ASF. These opinions are my own.)

A very popular blog post has been going around lately called Apache Considered Harmful, which criticizes the Apache Software Foundation (ASF) for being impossible to work with. On the surface, it looks a bit like a culture war between older and younger generations of open source hackers: the older generation is portrayed as stodgy and skeptical of distributed version control systems, making the ASF inhospitable to a younger generation used to the fast-and-freewheeling world of git and Github.

One of the ASF’s leaders, Jim Jagielski, then wrote a blog response which seems to say, “We’re not irrelevant; we just have high integrity. We care about long-term health of open source projects, not passing fads or hip popularity contests.”

But I think Jim is truly missing the main complaint.

Backing up a bit: what is the mission of the ASF? Why does it exist? My understanding is simple:

  1. to be a legal umbrella of protection
  2. to foster long-term, healthy open-source communities

The first goal is achieved by putting all of a project’s code under the Apache license, and getting all code contributors to grant nonexclusive IP rights to the ASF. This guarantees that the ASF “owns” the code, and thus can legally defend it.

The second goal is about encouraging and preserving healthy culture. The ASF has a famous saying: “community over code”. In other words, the ASF doesn’t accept donations of code (or code thrown over walls), it only accepts communities that happen to work on a common codebase. The community is the main asset, not the source code.

The ASF has a great set of cultural norms that it pushes on its communities via political means and lightweight processes. For example, the ASF requires that each community have a set of stewards (“committers”), which they call a “project management committee”; that communities use consensus-based discussions to resolve disputes; that they use a standardized voting system to resolve questions when discussion fails; that certain standards of humility and respect are used between members of a project, and so on. These cultural traditions are fantastic, and are the reason the ASF provides true long-term sustainability to open source projects. It’s the reason I pushed so hard to get the Subversion project into ASF.

Let’s go back to the original “Apache Considered Harmful” post again. Yes, the blog post rambled a bit about the ASF becoming “irrelevant”, but I think that’s just random grumbling around the actual issue at stake: the ASF’s insistence on forcing their hosting infrastructure onto projects. We have repeated examples of mature open source communities trying to join the ASF, which already use git as their version control system — and the ASF is insisting that they convert to Subversion and store their code in the ASF’s One Big Subversion Repository.

I fear what’s happening here is that the ASF elders have tragically confused “be part of our community” with “you must use our infrastructure”. There is no reason for these things to be entangled.

The ASF has teams of people dedicated to running servers for Subversion, SSH, QA testing, email lists, and so on. Ten years ago, infrastructure hosting was a Hard Thing. Getting to use the ASF’s hosting services was considered an attractive perk. These days, project hosting is utterly commoditized: we have Sourceforge, Google Code, Github, and other sites. In a matter of minutes, any two people can conjure up a hosted source repository, bugtracker, wiki, etc. So is it really a surprise that newer communities, ready to join the ASF, already have functional (and possibly superior) tools and infrastructure?

So why oh why does the ASF demand everyone use their Subversion service? They don’t force every project to use the same bugtracker; I wonder if source code is different because it’s the “special” asset being protected. Perhaps the ASF elders think it has to all be in one place in order for it to be protectable and controlled? A simple solution here is to simply require that at least one canonical copy of source code be stored on ASF servers. If that means doing an “hg pull” or “git pull” via cron job every hour, so be it. Who cares where the real coding is happening, or in how many repositories it’s happening in? Irrelevant. As long as a community has blessed a central repository as Official, and the ASF is keeping a synced copy of that somewhere, we should be all set. The ASF’s job is to shepherd communities, not force everyone to use the same software tools.

Ironically, years ago I too was suspicious of distributed version control, and wrote an article about how it tended to discourage ASF-style project cohesion. But in this case, we have examples of communities that are already cohesive and high-functioning, despite using git. They don’t need ASF’s tools; they just need a nice place to park their community. If they ain’t broke, stay out of their development processes.

(Note the ASF isn’t alone in this insanity. Others have told me that FSF projects are forced to use the Savannah collaborative platform, whether they want to or not. Crazy! Repeat after me, folks: your community is not your tools.)

WANdisco, ur doin it rong

Posted by on Monday, 3 January, 2011

Author’s Note: These opinions are my own. I’m one of the original folks that started the Subversion project, but no longer work on it. These thoughts do not reflect the official position of either the Subversion project or the Apache Software Foundation, which are located here on the ASF blog.

Subversion has reached the realm of Mature software — it’s yesterday’s technology, not cool or hip to work on anymore. It moves slowly. It is developed almost entirely by engineers working for corporations that need it or sell support for it. Alpha-geeks consider software like this “dead”, but the fact is that something like half of all corporate programmers use Subversion as their SCM (depending on which surveys you read.) This is a huge userbase; it may not be sexy, but it’s entrenched and here for the long haul.

Subversion isn’t unique in this position. It sits alongside other mature software such as Apache HTTPD or the GCC toolchain, which are famous projects that are similarly developed by corporate interests. There’s a tricky line to walk: none of these corporations “own” these projects. They understand that they’re acting as part of a consortium. Each interest sends representatives to the open source project, contributes code, and allows their engineers to participate in the full consensus-based evolution of the software. IBM, Apple, Google, and numerous other companies have figured out how to do this correctly:

  1. Let your engineers know what’s important to work on.
  2. Let them participate individually in the community process as usual.
  3. Profit. 98% of the time the corporations eventually get the features they want.

Today, however, we have a great counterexample of how not to participate in an open source project. Subversion was initially funded and developed by CollabNet; today at least two other companies — Elego and WANdisco — are employing numerous engineers to improve Subversion, and are just as vested in selling support and derivative products. CollabNet and Elego continue to function normally in the community, but WANdisco recently seems to have lost its marbles. Last week, they put out a press release and a CEO blogpost making some crazy statements.

It’s clear that the WANdisco CEO — David Richards — is frustrated at the slow pace at which Subversion is improving. But the two posts are simply making outrageous claims, either directly or via insinuation. David seems to believe that a cabal is preventing Subversion from advancing, and that “debate” is the evil instrument being used to block progress. He believes users are crying for the product to be improved, that the Subversion developers are ignoring them, and his company is now going to ride in on a white horse to save the project. By commanding engineers to Just Fix things, he’ll “protect the future”of Subversion, “overhauling” Subversion into a “radical new” product.

Is this guy for real? It sounds like someone read my friend Karl’s book and created a farce of “everything you’re not supposed to do” when participating in corporate open source.

Even weirder, he’s accusing developers of trying game statistics by creating lots of trivial commits. This is staggering proof that he has no knowledge of the svn developer community or its culture. If he did, he would know that nobody counts stats at all or even cares about them. David appears so desperate to prove that his company is the “leader” that he accuses a community of behaviors that he’s doing himself. (”We have the most active developers of any other company on staff” — who’s counting stats here? The svn developers, or David?)

OK, fine. So Dave Richards is a salesperson, and perhaps what he wrote is generic PR sales junk in order to get his customers excited. Unfortunately, in attempting to woo customers, he’s had the side-effect of making his company appear both clueless and antagonistic to the project:

  • Clueless: It’s obvious he has no technical knowledge of Subversion’s design, has no idea why certain features have or haven’t been written yet, and hasn’t actually brought any new technical proposals or insights to the table. All he’s done is repeat descriptions of features that everybody wants. And he actually seems to believe that all one needs to do is throw more developers at the problems. Suuuuuure.
  • Antagonistic: He’s insulted two-thirds of the active developers (and embarrassed his own employees) by declaring them to be incompetant stewards. There’s no simpler way to garner hate and come off like an ass than to say “everyone move aside and let me fix this” — it’s the opposite of consensus-driven development. It’s a juvenile, conceited behavior that completely disrespects the people and the process.

The Subversion developer community (and ASF) are known for their cool, calm-headed responses to provocations like this, which they’ve just posted. They know not to feed trolls. But speaking as a private developer, I just had to point out WANdisco’s insanity and hold it up as a textbook example of how to Fail in the open source community process.

An Interactive Fiction Gathering

Posted by on Thursday, 25 March, 2010

I’m flying to Boston today for a dual work/fun trip. I’ll be hanging out at the local Google Cambridge office. I’ll meet with some teams. But the fun part of the trip is visiting the PAX East gaming conference that goes through the weekend. It’s a bit like Gencon, but smaller and more focused on videogames than roleplaying games.

Why PAX East? Because for the first time in the ~15 year history of the indie interactive fiction (IF) community, a large number of us are finally congregating in meatspace. Most of us only know each other from mailing lists, competition entries, game reviews, and chatting on a MUD. The fantastic Andrew Plotkin (a major technical and creative leader in the IF community) is setting up a hotel suite for people to gather in and geek out over interactive fiction. It’s not just for longstanding community members though — we’re hoping to evangelize newbies from the conference and get them excited about the genre. We’ll be demoing games, passing out CDs, coins, cards, and even doing some mini-talks.

My own schedule and agenda is deeply entwined with this event:

  • Thursday night: dinner with IF folks.
  • Friday morning: I’m giving an academic talk on the history of IF at the Google Cambridge office. I’ve given it twice before and it always is a huge success — there are a lot of closeted fans out there who show up. Interestingly, when I gave the talk in Mountain View, Don Woods (co-author of Colossal Cave Adventure) showed up to listen. And for my Cambridge talk, Marc Blank (author of Zork and co-founder of Infocom) will be in the audience. Who knew that these guys work for Google? It’s weird to give a talk on computer history when the historical figures keep showing up to listen. :-)
  • Friday afternoon: watching a panel discussion on interactive fiction, which includes prominent community members as well some original Infocom alumni. I’ve been asked by SPAG Magazine to do some basic photojournalism and make some pictures of this event. I’ve got a new monopod to try out with my telephoto lens…
  • Friday night: the premier of GET LAMP, the new documentary on the history of Interactive Fiction! It’s done by the same guy who did that excellent documentary on 1980′s Bulletin Board Systems. Should be really fun. I’ll be taking photos of the post-screening panel discussion as well.
  • Saturday: hanging out in the IF suite. Gonna try doing the Speed IF contest with Jack, put up wall portraits of all the participants, play some games, watch some discussions.

I should also direct readers to a new website for IF virgins. If you’ve never tried interactive fiction, head on over to the Play IF site, and you’ll see that Andrew has posted a bunch of “newbie friendly” games that you can play directly in your web browser. See what it’s all about… it’s come a long long way from Zork. :-)

Another Interactive Fiction Contest Win!

Posted by on Tuesday, 2 March, 2010

It’s old news now, but our second text adventure has won a second contest. If folks haven’t figured it out by now: our secret weapon is a secret cadre of crack beta-testers, copyeditors, and writing critique-ers. They are invaluable! You haven’t tried the game yet, you can play it in your browser right now. Type ‘help’ to see all the people who helped us out.

In other Interactive Fiction news:

  • Jack and I were recently interviewed in an IF e-zine about our history and writing process
  • Jack and I will be attending an historical meeting of all the big IF personalities at PAX East at the end of the month. I’ll be taking lots of photos, so stay tuned for stories coming out of that conference.

Another text adventure released!

Posted by on Monday, 1 February, 2010

Jack and I had great success with our first text adventure game, Rover’s Day Out. It won first place in the 2009 Interactive Fiction Competition last November. I figured we were done for a while; after 5 months of furious coding and testing, we could take a break and start brainstorming up a sequel for next summer.

But no, Jack found us another competition to get into. Just before the new year, he insisted we get going on a “one room escape-themed” game for the Casual Gameplay IF Competition. But it was due January 31st! Could we scrape together a one-room game in only 5 weeks?

Answer: yes we could, and did. But it was a bit nuts.

We spent the first week arguing about the plot and puzzles, over videoconference and in shared notes. We spent the second week actually writing the “finished transcript” that represented the final game we wanted. Jack very cleverly solicited writing feedback from at least six peers in the IF community; at least two or three were folks that hated our first game, so it gave us some great perspective on our writing style and sense of humor. For the third week: code, code, code, day and night. We then spent the last two weeks fixing bugs from beta-testers. In other words, it was the same basic development strategy we did for our first game, just compressed down to 1/5th the time.

So without further ado, head over to the Hoosegow Game Site to try out our game! This game is much smaller and quicker than Rover; it’s designed to be played in a single lunch break, rather than over many hours. We did this because the game is going to played and judged by a much more casual gameplaying audience who aren’t as familiar with the text adventure genre. We also did some old-school things, like award points for solving puzzles. :-)

If you’d like to judge the competition, take a look at the main competition link above. You need to play at least 5 competition games for your scores to count.

Let us know how you like it!

1st Place in the Interactive Fiction Competition

Posted by on Wednesday, 18 November, 2009

Jack and I are giddy with glee, as our recently released text adventure just won 1st place in the 2009 Interactive Fiction Competition. As someone who’s been tracking the community of IF authors for 15 years, this is a bit of a fantasy come true. Most of the really accomplished, famous authors didn’t enter games this year (or released games outside the competition), thus making room for a new generation of authors. We owe the old-timers big thanks for inspiring us, writing great tools, and giving us a chance to shine!

If you haven’t played the game yet, go do so! Cuddle up with a laptop and cup of cocoa. You can get the game (and the source code too) from the main main website we set up. You can file bugs there too.

Note: My one frustration is that genre seems to have a bad reputation among gamers. The natural-language parser is mocked for being overly primitive and unfriendly to casual players. Paraphrased (from a friend):

The creature approaches!

> swing sword
What do you want to swing the sword at?

> creature
What about the creature?

> attack creature
What do you want to attack it with?

> the swod
I don't understand "swod".

> sword
What do you want to do with the sword?

I'm sorry, the creature has eaten you.

In reality, enthusiasts of text adventures consider the primitive parser to be a feature, not a bug. It expects commands of the form “verb noun” and only understands about 30 verbs. So it’s an easy interface to master; experienced players know them all by heart. If you haven’t played text adventures before, be sure to have this crib sheet with you, as it explains the sort of commands most games understand.

And now the obligatory post-mortem on the experience, taken from a post I made on the newsgroup yesterday.

  1. The methodology of “write the transcript first” really works. Emily Short mentioned this technique on her blog, and I’m here to testify. As a programmer, I’m always tempted to start fiddling in I7 in technical ways, wondering if I can implement some clever algorithm — and then later trying to figure out a way to justify its use. This is not the way to write a good game. Instead, come up with a GOOD STORY first (or partner yourself with a great writer like Jack), and write out the entire hypothetical transcript first. Think of it like a screenplay: first conceive the whole experience from the user’s point of view, and decide if it’s a good script. If it is, then worry about the implementation. (For the curious, the original transcript Jack wrote — before a single line of code existed — is over here.)
  2. Keep the player captivated at all times! We goofed by requiring too much repetition of mundane routine for the first half of the game. IF geeks and programmers generally had the patience to muddle through (or noticed the status bar changing, and were intrigued about the double-meaning of things). But at least half of the players out there — including some beta-testers — rightfully had no patience for such a thing. “Just let me do something INTERESTING already!” Many people simply weren’t able to delay gratification (or keep faith) as long as we’d hoped. Especially when you have 20 other games standing by, ready to test. Given the blog reviews, we were convinced we were headed right for the Banana of Discord. Emily’s review and Jim Aikin’s reaction were the canonical example of this. We’ve learned our lesson here.
  3. Avoid linearity. This was my fear all along, when I first read Jack’s transcript… particularly in the second half of the game. I liked the story enough to overlook it, but reviewers correctly called us out. Killing invading bots may be fun, but this still ain’t no Photopia. In the future, we need to really construct some non-linear mid-game plot flow.
  4. Write a hint system.This seems to be the most requested feature, and I was surprised. I grew up playing Infocom games, when games were supposed to take weeks to solve and ‘walkthroughs’ were expensive InvisiClues you had to mail away for. Ordering the walkthrough was a badge of shame, an admission of defeat. These days, the culture seems to have changed quite a bit. People not only expect every game to have a walkthrough, but they check it after being stuck for 10 minutes (!) Maybe that’s just the environment of the Comp (when people are in a rush to “get through” quickly and judge), but clearly an in-game hints would make the game much more accessible to a wider audience. Perhaps fewer people would have run screaming from the repetition. :-)

Subversion moving to the Apache Software Foundation

Posted by on Thursday, 5 November, 2009

It’s no longer a secret, but now a public press release.

Not that this should shock anybody, but in case you didn’t know, now you do. The overlap between Apache and Subversion communities has always been huge since day one — with essentially identical cultures. We’ve talked about doing this for years. It means we can finally dissolve the ‘Subversion corporation’ and let ASF handle all our finances and legal needs.

“Why didn’t this happen sooner? Why now?”, you may ask. There are several answers.

First, the intellectual property was scattered. Collabnet owned a huge chunk of it, but so did other corporations and a large handful of other random volunteers from the internet. The ASF requires software grants to join, and we didn’t have our eggs in one basket.

Second, when the Subversion project first developed legal needs a few years ago — and also started receiving money from Google’s Summer of Code — it was relatively easy to set up our own non-profit. It gave us a place for money to live, and an entity to defend the Subversion trademark from a number of abusive third parties.

But over time, running our own non-profit turned out to be an awkward time suck. So about a year ago I started focusing on collecting Contributor License Agreements (CLAs) from both individuals and corporations, including Collabnet itself. Once the IP was all concentrated in the Subversion Corporation, it freed us up to move to the ASF of dump all of the bureaucracy on them. :-)

So this announcement is also a bit of a point of pride for myself. I’ve long stopped working on Subversion code, but I wanted to make sure the project was parked in a good place before I could really walk away guilt-free. I now feel like my “work is done”, and that the ASF will be an excellent long-term home for the project. This is exactly what the ASF specializes in: being a financial and legal umbrella for a host of communities over the long haul. The project is in excellent hands now.

Of course, Collabnet has always been the main supplier of “human capital” for the project in terms of full-time programmers writing code, and that’s not going to change as far as I can see. Collabnet deserves huge kudos for the massive financial investment (and risk) in funding this project for nearly 10 years, and it seems clear they’re going to continue to be the “center” of project direction and corporate support for years to come. And this pattern isn’t uncommon either: the Apache HTTPD Server itself is mostly made up of committers working on behalf of interested corporations.

What’s interesting to me, however, are all the comments on the net about how this is a “death knell” for Subversion — as though the ASF were some sort of graveyard. That seems like a very typical viewpoint from the open source universe — mistaking mature software like Apache or Subversion (or anything not new and shiny) for “old and crappy”. In my opinion, the open source world seems to ignore the other 90% of programmers working in tiny software shops that utterly rely on these technologies as foundational. Even though I’ve become a Mercurial user myself, I can assure you that these other products aren’t going away anytime soon!

Hm. I smell another talk here.

New game released!

Posted by on Friday, 2 October, 2009

What did I do with my summer?

Answer: helped a friend write a new text adventure game. After extensive beta-testing on our friends, we’ve released it to the public this week and submitted it to the yearly Interactive Fiction Competition to compete against twenty-something other new games.

The whole experience was really fun. Jack normally writes brilliant D&D adventures, and bunches of us travel the country to gather once a year and play them for a day. This year Jack decided to write the adventure as a solo text-adventure concept. Emily Short has written quite a lot about methodologies for writing a text adventure, and Jack used the “transcript fully” method: he started the entire process by emailing me a complete script — that is, a hypothetical start-to-finish transcript of what the entire game would look like to somebody playing it. The plot and puzzles were fantastic, so I got excited and volunteered to help him code it.

Over the next few months, I did help with some coding, but I mostly played ‘product manager’ and ‘editor’ roles. Jack has huge ideas, and I helped him edit them down, sculpt the shape of the plot, sanity-check puzzles and assumptions, manage beta-testers. As my buddy Andre would say, “everybody needs a friend who can be an ass-filter.” I also forced us to use standard software engineering tools and discipline: a real bug tracker, version control, tagging, etc. (Writing interactive fiction is traditionally a solo sport, so I think the whole experience of applying traditional collaborative software-development processes was particularly interesting.) All of our collaboration took place (of course) on this Google Code Project. We’ve released the source to the public under a Creative Commons license; however, I don’t recommend you start reading through it until you’ve played the game first. Spoilers, you know. :-)

To play the game:

If you’ve never played a text-adventure before, it takes a little while to get used to the paradigm and limited parser-syntax. The IFComp website has some great pointers which introduce the genre, but here are my nutshell tips:

  1. Always type commands in the imperative: “look at dog”, rather than “I want to look at the dog”. Your best bet is the form verb noun.
  2. Examine everything to get a better understanding of your surroundings and objects available to you (abbreviation is “x”, as in “x chair”)
  3. In this particular game, you can learn a lot of backstory by typing remember THING.
  4. If you’re stuck, try typing “help”.
  5. Save your game often (“save”), so you can resume progress whenever you wish (“restore”).

New Theme.

Posted by on Tuesday, 15 September, 2009

…because I got tired of the old theme. I’m truly impressed with the community of designers around WordPress! So many themes, widgets, plugins. What an amazing ecosystem.