RSS

Monthly Archives: October 2016

Ludum Dare 36 – Post-Mortem


In August I took part in the Ludum Dare 36 game jam with a couple of friends of mine.  Having taken part in Ludum Dare 35 in April I was aware of a lot of the common mistakes and how to avoid them and was pretty confident going into it.  So naturally I went overboard with design and we came up with an idea that would’ve taken months to make, rather than 3 days.

What went right

The sound and music.  It was very much a spur of the moment effort from one of ours friends who burst out with nearly everything in a couple of hours on the first day, and judging from the feedback we got they really stole the show.  While there were a few technical issues in terms of getting the audio to play right, and fine tuning the volume levels, it worked out pretty well. Hopefully we can convince him to do the same thing for the next game.

The graphics ended up looking pretty good too.  We had a few pieces of character art we never ended up using, but we expected that would be the case.  There were some issues with quality reduction due to compression that we weren’t expecting, but now that we know how it happens we won’t be making that mistake again.  We did have an issue with the texture stretching on the scenery, which was due to scaling everything rather than tiling it.  Looking at it now it seems we needed to modify the material to make this work. Another lesson learnt there.

What went wrong

I think the first place we went wrong was having a design that involved many different enemy and weapon types.  Our original plan involved 5 different enemies, and 10 different weapons, and while we knew we were not going to make all of them, we didn’t take on the more realistic idea of only making one or two until late into the second day.  This led to us spending time developing mechanics for areas we wouldn’t have time to work on, which could have been better spent on refining the ones we would end up using.  As you can see from the end result, we ended up having one make weapon in the game, an old brick phone, in the style of a Nokia 3310.  When we originally designed this I had the idea that you would use it to bounce off walls to do trick shots where you hit an otherwise un-hittable enemy.  To help prevent spamming this attack, I had a 2 second delay between attacks but let you fire again immediately if you hit someone.  For some reason, I never took out this delay, so it made the combat extremely frustrating if you missed even once.

The second area was the level design.  We spent so long trying to get the mechanics working, that we never spent any time focused on the levels themselves, other than some initial sketches which were fine by themselves, but built around you having a number of weapons which just didn’t end up in the final game. The final result is at least playable, but it breaks many cardinal rules of level design, such as not showing the player whether a fall would be safe or deadly.  Most of these could have been resolved if we’d put the game in front of other people early on, which ended up being difficult as it wasn’t in a playable state until the last day.  It all comes back to mechanics again, and trying to get something that works and plays reasonably well on day 1.


All in all, this jam ended up being a mixed experience.  Thanks to working in a team we made a game that looked a lot more impressive than my last one, but I’m not overly happy with how it felt playing it.  Next time I’m going to try to make the core mechanics simpler, and focus more on level design.  Bugs in the game are bad, but if a bug-free game still isn’t fun to play then I’ve really missed the mark.

 
Leave a comment

Posted by on October 19, 2016 in Uncategorized