Deciding to not use the same silly mechanics everyone was using, on account of being certain I couldn’t pull it off better than most of the others.

Choosing to go with a completely monochrome art style, on account of not being very good at art, myself.

Sleeping for at least 6 hours in the middle of the competition.

Dropping the target length of the game when it became apparent the performance would go down massively.

Recording my own guitar melody on my awful microphone, and using Audacity to somehow clean it up enough.

Bad decisions:

Using a single image file for each level, with the three channels describing each pixel in the game. See addendum 1.

Using Pygame. Over half the time was spent searching through the documentation or source code to the library due to odd errors I got.

Deciding to not create a robust framework, and build it on workarounds and hard code, on account of trying to stay in the timeframe.

Not taking a pre-emptive analysis break. See addendum 2.

Not posting quite as many developer logs I was hoping for. 5 is good, 10 would have been better.

Not setting up either a recording method to record videos to show people, or a way to stream my screen.

Addendum 1: The way I organised each level wasn’t really up to par to the huge size each of them had to have. I tried to go with the method I’ve seen used for tile-based platformers. Each level is a single image, with the RGB channels encoding information about each tile. For example, red being 0 means solid, otherwise means pass-through. This works well with tiles because you’re unlikely to have a level be more than, say, 1000 tiles by 1000 tiles. On the other hand, my game had levels that were 20000 pixels by 5000 pixels. Encoding each pixel as a pixel in the image means, yes, a 20k x 5k image. Pygame, for one, can’t load images past a certain limit (20k x 10k I believe?), and it has, second, a large overhead when reaching that limit. And I mean exponentially increasing. That’s the reason my game freezes as you move to a second level. The culprit is a single line of code, so I could have done two things: split the level into multiple images and load and stick together, or rewrite a bit of the pygame library. I wasn’t going to get either of those in the 5 hours I had left, so I left it at this, with a warning.

Addendum 2: This is related to addendum 1. What I should have done, rather than plow ahead only playing the occasional attempt through the game to check for massive errors and obvious bugs, is take a break six hours in, or even every six hours, and just play through what I have intently. Figure out if I like the direction it’s going, check for performance issues, fix everything then and there. I basically piled myself a ton of performance bugs as I kept coding, then had to fix them all at the end. Considering that, for example, if I were to fix the first bug I’d have to rewrite a good deal of the game that would have meant bugs 2, and 3 wouldn’t have popped up. However, now that bugs 2 and 3 have workarounds, fixing the first bug while keeping the same outcome would mean even more work. Basically, early playthrough-and-fix breaks, or often if possible.

Overall, I’m happy with what came out of this. To use the Ludum Dare scoring system, this is what I’d give myself objectively:

Innovation: 2/5 — It’s just your basic sidescroller, after all.

Fun: 1/5 — Not much else to do, other than follow the story.

Theme: 5/5 — The theme really was the focus, even if through the story and the mood.

Graphics: 3/5 — I like to think the graphics weren’t that awful.

Audio: 2/5 — No sound effects, just a single backing track.

Humor: 1/5 — Not much humor in it, after all.

Mood: 4/5 — I like to consider that with the writing and the art style, I managed to set a mood, even if a bit offset by technical issues.

This entry was posted
on Monday, August 27th, 2012 at 9:04 am and is filed under LD #24.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.