Voting is done, and the results are in.
Roomba’s Revenge placed 167th out of 2390 entries. Pretty good!
The group decided on a tried and true template: destroy everything you can see. Unity’s physics engine makes implementing destruction a breeze, so I focused more on the overall experience rather than gameplay mechanics.
While the game came out feeling finished, I really wish we had chosen a more innovative game. That’s where I think Ludum Dare shines; creating games that wouldn’t otherwise come into existence. My enthusiasm and thus motivation to program was lacking, especially at the beginning. I didn’t lose any sleep over the weekend. At least this LD proved that our group can make a functional, fun game that people enjoy playing.
I read up on project management beforehand and got to use a lot of what I read throughout the weekend. My favorite parts were the one-on-one discussions I had with everyone. I would talk about what they made, how to implement that into the game, and what features they should work on in the meantime. This was an improvement over the previous LD where I made everyone write up any suggestions to a shared word document, which was rarely used. This also allowed everyone bring up any qualms they had about the game in a controlled environment. Rather than yelling into chat and talking over one another, it gave everyone a chance to be heard.
A big part of the project management tips involved listening, which I may have overdone. People would ask for suggestions about what to create, and I refused to help them along. I did this for two reasons: I wanted everyone to have ownership over their contributions to the game, and I wanted to see what people made given no direction, which I thought would help creativity. The results are as follows:
Audio: Players really liked the audio, and I would often firing up the game just to listen to the music. But the musician had a tough time getting the sound right, and was disappointed in the final outcome. A lot of recorded music was discarded, and the end result was nothing as he imagined.
Graphics: The only suggestions made for the 3d models were what types of objects we wanted in the game. The modelers tried their best to come up with them all, but probably half of the models that were created weren’t production ready and had to be cut from the game. If I had discussed with them what was important to make and how to create models that fit into the game better, I bet we could’ve included a lot more destructible objects into the game.
Menus: I told the designer we probably would need a main menu, a pause menu, and an end game menu. She went to work, but because I asked for so little, she spent a long time making just the main menu. While the outcome was beyond great, I could’ve been more clear in what I expected from the UI. My biggest letdown is the in-game interface: text for the timer and battery life, instead of something more visual, like a clock, or battery icon.
Here’s the breakdown of the scores, with past Ludum Dares for comparison. While I personally thought innovation was lacking, we placed in the top 10% in that category. Note: voting was disabled for LD 36 (thank goodness), and I did LD 34 on my own.
All-in-all it was a good time, and the game (and results) speaks for itself. I really enjoyed being more of a project manager this time around, but it came at the expense of sub-par gameplay. Couldn’t have been happier with my teammates though. Just wish we could’ve broken into top 100 overall.
As always, looking forward to the next one!