Ludum Dare 35 happened a weekend ago, and although I published a postmortem on my LD48 blog, I haven’t posted here about it.
The theme for this one was Shapeshift. The first idea I had was to do a game that played like the arcade classic Asteroids, but where your ship’s shape would shift according to its state. I did a quick proof of concept Friday night, where the ship stretched under acceleration, and while it was a pretty cool effect, it wasn’t really something that made the game better or more interesting than the original. By late Friday I was convinced I was on the wrong track, and should start over with something else, but wasn’t sure what.
Saturday morning, I woke up and briefly considered just giving up my efforts for the weekend, and working on other stuff with my weekend time. In the afternoon I attended a Cleveland Game Developers “Excuse to Create” event, and started over with a new project. In the morning, I’d thought about another arcade classic, Robotron 2084, and I started getting interested in making a twin-stick arena shooter. In part I was spurred by the discovery that the keyboard for my new Lenovo ThinkPad P50 laptop has poor rollover characteristics, which make playing games on it all but impossible. I started building it at Excuse to Create and by the end of the 3 hour session I knew that I was on the right track. What I ended up with was much closer to a Geometry Wars clone than I had originally wanted, but it plays pretty well and I had fun making it.
I would have preferred to come up with a more original concept than that, but oh well. It’s not an attempt at a straight up clone of Geometry Wars, but more of a knock-off. The shape-shift theme comes into play with the target shapes, which “lose a side” when shot and shift into the (N-1)th sided polygon. This gives the larger shapes a kind of “hit points” which makes them take several hits to completely destroy. I thought that would be a novel enough twist, but in practice it plays feels about the same as the original Geometry Wars.
Along the way I learned a few things, all of which are game design rather than programming lessons.
- At one point in my development, I had the power-up items be vulnerable to the player’s shots, and also if the player shot a power-up item, they would lose one level of that power-up. This would have made the game a lot different from Geometry Wars, where it’s safe to shoot indiscriminately because your shot has no bad effects in that game. I had hoped that this change would make my game more about aiming and looking where you are shooting, and being careful. But in testing, it just made the game too difficult. As the difficulty of the game ramps up, it becomes a frenetic twitch game where you mostly dodge and run away from a swarm of shapes that are following you, and there’s not really any opportunity to be selective about when you’re shooting or where you’re aiming, and if you do lose a level of power-up, it’s pretty much instantly lethal.
- Spawn location matters. I knew that I needed to spawn enemies far enough away from the player that they would not be prone to crashing into a newly spawned instance that appeared directly in their path, leading to unfair death. But I also learned that spawning near the edge of the view makes the game seem more active, and puts more instances in view especially in the opening seconds of the game, when there are few objects and the pace of the game is slow. The compo release has enemies spawning randomly anywhere in the room, and as a result feels much more sparse and too slow during the opening.
- Code mistakes can be fun! My original code for spawning a swarm of enemies accidentally placed them all in the exact same location. Since the movement of the enemies is purely deterministic, this resulted in a “stack” of enemies all piled up on top of each other, looking like a single instance. When shot, instead of destroying the entire stack, the bullet would only destroy the first instance in the stack, and the rest of the stack would continue to advance, looking to the player as though a early-invincible “super shape” that took a great many shots to destroy was inexorably running the player down, and the player’s shots merely chipped off lesser shapes, which then joined in the attack. I liked the effect so much that after fixing the swarm spawn code in the compo release, re-added a toned-down version of this to the post-compo branch.
In looking back over my Ludum Dare games, I’ve come to realize that I’ve felt overly negative about my performance in LD48. I do have high standards for what I think makes a good game, and so naturally I feel disappointed if my efforts fall short of that mark. In my first few events, I was happy just to have proven to myself that I could build something playable in under 48 hours. In later events, I became disappointed that my abilities didn’t improve as fast as I wished they would. And, really, unless I take game development as a full-time occupation, it’d be hard to improve as fast as I would like. But perhaps an even greater sense of frustration has come from my inability to come up with a good idea for a game — or rather, a good idea that I could complete with my abilities in 48 hours that fit the announced theme. Particularly after the submission deadline, when I’d see so many good games produced by others. But if I focus on the 8 games that I did complete, rather than the 6 LD48 events I didn’t submit for, I’m able to view my work more positively. In the immediate aftermath of the event, I would always feel a certain amount of frustration and disappointment in some aspect of the game I’d made — some feature I struggled too much with implementing, some stupid bug that I got stuck on that took too much time to fix, some feature I had to drop for lack of time, something that was missing, but I couldn’t figure out what it was that the game needed, or something that just wasn’t quite right. But looking at what I have produced, there are some good ideas in six of the projects, and I’m happy about that.