Ludum Dare 39 Postmortem: Audio Hook

My previous participation in Ludum Dare involved music for seven game projects, and sound effects for one. That went super well, because I needed that many projects to occupy me for the entire weekend. I even had a painful amount of downtime and wrote a couple bonus songs.

This time, for Ludum Dare 39, I created Audio Hook in 48 hours. This showed me how little down time you get if you make a game entirely by yourself. Games are huge, complicated beasts, and 48 hours isn’t a huge amount of time.

Something else totally new: I streamed the entire event live on my Twitch channel. You can watch the full recording on YouTube. But be warned: I overworked myself and might be a little zanier than usual.

My past couple experiences with this – LD 34 and LD 36 – were meant to be Compo entries. However, by the time the 48 hour deadline started rolling around, I decided it would be impossible to have a finished, working game in that time, so I took on the extra 24 and entered the Jam instead.

For LD 39, I used what I’ve learned about time management (at least in the context of game jams) to force myself into the Compo, whatever it took. And I succeeded.

As always, this document is meant primarily to tell my future self what to do and what not to do with the next Ludum Dare I enter. There won’t be a lot of info about the game itself, so you might want to glance at the Audio Hook LD page before reading.

Take my advice with a grain of salt, because it’s specialized to my particular situation. I hope you can get something out of it. Feel free to reach out if you have any questions about my experience, or want to talk about Ludum Dare in general.

What Went Right

Have a solid idea before going to be the first night – and sticking with it.

The first night, I paced back and forth in front of a whiteboard, marker in hand, spewing out whatever came to mind. This eventually paid off in the following design:

The next morning, I had doubts. The idea had holes, didn’t fit the theme perfectly, and might require a ton of music. Also, there would be several graphical assets to produce.

The takeaway here? Stick with it. The 48 hour limit doesn’t give you time to redesign after spending a night sleeping on an idea and dreaming about its possibilities. Maybe you’ll fix the problems, maybe not. But commit to succeeding or failing the whole jam.

Doubts are a good sign. You should be even more suspicious if you think the idea is perfect after reflection. This means you’re blindly loyal to it, and that could cause more problems in the end.

Commit to requirements (in my case, minimal graphics with a focus on audio/gameplay) early.

I’m basically an audio person, with a strong programming background and a bit of dev/design experience. The gaping hole in my skillset is visual art. With enough practice, maybe I could be okay at sprites and models, but since my interests lie elsewhere, it’s difficult to polish up this skill.

With this in mind, I set out trying to create an audio-focused game with minimal graphics. My approach for Ludum Dare 36 was to make a text game, but I don’t think this appealed to much of an audience. Having some kind of graphics and a more traditional video game (with actual visuals) sounded like a better idea.

This one was a double-edged sword, though. I’m not totally satisfied with one or two of the game’s sound effects, and the music could use some extra polish. However, I spent very little time on graphics. At one point, I made the misguided attempt to texture the hookshot line. This turned out okay, but I could have spent the time and energy better elsewhere.

Implement a full play experience before broadening the game.

The advice I hear over and over, and constantly gave myself in previous postmortems, was to start with a tiny, playable experience. Get that working, and the rest is just filling in content. Although I ran into some roadblocks for this (see the bit about the audio system in the next section), I did manage a complete playable experience with a single level before expanding to more.

Cut corners early to start release process with several hours left before the deadline.

The initial plan was to have a full playable on the first day. That didn’t happen. I pushed it back to noon ET on the second day, then 3pm ET on the second day. The deadline was 9pm ET.

Eventually, I started cutting corners when it got to be around 3 – 4pm. With the deadline fast approaching, I knew it usually took more time than estimated to produce the final executable and make sure it works. The build came around 6pm, leaving me three hours until the deadline (with an extra hour of leeway for submission).

This was a fantastic idea, because the built version immediately showed critical problems. The whole time, resolution hadn’t even entered my mind. Unity uses a free-form shape when playing in the editor by default. This doesn’t show you how your interface will look in, for instance, 16:9 or 4:3.

When I played windowed mode at the lowest resolution to test (640×480), a viewer on the stream pointed out that the interface was getting chopped off. Sure enough, he was right. Wish I knew his handle because I’d love to credit him for it. This is one part of:

Stream the event. This forces you to work diligently and gives you pseudo-playtesters in the eyes of the viewers.

Streaming might not be for everyone. Some people don’t have the setup, some people just don’t like it. I thought the experience would be far too distracting because I enjoy interacting with chat.

The result was the opposite. Because I had to come back for streaming, and I knew there were people watching, there was an extra urgency to getting back to work. Most jams, I’d take all sorts of breaks, convincing myself they were needed. For the most part, they’re just a waste of time, and streaming helped me focus on the task at hand.

As previously mentioned, viewers can also be a sort of playtester. They’ll spot things you might miss while you’re focused on something else. This simultaneous feedback is hugely useful because you rarely have time to iterate during a game jam. It just takes too much time to get the game into someone’s hands and take their feedback into consideration.

What Went Wrong

Take more breaks.

Although streaming helped me avoid taking too many breaks, in the end it ended up forcing me not to take enough, either. The streaming+jam mindset had me locked to the computer more than a usual jam, feeling like leaving the house would be problematic.

I took one break on Sunday to get the mail. Other than that, my breaks were just grabbing food or coffee, no more than five minutes. This led to some of the more frustrating moments which could have done with a brisk walk out in the fresh air. Usually I can approach problems from a new angle when I come back from such a break.

Build the critical system first (in my case, audio layering).

I knew from the first hour that the game would involve layering of audio stems as a core mechanic. With this in mind, it should have been one of the first systems I developed, if not the first. Tacking it on after the code had already become a bit of a convoluted mess led to many problems.

Eventually, I scrapped a lot of the code I’d written to rewrite that particular system. It ended up a bit too coupled by the final product, a mess I could have avoided by taking some breaks (see previous note) and making it before anything else, so the critical bit would be working first.

Design around content taking more time than anything else.

A common piece of advice for game jams, especially short ones like Ludum Dare, is to use procedural generation as much as possible. This allows for a larger game experience in a limited design without the need for loads of content.

My design worked well for procedural generation of levels and graphical content. Not so much for audio. See, each level needed its own unique audio stems to work. Even if I had multiple levels with the same song, I would have to manually split into a different number of audio stems in order to handle a different number of in-game stems.

I’m glad I went forward with it because I like the game’s design, but ultimately this led to having three levels in the Compo version rather than the planned eleven (or the currently planned 16).

Pick a name early on so you can reflect on it.

Right as the clock was ticking down and I was putting finishing touches on the build, I pulled a name out of nowhere: Hook, Beat, an Keeper. I thought it was a clever take on “hook, line, and sinker” and loved that “Keeper” was a reference to football (soccer).

Turns out, people thought the game was about hooker and beer. Names are important, friends.

Conclusion

This Ludum Dare was more successful than any previous LD for me. It’s the first time I’ve streamed the entire event and the first time I submitted to the compo. The votes and feedback are rolling in from all sorts of awesome people, and I’ve even made a few potential friends along the way.

Next Ludum Dare, I’m streaming the whole thing again, whether doing music or a game of my own. However, I’ll take more breaks, make sure the game’s size isn’t limited by the amount of content, and maybe experiment a bit more with graphics.

Thank you for taking the time to read through my reflections. I hope you found something useful, and if you aren’t already interested in Ludum Dare, I encourage you to dive in with the next event. You can learn a lot in a single weekend, especially working with a team for the Jam.

Again, feel free to reach out to me through Twitter, email, or checking out my Twitch stream on Mondays, Wednesdays, and Saturdays. I’d love to talk about my experience, Ludum Dare, or game development in general.

 

Ludum Dare 36 Postmortem: Conor & Harley

This is the postmortem for my game Connor & Harley made in 72 hours for the Ludum Dare 36 game jam.

Yes, you’re reading that right–there’s no Ludum Dare 35 postmortem. Although I was involved in making music and audio for that particular jam, I felt separate from it, and my work was sporadic rather than constant. For that reason, I never got around to doing a postmortem because it felt wrong doing it for a disjointed event rather than a specific project.

For the 36th edition of Ludum Dare, which was my third and the second one in which I attempted the compo (working alone), I decided to make a text adventure. I know the modern parlance is to call it interactive fiction, and in fact the game did veer in that direction, but I can’t bring myself to call it anything except a text adventure, because to me these games owe their legacy to Crowther’s Adventure and Infocom’s Dungeon (Zork series).

No, I don’t think the thing I cobbled together in 72 hours come anywhere near comparable to these. Actually, I won’t even call it a finished game (story) until I’ve had at least three or four more releases in the distant future. However, these games are a deep part of my childhood, even though they were around for decades before I was born.

I won’t bore you with a historical account of my experience in interactive fiction, except to say that I owe a lot to Campbell Wild’s ADRIFT system. Not only did this system get me making my first games, it also taught me many things about programming, including the revelation of the mysterious things known as “variables.”

And now we move on to the fabled Two Sections of a Game Postmortem.

What Went Right

The decision to switch to the jam (72 hours instead of 48) in the middle of the competition.

I also mentioned this in my Ludum Dare 34 postmortem, and it was exactly the same situation. I figured because I wouldn’t be spending time creating assets, I wouldn’t have this problem again. I was very wrong, for all the reasons outlined in “What Went Wrong,” below.

But it was a good idea. I came to a point in the middle of the second day where I realized my game had potential. This left me with two options: cut corners now to get the game into a finishable state, or continue on to the third day. There weren’t really any cons to adding on the extra day, other than being out of the competition. Since this Ludum Dare doesn’t have rankings it didn’t make a huge difference.

The jam option allows additional benefits, such as working in teams and not sharing your source, but I decided to stick to the compo rules and tack on the extra day as a sort of hybrid challenge to myself. The end result is much better than it would have been otherwise, especially because:

Someone who wasn’t me play-tested the game.

Watching this play-test, taking notes, and seeing the resulting transcript led to a huge number of changes in the last four hours of the jam. These ranged from simple typos like “your hair rubs against your ceiling” to huge, game-breaking situations like the player being able to magically hop into the ending without solving the second-to-last puzzle.

Even though this meant finishing the game before the deadline and taking time out to watch the play-test on-fold, the benefits were huge. I had always heard it’s a good idea to finish at least half a day early for play-testing even in a severely limited event like a game jam, but now I’ve experience it first hand, and I truly believe it. I only wish I had left more time for testing, or had more testers to try the game.

Eating, sleeping, and generally looking out for myself.

This one is a given which I learned was a good idea in my first jam. Although Conquistaquest ended up being rather impressive since I was learning the tech as I went and didn’t have any prior completed-game experience, I basically blew off the last 12 hours in a blind daze and couldn’t solve some of the more killer bugs late in the jam. This led to us dropping a couple features which could have been fun, and which I could have implemented quickly after some proper sleep and nourishment.

Using good tech designed specifically for what I wanted to accomplish.

You’ll see my decision to use Inform 7 as a pro and a con. It’s a pro because the system is hugely intuitive. Inform 7 uses a “natural programming language” which means most of the code reads like a book. Some of it can be a bit weird–which I’ll get into in the “What Went Wrong” section–but generally it’s as smooth as writing a novel.

Here’s an excerpt of actual code from the game which reads like normal English:

The crystals are part of the chandelier. They are scenery. Understand “crystal” and “pearls” and “glass” as the crystals. “Glittery balls of glass held together by nearly invisible string or chains. Some are more globular than others, and a bit cloudy. You wonder if they’re pearls or simply meant to look like them.”

Although some of it is a bit stilted and technical, you can get a good idea of what’s going on here. You can see more by browsing the game source and learn more about the language on the Inform 7 website.

Going out of my storytelling comfort zone.

I have a long history of jumping on fantastic worlds, magic, the traditional (cliché) medieval setting, and the like. I used a bit of this as a crux in this adventure, but the idea of setting it in a modern, real-world (ish) place would normally terrify me.

The leap out of my comfort zone was intentional: by doing so, I created a brand new universe to explore. Although the game isn’t set in a specific, real place, it involves college students in a renaissance-era palace and I did a significant amount of research in the short 72-hour development period. I think this led to a more believable and interesting experience, but it may have also led to some holes and inconsistencies. We’ll get to that soon.

What Went Wrong

Very minimal outline before starting development, which led to all sorts of problems.

Here’s a shortlist of the problems this cause:

  • I was way too blabbery in the beginning, and as I started to run out of time, the game text grew terser.
  • I didn’t leave any time in the beginning for research because there wasn’t any idea specific enough to research. This was especially a problem in a modern setting.
  • The work went from start to finish. As I suggested to myself in the LD34 postmortem, it’s always best in a tight deadline to get the thing done from start to finish as quickly as possible, then fill in the complexity and details of the middle. Didn’t do that.
  • A lack of focus as to what the game was going to be. I started making an event-based story but had it in my head that I wanted a traditional text adventure, so the game became this weird collection of both and sometimes a hybrid.

Limited prior experience with Inform 7.

Although I worked through the entire tutorial book several years ago, Inform 7 has changed drastically since then. I’ve also only made a single, very small game with the system, so I wasn’t familiar with all that it took to build a larger project from start to finish. Sometimes I tripped on the more obscure pieces of the compiler.

For instance, you can’t use “if, otherwise if, otherwise” unless you’re using the “big if statement” format. This means that the following won’t work.

If the player is tall, say “You hit your head on the ceiling”;

otherwise if the player is short, say “You pass through with ease.”;

otherwise say “You pass through, but your hair brushes the ceiling.”

Instead, you have to phrase it like this.

If the player is tall:

say “You hit your head on the ceiling”;

otherwise if the player is short:

say “You pass through with ease.”;

otherwise:

say “You pass through, but your hair brushes the ceiling.”

Notice the semicolons, colons, and indentation here. Those are all super-finicky, including the periods, so it took a long time to get used to these rules. No matter how natural Inform 7 appears, it’s still a programming language. That means it abides by very strict, very technical rules.

On this same note, finding a specific phrasing of something can be very difficult. The functionality to search through the documentation searches broadly and has no advanced features. So if I’m trying to find what the word “called” does, I get every single instance of the word “called” in the documentation, including the ones in the main text (not in code examples).

These problems largely went away later in the jam as I grew more familiar with the system’s quirks. I also started to find answers more quickly as my vocabulary began to match that which the system expects. It’s kind of ironic how using Inform 7 can be like playing a frustrating text adventure sometimes, where you’re stuck trying to guess the verb, like when the action is “using it with” instead of “using it” or “using with it”.

No codebase to work from.

Related to my lack of experience with Inform 7, I didn’t have any code for it lying around. Before the jam, I pulled together as many extensions as I could so I could make my starting point super-flexible. However, I found that many of these extensions use obscure language just like the core language, so trying to figure out all their technicalities on top of the language itself only made things worse.

Now that I have some more code under my belt, I can start creating my own personal extensions. The next time I write an adventure I’ll have a lot of the technical bits from this specific game already implemented in a way that makes sense to me. That’s a huge boon over starting from scratch.

The adventure blew way out of scope.

This is something I need to continue to work on, and I think it’ll get better as I do more of these jams. You can’t do a lot in 48 hours, or even in 72. There’s no getting around that. So instead of trying to do more, you should find a way to accomplish more in less actual content. Hence the popularity of procedural generation at Ludum Dare.

The scope getting out of hand was largely a product of not having a complete outline. I didn’t know the ending, I didn’t see the bigger picture, and I kept changing course as I went along. I started with large swathes of text, spending the entire first day on what I thought was going to be nothing more than the introduction to the game. Possibly I should have cut my losses at that point and made the introduction the full game. In that case, I might have finished in 48 hours.

In the end, the game has a lot of empty space and things which don’t exist because it was too big for me to handle in this short period of time. Next Ludum Dare I’m going to think so small it hurts, and then build from there. Much easier to do that than to think big and cut down.

Conclusion

My initial thought was to do procedural generation, but when I went down the text route, I had to familiarize myself with the language. Now that I’m more clear on how Inform functions, maybe I could pull off something a little more procedural. The problem with text is that it can’t be abstract enough to really be generated without insanely advanced natural language processing.

Maybe at the next Ludum Dare I’ll do something procedurally generated, more abstract, more programmery. Or maybe I’ll try another crack at a text adventure. My next big project is going to be NaNoWriMo, so it could go either way: I might be burned out from writing my novel, or I might be so into writing that I want to keep going with it.

In any case, I feel like I succeeded again at this Ludum Dare. I made a game that is playable–and winnable–in a period of 72 hours, on my own. Got to give myself credit for that.