The Post Mortem thread

WARNING: This is a pretty long read

I made a post a while ago about starting a thread dedicated to post mortems

http://forums.tigsource.com/index.php?topic=13650.msg403160#msg403160

Mostly, I wanted to read some myself so I could learn from others. I thought it would be a really useful resource for everyone to learn from, especially those new to indie development like myself. There seemed to be genuine interest from several people but unfortunately no-one wrote any up. I wanted to kickstart it but I hadn't completed any games at that time. Not so anymore! My first game's been done for a while now and I've had some time to reflect on the entire process so decided to kick start the thread.

Game information

Title: Spectrum Boy
Genre: Puzzle Platformer
Dev Time: 3 months
Team Size: 1 (Me!)
Things I didn't do myself: The main character sprite. All sound FX and music
Engine: HGE (C++)
Budget: $0
Revenue: $0 (it's free)

What motivated me to make the game
I was speaking to a friend of mine about always starting projects but never seeing them through. In the past I've attempted everything; game mods, short movies, fully detailed RPG worlds, machinima using various tools...you name it but always give up before completion. We spoke for a while and he made a point that simply stuck in my head. Something along the lines of "No excuses, you just need to buckle down and do it!". For some reason it flipped a switch in my brain. It was an odd feeling because I knew right then and there that whatever I would attempt next I would see to completion.

How I came up with the concept
I knew from the start that the game would have a really simple mechanic. The reality is that my total coding experience was 2 years at uni, and that was 6 years ago. I knew my limitations. I started to sketch ideas in a notepad and within 15 minutes I'd designed the colour mechanic that is the core of Spectrum Boy. So I basically ran with the first idea that popped into my head. Sometimes I ponder what might have been had I spent a solid 2-3 hours just brainstorming ideas. Maybe I could have come up with a better game idea. But colour management was what I went with. To be honest puzzle platformers aren't really my thing but I knew that my favourite genre of games (RPG, FPS, MMO) was not realistic. I needed to do something that I could finish in a reasonable amount of time. The number one goal for my first indie game was completion, even above fun factor.

What I had BEFORE writing a single line of code
I had the core mechanic down on paper, that's it. No nicely formatted design docs...nothing. Probably about 2 pages of crude diagrams and rough notes. I had a bunch of half ideas on paper as well such as enemies, doors, moving platforms...etc but these weren't fleshed out at all. I figured these weren't important until the core game mechanic was playable.

Prototyping
For the prototype I used a really simple 2D engine I had gotten from uni ages ago. The first couple of days were painful. I installed Visual Studio, looked at an old project of mine for reference and everything looked alien. I had to google 'how to declare a string', 'what is a virtual function?'. I was that lost. But after abour 3-4 days everything came back and I had the core game up and running (player movement, jumping, collision system, colour mechanic). Within a week the game was playable. All the art was placeholder. I didn't care how it looked I just needed it to work. Thought I'd mention here that the game was created entirely outside of work hours. I have a regular 40hr/week job but I pretty much worked on it every single minute that I wasn't at work throughout the 3 months. I slowed down towards the last 3 weeks or so when the game really started to come together.

Prototype Completion
I built 3-4 levels and the mechanic seemed to hold up pretty well so I started to flesh out more sub-mechanics. Over the next 3 weeks I added extra features and made about 25 levels. By this stage, the game was beyond what I would consider a prototype. It was time to build it properly. The prototype was all about getting it to work as fast as possible so most of the code was REALLY hacky. I knew I was going to rewrite the whole thing anyway so any hack in the prototype was acceptible.

Rewriting the Game properly
The 2D framework used for the prototype wasn't going to cut it so I did some research on free 2D engines, and went with HGE. By this stage I knew all the features the game would have (since I prototyped them all) so I could plan how to write the game much more cleanly in advance. There's not much more to say from a production perspective. This second iteration took about 2 months. I didn't find an artist so I did all the art myself. I added polish stuff like the death system, lobbys, elevators to get to the next floor, tutorial levels...etc. The prototype didn't have any of these things as they weren't necessary to prove out the gameplay. Ultimately, this phase consisted of looking at the prototype and doing it again, except this time it needed to look and feel like a finished game. I reused a lot of code from the prototype but I did write it again entirely from scratch.

What worked

Small scope. I truly believe it is imperative that your first project needs to be small and completable. You need to get into the habbit of finishing things, to ingrain the notion that completion is the norm rather than the exception. If on the other hand you condition yourself to quit projects, that becomes the norm instead and it is incredibly easy to just give up in future endevours because you are used to it. If you aren't working on your first game...well this may not apply.
I never felt like I had trouble with feature creep. I stuck to my small scope mentality quite stubbornly. I rarely felt the need to make my first ever indie game the greatest thing since Braid or Plants VS Zombies. I KNEW that feature creep kills projects and is probably the biggest reason of abandonment for veterans and rookies alike. The one thing I decided to include very late was sound FX and music. I originally decided it wasn't necessary but after downloading and playing several indie games, I realised that it added so much and games without it felt somewhat incomplete. Even then I didn't just make the decision on a whim. I estimated it should take no longer than a week since HGE already has a sound library set up (Bass). If I had to write sound code from scratch, I definitely wouldn't have bothered. In the end it took maybe 3 days to do so it had a small impact on schedule but major impact on polish. I think you need to make these calls on a case by case basis. What will it cost to get in? How much does it really add?
The throwaway prototype was extremely useful! Having something you can just hack away at by any means to test mechanics was awesome. In the end, the prototype is almost exactly the same as the final game except it looks pretty crap and is quite unpolished. I used global variables very liberally and it felt GREAT
I had a notepad on my desk that I'd scribble notes in, write pseudo code, draw rough diagrams of new mechanics and levels. This was incredibly useful and I'd suggest that if you aren't doing this already, you should!
All the game mechanics and engine features were really well defined. Walk, Jump, Parallaxing background, collision system, bricks, enemies, teleporters, moving platforms, lift...etc. Each one was also fairly simple and modular. This meant that on most days I managed to add something entirely new to the project whether it be a framework or game feature. I think this really helped in keeping me motivated. The really cool thing is that all those features are visible in the game so I can see my progress.
There were days I really didn't want to work on the game, but somehow I just forced myself to do it. I wish I could explain how I managed to do this in a step by step guide but I can't.
The TIGSource community helped with my motivation. I would scouse the forums frequently, update my dev log and play other people's games. Just writing and reading about indie dev helped immensely.
Overall I felt like my production process worked really well. I didn't follow any project management methodology. I kind of winged it but hey...it worked.

What didn't work

I wrote a lot of framework functionality that already existed in HGE. Had I read the documentation more thoroughly I could have saved myself a lot of time!
I originally really wanted to include a story in the game. There's a reason why you're collecting baseballs and the enemies are cars. BUT...I decided it would take too long to write a cutscene/scripted sequences system so I cut the story entirely. It was supposed to be a story about life and death. This is the only thing that I'm truly disappointed about not being in the game.
There's got to be more than this...but I just can't think of any more right now. Will update this post if I remember anything.

Success or Failure?
From a development standpoint I'm really pleased with how I managed the project. I think I made pretty good calls in terms of project length, what features to cut, what to keep, scope...etc. So definitely a success in that regard. I actually released it earlier than my release date while adding sound and music which I hadn't originally catered for. The process of rewriting the game, using the prototype as reference went REALLY well. I thought it would take me at least 2-3 weeks to rewrite all the levels but I think in the end I did them in 3-4 days.

In terms of it being a good game well that's all subjective I suppose. I'm not sure what to base this on. Positive VS Negative feedback? Number of replies in my Announcement Thread? So far I've gotten mainly positive feedback. People seem to enjoy the game. But there haven't been too many people replying to my game thread. But all in all I'm definitely happy with the response from the community.

What's next?
Well I've started working on my next game already. It's completely different from Spectrum Boy but not much else to say right now.

Questions?
If you would like to know something I haven't mentioned, just reply and I'll do my best to respond.