Ludum Dare 22 write-up

If you haven't heard, Ludum Dare 22 just ended, and you can try all the games here. Ludum Dare is an "accelerated game development" event, in which participants try to make an entire game over the course of a weekend. This seemed like a fun way to work on a new game without taking much time away from Overgrowth, so Aubrey and I decided to participate. We didn't manage to create the game in time, but it was still a great experience! For posterity, here is an overview of the process we went through and the lessons we learned.

Brainstorming on the theme

As soon as the theme was announced (it was "alone"), we started brainstorming game ideas. Maybe you are in a damaged space capsule, like Major Tom -- that is a pretty lonely scenario. Or maybe you were mistaken for dead and buried alive, and when you finally dig yourself out, all of your friends and family run away from you in horror. We finally decided that you would be a rock star who is hounded by rabid fans and paparazzi, and wants to get away from them all.

Aubrey picked this painterly, monochrome art style for several reasons -- it fit the theme very well, he could paint that way very quickly, and he also just liked the style and wanted to try it in a game.

Designing the game

When I play through Ludum Dare entries myself, I often only try the ones that I can play within the browser -- it's easier, doesn't clutter up my hard drive, and I can be pretty sure it won't infect my computer with anything. For that reason, we decided to try to make the game using some kind of in-browser 3D technology. Since this would be a significant technical hurdle for me, we wanted to choose a design that relied more on Aubrey's artistic contributions than on complicated game mechanics.

The point-and-click adventure genre best fit this requirement, particularly the musical spell mechanic from Loom: a 1990 adventure game in which the player interacted with the world using brief songs played on a magical staff. This led to the idea that the player could play musical riffs on her guitar in order to solve puzzles, and then to the idea that you could even change the emotional state of inanimate objects.

We planned out the basic course of the game -- you start out backstage after your show, and then make your way outside into an alley, then down a manhole into the sewers, out into a harbor, and then you escape into solitude on a small boat.

To illustrate how much the rock star wanted to be alone, she saw other people as mutated parodies of themselves. For example, the photographers had giant, staring eyes, and the fans had big yelling mouths and grabbing hands.

The player would have four songs that she could play to instill different emotions: "Happy" "Sad" "Afraid" and "Attracted", and the puzzles would revolve around finding the interactive elements in the background and playing the right song. It wouldn't be particularly difficult, but would be more about having fun playing the songs and seeing surprising results in the environment. The whole design was figured out in the first couple hours, so we thought we were off to a solid start!

Technical execution

At first I tried to use HTML5 and WebGL, since they are open standards and I had tried some impressive demos (like ro.me and X-wing). However, I soon ran into difficulties -- there are a lot of small variations of functionality between platforms and between browsers, which required a lot of testing, tweaking, and browser-specific branching. After spending a few hours working on this, I decided that it was obvious that I wouldn't be able to make a complete game this way within the time limit, even using a library like 'three.js'.

Next, I decided to look into Flash, since it has a long history of games, and had a lot of open-source projects and tutorials to use as a starting point. I found that you don't need to actually own Adobe Flash in order to program a Flash app, you can just use the open-source Flex library and the command-line, or a free IDE like FlashDevelop. Once I set up those tools, it wasn't hard to get a simple Stage3D wrapper set up (mostly by combining sample code from developers who actually know what they're doing).

I continued along this path, combining bits and pieces from existing Flash engines like Flixel, Flashpunk and Away3D, along with some novel code, until I had most of the basic components working. Here I loaded up Turner from Overgrowth into the engine to test out '.obj' model loading and mouse input.

I then started to run into some discouraging problems -- for example, Flash mouse input on Mac Chrome didn't seem to work properly, precisely the kind of incompatibility issue I had switched languages to avoid. Also, I kept having to spend time looking things up every few minutes, because I wasn't used to the Flash API patterns. For example, to load a model, I couldn't just call model.Load("Data/Models/Turner.obj") and be done with it, like I can in Overgrowth. Instead, I had to get an AssetLoaderToken from the LoadData function, and then attach an ASSET_COMPLETE EventListener to the token with a pointer to a OnAssetLoaded function, and then wait for the function to be called asynchronously.

In a full project, I probably would have tried to power through the API and spend the time to wrap it until it was easy to use, but this was obviously not going to happen within the deadline. Four hours before the deadline, I gave up on this approach, and decided to try Unity as a last effort to at least get a basic prototype working. Compared to my previous efforts, this went surprisingly smoothly, and pretty soon I had a simple point-and-click framework working:

I then added Aubrey's assets, but first let's look at how his process went!

Artistic execution

After creating all of the concept paintings above, Aubrey started working on the 3D model for the protagonist, the overwhelmed rock star. He went all-out on this character, even detailing the fingers, guitar strings and tuning pegs. He then rigged the model (attaching the polygonal skin to an animatable skeleton), and animated a walk cycle.

Because the rock star was so detailed, she took a whole day to set up, so there wasn't much time left to create the rooms! However, in the last couple hours he managed to finish the first room using a hybrid of 3D geometry and alpha-masked 2D planes, taking advantage of the relatively constrained camera of the point-and-click adventure genre.

Putting it all together

Now we had some basic engine functionality, an animated character model, and a room, and wanted to see what it all looked like together. But we still didn't have the guitar mechanic prototyped at all. Fortunately, fellow indie developer Max Crane generously volunteered to record some guitar riffs played by his friend Drew Southern, guitarist from local band BLACK, WHITE, RED and BROWN. I asked them to record several sustained notes, followed by a riff based on each note. Here is a brief excerpt of two of these notes.

I cut up the sound file using Audacity, and then hooked it up in Unity so that guitar notes would play when you press any of the ASDFG keys, and a riff would play if you press them all in order, or in reverse order (GFDSA), to prototype the song system. Here is the final prototype, with everything hooked up:

While far from a complete game, I'm glad we managed to at least create this little prototype -- even without any puzzles or mechanics, I think it at least communicates some of the tone and style of what we were going for.

Lessons

Our experience exemplified some important lessons in each of these categories. We already 'knew' them, but we probably know them at a deeper level now. From a design standpoint, we demonstrated the multiplier rule that every game developer should keep in mind -- everything takes at least ten times longer than it seems like it should. In particular, this game design wasn't a two-day project, it's more like a one-month project. Next time, we should probably try designing a game that seems like it should take four hours, and it might be doable within 48.

From a technical standpoint, I demonstrated that I can't write a new game engine in an unfamiliar language in two days, even if I assemble most of it from open-source libraries. It might be possible for someone to write an engine in a familiar language in that amount of time, or learn to use an unfamiliar language, but probably not both at the same time. Most successful Ludum Dare projects use a complete existing framework like Game Maker, Unity, Flixel or Flashpunk. I'm planning to do that from the start next Ludum Dare, so that I have more time to spend on the game experience as a whole.

From an artistic standpoint, Aubrey demonstrated that it's necessary to budget the time spent on each asset so that it will all fit into the allotted schedule. For this project, it would have been more efficient to sacrifice some detail on the character model in order to have time to create more rooms.

I hope you enjoyed this write-up of our experience, and I encourage every game developer to participate in these events! It's a great way to get some perspective on the entire process of developing a game, especially if you're in the middle of a giant project and find it difficult to see the forest for the trees. What do you think of Ludum Dare? Should I spend the time to participate a couple times a year, or just work on Overgrowth instead?