My First Successful Game Jam
I competed in Ludum Dare 41 last weekend, when I made a small video game in 48 hours. Was that ever a learning experience.
First off, you can play my entry, Puzzle Prizon, here! LD 41 is still in its voting rounds, so if you also participated in Ludum Dare, I’d like to have your feedback.
Preparation
I’ve written about my other failed attempts at participating in game jams. Every time that I’ve gone to join one, life has gotten in the way, whether that be schoolwork or laziness. This time though, the stars aligned. It was a weekend before dead week, so I didn’t need to worry about projects or assignments, nor did I need to really double down on my study sessions.
So I watched Ludum Dare timelapses, where people demonstrate their system for developing a game. I especially liked watching the videos of Pixel Prophecy, since he always makes his videos so engaging. I blocked out a schedule and let my friends know that I would be disappearing for a week. I wrote some small tech demos as warmups to actually competing. I religiously checked the Ludum Dare website to see when theme voting would start.
A Note on Themes
Everyone (including me) likes to complain about the Ludum Dare themes, and this year is no exception. After the final rounds of voting, the chosen theme was “Combine Two Incompatible Genres.”
Bleh.
I particularly hate this theme. Rather than talking about topics or ideas that can be discussed, it instead focuses on mechanics and process. My personal opinion is that if you want to really let people work in the incredibly varied video game genres (top-down, platformer, FPS, text-based games), then you really need to allow it to be open. I got into a couple of small debates about this; other people think that themes should inherently be difficult to work with, forcing designers to think outside the box of the theme. I still think that this is the wrong kind of restriction to impose on people, but to each their own.
The Competition
I’m not going to lie: creating a video game in 48 hours is stressful. I barely left my room during that time except to eat and take the occasional exercise break. The one maxim of video game development is that you will run out of time, and I certainly found that to be the case. At the beginning of the competition, I had all these ideas for complex mechanics and puzzles that I eventually left on the cutting room floor.
In order to really make a good game, you have to come up with some good ideas and mechanics right off the bad. Game design is an entire career apart from programming and art, so I knew that my ideas this time around may be less than stellar. I was right. My chosen genres – stealth games and puzzle games – were really quite similar, and so I had to shoehorn them into this theme.
As my freshman computer science teacher said, “garbage in, garbage out.” Without a really solid idea, my work stagnated, and I found myself struggling to think of puzzling mechanics I would reasonably be able to implement. The ones I settled on are kind of half-baked, so I struggled to find ways to make the game more fun. It eventually worked in the end; I’ve gotten several decent reviews on my game so far. But I still think that adding a little more thought into the game at the beginning would have paid me ample returns.
Using Restrictions
When you go to make a game, it can be anything. Anything. Unless you already have a firm idea of what you want, this vast emptiness can lead to paralysis of choice. When you impose restrictions on yourself, you cut off some options you might otherwise consider. Writers are very familiar with this: it’s much easier to write something under restrictions than something that can be “anything you like.”
There’s another good reason to use restrictions: to make a good game, one has to be good at everything. A good game has good graphics, good music, good sound, “feels” good, is playable, is well-designed, has good controls, etc. No one person can do this well on their own in 48 hours. It’s just not possible.
Well, it is. It just depends on your definition of “good.”
When playing a lot of LD games, you’ll find that a large number of them use pixel art, and that many games that include music involve classic video game instruments. My game is among these. That’s because when you’re working in something that’s restricted in these ways, it’s much easier to make something decent. I’m not a good enough graphic artist to do proper character designs on a high-resolution canvas; instead, I just made all of my sprites 16x16 pixels and called it good. Likewise, when I already had 8-bit samples lying around, I didn’t have to figure out how to make a saxophone sound realistic. I just put in notes and durations and call it good.
Lots of other games make things restricted in other ways. For example, some games use minimalistic graphics and gameplay, since these are much easier to craft than games with lots of mechanics and control schemes.
The Danger of Polishing
I spent way too much time on graphics that ultimately didn’t even get used. I think that I spent about 2-3 hours on the player character and guards, which went through several revisions. That’s time I could have spend implementing core mechanics, so that when crunch time came, I wouldn’t have to put in a relatively bare-bones puzzle system.
By focusing too much on one aspect of a game, the other aspects get neglected. There are only so many hours available, and budgeting time effectively is paramount for getting something that’s playable at all. I scraped by, but just in the nick of time.
The End Result
Overall, I’m happy with my game. It’s not perfect, and it’s not really what I expected it to be, but it’s a project that I started and finished and is (mostly) playable. I can show this to people and say “I made this.”
And that’s enough reason to be proud in itself.