So, my first Ludum Dare is over, and it’s time to reflect on my experience. I made a simple collision-based game and named it, in a demonstration of true novelty, “Planets”, for the 48 hour jam. It is a very basic game, but just completing it made me very proud. This also happens to be my first game ever, if I’m not mistaken.
This means that there were a lot of things to learn, not so much code-wise as more general project- and time-management related. While I did learn a thing or two about Java I didn’t know, 48 hours just aren’t enough time to allow for a good study. Though it serves as motivation for more study after the competition.
The most important aspect I learned about was performance. Up until now, performance had never been an issue for the small, simple programs I wrote, mostly because unlike in games, nothing was in real-time. Having the game running is nice, but if it’s running at 5-10 FPS it becomes not only ugly, but also unplayable. Trying to minimize overheads and finding as many optimizations as possible was not only a whole new challenge, but also a joy to code. Gaining a 20% performance boost out of simple changes taught me how wastefully I had coded in the past (and am sure I still do). In the end, it turned out to be a game between me and the compiler, trying to squeeze as much power as possible from the CPU without sacrificing the gameplay.
As for the gameplay itself, it turned out quite well, albeit in a much simpler form than originally envisioned. Originally, it was supposed to be visibility-based, with the player emitting light in order to see the objects for a brief amount of time, but as time didn’t suffice, I had to settle for something less ambitious. It was a good compromise in the end, since a simple but finished game-mechanic is much more enjoyable than a bigger but broken one. The game was fun albeit too short, something reflected in the comments. I couldn’t have asked for more for my first game jam entry.
Now, onto the “what went well/bad” feature:

What went well:

• The timeplan was helpful. It turned out to be very realistic, more so than myself, and as long as I followed it to a certain degree (which was probably only the first day) I had a good, reassured feeling. During the second day, I tried to convince myself that I could pack more stuff into the programme despite the timeplan, and it didn’t work.
• Sleeping after having the game announced was probably the best idea. Normally, I’d spend at least half an hour to come up with an acceptable game idea, but this was time spent in bed, so I didn’t really fall behind. Plus, it helped me sleep better once I had an idea and not worry about the contest until next morning. The time zone surely helped though.
• Incremental development. Limiting the game’s scope is a necessity for these jams, it seems, and incremental development allowed the game to stay at a simpler stage without any additional effort. It’s probably not the best approach with bigger projects, but for short jams it really helps in staying within a reasonable scope.

What went bad:

• Free schedule. 48 hours is barely enough time to create something playable, so it’d be good to get the most out of it (which by the way does not mean to cut back on sleep). Some things, like going to the supermarket in the first morning (1 hour), arranging a Skype call (1 hour), or working on the assignment due two days afterward (4 hours) could’ve been done before the jam (or at least afterwards). Time management isn’t only about the two or three days, but also about the whole time period that affects them.
• Not sticking to the plan. Everything was working out relatively well as long as I was following the timeplan I’d laid out for myself. It was only when I thought I could squeeze two or three more features in during what was supposed to be debugging time, that time really started to run out. I made it eventually, but with more stress than needed, and with less time to polish. Most bugs were luckily dealt with, so the gameplay was more or less stable, but the presentation was just plain bad. The welcome and ending screen were coded between 2 and 3 a.m., and this shows.
• Preparation. The game was coded from scratch. When I say from scratch, I mean every single class and method. While it was interesting to see the program evolve from scratch to game, I’d prefer having the basic set of classes pre-coded next time, at least the canvas and the timer. Things shouldn’t be practiced just for practice’s sake, as soon as they’re learned. Having a small library, along with some general design patterns about rendering, should save me another couple of hours.
• Contest familiarity. This was not only my first Ludum Dare, but also my first game jam in general. As a spectator, I was familiar with some aspects such as the journals, but not with things like the submitting process.  For example, I didn’t know I had to submit a screenshot. It took me 20 minutes to submit the game, up until 3.01 a.m., and were by far the most stressful minutes during the competition. This couldn’t have been averted, really, but I’m positive that I won’t have this problem in my next jam.

The future

So, what are the future plans? I really liked the game idea, especially the parts that weren’t implemented. I think I’ll keep working on it on my spare time (as a welcome change of pace form the competition). It should keep me occupied at least until the next Ludum Dare. I loved the contest and am looking forward to joining again.

Thanks to everybody who participated!