In 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.
- 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.
- 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.
Takeaway: 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.
- 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.
- 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.
- 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.
- 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.