Postmortem: For Science!

Game concept

I had a good idea for the "secret identity" theme, but I failed to find anything interesting for the other themes before the challenge started. Because of that I spent all the first day figuring out what to do.

I decided to use the "arch-enemy" twist of nemesis and I wanted to do something with a strategy component presenting two enemies fighting each other over and over. Besides I wanted to let the multi-player door open, just in case I had the time and the inspiration, and a "vs" game seemed a good idea.

One element that is frequently used in strategy games is resource management. Basically I needed a way to provide to the player limited resources so he had to choose between different actions in order to defeat his enemy.

I'm not sure how I ended with a match-3 puzzle game for that, specially because I used Command & Conquer as a reference for the resource management idea. C&C is one of the strategy games I've played most (back in the day), and I tried to find a way to reproduce some of the basic mechanics with my limited art skills.

The match-3 puzzle kind of works, with very simple rules:
  • You must match 3 tiles or more to obtain resources: money and the assets to use against your enemy (they cost money).
  • Assets let you attack and defend (repairing your shield).
  • It is turn based (just in case the multi-player part happened, remember?): you can match-3 or use assets, so you must choose what is best for you each turn.

At first I meant to use rock/paper/scissors mechanics with each attack having a defensive counterpart, but because my artistic limitations and the time pressure I had to simplify the idea: several attacks with different price/damage to make the game more interesting and a "shield up" asset as defensive element.

The main problem with this game idea is the artificial intelligence, because the player will fight against the computer and it needs to be both challenging and fun. I didn't want to do it too difficult neither too easy.

The best way to minimize the effect of a bad AI is to have a "tournament" or "story" mode with a increasing level of difficulty, or a "human vs human" mode. Unfortunately I didn't have the time to get that far, but it would have been nice.

You can check the "final" idea here: http://media.pyweek.org/dl/16/useboxnet3/game-idea.jpg

I'm very happy I stuck with the plan, because by the end of the week I was inclined to simplify things and the result would have been quite different.

Development: what went OK

I read about OpenGL, Pyglet and Cocos2d before the challenge. I made a warm up game with Pyglet, and that was very valuable. In fact I should have done the same with Cocos2d because I didn't know how to use the library and that made things a lot harder (but that's part of "what went wrong").

This time I've used Inkscape for the graphics and I like the results. I didn't have experience with the application, but that wasn't a big deal because I have limited pixel art skills too, and looks like it's easier (or faster at least) to draw decent stuff with Inkscape than to do good pixel art.

For the audio I used sfxr and Audacity, plus SoundTracker for the song (nailed it, didn't I?). I kind of regret adding the song too early in the development process because by the end of the week I couldn't get it out of my head.

Having one day off was great. I don't think I would have finished the game without that extra time, specially because I didn't have a game idea to start programming on Sunday.

My development cycle is kind of slow because of testing, and it is a good thing. In fact I've only detected a very small aesthetic bug in the final version of the game, and that feels great!

Development: what went wrong

Again: don't use a library you don't know well enough. Just don't.

I did it in the previous PyWeek with PyGame, and did it again this time with Cocos2d. Yes, Cocos2d is amazing; but it's hard to use and too easy evolve your code into something unmanageable. Besides that feeling of "I don't know what I'm doing" doesn't help when you are programming against the clock!

I tried to have a better structure for the code, and I had a plan. When I went with Cocos2d I thought the Scene/Director/Action structure of the library would force me to "do things right", but I was wrong because I still made a couple of big mistakes (I went with a view/controller pattern and in some cases I put data in the wrong place). At the end of the week I had a mixture of spaghetti code with some lasagne code (too many layers!).

I didn't test Cocos2d with py2exe and I found a couple of glitches. Not a big deal because I was lucky and I could patch the library, but that's something I should have done before the challenge. After all the hard work it's really heartbreaking when you stumble upon a bug in one of the libraries!

Finally I completed the game scene too late, and I didn't have enough time to play it to fine tune the gameplay and the AI. I think it happened that way because the game is like two games in one: the match-3 part (it was "ready" on Friday) and the attack/defence part (I couldn't finish it until Saturday afternoon); and two control parts: the mouse and the AI.

I have setup a web for the game and I'll release post-compo updates fixing any bugs I find (not many so far).

Final words

This PyWeek was intense, as it is supposed to be :). I had more time for coding than in the previous PyWeek, but the game was more ambitious and at the end I had more or less the same stress level.

I loved it, but I need to find a way to do it less tiring next time!