I finished my first Ludum Dare! For those not aware of what Ludum Dare is, it’s a game jam where an individual must work alone over 48 hours to create a game based upon a theme. An interesting caveat is that you must create ALL the content for the game yourself, which includes any graphics and audio you utilize. If you just want to take a gander at the final product, head over to the Game Page or check out the Source.

Anyhow, I had wanted to do a game jam for a while, and this felt like a good opportunity to get my feet wet. I went in not really knowing what to expect from myself, but I tried to prepare as best I could – I heard that you should try to finish your core game in the first 24 hours, and I knew I wanted to aim low for my first try, just to make sure I could get everything done. I also went on a shopping spree for caffeine and junk food to try to stay programming for as long as possible (2 bottles of Monster, a supply of Coke, Cup of Noodles, Hot Dogs, Poptarts, Doritos, and some Bananas).

When the theme was announced (Beneath the Surface), I was a bit disappointed. I had thought briefly on some of the other themes, but not this one. This one also seemed kind of restrictive – the first games that came to mind were basically platformers, and I wanted to steer clear of them just because of how much content I would have to generate. I set aside the first 30 minutes to freely brainstorm ideas without judgment. Here’s what I came up with:

• Treasure Hunting
• Gain power for plunging under water
• Explore connecting holes – transportation
• Microsoft Surface
• Some kind of molten earth thing?
• Shape the exterior by working with the underlying
• Pimple Exterminator
• Different persona from sprite display (mean-looking guy, tender heart)
• Some kind of worm game
• Some kind of ant/termite game
• Reverse Groundhog bopping game – you are the groundhog
• Search for the lost plane with drones
• The ground is the main enemy
• Able to see people’s motivations as you pass them

It was slow to get started, but I was surprised that once you start getting ideas, they keep coming. I was most interested in doing the Pimple game, but I couldn’t really work out your purpose. I thought your goal would be to get to Prom with a clear face, but the gameplay sounded stagnant – pour clearasil on the pimples as they randomly pop up? Meh. My next two choices were either the termite game or the groundhog bopper. With the termites, I wanted it to be strategic – your goal would be to take down the house, but going directly for a structural support would make your presence obvious and you’d get exterminated. The key would be weakening everything simultaneously so the collapse happened all at once. While I still think the idea has potential, I think the groundhog game just seemed simpler to make.

So, the groundhog game was the idea I ended up with, but it started out as a simple arcade bopper. In my head, the gameplay still seemed stagnant, but I began to see a possible way to make the game interesting if your goal as the gopher was to survive, and you’d simply memorize the various patterns that the bopper would use, with the bopper giving some kind of indication of which pattern he was in. Since I couldn’t really see the point of just dying when the bopper randomly selected your hole, I settled on making the bopper more of a sprite and have him chase from hole to hole – and at that point, I suddenly realized I had a game mimicing Animal House…which led to the bombs, emotes, etc.

That initial prototype took less than 2 hours. The initial version had the gopher moving from hole to hole instantly, and your only goal was not being at a hole when the groundskeeper arrived. I quickly realized that the gameplay wouldn’t be particularly rewarding – you’d have no problem surviving until the groundskeeper reached some high speed, and then you’d find it impossible to survive. So, my next thought was creating some interaction between the gopher and the groundskeeper. I thought of 2 things: having the gopher have the possibility of leaving behind trails that would slow the groundskeeper’s movement, and having the groundskeeper leave behind bombs that would kill you. As soon as I tried to implement the shadow trails, however, I realized the movement slow would be unnecessary – I already felt like I had decent control over my survival, but wanted more reason to visit other tiles. To solve this problem, I implemented the carrots, which are still likely not enough of a solution. Eventually, that ‘emergent’ gameplay revelation happened, where, despite the groundskeeper planting a ton of mines, I got a little thrill out of quickly clicking (it was mouse-based movement) to dodge the mines while still getting to a carrot. Basically, I wanted more of that.

The most challenging part was figuring out a good control scheme. I had to revamp the controls many times. First, it was mouse-based point and click, instant movement. Then, it was mouse-based point and click, but with the movement taking time. Then, I assigned keys to every hole. Then, keys assigned to the directions based on the hole you were originating from. Finally, the keys were mapped to the cardinal directions, but with those directions assigned based on your current location. I think there’s still room for improvement there. I was able to sneak into holes surrounded by mines, but often a safe return path was no longer available because there was no hole in the proper direction. I was worried that a simple WASD movement scheme would be too easy to exploit, but it may have made the game more intuitive and given me the flexibility I wanted.

In the end, I’m reasonably satisfied with the result. The game is somewhat enjoyable for me to play, and I surprised myself with being able to find the tools needed to do more than just programming – I used Audacity to modify my own recordings, found a music generator for the backing track, and did the animations and other graphics in GIMP.

Post-Mortem

What went Right

Lowballing it

Being my first time, I didn’t know all the tools I would need. By choosing a relatively simple concept, I gave myself enough time to dig up the audio generators, etc, and refresh myself on the geometry I needed for the controls (Yay arc-tan!).

Just going for it

I generally try to outline my work and make a design doc, but there wasn’t much room for that here. I tried to come up with my intial structure for the game before diving into coding, but the end game really was an iterative process. It took actually creating a basic prototype to figure out what I wanted the game to be.

Hacking

The code was/is not clean. I’m a perfectionist, and that 48 hour restraint really helped get me out of my comfort zone and just start pounding out some ugly code that got the job done. If I ever wanted to make this into a more fully-featured game, I’d start over anyhow, so I’m not too embarrassed that the code is often inefficent and not ideal. That said, I actually do have tests in there, as it was the best way for me to verify that my control logic was correct.

What I could do better

Be more ambitious

While I still think the game was the right choice for me this time around, I did get into a rut midway through the project when I basically got bored of it. At a certain point, it began to feel like a school project that I just had to get done, because it felt very obvious to me that it wasn’t something I’d really play on my own. The Ludum Dare keynote was telling us that it could change your life, but I think I played it too safe to really do so. Next time, I think I’d like to focus on something more challenging for myself and give myself the possiblity of failure. At the very least, I think I’d be able to keep my motivation higher for longer.

Find a better 2D engine

Unity was the wrong tool for this job, no questions asked. It may have been a better fit if I implemented all the sprites as game objects, but with the way I went about it, i.e. with everything in the GUI layer, Unity was more of a hindrance than a help. I had to create my own sprite animation class! And I discovered that Unity really sucks at something as simple as drawing lines. The main perk I see of using unity is that it makes prototyping easier, but I couldn’t even take advantage of that as soon as most of my game logic got buried in individual state classes.

Learn better game patterns, or make the code more monolithic

As stupid as it sounds, I probably should have lumped most of the code into the same file. With the competition’s constraints, I know this isn’t the type of code base that will need to be maintained. The big stumbling blocks were when I was sitting there trying to figure out how to squeeze some feature into my object hierarchy. In particular, I had some difficulty figuring out how to determine when my explosion animations were done, because the explosion animations were included in the individual landmine objects, which were owned by the groundskeeper object, which was the only thing directly accesible to my game logic. Due to time, I ended up just hacking around that issue anyway, so I would have been better off if I had just removed the hierarchy and created the mines as part of the game itself – or learned a better way of doing all of this.

---