A couple weeks ago I participated in the 27th Ludum Dare. Ludum Dare is a game jam: participants work to create a game from scratch within a weekend. I wrote about the last time I did Ludum Dare here.
This Ludum Dare, I competed in the compo instead of the jam. The compo is the individual event: games must be created by a single person over 48 hours. This was my first time doing an individual game jam – the previous Ludum Dare I was in a team of four people.
A game jam with a team of talented, creative people is much different than one where you only have yourself. In previous game jams, I’ve focused almost exclusively on code, leaving the more creative pursuits to more talented teammates. That was now impossible. I was forced to learn the limits of my own skills and creativity – I had to design all the mechanics, draw all of the art, create all of the sounds, and do all of the level design. And this was in addition to programming everything.
I knew game jams were stressful, but this brought it to a completely new level. Keeping everything in my mind at once was mentally exhausting, and the sheer variety of things I had to worry about was overwhelming. I felt as though my brain simply didn’t have enough capacity to realize the entirety of what I was creating.
That being said, the sense of accomplishment is also unequaled. Looking at the final product and knowing that I was fully responsible – that the entire thing had not existed until I created it – was incredibly satisfying. I think I prefer doing game jams in teams. I love the collaboration and the ability to call on other people’s skills; but the individual jam was an experience I’m glad I did.
For Ludum Dare 27, I created a game called Firefly. Firefly is a simple platformer game about catching fireflies.
I created this game mostly out of frustration with the theme, “10 Seconds”. I first saw the theme and was instantly disappointed. I predicted that nearly every entry would be a variation on “you have ten seconds to accomplish a goal”. I desperately wanted to avoid making a game like this, and brainstormed for hours trying to think of a good idea that was different.
I failed miserably at this.
Eventually a somewhat random thought floated into my head – a poignant image of a kid and his dad sitting on a hill at night under the stars, and the phrase “the universe is so large that a star dies every ten seconds”.
For a lack of anything better to do, I started drawing some pixel art to emulate this mental image.
This was my first progress toward my game. I had a solid vision of what I wanted the game to look like visually, an idea of what the mood should be, and absolutely no clue about gameplay.
What Went Well
My game started with art – and it shows. The visuals are the most polished aspect of the game. This was especially encouraging to me as it was my first time doing pixel art (or really art of any kind since elementary school). I wish I had time to create more varying environments and more unique areas for the player to explore, but 48 hours is not a lot of time.
This goes hand in hand with the art. I managed to pull off very nearly what I had in mind for the mood of the game. The art, slow gameplay, and intro all work together to put the player into the mindset of the kid.
The biggest thing that I think the game is missing from this perspective is better sound design. I would have loved to make some background music and add some more ambient sound effects – crickets chirping, grass rustling, other peaceful night sounds. But music composition is completely overwhelming to me, and capturing or synthesizing other sounds was more than I had the time for.
I was somewhat terrified of doing the individual event just because of the variety of tasks I would have to do. For previous game jams I had focused almost entirely on programming; my strongest skill, and probably the only one I am comfortable with. For an individual game jam I had to handle art, design, and sound, all while making sure that the game was complete and reasonably interesting.
I impressed myself with the amount that I was able to achieve and with the focus I was able to maintain. Even more surprising was the fact that the programming was the weakest part of the game – the finished product had very buggy collision detection (mostly fixed after the jam). The strongest part of Firefly – the art – is a completely new skill for me.
What Went Poorly
I never fully realized what I wanted the gameplay in Firefly to be like. I think given a couple more days, I could have come up with some interesting variations on the “catch fireflies until time runs out” theme, but I was too overwhelmed with trying to finish that basic concept in the time given. Ultimately I’d like the focus in Firefly to be more on exploration; something the current mechanics do a poor job of encouraging.
This weakness stems directly from the fact that the core game concept was never rooted in gameplay. The game was an experiment in art and mood, and the gameplay is very auxiliary. In an ideal game the gameplay should work very closely with other elements to achieve the art and mood I was trying to produce, but in Firefly’s case they ended up just being somewhat tacked on. This is definitely something I’d like to change for the next Ludum Dare.
Level design is a very similar situation to gameplay. The level I created for the game was made in perhaps an hour or two on the last day, and did not really serve a purpose besides saying “look, I have a playable level here”.
The lesson learned here is that the level design should have followed a similar design process to the other art assets; I should have worked on a rough sketch in the first day or two, and continued to refine it as the jam continued. Leaving it for the last hours of the jam and expecting good results was just setting myself up for failure.
Sound is always an afterthought in game jams for me. Producing all of the other assets is draining enough, and any sounds that do get produced are usually the result of 15 minutes fooling around in bxfr. This was the case for Firefly as well. I had rudimentary sound effects for the primary actions in the game (jumping, landing, catching a firefly), but they were neither exhaustive nor well done.
I’m not sure how to improve here short of spending a lot of time practicing sound effect design outside of Ludum Dare, which is not something that greatly interests me. Ludum Dare always involves compromises on use of time, and I’d rather focus on other things besides sound design.
I mentioned earlier that I had substantial difficulty with the collision detection in the game. The end result sometimes had players warping through platforms, getting stuck in midair, or getting stuck in endless fall-to-your-death loops. Given my difficulties with collision detection in the previous Ludum Dare (although that time from a performance perspective), I was disappointed that I wasn’t able to improve. This is one of my goals for the next Ludum Dare – have rock-solid collision detection.
I’m relatively happy with how this jam turned out. I proved I can make a game all by myself – all assets included – in a couple of days. From an ego perspective, this went a long way toward proving that I’m not a one-trick pony.
My biggest learning in this Ludum Dare was to focus on iterating on the entire game at once. I followed on art-first, everything-else-second approach this time, which predictably ended up in a game strong on art and weak on everything else. I’d like to iterate on all elements at once for the next jam, which should end up in a more balanced creation.