Seems like everyone’s doing a post-mortem of their game jam – and since it’s easier for me to do one than it is to find out if it’s actually mandatory, here we go.

1. What worked

Almost everything worked for me, actually. Being forced into a small time frame made me simplify the graphics – meaning I didn’t have time to be fussy over colours, and didn’t have the time to agonize over the placement of each pixel, which is something I’ve had a lot of problems with while developing my other game, Return to Roots. This also resulted in a much more consistent aesthetic, which leads me to believe that the more time I spend on sprites, the worse I get.

AI development also worked out really well. Before tackling the AI, I wrote out a sort of “chain of command” that all enemy units would follow and communicate to one another. Having a bulleted list of “Do this, and then either to this or that” made it easy to split up the process into smaller, isolated tasks.

Program workflow kind of worked well. Stages are split into scenes, which contain a list of brawls. The “brawl” class could have been designed much better than it was, and creating a new scene required writing an entry into two places instead of one. Same for the brawls: edit code in two spots instead of one. But that was it; it was very easy to define where brawls would occur, who would be in them etc.

The control scheme. Controls feel smooth and (mostly) responsive, though I regret not adding single-key input buffering. The ability to attack in different directions regardless of which direction your character is facing was adopted rather well.

Feature Creep was rather nice to me. I had little trouble coming up with great features to add, but also had little trouble axing them due to time restrictions. So despite it being my first game jam, I managed to avoid biting off more than I could chew. (Chew means code.)

The storyline/plot of the game also came naturally, worked very well as a framing device for the game, and was well-received.

2. What didn’t work

My animation manager, for starters. I’ve developed a small but versatile class for handling spritesheets that allows for multiple animations of varying sizes and framerates and playback styles. Due to the nature of the LD48 compo, I couldn’t use it, and instead wrote something similar but much more barebones, from scratch. The result was slightly messier and more restrictive.

Time management was also pretty lousy. I thought I’d pace myself, so I went to bed by 3:30am on the first night. And slept for 11 hours. I had to make up for that by skipping sleep the next night, instead taking a 3 hour nap around 10am. I also did some other things unrelated to the competition during the competition, but they were more in relation to the next thing that didn’t work:

My chair. After sitting in it for 8 hours straight, even with a throw-pillow between me and the chair, my arse was killing me. I had to sit on the couch or in bed and play video games (Kingdom Hearts: Dream Drop Distance and a full run through Sonic the Hedgehog 3 + Knuckles, specifically) to pass the time and get the soreness down. I’ll need more cushions and regularly scheduled 5 minute breaks next time. Because there will be a next time.

Playtesting. I’ve got a lot of experience in software testing (well, comparatively to other things I do) so the game itself was functionally tested, but game balance didn’t receive any attention until 90 minutes before the competition’s end. Enemies were given too much health at first so that was pared down a little, but I think it still got overwhelming near the end. Game Overs boot you to the title screen, which someone was quick to point out the viciousness of. A game should be difficult and challenging, but it should not be frustrating. A fair punishment would be restarting the stage, but to redo the entire game is enough to make people drop it, especially in a competition such as this one.

The Main Menu. I should have spent more time on the title screen, making the difficulty select be menu driven instead of pressing a specific key for a specific action. The number keys aren’t used at any other time, and they don’t exist on the gamepad, so when I do port the control scheme to XInput gamepads, I’ll be having to redo it anyway. Should have planned that one ahead.