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 starting with the video below. But be warned: I overworked myself and might be a little zanier than usual.
https://www.youtube.com/watch?v=rVZ0FPslC-M&t=25s&index=1&list=PLUoOzzJDDg5f6O5fUhfqnX1BgwyHQ5P
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 (640x480), 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.
|
|
