Postmortems in interactive fiction

I’m a big fan of postmortems in projects.  While they are interesting to read as an outsider to a project, they are most beneficial to the stake holders of any project.  In Interactive Fiction, this is no different.  They are usually very interesting to read, but of more importance to the author.

Following the results of IFComp 2014, we’re seeing quite a few postmortems appear.  You can read quite a few interesting ones on the forums (http://www.intfiction.org/forum/viewforum.php?f=32).  What I find great about reading these is you get an insight into what the author was thinking / feeling as they wrote their work, it’s just great reading about the inner reasonings behind their decisions and their reflections on what they learned.

I’ve released two games, not counting my IntroComp entry this past year which I’m still working on to get to a truly releasable state.  I’ve written postmortems for both and while not as comprehensive as some I’ve seen come out after the comp, they serve the purpose I set out for.

My format for postmortems is simple.  I simply find 3 things that went well, things that I want to do more of and then find 3 things that didn’t go so well, things I want to learn and grow from.  With that simple template, I create a document for myself (and others) that is not only an exposition on the work that went into the piece, but also something that I refer back to from time to time.

I hope that more people take the time to write postmortems, not only for their comp entries, but for anything they release.

Puzzle Design – Resources

As I’ve recently been struggling a bit with some puzzle design issues (basically my mind is coming up empty on ideas lately), I thought I’d put together some resources that I’ve found that I’ve read (or queued up to read).  I’m sure I’ll add to this over time and I invite you all to offer up suggestions in the comments.

Note this list is more for me to have handy when I need inspiration.

Designing the Puzzle – older article, but the information seems to be very relevant.

Emily Short Puzzles – Emily puts together a nice list of types of puzzles with gaming examples.

Making of Counterfeit Monkey – Emily discusses the making of her game and contains a lot of puzzle design comments.

Coding puzzles – Another article by Emily detailing some concepts of puzzle coding in Inform 7.

Emergent puzzle solutions – OK…one more by Emily sharing some thoughts on a simulationist puzzle design.

Making Better Puzzles – Stephen Granade gives us a simple article on designing better puzzles.

Designing the puzzles of escapade – Great article on how Juhana designed the puzzles in this game.  Great usage of mind-maps.

Puzzles, what are they good for?

This is a nice start to a list.  Please add comments to what you may think is useful.

Fun vs Realism in IF

One thing I struggle with at times when coding on my WIP, is the idea of realism in modeling objects or actions.  I think often we (or maybe it’s just me) can get caught up in perfectly implementing something and duplicating it’s exact functions that we forget or don’t realize that often our mundane tasks aren’t really that fun.

Let me share an example of something I was working on a while ago (still in the works, just on a bit of hiatus at the moment).  Early in the game, the PC comes across an elevator.  My original implementation had the complete function of the elevator.  When standing outside, you pushed the call button. Then you waited for the elevator arrive.  If the elevator was on the 3rd floor and you were on the 1st, it would take 2 turns for the elevator to arrive.  I had implemented a floor indicator above the elevator that told you exactly where the elevator was each turn and then when it arrived, the door opened.  Then after two turns, if you didn’t trigger something else, the door would shut automatically.  You got in the elevator and the process repeated itself as you moved to your destination.

A typical transcript might look like this (abbreviated of course):

You are standing in front of the elevator on the 1st floor.  Beside the elevator is a call button and above the elevator door an indicator showing that the elevator is currently on the 3rd floor.

>push call button

When you push the button you hear a distant ding and then the whir of the elevator as it begins to descend.

>look

You are still in front of the elevator but the floor indicator now says 2 as it descends to you.

>z

You wait and the elevator has arrived and the doors part.

>in

You enter the elevator.  Before you is a panel of floor buttons and again above the door is an indicator showing that the elevator is currently on the 1st floor.

> push floor 3 button

The doors close and you feel the elevator begin to lift.

>z

The indicator above the door indicates you’ve now reached the 2nd floor.

>….

Well you get the idea.  In the real code, I had much more interaction you could do while waiting, but the essentials were there.  I finished it up and I was quite proud of myself.  I had learned a lot during the development of this and actually had thoughts on expanding it even further.

But it wasn’t fun!!!

After playing through the elevator section multiple times during testing of it as well as coding up the areas on the upper floors that I was moving to, I was sick of it.  I didn’t want to wait around for the damn elevator to show up.  Ugghhhh,…..what to do.

Well I scrapped it all.  Well not really, there is an elevator there still and you still need to use it to go to the upper floors (and of course I saved all the code off in my archives to reference later), but the transcript goes a bit like this now.

You stand before the elevator on the first floor.  Beside the door is a call button and above the elevator is a floor indicator showing the elevator is currently on the 3rd floor.

>push call button

You push the button and you were the elevator begin to your floor.  After a few moments the doors part and the elevator has arrived.

>in

You enter the elevator.  Before you is a panel of floor buttons and again above the door is an indicator showing that the elevator is currently on the 1st floor.

>push floor 3 button

You push the button for the 3rd floor and the doors close.  You feel the elevator being to rise and a few moments later the elevator doors open and you arrive at your destination.

Much better….I still kept much of the scenery and things to play with there, but I made the travel much easier.    Still perhaps not the epitome of fun, however it keeps enough of the realism of the elevator without forcing the player to step through all the mundane steps that we take each day without thinking about it.

My takeaway on this is to make sure that no matter how cool the code is, no matter how realistic it may be, unless I’m writing a historical simulation or a particular puzzle or story element truly requires that level of detail….I need to make sure it’s fun and truly necessary before putting the player through something truly mundane.