RIP. Well, that was fun. And horrible. But still fun.
- 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.
- 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.