About qrunchmonkey (twitter: @qrunchmonkey)
Ludum Dare 24
Ludum Dare 22
Ludum Dare 21
Ludum Dare 20
Archive for the ‘LD #20 – It’s Dangerous to go Alone! Take This!’ Category
This was my 2nd Ludum Dare (you can play my LD #20 game here) I was a bit un-prepared this time, since I only found out that I would have the weekend free about 45 minutes before Ludum Dare started. Talk about timing!
Once again I chose to use the Flixel engine. It’s a powerful and simple little engine, and developing in Flash means just about everyone will be capable of playing my game with no trouble. For my IDE, I used Flash Develop running in Windows 7, running in a Parallels VM on my Mac. I don’t recall exactly why, but that’s what I did last time so I stuck with it. Once again, sounds were recorded on my iPhone and edited in Audacity (cfxr doesn’t work on OS X Lion. I might need to fork it and fix that…) Also, I recorded a time-lapse of the whole thing using ScreenNinja, a Mac app I developed for exactly this purpose. One minor hiccup: I didn’t have Photoshop installed on the machine I was using, so I grabbed Pixelmator from the App Store. It’s a nice little photoshop replacement app suitable for most tasks, but unfortunately making pixel sprites isn’t one of those things, and I think that may have cost me some time.
The main frustration I had with my previous Ludum Dare game was that it was very short, so this time I knew I wanted to have some sort of endless map (plus, I think it fits with the theme) – so that’s where I started. Progressive level generation is tricky to get right, and looping though a single map just isn’t the same thing. What I ended up doing was designing a number of levels (at first 3, in the final entry I believe there are 11), each only slightly larger than a single screen, and as you approach the edge of one level, the game randomly picks another level and inserts it on the screen. Because the ‘levels’ are tile maps, and each is loaded from a .png file, I was able to design levels in Pixelmator and easily see how each level would look next to all the others, and make sure the edges lined up right.
Once I got that working I quickly threw together some basic player and enemy logic (it’s fun seeing the henchmen jump off cliffs, lemmings style), then it was just a matter of throwing things together and seeing what was fun. In action movies, the gun is a versatile tool. Along with killing the bad guy, guns can also be used to open doors, disable equipment, activate buttons or traps at a distance, or anything else an escaping hero might need to do. So I thought a game based around a sort of chase sequence might be fun. One of the things I programmed and didn’t end up using was for the wall mounted turrets to fire missiles that would destroy the ground under you. It looked really cool, but unfortunately the player could get stuck in the craters, so I had to take it out (although it’s still in the source code if you’d like to see how I did it)
Bugs. Hopefully there are no major bugs in my game, but there’s always a few weird ones. Occasionally the henchmen just won’t jump off the edge of a cliff, and I can’t figure out why. I’m pretty sure 30 lines of AI code isn’t enough to gain sentience, right? Also, sometimes the door spawner will spawn a henchman 32 pixels lower than it’s suposed to (and he ends up stuck in the ground below) But, since neither of these were game breaking bugs, I said screw it and worked on new features instead.
And finally, I tried to add a little humor and competition to the game in the final few hours with the game over screen. Much like in Super Shotgun Deathrace, the final text is assembled from many different pieces so it’s different each time. After showing a near final prototype to a few friends online as well as the IRC, it was suggested that I should have some stats besides distance displayed at the end of the game. So, I added the damage values and a henchmen killed counter. Took all of about 10 minutes to do, and I think it significantly improves the game, so thanks everyone who suggested that.
This was my first Ludum Dare – I went into it feeling completely unprepared, and finished the compo with a game I’m pretty happy with. I’m going to attempt to describe how that happened.
What Went Right
- The Toolchain. I made a rather risky move going into this LD. I decided to use a game engine I’d never tried (Flixel) in a language I haven’t used in years (ActionScript 3) in an IDE that doesn’t run on my OS (FlashDevelop) Crazy, right? Actually, I don’t think it could have gone better. Flixel’s handling of basic motion and collisions is far more intuitive than any physics engine I’ve tried, and the engine as a whole seems perfectly tailored to quickly prototyping games. Due to some of the awesome features in Flixel, I ended up using Photoshop as my map editor, which worked quite well, and is something I’ll be thinking about doing more of in the future.
- The code. The one piece of advice I got before Ludum Dare was to not get caught up in the code. That’s a problem I’ve had in the past (I’ve got a number of game prototypes that are more engine than game, nearly all of the utilities I’ve released have about 3x the functionality that can be shown in their UIs) but with the looming 48 hour deadline, I was able to ignore best practices and just get sh*t done. There’s dead code, unused variables, methods copied from class to class, and not a comment in the entire program. But it works, and ultimately that’s all that matters.
- Music & Sounds. The audio ended up being much less of a hassle than I’d initially thought it would be. For the music, I used Garage Band on iPad which has a feature called “Smart Instruments” – I gave it a couple chords, and it gave me back a groovy baseline. I spent about as much time making the music as I did trying to get the .mp3 to loop properly. For most of the sound effects I just decided to record them myself. I grabbed my iPhone, went in to the quietest room of the house and made zombie noises for a few minutes. It was fun, actually.
What Went Wrong
- The Theme. At least initially, I had no idea what to do with this theme. I didn’t want to wind up with the same idea as everyone else, so the obvious ideas of a zeldaish game or something where you only win if you’re holding the MacGuffin were out. I spent probably 4 hours tearing my hair out and contemplating leaving the competition before scrawling down “you start in a portal like chamber where you don’t get the macguffin, then you fight zombies or something”
- The Graphics. Unlike the code, where I only did what I needed, as I needed it, when it came to the graphics – I didn’t really have a plan. I started the graphics before starting the code, which was a mistake – but the bigger mistake was starting the graphics before I’d nailed down what the game was going to be. I wasted a lot of time on graphics I didn’t end up needing, or which just didn’t look right (all the walk cycles) I’m relatively happy with where the graphics ended up, but it took too long to get there.
- Planning. I didn’t really know what my game was going to be until after I was 3/4 of the way finished, so I didn’t even have a todo list until the last 12 hours. I’m pretty good at flying by the seat of my pants, but I think a little pre-planning would have helped. You know, trying to set a couple milestones, researching the engine I was using a little more, that kind of thing.
And if you read all that, here’s your reward! I’ve uploaded a Timelapse of the development of Super Shotgun Deathrace which you probably shouldn’t watch until after you’ve played the game
This is my first Ludum Dare (and my first game jam of any sort) I’ve been wanting to do this for a while, but I never had the time. I’ve been doing iPhone development for the past few years, so jumping back into Flash should be…interesting.
Here’s what I’ll be using:
Libraries: Flixel, possibly Box2D
Sound Effects: One of the various ports of sfxr, Audacity, GarageBand
Graphics: Photoshop, ImageMagik
Other Tools: Tiled or DAME for maps, TextMate, git, Parallels (just in case I need to use some Windows apps)
I’ll also be using an app I wrote called ScreenNinja to produce a time-lapse video of the process when I’m done.