Well, that was fun.

I’ve never made a game like this before, or, I’d never really finished one, so getting the chance to do it was great. I felt very motivated this time around. However, I must admit that the game’s not in the ideally finished state for me. Where the game only has 3 levels, I was hoping for 5, and I never got to include anything like keys and locks, or even a possible time limit on the levels. (Which would have made the stun from falling relevant.) So, because of this, I have to do some introspection.

What went wrong?

Time: 3 hours is not as long as you think. When I found myself thinking I had 9 hours left and I’d be fine, I got a little nagging feeling that it would pass by very quickly without me getting anything done. My intuition was correct, and I was only able to just finish. Act like all time is crunch time, and don’t spend so much time in the IRC .

Level design: Oh goodness. I decided to design the levels using the Tiled software, and I was very satisfied, but when I exported a file, I realized that I wasn’t sure about parsing the files. So, what I did was export to JSON, and just cut out anything I didn’t need, leaving the comma-separated-values that were easy to parse. Later, I wanted to add objects aside from the player that move independent of the tile grid, so I had to make up a format for that, and append it to the level file. So, every time I was making a change to a level, I had to export it, open up the file, strip the junk, and add the object data. This isn’t efficient, and level design depends on rapid iteration. Next time find a library or something that can parse it.

Poor code design: Global state everywhere, duplicated code, and like one comment that says “//Player Status. OOPify later” followed by a list of  previously mentioned holders of global state. The result of all this? Extremely unreadably, buggy code. Consider actually OOPifying from the start.

What went right?

Time: As much as I felt like I wasted some of my time, when it was approaching the deadline, I was on fire. I figured I had a problem and like magic the solution was already being added to the code. I don’t think I’ve ever felt the feeling of just making so much progress like that. I felt like I finally knew what to cut out and what to keep in.

Motivation: Whenever I felt like a problem actually was getting to me, I decided to get up, and go for a walk. I’m not sure if this ended up saving time, but I felt like pulling my hair out less.

Not reinventing the wheel: I knew I’d have trouble reimplementing a tilemap class, so I took the one I put up on GitHub some months before. That was a huge timesaver.

Previous artistic experience: When I was younger, I never could make games, but I always was fascinated with the look of games. As a result, I spent a lot of time in Paint.NET, just making textures that’d never be used. That was really handy.

Knowing your tools: I’ve been using SFML for a while now, and I understand the ins and outs, and leading up to the competition, I made sure I knew how to use Tiled. (Just not its formats. :P)

Poor code design: In the end, I realize that there’s actually no time for sensible design in the game’s code. Though the code I produced isn’t that maintainable as a whole, it still works, and that’s what matters. This jam has taught me what it means to make a game and not something like an engine.

Conclusion

I had a lot of fun for my first Ludum Dare. Though it was stressful, it was also very exciting, and knowing now my weaknesses and strengths, I feel like I’m more prepared for next time. It was a good time.