(This is the second in a two article series.)
Music and Audio
Once the final direction of the game was decided, music took up the single biggest share of effort. If you have listened to the game, this should be a warning light; the music (such as it is) is minimal and definitely doesn’t point to more than 15 minutes of work being put into it. In the end, there are for two reasons so much time went into the music- one good, and one bad. The good (or at least neutral) reason is that I had two hours of car ride to sit through and I was able to poke at the iPad incarnation of GarageBand (which is awesome, and would be more awesome if I could string three notes together) during what would otherwise be downtime.
None of that music actually made it into the game (so it wasn't the most efficient use of time) but the road trip was going to be dead time as far as the Ludum Dare went anyway. It’s tempting to call it just breaking even on that account, but it was a good use of time in principal because there’s the chance that I might have come up with a 30 second loop that didn’t make me want to gouge out my eyes with my ears.
After poking at GarageBand and some of the various pieces of electronic music hardware I have compulsively collected despite my total lack of musicality, I eventually put together a simple loop in ReNoise (which is a solid dice of software, though well beyond my ability to actually use) and slotted that in.
Music is a very alluring area because there are so many cheap or free pieces of great software out there that don't require you to build up four years of muscle memory before attempting to bang out Pachelbel's Canon. All you need to do is hit buttons, and programmers are great at hitting buttons. Plus you can just hit different buttons until it sounds good, right? But it turns out that if you want to avoid an "infinite number of monkeys" scenario you either need enough practice in a genre that you can intuitively tell what will and what won't sound good, or a lot of background in music theory, composition, and probably that four years of piano from before.
So I urge you: ignore the siren call of writing your own music, especially if you're in a time-limited situation like a 48 hour challenge. It is not like the other art assets; you can't fake it. Even if you are prototyping a full game– add enough music to get by (or better: use existing music that fits the feel you want and the sub in actual music later). The only exception I can think of is music-based games like DDR or Guitar Hero; those obviously need a big focus on music assets from the start (but even there you would probably be better off using stock music until you were well into the project).
Sound effects were a lot simpler. Ludum Dare offers a free utility called SFXR (CFXR on the Mac) procedurally generates dozens or hundreds of sound effects from basic sound structures like sine or square waves, and you can just browse through and pick the ones you like. That's we're all the incidental sounds came from (with some tweaking in the excellently free Audacity).
Obviously the graphics are where Escape from Planet 21 shines. The game took 6th overall for graphics, even though they were, for the most part, stuff like this:
I think the big takeaway on the graphics side –and this is maybe the biggest single lesson in the game– is that you do not need high quality graphics. You need consistent graphics. Consistent graphics tell a story. High quality graphics can tell a story better but they aren’t necessarily going to help you tell a better story. I’m going to follow-up on this with another post later about jungles, but the quick-and-dirty moral is that consistency across the board trumps unevenly applied quality. You know when you’re watching a mediocre movie and there’s a completely out-of-place 15 seconds of CGI and you think to yourself “Well, there goes the effects budget...”? That’s a symptom of quality being unevenly applied.
All of the graphics were done in the magnificent Blender. The textures on all the rocks are basically some Photoshop noise with blue and some lines drawn on top. The matte painting is left as an exercise for the reader (hint: draw a white circle, add some noise, apply the smudge tool, clean up the mask). This was actually the first big project I did with Blender (System Protocol One was done in Modo with some finishing work in Cheetah 3D since Modo doesn’t have character animation) and it worked very well here. The low detail requirements of the art genre meant that building landscape was as simple as eight or nine extruded cube faces. Ground was equally trivial to make.
The player’s ship, the UFO and the rendezvous goal were the more complicated models, but a quick glance at them will illustrate their simplicity– these are largely basic shapes with radial symmetry and simple extrusions:
There are four major unifying forces on the graphics side that tie the visual theme together:
- Low-poly graphics with “cardboard sensibilities” (whatever that means)
- The matte painting
- The wires holding all moving objects in place
- The gray/noise filter
Everything here drives graphical consistency. The models are all built using the same basic 3D approach, all have approximately the same level of detail, and all are intentionally rough around the edges. The matte painting is omnipresent in the game (even the lobby) and acts as an anchor for the action. The fact that the spotlight tracking the spaceship also illuminates the “space” behind the ship adds a layer of verisimilitude to the aesthetic. The same goes for the wires (which were actually very complicated to implement) and the gray/noise filter. Noise filters are easy to implement (many engines support them out-of-the-box).
Of these, I would say that the wire are ultimately the least important (and in fact, they are what will be taken out for the follow-up game). The problem with wires is that ideally, objects would have been held up with string… but since the player is actively flying upwards, as you passed objects suspended by strings the screen would eventually be totally filled with string, since they couldn’t just disappear. The workaround for this was to suspend them with what looked like an unbent coat hanger. This works but poses its own set of problems– if you know where to look, you can see the ends of hangers poking out from the scenery.
I think the better solution will have been to fake fishing line- a string that faded in and out of visibility as it “caught” the light and ultimately faded to nothing. This would have solved both problems.
Gameplay and Theme
The gameplay for Escape from Planet 21 is very challenging. The player needs to get very familiar with the nuances of the control scheme (6 buttons controlling 5 thrusters, each pointing in a different direction) if they don’t want to die immediately. It’s also challenging because players tend to want to go quite fast- fast enough that they don’t have time to break for obstacles. I tried to temper this with more of an Apollo-Lander feel for the ship but charging headlong into asteroids they can’t see seems to be a common use-case for the game.
The feedback loop of thruster destruction is also a sticky point. It works if you consider the game to be a “see how high you can get” point harvest, but I’ve come to decide that if the player is trying to reach a milestone or story goal, it will be frustrating. The nutshell analysis is that losing a thruster makes it much more likely that you will lose additional thrusters. While the game is actually beatable with any three thrusters (and some combinations of two) the extra fuel needed to overcome this handicap means you will run out of fuel long before you crawl your way home. I am pleased with the ship’s handling overall, but I should have added more cues to indicate that this was meant to be more of a graceful, RoboRally-esque ballet of movement than a strict Race to the Finish.
In the iPad release of this game, this is being tempered in two ways. First, thrusters are each getting 2 dings before they explode. Secondly, after the first hit, I’ve applied impulse force away from the collision- one of the problems with the competition game is that after hitting a thruster your ship would often keep plowing into the same obstacle, losing one or more additional thrusters. Some bounce-back from the initial crash will help prevent this.
I’m not sure how well the Escape theme necessarily fits the game. Certainly the word is in the title and the aesthetic theme allowed me to easily work the premise into the story, but in the next dare I am going to seek out a tighter integration of the theme into the core mechanics. On the one hand, part of my dissatisfaction on this count probably stems from the fact that the rocket genre stemmed from my idea of “escaping a gravity well” (which several other games in the competition implemented directly) and resulted in a rocket game with very, very little actual gravitational influence. On the other hand this is a 48 hour competition (and my first at that) and part of the point is to see what interpretations of the theme you can make. Still, I wonder if it would have been possible to add an additional threat coming from behind- a slow burst of radiation, pursuing UFOs, anything- to lend a more credible threat to the deadly planet 21.
I will be releasing the competition game for the iPad (with minor tweaks and a new touch interface). I am not convinced it will run on an iPad 1- that device just isn’t designed to handle 3D games that aren’t built around its capabilities so it’s not a great port target, but we’ll see. It definitely runs without problems on the iPad 2, and I’m anticipating a free release and possibly an “endless” mode. In the long term, we are looking at a more in-depth, story-driven game with multiple spaceships to choose from (each with its own control scheme) with better production all around and things like actual music that I didn’t write (you can thank me later).
So that’s the end. Definitely feel free to ask any questions about the process. If you’re a Unity developer, the source files for the game are available here. You need Unity Pro to access some of the non-critical stuff (like the noise image effect) but everything else should work out-of-the-box. Obviously we won’t be supporting the code per se but if you have any questions we’ll try to help.