I’ve thrown in the towel, too much stress and misery working on my game and that’s not really what LD is all about for me. I’ve still submitted what I’ve done in all its unfinished glory, click to play.

I thought I’d reflect on the experience as a whole and write a post-mortem on what I managed to complete. I’ve learnt a lot, which is always a bonus, as a result I don’t really consider it a failure. The game wasn’t complete for a number of reasons: I bit off more that I could chew (simple mechanics != simple programming), was using unfamiliar software and an unfamiliar engine (due to reasons out of my control) and, amongst other things, I’ve not been very happy with my working environment.

What went wrong?

Working environment : I’ve been working on a laptop with a fairly low resolution screen, without a desk and therefore without second monitor, mouse or graphics tablet… first world problems. It is surprising how less efficient I’ve been working with much less screen space and trying to produce art assets using the touchpad of my laptop. I knew it would be a problem but I didn’t realise how much time it would take up. Other environment-related issues included not getting enough decent food in the house, I’ve been living off what little I could scrounge from the cupboards (cue takeaway). Being comfortable and having the right set up is important when trying to churn out a game in 48 hours.

 Art pipeline : Getting artwork from GIMP through to FlashPunk is a smooth process but not an immediate one, as it was when drawing directly into Flash. I’m also not familiar with GIMP, add that with trying to draw with the trackpad and the additional steps involved in getting an image (most with multiple frames) into the game, and it became quite a time sink. I did actually enjoy working with the GIMP (at least it installed… I’m looking at you Photoshop), I think there is a potentially good pipeline there but I need to make sure I’ve got the right tools for the job and just practice to become familiar with the software.

No level edtior and an unfamiliar engine : FlashPunk seems pretty great to be honest, it works well and is smooth. However, I spent a not insignificant amount of time looking stuff up yesterday. As I mentioned above and in a previous post, Flash CS5 (my tool of choice for making games… because I’ve used it to make games before) and Photoshop CS5 wouldn’t install on my laptop. I’d used FlashPunk and FlashDevelop to make a snake clone a few months back and they were both free, so I went for those as I didn’t really have a choice if I wanted to take part. Coupled with that I made the board and positioned all of the game entities using code, I hadn’t had the time to get a level editor sorted nor develop the code to parse a level file.

What went right?

FlashDevelop and FlashPunk : Although I mentioned being unfamiliar with FlashPunk as an issue, the engine itself performed admirably. I initially thought about writing the game from scratch with just FlashDevelop but in spite of the problems I believe that using FlashPunk was a good idea and I achieved more than I would have otherwise (if I had just coded an engine from scratch in FlashDevelop). FlashDevelop is a considerably superior IDE than I’m used to as well. Overall, thanks to this combination, coding was much faster than usual. The main thing holding me back in this area was a lack of experience and a sloppy attitude towards structuring the code towards the end, both of which can be rectified.

Deriving mechanics from setting, story and theme : By far one of my weakest areas in designing games is working out the mechanics, what exactly the player is going to be doing. Pretty essential for creating a compelling experience. I’ve found that I have a hard time working from gameplay-to-setting and a much easier time when working from setting-to-gameplay. So in this case, once I knew who the player was inhabiting, where they were, what genre I wanted to work within etc… then it was much easier to start developing the gameplay. My biggest weakness this time around was not being specific enough and pinning down the core mechanics that I wanted, I left it all in my head and it was inevitably too vague and I floundered after getting tired and stressed.

Working on the interface as a whole : To develop the artwork for the game I (eventually) set up a new file in GIMP that was the same resolution as the game and began to work on drawing the interface as a whole (on different layers, grouping into layer folders etc…). I’d then cut out and extract the individual elements into their own files. Although hindered by the issues noted above I enjoyed the process, it helped to get the artwork done and resembles the way that I’d work in Flash (although that is much more immediate).

What would I do differently?

In an ideal world I’d try to implement the following suggestions but, of course, I didn’t implement the suggestions that I made last time…

• Design : I’d drill down from character and setting to game mechanics and be more specific about the gameplay that I want to implement. Once I have a list of the key gameplay features then I could use that as a to-do list and try to get something playable up much more quickly. In LD 24 I had a crude but playable game by the end of the first day which I could then refine, this time by 17:00 on Sunday I still didn’t have a game which could be won or even lost. A very simple example would be as follows: I know the player will be an out of luck goblin (setting), they want to control their local dungeon (goal), how will they control it? By hiring minions to fight for them (mechanic). From there I can get more specific, how will they hire minions? A trading system, giving gold and resources for creatures, where will they find minions? Collecting cards from dungeon lairs, traders or finding them scattered throughout the dungeon and so on. Although, this time I did have the setting and genre which helped, I left the gameplay too vague.
• Programming : The programming went well this time, it was messy in places but nothing compared to LD 24. Thinking in states right from the beginning helped immensely to structure the code (although breaking states down into sub-states would have helped as things became more complex). Creating display classes that managed numerous entities and just presented a simple interface outside of the class was also an effective technique. As was nagging myself about DRY. Two major issues were: ignoring feedback and transitions, and not separating the UI code out into a separate class (I just fudged it all into the main game class). If there is a next time then I’d like to: warm-up with the tools, get some base code (preloading, buttons, sounds, template classes for the main elements, level loading etc…), a config class (key variables were scattered in different classes making playtesting and refinement hard work) and base code to simplify adding in different transitions (pop-ups fading in and out or sliding around, delays and tweens) and more elegantly handling player feedback (buttons pressed, disabled interface elements, damage taken, stats changed etc..).
• Environment : Making sure I’ve got decent tools for the job, if I’m using a laptop again then an extra monitor is a boon, as are a proper mouse and my trusty graphics tablet. Being comfortable and prepared can only help, right?

Okay, so this wasn’t my best game development experience but I’ve learnt from it and that’s the most important thing. I hope the rest of you get on better and get your games completed, good luck! All the best.

Tags: post-mortem, postmortem