This was my 5th Ludum Dare, I was well prepared with a beefed up Frank Engine, my open sourced game engine that I’ve used for previous Dares. During the warm-up weekend I added some nice tile sheet support so I was planning to make a pixel art game to test out that tech. I ended up throwing that idea out the window to go with a cleaner un-textured look. I was able to use a debug display for the lighting system to create the unique visual aesthetic. Looking back I would have done a few things differently but overall I’m satisfied with the final result.
Friday – Core game mechanic and visuals
After hearing the theme was “Minimalism” I sat down and brainstormed for about an hour, making a list of as many game ideas as possible. I decided that simplifying the controls was of key importance to capture the theme. I settled on a platforming game with a twist of physics. The complexity comes in with the spin and bounce mechanics which are more physical then normal platforming gameplay. A few years ago I made a rough prototype called Pill Bug and I thought this was a good chance to start fresh and revisit that concept in a new way.
I searched online for visual inspiration from minimalist artists and I saw that use of pure color values and geometric shapes were a common theme that I wanted to explore. I’ve always been a fan of Mondrian in particular. I got to thinking about his use of primary colors and how in computers the color space works a bit different from what painters work with in the way colors combine. For example in computer images red and green mixed together make yellow! Cyan and magenta are secondary colors instead of orange and purple. With a game concept and an idea for the graphics I scribbled this rough sketch down on paper before I set to work…
Typically I don’t do any programming on Friday night but this time I actually made a good portion of my game. I focused on the getting core gameplay controls and visual look right. By late Friday night I had a game that looked and felt kind of similar to the final version just with much less stuff, no level design, and rougher controls. Here’s a screenshot I took very late Friday night…
Saturday – Game objects and effects
On Saturday morning I came up with the idea to start the game by zooming out from a lcd display of RGB pixels. I have used zoom sequences before with my game engine and had an idea about how to quickly program the lcd effect. Basically I’m just rendering a quad in front of the camera with a lcd texture wrapped many times while zooming out from close up, then fading off that texture at a certain point.
During Saturday I focused on building up a pallet of objects and effects while continuing to polish the gameplay. I’ve always loved the magnetic tracks in Metroid games that you stick to as a ball but I’ve never implemented anything like that before so I thought that would be a fun gameplay element to play with. I wasted some time adding stuff that ended up being cut, like water that you could float in for example.
Midway through the day I began working on the level design and made about 25 percent of the level. By the evening I was confident enough on my progress to invest some time adding visual touches to really show off the lighting system. The way light passes through the semi-transparent doors was a cool effect that I tried to accentuate by making them physically open up rather then just fading off so you can see the shadow move. It was raining really hard here that evening which inspired me to code up a rain system. It simulates each rain particle by piggybacking on my weapons system, each rain droplet is a bullet fired from above the player. This is probably way overkill but it looks awesome and it was easy to do.
Sunday – Level design, sound and music
For the first time in a Dare I decided to music more of a priority. I have been playing around with some iPad apps recording into Audacity to make simple songs quickly. I ended up using Figure by Propellerhead which is kind of like a stripped down version of Reason. I set it to the longest possible loop and played around for half an hour until I had decent drums, bass and lead tracks going with a few different variations. After I was satisfied that I had the proper elements I recorded the song live by play around with levels and effects and changing up the beat. This seemed to work much faster for me then actually composing the whole song with an editor. I just wish that I had better control afterwards for editing the song, I cut it up a bit but there’s not much you can do to a live recording without introducing glitches. In a way though it was good because it forced me to move on to other stuff rather then continue tweaking the music.
I used BXFR for sound effects. My strategy is to use the random sound for pretty much everything to get more unique effects. I just hit random about 100 times, pick out anything I can use and play around with the settings a bit. I already had the gameplay implemented so I knew what sounds were needed. For the rolling loop I generated a sine wave in Audacity and added vibrato at a resonant frequency. I tied the volume and frequency of the roll sound to the player’s angular speed. Some players complained that the sound was annoying so I have since re-tweaked the levels but it’s easy to miss that when rapid prototyping.
Most of Sunday was spent building a level using all the stuff I had made on Saturday. I found that I had a bit too much stuff and ended up not using or only barely using some of the features I implemented. The level design also went slower then I had expected and took most of the day even though I already had nearly all the design elements. Also I realized that for future projects I must add something to my engine that makes it easier to copy and paste large areas of the map. Without being able to move stuff around easily I get locked into my choices about how the level is laid out. My brother helped by play testing an early version of my game and I made a lot of changes based on his feedback.
I noticed that the rain felt somewhat fake without sound effects or clouds and lighting so I took about an hour to hook that up. There wasn’t time to add new sounds so I re-used explosion sound effects played at higher pitches for rain drops and lower pitches for thunder. Towards the end I ran into some repository issues that cost me some time, and I also got pulled into fixing some really annoying bugs that I couldn’t afford to ignore. Minutes before the deadline I throw in a really quick ending to give the player some sense of accomplishment.
What I learned
I think this was my most successful Ludum Dare and my process worked well. Based on the feedback I’m getting players seem to enjoy it, but there’s always room for improvement. Here are some of the key things I took away from the experience.
- Don’t hold on to tightly to any ideas you had going in
- Keep it simple, you only need a few elements to make a game
- Get at least one other person to play test your game before you submit
- Core gameplay and controls are the most important thing
- Good level design always takes longer then you would expect
- Put save points before anywhere the player can die
- Recording a live set is a good way to make music quickly without it sounding repetitive, I recommend Figure for iPad
- It’s easy to miss annoying sounds in your game when you’re used to hearing them
- It’s ok to put in hacks to fix engine bugs but keep notes so you remember to properly fix them later
You must log in to post a comment.