Guest Blog Post: 10 Second Defence post-mortem — Part 2

10 Second Defence post-mortem. Musings on my first Inform game (continued)

by Christina Nordlander

10 Second Defence can be found here (http://www.ifdb.tads.org/viewgame?id=o3l8ac72owqdhj66).

 

5. The Process, Reloaded 

(This section contains slight puzzle spoilers.)

LD’s extreme time limit is a cure for perfectionism: whenever you come across a flaw, you can soothe yourself with “well, I only had 48 (or 72) hours”. I hadn’t intended to make a post-compo version, but I got enough positive comments that I felt like I owed it to my players.

Of course, at this point, perfectionism came into full swing. Creating Version 2 took several months. A lot of this time was spent waiting for feedback from my patient beta-testers. It’s at this point I would like to thank them: Adri, Hanon Ondricek, Andrew Schultz, Steven J. Scott, and Streever. Getting the perspective of other people (who lack your own blinkers and foci) is vital, especially given that most of these players had more experience with IF and Inform commands than I did.

Since a principal criticism of the game was that it was too difficult, I went about implementing different solutions to the puzzles, getting a lot closer to the fully interactive, immersive world I wanted when I first made the game. For examples, there are now two different ways to use the capsule with the sleep drug, as opposed to only one possible use in Version 1. On the suggestion of the testers, I also created a GLUE verb, making the use of the glue a lot more intuitive.

6. You Should See the Bits We Had to Take Out

(This section contains major puzzle spoilers.)

Some things I originally planned never ended up in the game, for one reason or other.

If you’ve played it, you’ve probably noticed the biggest one: the PC’s brain implant is a massive red herring. It is the in-story explanation for how the PC can relive the same potentially fatal scenario over and over again: the game is understood to be a simulation created by the implant in order to help the player find the optimal solution to the problem. This is why the death message is “You need to run this again,” not “You have died.”

My original idea was that once the player has reached the successful ending, they would be able to turn off the implant, moving to the “Real Apartment” where they would then replay the scenario for a permanent victory. When I made Version 1, I didn’t have the time or the experience to implement this. During the editing process, I was technically able to implement the idea, but realised that replaying the same scenario twice would be more annoying than enjoyable.

The Real Apartment was supposed to be a messier, more stressful affair without the implant blocking distractions for the PC; full of interfering information. The actual gameplay would probably not be very different, but things that seemed to proceed easily in the simulation might be slower or clumsier.

In the finished product, the implant is pretty much set dressing. Late in the game, I did give it a function as a very primitive hint system: try EXAMINE WEB at various stages of the game, and it will draw your attention to the next area you need to focus on.

More minor puzzles I was thinking of implementing, very early in the creation process, included a risk of slipping on the cleaning fluid when you leave the apartment unless you type JUMP, and a disambiguation between the hallway floor and the living-room floor when you POUR FLUID ON FLOOR. I nixed both of these ideas on the simple principle of not being a dick to the player.

7. Things I Could Have Done Better

(This section contains major puzzle spoilers)

It’s always useful to look back at a work and check what could be done better next time.

Within hindsight, the implant wasn’t necessary: it does explain how the player can carry out the actions within ten seconds, but the only reason I made the time-frame “ten seconds” was to comply with the LD theme. (And I strongly doubt that it is feasible, even with a reaction-enhancing implant.)

I have learnt many simple technical lessons from this work: in the future, I will know how to give objects different states instead of creating separate objects, reducing word count and obviating the need for disambiguation.

Most importantly: I would aim for a less difficult game. I suspect that making overly difficult games is a common temptation for novice game-makers, out of the reasoning that if the player can just breeze through the game, you’ve wasted your time. Of course, there’s also the “reading the author’s mind” problem. I think one of the main mistakes I made was, not to assume that the player would think exactly like me, but that they would think of solutions in the same order. The game would have benefited from some way to narrow the player’s focus.

Another problem with the puzzles is that they involved interacting with certain parts of the scenery (the floor, the walls) that are normally irrelevant to IF games.

 8. Conclusion

I greatly enjoyed making “10 Second Defence,” and I hope that at least some people will enjoy playing it. I will certainly enjoy creating more IF games and improving my Inform skills in the future.

Advertisement

Guest Blog Post: 10 Second Defence post-mortem — Part 1

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.