Ludum Dare 27 Postmortem

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.

The Game

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

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.

Collision Detection

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.

Ludum Dare 26 Postmortem

About a month ago, I participated in the Ludum Dare Jam. Ludum Dare is a three-times-annual online game jam. Participants compete to create a game in 48 hours according to a theme. Ludum Dare also does a simultaneous competition called the Jam, which is slightly relaxed: teams are allowed, and it lasts 72 hours instead of 48. I did the Jam with a few of my friends who are also interested in game development. This was the first Ludum Dare for all of us, and the first game jam for all of us except me (I previously did the WolverineSoft 48 hour competition in college).

We created a game called This One.

This One Title Screen

Each Ludum Dare has its own theme. The theme is chosen through several rounds of voting, and is announced right before the competition starts. The theme for this particular Jam was “minimalism”.

Minimalism felt like a very weak theme when I first saw it. This was a game jam; games made in a weekend were bound to be minimalistic. The theme didn’t seem to constrain the creative space in any interesting way. Due to the nature of the competition – lots of programmers and fewer artists – minimalism would seem to encourage a trite aesthetic as well: blocky shapes and simple, flat, primary colors. This might extend to gameplay as well with puzzle-arcade-platformers that took a simple hook and created a game around it. Many amazing entries definitely broke these trends, but we saw these predictions come true while playing entries after the competition was over.

Wanting to do something different, we settled upon the idea that eventually became This One. Rather than create a minimalistic gameplay mechanic, surround it by cute minimalistic art, and then wrap it up in a nice neat package, we explored the theme in a different way. We discussed the concept of a reduction to minimalism instead. This One is a top-down JRPG with a bit of a difference: instead of gaining strength and abilities as the game progresses, you lose them. You start out with several abilities and gradually get weaker and weaker. By the end of the game you have no abilities and must rely on other means to progress. This is paralleled by a narrative that explains the reduction.

This One combat

Needless to say, This One was incredibly ambitious. We had a lot of ideas going into this one tiny game, and the final product didn’t address half of what we wanted. This One ended up being something much different from what we intended to build at the start.

Despite all this, I’m still incredibly proud of our achievement. Ludum Dare was an amazing experience and one I hope to continue for many Dares to come. I’ve learned a ton about developing for a game jam and came out with a lot of great ideas. I’d like to share some reflections about the creation of This One, as well as detail some of the things I learned along the way. 

What Went Well

Amazing Art

At the last minute, we enlisted the help of our friend Andrea to create some sprites. She ended up working all through the jam making some incredible art for the game. The amount, quality, and aesthetic were all astounding to me.

Great Ideas

The idea we went with was far too ambitious, and yet it’s something I’m still very happy with. The purpose of a game jam is to get creativity flowing and make something. With that goal in mind, This One was a huge success. Chris’s concept for the game was new and interesting, and it’s something I’d love to pursue after the Jam. While the idea may have been too big to win a weekend game jam, it was also interesting in its own right, and I think that’s what jams like Ludum Dare are all about.

Great Team

With Andrea, Aryan, Chris, and myself, we had a good collection of artistic resources, creative thinking, and technical prowess. However, we also worked very well together. Despite this being the first time we had worked together on a project (and several of the teammates hadn’t even met before the Jam), there was a remarkable lack of friction. We quickly buckled down on an idea and shared the vision without any arguing or drama.


There was a point in the last day where we weren’t sure if we were going to finish the game. Our game had almost no content, we wanted to implement multiple more features, and it wasn’t close to looking complete. To finish we needed to cut the scope dramatically and even then compromise on the content we would be able to build. We thought about slowing down and finishing it after the Jam instead. This would allow us to create a more refined product that better reflected the concept of the game.

But we didn’t do this, and instead we buckled down and made something complete. We implemented three levels instead of the original five and cut the script by an enormous amount. We reused enemy behaviors instead of writing new ones. The levels we did complete were massively simplified. We made a title screen. Eventually, we had something that could be considered a game.

To do this we had to significantly compromise on quality. Every aspect of the game was not quite at the level that we originally wanted. And worse, we did a poor job of communicating the original vision: the gameplay reductionism was rushed at the end, and the exposition didn’t do a great job of setting it up. The game simply didn’t provide enough context to deliver the message we were aiming for.

All of this was made up for by the emotional impact of creating something finished and watching people play it. Finishing projects is a personal bane of mine – I start many, and finish almost none. Sticking with a project from start to end was a huge achievement for me. Seeing the feedback from people playing the game was an experience I’ve never had before and it was very valuable. I feel motivated to finish more projects to show off to the world; that alone makes the entire experience worthwhile.

What Didn’t Go So Well

Not Enough Preparation

We didn’t do a great job ensuring that everybody was set up with all the right tools before the Jam. We spent a couple hours struggling with version control, and a few more later when git inexplicably failed. Some of this could have been avoided with a simple prep session where we made sure that everybody was on the same page regarding tools and processes.

In the end, this only cost us a few hours – but a few hours in a competition like this is a lot of time (and a lot of stress!). Avoiding these kinds of situations makes for a much smoother and enjoyable experience.

Poor Technology and Middleware

We used Python for development, which is a language the two coders on the team were fairly familiar with. I had written a fair amount of game middleware for other projects and worked with a game library called Pyglet, which was a big advantage. I find the technology part of game development as interesting as the gameplay part, which biases me toward developing my own tech instead of reusing proven software. This was a huge mistake for the Jam.

My middleware was untested and buggy, and caused a lot of problems with our game. The collision code in particular was a nightmare. I spent a lot of time hacking it into shape to work with our game. Eventually we got it to a point where it worked – but then we ran into horrendous performance problems. We spent hours debugging and improving it, and even redesigned one of the levels to be less stressful on the collision engine. We thought the final product was “good enough”, but were proven wrong when people started playing it. There were reports of terrible performance in some sequences which made the game unplayable.

While working on technology is interesting and fun, it runs against what Ludum Dare (or any game jam, really) is all about. Making and iterating on games in a very short amount of time means as little time as possible should be spent working on technology. It is worth building new technology in a jam if two things are true: it is essential to the game idea and is novel. Neither were true in this case; simple 2D game libraries have been written half a million times. We could have had much more time available to actual gameplay, and as a result a much better game, had we not ratholed on technology so much.

Not Building For The Web

This is a small thing, but something I intend to change for the next Jam. Ludum Dare recommends you create a browser-based game so that as many people as possible can play it. We used Python and froze it into a native Windows executable. This creates a barrier to entry for people to play the game. This barrier is admittedly very small (just a download and unzip) – but to win you need many votes, and many votes means many people need to play your game. Playing your game should be very, very easy.


As mentioned previously, our game was much too big to create in a single weekend. We were creating content up until the hour before the competition ended. We had no time to playtest or iterate on mechanics, so we had to get everything perfectly right the first time. This didn’t happen for many of the systems, and it was a less fun game as a result. The combat encounters were raw and unpolished and didn’t have a ton of variety. The difficulty curve was much too high at the beginning but then flat for the rest of the game. There wasn’t any exposition of the goal or how to play, which was frustrating for players.

None of these things were a problem with the basic mechanics, but rather with our rushed development. I think for my next Jam I would like to finish all the basic gameplay features by about the halfway point and then spend the remainder iterating, polishing, and developing content. The lesson here, I think, is to ruthlessly cut scope. Once you have an idea, cut it so it will fit in a weekend. Then cut it in half, and then in half again.



The iPhone Killed My Creativity

This article made quite an impression on me the other day.

Numerous studies and much accepted wisdom suggest that time spent doing nothing, being bored, is beneficial for sparking and sustaining creativity. With our iPhone in hand – or any smartphone, really – our minds, always engaged, always fixed on that tiny screen, may simply never get bored. And our creativity suffers.

Spending so much time texting and updating, tweeting and watching, calling and playing at every free moment, from every location, never alone with our thoughts, never allowing our thoughts to drift, impacts our creativity, which in turn can limit our full potential.

I don’t know how much truth there is in boredom contributing to a loss in creativity. I find sweeping generalizations like this are often constructed to maximize their impact. The truth is likely more complex than this simple thesis posits.

But this does have the ring of truth to it on some level. I do think it’s true that moments of boredom – moments when I truly have nothing to do except observe both the outside world and my inner thoughts – have almost disappeared from my life since I’ve owned a smartphone and tablet. And consumption of what I want to call “trivial content” – things that consume time but otherwise have almost no lasting impact on my life – has risen to an all-time high.

Maybe it’s just nostalgia or my inner luddite speaking out, but part of me misses those moments of boredom. I tend to do my best thinking then, and allowing those moments to disappear seems like a mistake.

So much of what we do on our smartphones, however, is decidedly short-term: a few moments playing a game while we stand in line, a minute to scan Instagram as the person in front of us at the grocery store pulls out their checkbook.

I’d rather be more engaged in the world around me than check my facebook feed every hour. I’d rather examine my thoughts and create a more accurate worldview. And I’d rather let my mind wander and potentially even have a creative insight or two.

So, I’m making a resolution. I’m going to stop using my smartphone – or any tablet, laptop, PC, or other gadget – as a time-wasting device. When I’m sitting on the bus, or waiting in line, or in any situation where my brain is free to wander, I will let it do just that. I don’t know if it will be beneficial or not. Maybe I’ll just become more ignorant and bored. But this seems like a good experiment to perform, and it may very well be a good thing. Maybe I’ll be able to think more deeply about fewer things, which in the end seems like an excellent tradeoff to me.