Post Mortem – White Houses

I just released a second release of my ShuffleComp 2014 entry White Houses.  Now that the competition is over and I can reveal that this was mine, I felt it was time to do a postmortem on the game and see what I did well and what I could do better.

What I could do better.

  1. Be careful of the scale of my initial idea.  Big ideas aren’t bad, but with the limitation on time to work on this as a nature of the competition, big ideas can be a dangerous thing.  When I first went through my songs, I was less than thrilled by the ones I had to choose from.  I knew none of the works and none were really in my genres of music that I listen to.  So to listen to them enough to pick something out was really tough for me.  Once I settled on “White Houses” by Vanessa Carlton, it seemed natural to me to choose to base it around the White House from Zork. I have always been a fan, so it seemed a natural fit.

    However, my initial idea had about four different characters and would have required a lot of interactions and conversations between them all.  I also had the demeanor of the main character change based on those interactions, based on items found and tasks performed and actions taken.  This led to the potential story paths that could have lead into the hundreds if not more of endings.  It all sounded pretty exciting and I had a large part of the map framework laid out and the characters sketched and then realized that while a pretty cool concept, there was no way I could finish in just a few short weeks.  Time to scale back.

  2. I got caught up in trying to reproduce the white house from Zork 1.  While this was fun and was actually part of the intent, I got caught up in reproducing Zork 1 (just with some minor detail changes) and forgot that while my setting was similar, my story was different.  Yes I implemented the map pretty similar with a lot of the same objects, it was a lot of meaningless details that I didn’t need.  Many items found in the white house have function that is important later in Zork 1, but beyond the map of my game.  So the items are there, but serve no purpose other than to fill out the map.  I think this gives the game a bit of an unfinished feel to it.  I should have concentrated more on what was used / needed in my version of the game to expound on the story more.
  3. I need to expand on the story more.  Partly because of the two issue above, the story that I had in mind was left a bit to the imagination of the player.  While this may not be perceived as a bad thing, I don’t think my intent came through.  What is the story between the characters and why are we in this White House?  How is this all related to Zork?  Does my story happen before or after the time of Zork 1?  Many of these questions have answers, but unfortunately, they are still sitting inside my head.  Even though I scaled the actually playable game back, I don’t think I scaled the back story that surrounded this very much.  I also didn’t express it as well as I had wished.

What went well

  1. I had plenty of beta testers.  I had quite a few beta testers.  Thank you to Andrew SchultzPeter OrmeMarshal Winter, Carolyn VanEseltine, and Hanon Ondricek.  With their diligent testing, I was able to get this game to the point it is.  Many suggestions they had, I simply ran out of time before the deadlines to implement all it.  Had I done so, it probably would have been received better as they had some great ideas.  Perhaps I’ll get around to an expanded version, but who knows as I have a lot of other ideas to work on.

  2. I enjoyed writing this one.  I think half of the battle of writing any IF (or other works for that matter) is that no matter how great or exciting an idea you have, you run into that wall where it just is not enjoyable to work on anymore.   I never felt that way with this one.  There is so much material to draw upon in the Zork universe that I had to keep myself from trying to squeeze it in there. I love the feel of the Zork universe, with it’s fantasy settings and some dark undercurrents, yet always with that tongue in cheek humor.  I could enjoy expanding on this one or doing other take-offs of this world.

    Plus I like the old treasure hunts of old.  I have a hard time calling this interactive fiction.  I still like the term adventure games as for me, that is what drew me into this world back in the 1980s in the first place.  But I did enjoy trying to make this (with varying degrees of success), less of a treasure hunt and more of an interactive story, yet have it in the setting of a treasure hunt without making it the focus.  I’m sure it could be debated on how well I managed to do that, but I do think I succeeded at a certain level.

  3. I learned a ton.  As always, what I enjoy about any kind of software development is the learning that always comes.  This was no different.  From suggestions from my beta testers to a few challenging technical pieces, I stretched my Inform 7 programming chops a bit more with this release.  Now I feel even more confident heading into my next challenge and getting ready for my next release of my next work.  When I stop learning, I’m done…..I don’t think I’ll be done for a while.


Postmortem on my EctoComp Entry – Jack

small coverIn my real life job as a software developer and manager, I like to do postmortem’s on my projects so I know what I did well (so I can do more of that next time) and what I didn’t do so well (so we can make adjustments for the next project).  I thought this would be handy for my IF works as well.

My first released work was for the EctoComp 2013 competition titled Jack.  I came in 16th out of 24 with an average score of 5.14 (out of 10).  While perhaps not as high as I had hoped going into it, having played the games above me, I feel it was about where my game should have been.  So I’m happy.

Being a speed IF competition, the rules allowed for 3 hours of work (actual coding / writing) and no more.  It also, while not a strict requirement, had a specific theme to follow…something Halloween.

What I did poorly.

  1. I didn’t spend enough time prepping.  One caveat too the 3 hour rule is that we could spend as much time prepping the story beforehand.  As long as no work was done on the computer, no coding nor any writing of dialog in a text editor or anything.  I spent too little time here.  I came up with the idea the night before the deadline and spent an hour or so, laying out a brief story line and a smallish map.  When I started coding the next day, I found myself spending too much time rewriting text and changing implementations of puzzles and actions as I just hadn’t thought it through enough.

    There are many different ideas on planning, Emily Short has a nice article on  her thoughts, but I feel I work better if I have a concrete plan in place first, not that I’m stuck with that plan, but it’s a good guide to work with.  Without that, I can usually work pretty well for a portion of my story, but there comes a time when I run into road blocks.  I have plenty of unfinished / unreleased works that fell in this trap and I find it harder to go back after the fact and fix story or implementation issues.

    Takeaway:  Spend more time in the planning phase. Make sure the story makes sense, make sure there is a clear path from start to finish, put the puzzles (if any) in place in the design phase and know how they work, and have in front of me a blueprint and plan of what I need to work on.  This might sound methodical and not very creative, but the creativeness goes in the planning stage and now we are working on writing code.

  2. I was too ambitious.  Not that ambition is a bad thing, but for a speed IF that only gave me three hours to code, I planned too much for my game.  The little planning that I did do for this game, created a map of about 6 rooms.  Not overly large, but because of the time restraint, each room was necessarily sparse.  Also the atmospheric text suffered some.  While I think I did a reasonable job of providing a decent setting, the rooms were not done to my normal level of completeness.  Room descriptions were limited, a few items mentioned were not implemented and the game became very linear.  One other problem I ran into and probably the biggest problem with my game, was the ending.  I was not happy with it at all.  When I was nearing the end, so was the clock.  With little more than about 15 minutes left to go, I still had two rooms to implement to get to the ending that I was trying to setup.  I quickly wrapped those up with nothing more than some quick descriptions and an end-game that just required you to get to the end location.  The ending text also hinted at the story that I was trying to create, but left the reader hanging horribly.

      Know the limitations you are working under, whether a time constraint, game play constraint or perhaps theme restrictions.  Plan accordingly.  I would have rather restricted my map to just a room or two, yet made them much more descriptive and interactive.
  3. Not enough testing.  This again, was a problem with the time constraints, but still I could have done better here.  As I started to get feedback, I was dismayed with the amount of spelling errors, grammatical issues and unimplemented (unintentionally) verbs, actions and items.  While I don’t believe there were any major bugs that made the game unwinnable as it exists for the competition, they definitely took away from the immersion into the story.

    In this competition, any time beta testing was included in the 3 hour limit, so there was little I could do.  I did have my son run through it once before I submitted, but he’s not an IF player and found little.  My wife ran through after I had submitted and found a few issues, but those will wait until a second release after the competition is over.  Not sure how much I could have changed with that…but if I take into account my first two points here, then I would have more time for testing.  It did point out the strong need for testing however….when I submitted it, I truly felt it was pretty good with very few problems…and while it was generally OK, and I got some decent remarks, I was still surprised with some of the basic things I missed.

    Takeaway:  If time permits, make sure there is plenty of beta-testing by multiple people if possible.  No matter how good I think it may be, I have to remember I’ve not caught everything.

What I did well.

  1. Made sure there was a path from start to finish.  I wanted to be sure that the game couldn’t get into an unwinnable state.  I made every effort to ensure that even if it stayed very linear, there would be no way you could get stuck.  Sure you could die in this game, but you always quickly did so and could recover from it or make an obvious change in direction next time.  Dying in the game, was actually critical to the story as my intention was to have it help to explain the story a bit each time you died.  I may not have achieved that entirely in this initial version, but the groundwork has been laid.
  2. Make sure the implementation is solid.  While there are some implementation issues, most are relatively harmless in the sense that it didn’t affect the gameplay.  There is some color text lacking and some scenery items lacking decent descriptions.  There are also some verbs that were not implemented, but they did tend for the most part to be secondary ones that yes add flavor, but not necessary.

    I think I was fairly successful in keeping from causing and “guess the verb” issues.  I did that by keeping my vocabulary simple and make sure that anything that was a bit out of the ordinary, was well hinted at.  Based on a few transcripts and comments I received, I think I did fairly well with that also.

  3. Began work on an update right away.  As soon as I submitted the game to the organizer, I began making updates for the post-comp release.  I knew of some things that needed implemented that I hadn’t because I ran out of time.  I went ahead and fixed those.  As I began to received feedback and reviews with suggestions, I began to implement those as well.  I am also planning for an expansion on the story with multiple solutions to puzzles and paths through the game, based on feedback and criticism received.

    I think it was important to start right away while my enthusiasm was high and everything was still fresh in my mind.  I hope to release a version soon after the competition is over that fixes most of the major concerns, with perhaps a third release later that expands on the game in a number of ways.   I hope to find beta-testers for these later releases so I can catch more problems before their released.

Overall, I was happy with the release and the results.  It got me over the hump of actually releasing my work which I hope makes releasing future games easier.  I’m looking forward to seeing some of the comments from the scoring sheets as I’m sure I’ll be able to glean a lot of good information for future games.