Ludum Dare 30 Post-Mortem

Games

Last weekend, I participated in Ludum Dare 30, which was my first game jam. In this post, I’ll describe my team’s submission, as well as some of our thought processes during the competition.

The Jam & Compo

Ludum Dare is actually two separate events:

  1. A single-person 48-hour game competition (or ‘compo’).
  2. A team-based 72-hour game jam.

I participated in the 72-hour jam. The result of our efforts was Planet Smasher, a game about shooting projectiles at your opponent while in orbit. You can play the game here.

planetSmasherIntro

Each Ludum Dare has a theme that all submissions should try to incorporate into the game. Ludum Dare 30’s theme was Connected Worlds.

Ideating

During the first few hours of the competition, the team thought hard in search of an idea that would be novel, fun, small in scope, and conforming to the theme. We had some wacky ideas, and after much deliberation we decided to use orbiting and gravity as core mechanics.

Orbital Math

planetSmasherGameplay

I had some previous experience simulating gravity in 2D game prototypes, and was able to recover some old code that calculates acceleration due to gravity from a previous project. Surprisingly, the meat of the logic exists entirely in these few lines of code:

float gravityAccel = GRAVITATIONAL_CONSTANT * ((this.mass*otherObject.mass) / (distanceToObject*distanceToObject));
float angle = (float)Math.Atan2(relativeY, relativeX);
float accelX = -(float)Math.Cos(angle)*gravityAccel;
float accelY = -(float)Math.Sin(angle)*gravityAccel;

Using this simple formula, we were able to create all the orbital behavior for the planets and projectiles. We got some emergent behavior as well. Sometimes planets would pass very close by one another and perturb each other’s orbits.

Scrambling for Assets

Every serious attempt at a video game needs graphics and sound, but we didn’t have any experts in these areas on the team.

Instead of trying to create our own sounds, I searched the Ludum Dare website and found a forum thread full of people offering their own assets for use in the jam. One chiptune producer was nice enough to send us a copy of his song to use in the game. There were also a few repositories of free sound effects that we used for the shooting and exploding sound bites.

For the game’s art, I quickly drew some circles to represent the sun and planets in orbit. These ‘placeholder’ assets were never replaced. Additionally, several other images started out at higher resolutions, but we intentionally pixellated them in an attempt to make it look like a retro video game. A good example of this is the image of a galaxy that is the background throughout the game.

Quick Iteration

In our game code, we had a section devoted to the game’s ‘magic numbers’. These numbers were the values that determined how the game worked. For example, we had the gravitational constant shown in the code sample above. We also had variables that determined the feel of the game, like how fast the player can rotate or how long do they need to hold the space bar to charge a shot.

Throughout the development of the game, we playtested many times to test new features and balance existing ones. Because we kept all of our tweak-able numbers in one place, it was easy to create a very fast feedback loop and continually hone in on the ideal values.

A Touch of Humor

Entries in the Ludum Dare competition are judged in many categories (Innovation, Fun, Graphics, Audio etc). The most overlooked category is Humor. Most games in the competition don’t try to be funny at all. For our game, we wanted to at least attempt some humor.

planetSmasherEnd

After each round, the player sees an end-game screen that displays their results. This felt like a good place to add the flavor text.

Post Mortem Analysis

Summing it all up:

  • What went right
    • We made a game in a weekend and it runs without crashing!
    • We made some good decisions on:
      • Keeping the scope small
      • Creating a simple, engaging core mechanic
    • Generally positive reviews from players:
  • What went wrong
    • We didn’t have any graphical artists of any kind and it shows.
    • This was the first time anyone on the team used Unity, and we spent lots of time just learning the tools.
    • Negative feedback from players:
      • Different reviews say that the controls are too slow or too fast. There were also requests to use mouse controls instead of keyboard-only.
      • Some players can’t play the game because we only deployed to web.
  • Lessons learned
    • The competition really is about knowing your tool set and workflow ahead of time. This preparation allows you to focus on only the ‘production’ aspects of the game.
    • Come into the competition with some of the problems already solved. For example, where are good places to find music and sound if you’re not an audio expert? Lots of entries solved this by using music generators.
    • Try to get the game running on as many platforms as possible.

Thanks for reading about Planet Smasher. See you at the next Ludum Dare.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s