In case you haven’t played yet: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=7658
So, my second Ludum Dare is in the bag and in my opinion, I think it went A LOT better than last time. The game is significantly more polished and I’m very pleased with the end-product and reception to said product so far. So now its time to share my thoughts:
What Went Right:
Game Concept and Theme: I really didn’t want to go the obvious way with Ludum Dare 28’s theme. “You Only Get One” was a good theme but there were some pretty common avenues I could take with that. Though not necessarily bad ideas, I wanted to be unique in my game design. But how? Mainly, the theme struck me as one that could key in on consequence. Having “only one” wasn’t supposed to be merely an inconvenience; I wanted it to mean something gameplay wise. One of the ideas I thought about was a system where you might have multiple robots, where one was randomly assigned to you at the beginning of the game and, should it die, you might not see it (and its special abilities) again for many playthroughs because of the random select. Unfortunately, this would have taken a lot of time to put together, both mechanics-wise and art-wise, and I knew pretty quickly it wasn’t a very viable option for me or the artist. But I liked the idea of having multiple robots with different abilities, and from it stemmed the driving idea behind “Batteries Not Included”: you would have multiple robots, but you could only use one at a time because you only had one battery. Though swapping characters isn’t particularly new, that idea combined with the shared battery gauge I felt gave me a solid interpretation of the theme and a good basis for gameplay.
Coding and Workflow: Teaming up with Max Glockling Games from Stencyl meant that I could focus on my strong point: programming and logic. Sure, I used placeholder graphics a lot at first, but up to that point I’d sort of underestimated them. Problem is, in the past I’ve been reluctant to use them; knowing my artistic abilities on pixel art and what have you, I was leery of assigning a certain “level of detail” to my art prematurely per size. However, this time I could shoot some dimensions at the artist and he would come through. And I must say, looking back it’s a little eye-opening to see just how efficient I was as a result. On Saturday, with art not so much a concern for myself, I was in the zone with my coding. Code, code, NOT art, and more code. Thanks Max! I did eventually take a “break” and whip up a quick musical tune, but mostly it was me coding away and designing levels. I think its definitely shown me in part how I work best when it comes to games, and its certainly something I need to take into consideration for future projects, particularly those where I’m doing everything myself.
Strong Gameplay Mechanics and Overall Level Design: Though I can’t say I necessarily got to fine-tuning everything to perfection, I feel the game is moderately balanced and diversified in terms of gameplay. Each robot has its ability, specific shape, and battery consumption. The combination of all of these gives some good flexibility, even if I lacked the time to utilize every aspect to its fullest. In short, I had a good set of advantage(s) and disadvantage(s) for each robot. Although I might argue the Floater/UFO guy was harder to balance than the other two, there were certain nuances particularly about his tractor beam that I could exploit to prevent him from making the game too easy (and he’s the biggest battery hog for good reason too).
What Went OK:
Audio: No sound effects, but I did get music in there. It would appear though that the music got to be very repetitive and annoying after awhile to some… at least per the responses on the livestream playthrough I was watching. I actually laughed (I wasn’t the only one). When and if I release a post-compo version, I may have to change things up and look into getting some sound effects too. Ultimately though, I think I made it somewhat satisfactory.
Collision Coding and its Quirks: This. This arguably is what consumed the half or so of my coding time. I dealt with this A LOT. I tried to make certain objects pushable under different circumstances. I tried to make it so the UFO guy couldn’t pick up objects from the side with his beam. I tried to make it so the dozer guy could move past certain objects at times and push them when he needed to. And it wasn’t necessarily unusual for me to get past one problem and have it introduce another. Trying to program all these nuances, in essence, around Stencyl/Box2D’s way of handling collisions was definitely a task! But, in the end, I got it to work. Having that clear dedication to coding definitely helped.
What Went Wrong:
Number of “Planned” Levels: I didn’t get to the amount of levels I wanted; I had been shooting for at least 15, and I only got to 12. On top of that, the first 8 were pretty straightforward because they were sort of introductions to different mechanics. That being said, the last four levels picked things up nicely… sort of. That brings me to my next point…
Somewhat Unbalanced Difficulty: Fortunately in the gaming world these days, people seem a little more forgiving of the super-hard difficulty. The people I watched play my devious Level 11 spent probably 20 minutes trying to figure it out (I went on to claim I probably should have made that one the last level instead of what was Level 12). That being said, they found beating the levels quite rewarding when it was all said and done. Nonetheless, with more time I could have potentially balanced the difficulty a bit better. I kind of cringed a bit as I saw them trying to get past even the first parts of the level, but they hung in there and still seemed to have fun while doing it (although on one occasion they cried my name out in “anger”).
Collision Problems: Hey hey… guess what? Still had some issues here. One issue was more of a collision box tweak that I thought I had fixed, while the other issue behaved like I would have expected it to but caused undue difficulties in certain situations. The latter happened on Level 11 many times in their attempt, and it was a bit hard to watch, especially since the game has that perpetual, looming battery drain going on that can cause total level restarts.
* * * * * * *
All things considered, I think Max and I managed to make a pretty great product. I’m quite encouraged by the feedback I’ve gotten thus far, and we’ll have to see how the ratings turn out. However, getting to see someone play it over livestream was big, and I’m glad I got to see that. This time, if all goes well, I would like to release a post-compo version to Kongregate. I have some ideas I didn’t get to implement, would like to add some more levels, and perhaps iron out a better difficulty curve; I think there is some solid potential still left to tap. If you’d like to see a post-compo version, say so! After all, I’m making the game so people like you can play it, right? 🙂
Thanks for reading.
Photon Game Development 
Leave a Reply