December 2013 IF Update

I can’t hardly believe it’s December already.  November was a busy month for me.  Work was really keeping me busy and I don’t see that slowing down a whole lot.   Not as much time on personal project that I would have liked to have spent, but I did manage to make some progress.

At the beginning of the month, having just submitted my work (Jack) to EctoComp, I was anxiously awaiting feedback.   I had some say it was actually a decent work considering the time limit.  Despite perhaps some grammatical issues, it was fairly well implemented for a first release.  Others were turned off by the overt violence that begins to happen half-way through the game and by the lack of an ending.  So I received a mixed bag of feedback, but it was all good advice that I was able to internalize and use to make a future release better and to consider in future works.

It also gave me an incentive to start on expanding and making the work better.  I’ve gone into some of this in my postmortem that I did on the game, but I’ve spent part of the month working on finishing it up and fleshing out the back-story more.  It actually evolved beyond what my initial ideas were so it’s going to take a bit longer to finish it up for a post-comp release.  Also some of you that didn’t like the violence, well….I’m trying to make alternatives paths through the game that are less violent, but the back-story has taken a turn and become a bit dark.  It seems to work in my head, but we shall see how others like it.  Maybe by the end of the year, I’ll put out a release.

Another thing that has begun to take my attention away from Jack, is the New Years comp that was just announced.  I’ve got a few ideas for that, that we’ll see if I can expand into something doable by it’s deadline.

And of course, there’s also the Spring Thing, which I really wanted to to enter, but I’ve not got much done, so I’m not sure I’ll meet that deadline.  I’ve got one work that is about 50% done, but just not sure if I’ll find the time (or want to make the time) to finish that up.

I must say that over the last few months that I’ve gotten back into the IF scene, I’ve met some great people that have helped me along quite a bit.  I know that community support is great and everyone for the most part, whether they criticize or praise your work, they do so in the effort to make it better.

I’m hoping to be able to give back to the community in some way through this blog (as well as hopefully releasing some new games).    I’ve got a few ideas for some series of articles here, that I think might benefit the programming community (at least in regards to Inform 7  and game design) at large as well as myself.  I might kick the idea around with a few individuals first to see if it’s something that would be helpful or not before going into any great detail here.

Well, that was my November and hoping for a productive December.  So go north my friends!

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.


EctoComp 2013 – Initial Observations

This morning I’ve played through over half of the EctoComp 2013 entries and I wanted to share some of my initial observations on the competition.  

*** Full Disclosure: I am an author of one of the games in the competition ***

Some observations on the games themselves

Being that this is a speed-IF competition, the games are of course very short.  Some are more of the one or two room varieties with a handful of puzzles or tasks….there are a few with relatively expansive maps, though the interaction and descriptions in each are necessarily small.  

For the most part, despite the small size of the games and the short time to write them,  they are pretty high quality games.  Sure there are some grammar issues and some unimplemented objects and most need more atmospheric text (mine included in all of those statements), but most have decent stories and concepts that I feel if expanded upon outside of the three hour window, could actually become pretty great games.  I myself have already begun work on a second release of my game based on some feedback I’ve received already as well as my own notes of things I just ran out of time to implement.

Out of the 24 entries, there appears to be 16 entries in Inform  and one Hugo….about 71% of the games are parser games….which is interesting as by contrast if you look at the IFComp13 where we had 35 entries, only 13 (37%) appear to be the traditional parser style.  I find this interesting especially given the conversation over on the forums in regards to the slow decline of parser games in favor of the CYOA style games.  

Why the discrepancy? I suppose there are many varied and complex reasons and I don’t necessarily discount that perhaps their is a rush of new authors that are attracted to the apparent ease of creating (not interesting in a debate on the validity of my unscientific observations here, I’ll save that for the forum.)  I suppose that the author’s entering EctoComp perhaps are more plugged into the community since the competition wasn’t as well advertised, thus perhaps they have been around a bit longer and are perhaps a bit more old-school.  All just assumptions on my part, I just found it interesting to think about.

The non-parser games were actually well done as well.  Even though they are not my preferred type of game, I found that those I played were actually well done.  Again, perhaps because they are coming from more entrenched authors which lending their experience to any platform would increase the odds of putting out a decent game.


As I played them and enjoyed most of them I thought about how I would rate them (and if I even would).  Still undecided on if I send in a score sheet, but my criteria for rating is going something loosely like this with weights of the components of the score in this order:

  1. Did I enjoy it?  Was the story, the game play something I had fun despite any other flaws,  If I had fun, it will score well here.  
  2. Would I like to see more?  In other words, will I be looking for an expanded more complete release down the road.  If I want more, it will score higher.
  3. Was it well implemented?  This is hard to do in just 3 hours.  I know I have some unimplemented areas, verbs and objects in my game.  But I’d not be doing justice to the game that made the effort to squeeze in some better implementation or if they structured their text and hints so as to minimize any confusion on the part of the player.
  4. Grammar.  Yes I will include this as a very small component.  But very minor, I don’t expect in three hours to have well edited text, mine was no where near as good as I would have liked.  But I run into any glaring issues that distract from the game, then perhaps a small deduction may be in order.
  5. Extras.  I’m a sucker for extras.  I like that when a game thinks like I do and makes the extra effort to include some basic atmospheric text or an easter egg or two (if I can find them).  To me that shows the attention to detail that I like.  No deductions here if none are included, but perhaps a bonus boost if I see something extras in there.

Not very scientific, very subjective and of course this is just something I came up with to assist me in rating the games.  For more full games, like those perhaps in the IFComp, these would necessarily change weighting and there may be other criteria in there that I would include.

Anyway, I nice crop of games here in EctoComp 13.  Lots of fun and potential for the future.  This was my first release ever, though I’ve written plenty that just need finished, so I was pretty excited to have a reason to release something.  Hope everyone enjoys the games and if you feel so inclined, please vote!