At the beginning of December, I participated in my second game jam: Ludum Dare #43. The previous Ludum Dare (#42 in August) was my first game jam ever, and I wrote up a long-winded postmortem dev blog post about how it went. So now, in keeping with the tradition, this post will take a look at my experience with Ludum Dare #43. Have a seat and grab some popcorn, because this will be a long one!

Plans & Preparations

Before the jam started, I had already decided I wanted to try Godot Engine this time around. It seemed like a good choice for quickly making a well-polished game that could be played directly in the browser… Two things that my previous tools, SpriteKit and ReactJS, didn’t do so well. (Check out this blog post where I wrote about the learning experience and my overall impressions of Godot Engine so far.)

Since I would be working with an unfamiliar engine, I figured simplicity would be key. So going in, my goal was to aim for something that my daughters (ages 4 and 7) would be able to easily play and enjoy. I thought that would help keep the scope small, and resist the temptation to put in the kinds of RPG mechanics and progression systems that I seem to gravitate toward.

The other big preparation I made ahead of time was to pre-arrange a vacation day from work. This was also based on lessons learned from last time, and it made for a much more relaxing time having a long weekend.

In the days leading up to the start of the jam, I participated in the theme voting process and considered possible directions to go in for each of the theme finalists. My daughters’ latest obsessions lately had been unicorns and slime… So I also considered if (and how) those might fit in for some of the themes.

The Idea

On Friday evening, the theme was revealed: “Sacrifices must be made.” This wasn’t my first choice… But unlike a few of the other themes, I figured I could work with it. The general idea I went with was as follows:

  • You play as a unicorn. You can run around on a 2D tile map adventure game style.
  • Slime monsters have stolen the unicorn eggs (because of course unicorns hatch from eggs) and taken them to a dungeon cave maze for some nefarious purpose.
  • You must “sacrifice” rare gems from your castle to the slime monsters in order to get the eggs back.
    • Win condition: If you rescue all the eggs, they hatch into adorable unicorn babies.
    • Lose condition: None (other than quitting)

In my previous Ludum Dare, the idea I came up with turned out to be too ambitious in scope… But the bigger problem was that it consisted of a lot of pieces that went together in a “package deal” kind of way. It sort of needed all of them in order to be playable. So this time around, rather than starting with an ambitious idea and then trying to figure out how to scale it down if needed, I tried to start with the absolute minimum and then build it up.

The Development Process

So the plan was to build up the game mechanics in three phases or “sprints” as follows:

  1. The absolute minimum needed to make it playable. You can explore the maps, and directly collect the unicorn eggs with no obstacles.
  2. The “theme satisfying” core mechanics. Slime monsters block the paths to collect the unicorn eggs unless you “sacrifice” the right gems.
  3. Optional additions and polishing. Make the unicorn eggs hatch at the end, animate the sprites, add sound effects, etc.

I figured as long as I could complete the first phase, I’d be able to submit something playable (even if it didn’t satisfy the theme very well). But would I be able to actually accomplish that using a brand new (to me) game engine?

Day 1 (Friday)

The first day of the jam consisted of only the few hours on Friday evening after the theme was revealed (at 8:00 pm). I spent this time creating a new Godot Engine project, setting up a git repository, and creating a basic skeleton for the game (a title screen as well as the different planned environment scenes). I also added a placeholder sprite and the ability to move it around using the arrow keys.

No progress screenshots from this phase – it looked like hot garbage, with just a few placeholder rectangles. But the project was set up and functional (on a very basic level) by the time I called it a night on Friday. So far so good!

Day 2 (Saturday)

On Saturday morning, I decided to replace the unsightly placeholder rectangles with some actual assets. I briefly considered downloading some free pre-made assets from somewhere… But ultimately decided that I wanted to try making the assets on my own. It would be a risky move in the sense of taking up precious time, but I thought it could also result in a more polished and cohesive-looking finished product.

So I spent the morning making some tile sets in Inkscape. Then I spent a good chunk of the afternoon setting up the tiles in Godot (with collisions)… And then setting up the actual maps using those tile sets. I put in a placeholder sprite – this little green astronaut guy that I made for practice a while ago – and got him animated and running around by the end of the day:

Animated gif showing a green astronaut sprite running around on dirt paths.
Progress: Sprite running around on a map (as it looked late on Saturday night).

The controls and collisions were all working… But as far as satisfying even phase one of having a minimal playable game, it wasn’t there yet.

Day 3 (Sunday)

On Sunday morning, I finally finished the basic functionality for collecting the eggs. And with that in place, I set to work on the features that would (at least attempt to) satisfy the theme. In order to “sacrifice” precious gems, the gems would need to exist, and the player would need to be able to pick them up.

So I made assets for 12 gems in different shapes and colors in Inkscape. And then I started building what was basically a very simple inventory system. (This was actually halfway finished before I realized I was failing at that whole “try not to accidentally make some kind of RPG” thing I had started out trying to avoid.) But by the end of the day, I had a pretty functional system where you could pick up gems and set them back down if needed:

Animated gif showing a green astronaut sprite picking up colorful gems and adding them to an inventory.
Progress: The inventory system (as it looked late on Sunday night).

It all worked smoothly, and I was happy with what was done so far, but I was heading into the final day of the jam… And the planned “theme satisfying” mechanics still weren’t finished.

Day 4 (Monday)

On Monday morning, though, I did get the planned slime monsters in place, along with the gem “sacrificing” mechanic. Things were coming together! It was time for the polishing phase… And I started it by attempting to create an animated unicorn sprite, rendered from a 3D model in Blender.

In retrospect, this was completely crazy. To model, rig, and animate a completely new thing, and then export two different animations (idle and running) from 8 different camera angles, all in the span of only a few hours… It ran the risk of burning through all of the remaining time, and maybe still not even finishing it.

A photograph of a 3D model of a unicorn, being edited in the Blender 3D software.
The unicorn sprite in progress.

I had a moment of panic when I went to rig it and realized I had no idea what a unicorn’s (or, uh… horse’s) skeleton even looked like, and had to go look it up. I did manage to get a somewhat passable animated unicorn sprite finished by mid-afternoon, though. Here’s what it looked like in the game:

Animated gif of a unicorn sprite prancing around in a green meadow in a game, with a fantasy castle, a mountain with a cave, and an inventory full of gems.
Unicorn sprite prancing around a meadow (as it looked in the final submission).

It definitely wasn’t perfect, though… It felt rushed in a lot of ways, and I think the run cycle ended up making it look like the unicorn was running backwards. (This bothered me enough that I really wanted to go back and fix it, but of course there was no time.) Here’s another image that better shows the not-quite-right backwards running animation:

Animated gif of a cartoon unicorn sprite in a game, confronting a green slime monster that wants a purple gem.
Unicorn confronting one of the slime monsters (as it looked in the final submission).

As the above gif shows, I also got an animated angry jewel-demanding slime monster in there. And for the rest of the “polishing” phase, I did manage a few other additions. Some basic sound effects, for instance – little jingling sounds when picking up picking up the gems and such. (These were free public domain assets found online rather than anything I created, so I opted out of the audio rating category.)

The final addition, which I didn’t think I would be able to finish but managed to get in 30 minutes before the deadline, was to make the unicorn eggs actually hatch if you collect them all. No spoilers though! Anyone who wants to see the cute little cotton candy colored unicorn babies will have to play the game, heh.

I made use of the submission hour for setting up the game page on, and writing the description and whatnot for the Ludum Dare site. (You can see the original submission page here.) And here’s what the thumbnail for the submission looked like:

The thumbnail for my game submission for the Ludum Dare #43 game jam, entitled "Unicorn Rescue" and featuring a logo with a unicorn.
Thumbnail for my submission on the Ludum Dare site.

Overall, I felt pretty good on Monday night. I mean, I knew it wasn’t a spectacular first-place-worthy submission. And it probably wouldn’t have much appeal outside of the 4-year-old-girl demographic. But I’d accomplished pretty much everything I’d set out to do for this jam.

Time Spent

I had recently installed the RescueTime app, which runs in the background and measures how much time you spend using different software or websites. Of the 72 hours between the start of the jam and the end of the jam, it logged that almost exactly 50 were spent on the computer. Which seems excessive… To the point where I looked up if/how RescueTime handles it when you have the computer open but aren’t actively working. But it sounds like it is supposed to account for that with an idle detection feature… So I may have gone a little overboard.

Anyway, the following is a fun pie chart with a breakdown of where the time was spent:

A pie chart showing a breakdown of the time spent on various tasks during the Ludum Dare #43 game jam.
Breakdown of time spent on different aspects of the game.

Here are some additional details on what specifically each section of the pie chart contains:

  • Development & Coding: Mostly Godot Engine, but also some SourceTree, which I use for git.
  • Unicorn Sprite: All the time spent in Blender… which technically also includes the slime monster. (Though that went super quick compared to the unicorn, maybe half an hour tops.)
  • All Other Art: Mostly Inkscape for making the tiles and gems and such, though also a tiny bit of GIMP.
  • Research: StackOverflow, Godot Engine documentation, and other resources trying figure out how to do various things.
  • Social Media: Browsing and posting to Twitter, and browsing the blog posts from other participants on the Ludum Dare site.
  • Submitting, etc.: The time spent setting up the page, and a few other miscellaneous things that didn’t fit anywhere else.

I thought it was really enlightening to see the percentages. Two things do seem to stand out pretty glaringly. First is that disproportionally huge chunk of time spent making the unicorn sprite… though I think it ended up being worth it (more details on that in the feedback section below). And secondly, that chunk that went to social media. Admittedly maybe not the wisest use of time as far as getting stuff done… But I think it adds a little extra fun and motivation to the whole Ludum Dare experience.

Feedback Received

Over the course of the next few weeks, the game received 24 ratings and 20 comments from other participants in the jam. And as a fun bonus, there was also a video play of it on YouTube – the indie games writer and YouTuber Jupiter Hadley played it in part 9 of her Ludum Dare 43 series, along with 10 or so other submissions. (You can see that video here – and check out the comments too, it’s actually not terrible advice in this case!)

One slightly unfortunate thing this time around is that I rated fewer games, and therefore got fewer ratings and comments on mine due to how the algorithm works. I attribute this partially to the “sacrifice” theme – so many of the submissions involved killing people or animals that it felt kinda weird to browse them when small children were around (which is pretty often in my house).

But anyway, like last time, I went through the comments received and tried to pick out recurring themes. The following are the different feedback points, ordered by how often they came up (keeping in mind that quite a few of the comments touched on multiple areas):

Positive Feedback

  • Compliments on the visuals: Specifically mentioning the art style (9 times), it being cute / adorable / charming (9 times), and having nice animation (8 times). I combined these into a single item since they all seemed related, but it was by far the most common thing that came up.
  • Use of Godot Engine (7 times). Some just mentioned Godot in general, but many of these were in relation to picking up a new engine and making something with it quickly.
  • Kid friendly (4 times). All of these seemed like speculation that it would be great for kids, or hoping that kids would enjoy it (as opposed to any mention of actual children playing it).
  • Fun (3 times). I was almost surprised to hear this one due to how simplistic the whole game ended up being overall, but it did come up a few times.
  • Polished (2 times). This also surprised me a little, but on the other hand, no one mentioned running into any bugs and I guess I did have that whole “polishing phase” thing I tried to do. (Though this also may have been indirectly related to the visuals.)

Room for Improvement

  • Needs music (2 times). While I hastily slapped in some sound effects, unfortunately I didn’t have time to find or put in any actual music. Definitely something I’d like to improve on in future jams.

  • Could be longer (1 time). While game jam games do tend to be short, I think this submission was extra short (something I didn’t realize the full extent of until it was nearly finished and I could play it through from beginning to end). It has maybe 2 or 3 minutes of gameplay, tops.

  • Uncomfortable controls (1 time). This one was interesting, and not really something I’d thought about: I’d set it up with the arrow keys to move and the space bar to pick things up, but you need to switch hands this way to transition from using the mouse and keyboard. This may be part of why some games use the W, A, S, and D keys for directional navigation, which would avoid this issue.

    • Side note: I personally find the WASD controls completely unusable due to using a non-standard Dvorak keyboard where those letters are scattered all over the place, but in Godot Engine it would be trivial to have both the arrow keys and WASD work as navigation options. So that’s something to consider for next time.
  • Animation is backwards (1 time). I was actually weirdly relieved that I wasn’t the only one who noticed this! Though also a little surprised that it only came up once in the feedback.

Specific Suggestions

Mixed in with all of the above, there were a few specific suggestions for improvement:

  • Adjusting the starting position. One commenter suggested that due to the starting position, the player will be inclined to go to the dungeon first, since it’s often natural to move from left to right… But in order to get anywhere in the dungeon, you need to pick up the gems from the castle, which are in the other direction. This is a good point… although unless you get really lucky picking up the correct gems on the first try, it’ll still be necessary to visit the dungeon and castle more than once. That overall design (and inevitable need to backtrack) is something I’ll probably want to think about more (and avoid if possible) in future games.
  • Let the player carry the unicorn eggs back to the castle. The way it was set up, collecting an egg instantly and inexplicably transported it back to the castle… Which was a bit at odds with the way picking up gems worked (those would go to your inventory). So having the player pick up the eggs the same way as the gems and carry them back to the castle would probably make things feel more consistent. (And shouldn’t create the need for any unpleasant inventory-juggling, since sacrificing the gem in order to get to each egg would free up a spot in your inventory.)

In-Person Kid Feedback

Last but not least, I had the pleasure of watching my daughters play it after the jam and seeing how they reacted to it. Here are a few notes and observations on how that went:

  • Gameplay length: The easy 2-3 minutes of gameplay for me (and probably most other adults) ended up being a solid 10 minutes for my 7 year old, and 15 minutes for my 4 year old. They would take their time running back and forth between the caves and the castle for a few gems at a time rather than worrying about maximizing efficiency. I was also surprised at how they found other ways to play with it, like making the unicorn sprite stop to randomly “kick” things, or make it flip directions (up and down) rapidly and then laugh at how this made its tail look like a beard.
  • Egg hatching: They wanted to see the eggs actually hatch at the end, rather than just returning to the castle and finding them already hatched. I had briefly considered trying to do something like this, but due to the time constraints took the easier approach (and even then barely finished the feature). But it’s something that would be a nice addition if time weren’t an issue.
  • iPad Version: They wanted one of these. Also prohibitive in the time allotted for the game jam, although it may be something to look into in the future.

Final Scores

At the end of the rating period, the final results were released on December 31st. Out of 1,750 games submitted to the jam, here was how mine did:

A screenshot showing the final scores my submission for Ludum Dare #43 received in all the different voting categories.
Final scores received in all the categories.

Like last time, most of the scores were pretty middle of the road. Although one exception was the graphics category – this one did pretty well, with an average rating of 4.239 which was good enough for 140th place overall.

Comparisons with Last Time

Now that I’ve completed submissions (and received scores) for two Ludum Dare game jams, it’s possible to look at the data points and compare them. Here is a beautiful chart showing how these most recent scores compared to last time:

A bar chart showing a comparison between the ratings my submissions received in Ludum Dare #42 vs. Ludum Dare #43.
Comparison of ratings received: this Ludum Dare vs. my previous one.

So most of the categories showed improvements – and in the case of Graphics, Humor, and Mood, pretty significant improvements. Innovation went down slightly, which seems reasonable – last time I tried to come up with a novel puzzle mechanic, whereas this time the only mechanics were walking around on a map and picking up gems.

The only category which showed a pretty significant decrease compared to last time was Theme. Which also makes total sense. The theme was “sacrifices must be made” and I made a game full of unicorns and rainbows, based around a mechanic that probably feels more like trading than sacrificing.

This next chart is exactly the same, but looks at the rankings instead of the ratings, and then converts it to a percentage… So for instance, that ranking of 140th place out of 1750 for graphics would translate to a 92%. Here’s how those percentages looked for all the categories:

A bar chart showing a comparison of the rankings my submissions achieved in Ludum Dare #42 vs. Ludum Dare #43.
Comparison of rankings in each category: this Ludum Dare vs. my previous one.

All in all, I feel pretty good about these scores. They weren’t the greatest, of course, but they show a pretty clear improvement over last time. Plus, they leave room for more improvement in the future.

Lessons Learned

So as far as the overall lessons learned from this jam? While I think it went pretty well in general, and better than last time in a lot of ways, there were some things that went better than others.

What went really well?

  • The phase-based development strategy. This was helpful for iteratively building up the game… But I think it also helped create a more relaxed atmosphere, since it lowered the chance of completely not finishing anything.
  • Using Godot Engine. Everything about this went amazingly well, and I have nothing but warm fuzzy feelings about this engine. I’m pretty much 100% sold on continuing to use it for any future jams I participate in. (As well as possibly other projects!)

What went sort of okay?

  • Making all of my own graphics. This was fun, and I think it paid off based on the ratings and comments… But it was an enormous time sink, taking up almost half of the total time spent on the jam. For future jams, I might try to figure out ways to be faster or more efficient about it.
  • Keeping the scope in check. This mostly went well due to the iterative approach and intentionally simple kid-friendly design… The only piece that seemed a bit excessive mechanics-wise was the inventory system. It all worked out this time in terms of finishing it, but in future jams I should be wary of including features like this.
  • Overall time usage and life balance. During the jam, it didn’t feel like I was completely overdoing it (i.e. not sleeping, forgetting to eat, etc.)… It probably helped having a supportive spouse and two kids who were more excited than usual about what I was making. But looking at the total time usage afterward, it seemed pretty excessive. Next time I think I’d make more of an effort to take breaks for a few hours here and there.

What went kind of badly?

  • The overly simplistic game design. This is probably the part of the whole submission that I feel most ambivalent about… As fun as it was watching my kids play and enjoy this little game, I ended up feeling like it was just too simple. Next time, I think I would want to focus first on making something that’s mechanically interesting enough to be enjoyed by an older audience… And then consider ways to make it more accessible to younger kids (if possible) as a secondary concern.
  • The short gameplay length and general lack of content. In making this game, I had a few small revelations about about inventory-based RPG fetch quests more generally… Firstly, they must require a massive amount of developer effort and content (as far as the number of maps / size of the world / etc.) to rack up any appreciable amount of gameplay time. And secondly, they aren’t really that fun or interesting all by themselves. For future games, I think I would want to explore other kinds of mechanics.


So what’s next? Last time around, making the Ludum Dare game inspired me to try fully finishing and releasing a small mobile game based around a similar premise. (That game is still in progress, and I plan to follow through and finish it – you check out the latest progress update here.)

As for this game specifically, I don’t have any immediate plans to expand on Unicorn Rescue further any time soon. It was just a great exercise in learning Godot Engine, and enjoying a game jam in the process. Further down the road, I might see about polishing it up enough to release on iOS and Android – I’ve been considering the possibility of moving away from SpriteKit in favor of Godot Engine, so that could be a valuable experiment in releasing a small game cross-platform. But no concrete plans for it at this time.

Anyway, stay tuned for the next dev blog update, which will showcase the latest progress on my mobile game mentioned above. (Lots of progress since the last update!) In the meantime, feel free to check out my Twitter for smaller updates and/or to follow. And if you made it this far, thanks for reading!