10 Second Defence post-mortem. Musings on my first Inform game
by Christina Nordlander
10 Second Defence can be found here (http://www.ifdb.tads.org/viewgame?id=o3l8ac72owqdhj66).
1. Preamble to a Post-Mortem
I never intended to write 10 Second Defence.
When the twenty-seventh iteration of the Ludum Dare (www.ludumdare.com) game jam rolled around in August 2013, I had decided that I would only participate if the theme really grabbed me. I had already participated in a previous Ludum Dare, and I knew how taxing and weekend-eating it could be.
The theme chosen was “ten seconds”, which I’d had my eyes on since it appeared in the shortlist. Despite my previous misgivings, I went for it.
I’d had vague ideas for a game about stopping time in order to set up a trap for an enemy, then restarting time and seeing all the pieces slide into place. Possible inspirations may have been the battle between Katara and Azula in Avatar: The Last Airbender, where Katara freezes the water around herself and Azula and then moves unhindered through it, or Puella Magi Madoka Magica, where Homura initially fights by stopping time and laying into her target with a blunt instrument. I’m sure you can adduce your own examples.
The eventual idea I went with wasn’t about literally freezing time, but it was a similar principle of getting the drop on your enemy by creating the perfect trap, carrying out actions that had been honed to perfection by learning from previous playthroughs. The learning-by-replay concept was strongly inspired by such classics as Varicella (http://www.ifdb.tads.org/viewgame?id=ywwlr3tpxnktjasd) or Rematch (http://www.ifdb.tads.org/viewgame?id=22oqimzgf8snv002).
Since I’d just played Porpentine’s Ultra Business Tycoon III (http://aliendovecote.com/uploads/twine/tycoon/crime.html), I got the idea that the game should be set in a cyberpunk-ish, corporation-run future, and that the goal was to defend yourself against a hitman sent to your apartment by a former friend and business associate turned enemy. The game would be a one-room affair (a genre I’ve always liked), but one where the goal wasn’t to escape.
2. The Specs
For my previous game, Display of Weakness (http://doopnet.com/game/), Twine was the obvious choice: Display of Weakness was an attempt at an unusual stats-based simulator where the goal was to perform badly (but not too badly) in order to lull an opponent into security. For this, Twine’s CYOA format and easy-to-use attributes system were perfect. 10 Second Defence, on the other hand, was intended to be a puzzle-heavy game with plenty of items to use and interact with. Thus, it became my first game in Inform 7.
I’d had a look at coding with Inform previously, but at the time I found it difficult to learn how to use it, and I didn’t have enough of an incentive to keep going. This time, the incentive was there, so I opened up Writing with Inform (http://inform7.com/learn/man/index.html), The Inform Recipe Book (http://inform7.com/learn/man/Rindex.html) and an energy drink and got to work.
3. The Process
(Note: this section will have slight puzzle spoilers. However, the game did end up harder than I intended, so spoilers might actually be beneficial.)
Once I got started, I found the majority of Inform 7 implementation very easy. Implementing objects was a moment’s work, and the engine itself already contains most verbs. Of course, as a newbie I had a lot of questions, but most of those were easily resolved by checking the various “how to make games in Inform” guides online. Some weren’t so easy, but I still managed to submit a finished and finishable product before the deadline.
Bear in mind, I learnt Inform from scratch during those three days. At the time, I felt like I was winging it, and possibly using cheating solutions, but looking back I realise that I did most things the same way a more experienced Inform developer would have. The text-based nature of Inform games are a freedom: objects do have properties and can be manipulated by standard verbs, but by and large, the developer can insert commands that will result in some form of change without directly being tied to the object in question. If the implementation is bug-free, a player won’t be able to tell whether the developer has winged it or not.
An example: one of the items in my game is a bottle of cleaning fluid that can be poured. Now, IF developers know that implementing fluids is tricky. I wasn’t trying to do anything incredibly complex, such as modelling a fluid that could be split between different containers, but my concept still required a fair bit of implementation: a container containing an item that can be poured, but not picked up, and not collected after it’s been poured.
Or, alternately, I could create a bottle object in the room, create the object “slippery film”, and have the verb POUR BOTTLE move the film to the floor (unless the film is already there, in which case the verb results in a “the bottle is empty” message). If the implementation works, why should the players be bothered?
Even though I went with a one-room game, I found that implementation became quite complex. Due to the nature of the gameplay, many objects needed to be manipulated: broken, fitted together, transformed into different states. I aimed for a very immersive, manipulable world. Some of it could have been done more elegantly. (See Section 7 below.)
You may have noticed that I’ve focused on coding in this section. I’m much more experienced as a writer than as a game developer, and the writing process of this game was fairly simple. Still, as when using Twine, I’ve noticed that writing an IF game isn’t the same as writing prose. There is a clear size limit: people (including myself) who would devour thousand-page novels balk at walls of text in a game. There is the requirement for clarity in order to focus the player’s attention on notable objects, while avoiding the repetitiveness of bald lists. Emily Short said it best in a review on her old website (unfortunately, I cannot find a direct quote, since the page is defunct): when we read War and Peace, we don’t pay attention to every exit from a room, but we have to when playing an IF game.
Writing advice I would give to anyone who considers breaking into IF: clarity is paramount. Beauty of style is a plus. However, overly florid or poetic writing may harm comprehension in a way that might not be a big issue in static fiction or poetry, but makes a game unplayable.
When I posted the game to Ludum Dare, I thought I had ironed out the bugs, but I am greatly indebted to one LD member, Zwergesel, who found that it was possible to leave the apartment without encountering the hitman (and thus sidestep the entire game) by typing LEAVE instead of EAST. The importance of beta-testers can’t be overstated.
Another piece of advice that might be useful: it helped me a lot to create new Inform files with “test rooms” where I could work out the best way to implement a certain mechanic (for example, how to disambiguate between objects).
Of course, I was a newbie. There are mistakes and places where I’ve overcomplicated the game: for example, instead of implementing different states for an object, I would create separate objects to replace each other. Of course, this led to disambiguation problems and a lot of unnecessary coding. That is one thing I know how to do differently in the future.
4. The Stigma of Sex
While I wrote, an issue started nagging on me: the hitman’s sex. It’s completely extraneous to the plot or gameplay: the hitman is essentially just a timed death message that can be avoided by setting up your trap in time. However, there came a point where I had to choose. Initially, I used singular “they”, but this is where my point about clarity comes into play: if this were a static short story, I could let the reader figure out that “they” referred to a single person, but a player might not have that leisure. Besides, I would need to implement synonyms, and “man” or “woman” would probably be the one most players would go for.
My mental image was that the hitman was male. I suspect it was intellectual laziness: the usual disposable guards or henchmen in action films are overwhelmingly male, so that’s where my mind went. Women are a marked category, as opposed to men, the unmarked one: sad to say, if I’d introduced a female hitman, the player might have asked “why?” in a way that they wouldn’t for a male one. That seemed like a good enough reason to make the hitman male: the simplest route.
However. There is an increasing cultural realisation among progressive people that male characters in fiction tend to be on the receiving end of violence a lot of the time: the cannon fodder, the redshirts, tend to be male. This isn’t because writers (many of whom are male themselves) hate men, but I suspect that at least one reason is the “unmarked category” I mentioned: if you’re going to pick a sex for the faceless mook who’s there for the heroes to kill, male is the default. I didn’t want to be part of that.
It came down to whether I wanted the game to be about violence (in self-defence) against a man or against a woman. In the end, I opted for a man, because I considered that more players would be upset by a game where you plan the gruesome death of a woman. I’ll put a disposable female guard in some other game.
And in case you’re wondering, the PC is 100% non-gender-specific. Making a blank slate PC is the easy part, after all.