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.

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.

Guest Blog Post: Entice

Reposted from HoraceTorys.weebly.com

How do we entice new readers to IF?

Unfortunately, I think a lot of existing IF isn’t what the average reader is looking for. The characters and conflicts (such as they are in many IF titles) don’t interest them, and learning to play requires too much effort, too many unfamiliar elements.

Do we dumb it down? Cater to fans of popular genres? Most of us would die a bit inside at the prospect of typing KISS EDWARD into aTwilight IF fanfic. On the other hand, while I won’t touch anything by Stephenie Meyer, I would definitely read an interactive young-adult vampire romance by Emily Short, because it would have complex characters with interesting interactions.

But let’s say we have a new “IF-lite” title that’s catchy and reasonably easy to get into. How do we get readers to it?

I think we can learn a bit from some other one-man creative enterprises with free or cheap products: webcomics, online novelists,  and indie video game developers. The good ones all do a reasonable job of promoting their works on limited budgets.

For example, indie gamers usually have a dedicated website or page for screenshots, videos, demo downloads, freebies, etc. Some examples would be yofrankie.orgafistfulofcows.com, and fiveminutemmorpg.com. Graphic novelists have the same sort of thing: wormworldsaga.com, and sevenextraordinarythings.com. The better online novelists’ pages tend to be less visual, but still professional: davidwellington.netcraphound.com. Aaron Reed’s lacunastory.com is a start, but most IF writer websites look like they were designed by, well, writers.

Also, in many of their cases, the site is the game, webcomic, or online novel. There’s no extra step, you click the ad or the link, and you’re playing the Flash game or reading the first comic or chapter. With Javascript parsers, this is now a cool possibility for IF as well.

Digital delivery is a powerful thing, but it’s hard to download “feelies,” the physical objects that allured players to buy golden-age IF titles. However, we can offer similar enticements digitally. For example, James Patterson’s young-adult Maximum Ride and Witch & Wizard series launched free iPhone apps that allow readers to take pictures “with” characters from the books, create wanted posters, and do personality quizzes, as well as read the first few chapters. Some iPhone CYOA titles have unlockable art. Echo Bazaar encourages social networking, and thus word-of-mouth/link. The right kind of IF game could incorporate a worldwide high score board, alternate reality gaming elements, or digitally tradeable aids and items — creating a sense of community and joint exploration.

At the very least, we need good cover art. A quick search showed that most indie/free novels have pretty sad cover designs, so we’re not alone, but readers do judge books by their covers, and if ours don’t even have one, or it’s clip art…

Most IF titles also lack a good tagline or dust jacket blurb. We’re not short on interesting and unique concepts, but we need to hook readers with them when they’re browsing an IF database or a writer’s website.

The last time I was in an airport, I saw “trailers” for new novels playing on screens at the bookstore. They were mostly slide shows or details of the cover art, with title cards and a voice-over, but held my attention with audio/visual while pitching the book’s idea. I think there’s something to be learned there for promoting IF as well, even if it was just a good animated banner ad or something.

Perhaps because of my background in advertising, a lot of these ideas use artwork. Graphics require hiring an illustrator or graphic designer, and maybe a web designer. But the aforementioned developers and writers budget for that, and IF like Floatpoint and Everybody Dies definitely benefits from having professional-quality illustrations.

For the time being, interactive fiction is a non-paying market (with a few exceptions). But there are thousands of game developers, filmmakers, webcomic artists, novelists, bloggers, podcasters, composers, and entertainers that offer a free digital product, but promote it like they were selling it. They believe in their medium, and they’re shooting for something bigger (a contract, living off ad and book sales, etc.). Interactive fiction has some of the most enthusiastic enthusiasts, but we need to convey that excitement to new readers if we’re to entice them.

About the Author: Horace Torys thinks too much for his own good. The results are at horacetorys.weebly.com.

Guest Blog Post: Simple IF Interfaces

Reposted from HoraceTorys.weebly.com

Recently Emily Short [twice], David CornelsonNick Montfort, and others have written about the command line/parser in traditional IF, and whether we can improve or eliminate it. Understandably, when a player tries IF for the first time, they are usually confused by the command line and the many conventions that go with it. They end up with more error messages than story, and are unlikely to persist.

The command line will live on as long as authors and readers keep enjoying fiction made with it. But many have pointed out there is a huge market of readers (print and digital) and casual gamers who ought to love all this free IF, but sadly, they aren’t exactly flocking to it.

One reason must be the interface. Another might be the lack of “packaging,” both in a marketing sense (few attention-grabbing covers, promotional materials, or sites), and a convenience sense (first download an interpreter, then a file, then find a FAQ or guide). A third for some is that playing IF can feel like using DOS or an early BBS, not reading a book. And if a reader gets past all of these things, they’re likely to find most IF is about “you,” trapped in an area, examining everything and picking up random things to get to the next area. Obviously, there are exceptions to all of these, but a beginner can’t count on finding them before giving up.

I tried to address some of these barriers, and below are mock-ups of my ideas. They fit an iPhone screen, and could be programmed in Javascript to work on mobile devices and browsers. The images are a sequence: the result of each click is shown on the next screen.

Click on images to see a larger version in another window/tab. Firefox and others may shrink the image to fit that window, you should be able to click it for full size.
Picture

Verb icons. Click the verb icon you want to perform, then the word in the text you want to perform it on. The main description and story carry on in the top bar (reflecting any changes you make to them), and immediate responses to your actions show at the bottom. For a working example, see my unfinished story Red.The way this mock-up turned out, it seems like it would be good to have both a TALK TO and a TALK ABOUT (with whomever you’re currently speaking to) icon. And maybe a GO TO icon.

Picture

Inventory. This version leaves its transcript available as grayed text, and only disables links that would break the game (e.g. players can’t pick up the same object twice). You can see an example of this method by I.D. Millington at undum.com.My mock-up also has an inventory, and works somewhat like point-and-click Flash games: clicking on an object in the text either interacts with it or adds it to your inventory, and objects in your inventory can be examined and combined, or used on yourself or things in the description text. As my simple example tries to show, this would allow for some lateral thinking puzzles.

One cumbersome part of the transcript method is having to scroll back for keywords you need, hitting the eye icon to look at the room again, and re-clicking objects for description keywords

Picture

Popup menus. The links look just like the rest of the text, and the reader just clicks on nouns or significant phrases to view and choose from interaction options. This would keep the text “clean” and require no extra panels, but almost everything in the text would need a menu to come up when clicked.I’ve shown two styles, the first more of a choose-your-own-adventure flavor, the second more IF puzzle solving. Either would allow you to examine objects and their details, but also manipulate them or make choices that moved the story.

I showed only verbs that served my examples, but the menus could be more consistent, offering the same limited set of verbs minus inapplicable ones based on context (e.g. no TASTE option for the moon). The menus could also use verb icons instead of words.

Inventory + verbs. No mock-up for this one, but it would work as a combination of the first two examples, like a LucasArts graphical adventure such as The Secret of Monkey Island. The player chooses from a list of verbs, and performs them on links in the text or items in the inventory list. Add directional buttons, and you could have most of the interactions of IF or graphical adventures.

Granted, it’s fairly easy to create short mock-ups that serve my purposes. These may look like glorified CYOA games to some. The proof will be to create a working story that provides an enjoyable experience. I believe that with some extra work (programming all by hand, without the benefit of a robust environment like Inform or TADS), one could create a fiction system that allows free travel, object manipulation, and puzzles, while still being intuitive and book-like to new readers.

About the Author: Horace Torys thinks too much for his own good. The results are at horacetorys.weebly.com.