Postmortem: Kill Cutie

What went wrong		What went right
iOS controls I didn't know that the controls played such a big part in a game. Mostly because they are much easier to implement on a keyboard where you have tactile feedback. What I realized is that in most casual games for iOS, the controls are the centerpiece of the game. Poor controls never gave Kill Cutie a chance. I knew that iOS controls were going to suck ape dick, but I didn't know it was going to suck dog poo.		Creating content Content creation was a breeze. I created levels, vehicles and stuffing very quickly. I modeled statics and meshes in Maya and edited dynamics (joints, engines and so forth) in Notepad. Then I ran my import script and I was ready to test.
Game design Apart from missing iOS controls (which should have been a top priority in my game design, duly noted), I simply had the idea of playing with a trajectory. I also didn't want to make it too easy by adding cross hairs pointing out exactly where the user would hit. Both were Big Mistakes. Trajectory is no fun unless you get the proper feeling. If you can't see the grenade 90 % of the time, it's not a trajectory to the user any more, it's just a grenade flying somewhere off screen. Cross hairs would have been the way to go. Easier is better. If I'd imagined I was making a game for six-year-olds, that would have helped, since a casual game should take seconds to get fairly good at, not hours.		Using my game engine The game engine did a good job, as well as helped in portability. 3D rendering, physics (through ODE), and the basic GUI stuff was all there. I added my own font rendering for iOS and Mac platforms, but that was pretty interesting. Furthermore I added stuff like basic HTTP client support (through HappyHTTP) and XM music player support (through ChibiXM) which I plugged into OpenAL. But generally it was all there for the taking. Which was nice.
Many permutations Single player vs. AI or PvP on split screen. On PC, Mac, iPad and iPhone. Using different resolutions and screen orientations. Different controls. Different GUIs, which need to be laid out differently depending on platform. Registering high scores in different places (since keyboard controls are much easier+better than touch controls). Some type of "keyboard mapping instruction" for PC+Mac. Awfully slow stencil map shadow rendering only available on PC+Mac, and only if the frame rate is high enough (I turn it off if frame rate drops to low over some frames). Handling high score entry on actual and touch keyboards differently. Link to iOS App Store for free PC+Mac versions. This may not sound like much, but it was. And it's more to it than I listed above. And Devil's in the details. When I'm going to make a good game in the future, I'm still going to redo this thing - but I'm never doing it again for a game I know is going to Epic Fail.		High score Implemented with a simple HTTP client on the game side and a Google App Engine (GAE) app on the server side, this worked nicely out of the box. A few lines of code in the game engine, a few lines of code to use it in the game and perhaps a couple of hundred lines of Python code on the server side to manage my free 1Gb slice of flatfile database from Google, thank you very much! I'll be reusing this for my next game.
Testing Originally I wanted to test everything thoroughly, but in the end I got stressed out by everything taking so long so I simply didn't give a flying fuck. Just after release I had one pretty serious bug, and one not so serious. The really bad bug I fixed in minutes and then I requested Apple to do an Expedited App Review, which they actually did. It occurred when the CTF-flag was initialized before the level was completely loaded, and it caused all the meshes to end up in origo, and without proper orientation. It happened quite frequently. Does it sound strange? The code was too. The other bug had to do with in-app purchase. The application hangs after a purchase, I think. But it doesn't matter much, because only seven people has bought the game. ;) I'll have to fix that one sooner or later. There are of course others, but see if I care.		Music For some reason I came to think about a guy in my high school called Jonas Kapla. Jonas composed chip music when we were in high school, and he was a friends frind and a nice guy. I haven't seen him for many years, but I found some of his music online and him on Facebook. He agreed on 10 % royalties, which is a robbery – music being the best part of the game and all.
Feature creep I just added stuff. It made the game somewhat better, but what’s a 1 % improvement in added features, when there’s a 500 % improvement available right under your nose?		Vehicle AI Went with a specific and very simple solution. It’s about 900 lines of code within an enum-switch. The enums are FIND_BEST_PATH, FIND_PATH_OFF_ELEVATOR, NORMAL, HEADING_BACK_ON_TRACK, BACKING_UP, BACKING_UP_TO_GOAL, FLEE, STOPPING_AT_GOAL, AT_GOAL, WAITING_FOR_ELEVATOR, GET_ON_ELEVATOR, GET_OFF_ELEVATOR, ON_ELEVATOR, ROTATE_ON_THE_SPOT, ROTATE_ON_THE_SPOT_DURING, ROTATE_ON_THE_SPOT_WAITING. I thought long and hard about if I should start working on a generic AI library, or incorporating an existing one, but I’m glad I scrapped that idea.

In total: my first game == Trial and Epic Fail!