Ludum Dare 37 Postmortem: Orb Protector

Every time I do Ludum Dare, the “competition” which gives developers 48 (or 72) hours to develop a game, I have a totally different experience. When I did the 34th and 36th editions, I decided to go the jam route, even though I was working solo. This gave me that pivotal extra 24 hours. The first time I did a top-down racing game, and the second time I did a pure text game.

For the 37th edition, I was planning long and far ahead to make a retro-styled platformer of some description using Unity, and to enter the compo (48 hours). This doesn’t mean I did much to lead up to it, though. More on that later.

I ended up with an action platformer where you protect orbs from enemies and can shoot them with a crossbow. Technically, I achieved what I set out to create, albeit in a stripped-down fashion.

You can play Orb Protector here or check out the postmortem after the break.


What Went Right

Design First

I started with a plan, and by golly gee I followed it. Living in the EST time zone, the jam started at 9pm, which is an awkward thing because it only gives me a couple hours at most (hey, I’m old, I need to get to bed early) to do anything on the first day (Friday). I wouldn’t let myself go to bed until I had a solid, workable idea.

Right off the bat, the theme triggered four ideas. I eliminated one of them based on scope, and the other three were awful. I racked my brains for another hour until I hit the proverbial light-bulb, whereupon this happened.


This is, more or less, the idea as it was eventually implemented. Forcing myself to do this was a great idea. I even threw together a preliminary asset list based on these thoughts before heading off to bed.

Technical Implementation Second

My proudest moment of the jam was having a functional game with boxes and lines before adding any other assets. It took most of the first day and almost half of the second day (more on that in “What Went Wrong”) but there’s something about seeing the ideas in play that allows you to think more critically about the design elements. Without any distracting graphics, you can see which parts are fun and which parts aren’t.

When the “bullets” hit the wall and didn’t disappear, I was intrigued by the idea of them sticking, so I made a script to stick them to the wall. I think it ended up pretty cool. I got the movement, reloading, shooting, spawning enemies, killing enemies, and so on working, tweaking as I went, conceptualizing what everything would look like when the art came along.

On the same note of the technical implementation, I’m proud that I kept to my reusable, readable code standards in spite of the time pressure up until the very end. There are few hacks, and I added most of them in the last few hours of the jam to fix some weirdness. Most of the code I wrote will be reusable as framework for my next game jam, or any other games.

Amazing Tools and Pre-Jam Experimentation

Unity was great as always. The 2D Platformer Controller by Markus Staib was an absolute godsend of a Unity package. I modified the code a lot, but it gave me a really good basis for excellent maneuverability and player control.

Aseprite has never steered me wrong, even with my lacking pixel slinger skills. Exporting from there to Tiled then into the project with Tiled2Unity is smooth and, although it has some kinks, does a lot of the heavy lifting quickly.

I used all of these tools to make a little thing before the jam started, which helped me rediscover a lot of things. I should have spent more time with this (see bits about animation and audio in Unity below) but I would have been completely lost if I’d jumped into the jam cold.

What Went Wrong

Freaking Out About the Idea

I couldn’t sleep much Friday night because I kept thinking the idea wouldn’t work, that it would have to be tweaked to be top-down or 3D, otherwise the game would never be any fun. I shouldn’t have come to these conclusions so quickly without going forward with the idea. Be confident in your idea. Not your first idea, mind you, but the one that strikes you as “hey, this is the one!”

Changing course should happen early, but know that game jams aren’t meant to create gems every time. It’s a sandbox where failure is not only possible but encouraged. If the game isn’t fun, if it’s completely unsalvageable, well hey – it’s a game. It’s done. Now you can eliminate a possibility that doesn’t work, and learn from why it doesn’t work.

Too Long to Technical Implementation, or No Such Thing as Small Scope

This issue was a combination of two things: having too grand a plan and not having enough of a framework from the start. Next Ludum Dare (assuming I do Unity again), I’ll have a lot more basic framework stuff to work with.

Without assets to implement, I didn’t have any framework for animation or audio, and I wasn’t handling all the mechanics correctly. This was a mistake because I ran into snags with all of these things in the final six hours of the jam. I should have modeled the final requirements (sloped surfaces, ladders) more accurately with boxes and lines before calling the technical development “finished,” and I should have put in temporary bits for audio and animation to make sure those technical areas were covered.

As the jam progressed, I had to drop features. Luckily, I was smart enough to develop the core before anything else, so I didn’t have to remove anything that I’d already implemented, but there were things I would have liked to have that I couldn’t:

  • Ammo limitations and static ammo box for refilling
  • Enemies with actual weapons (the swords are fake *gasp*)
  • Multiple enemy types
  • Melee weapons
  • More ranged weapon types
  • Player health
  • Other droppables by enemies etc.

Of course, that doesn’t mean I can’t add these in a future version. 🙂

On a related note…

Not Enough Time for Assets

I literally threw together the wave complete, game over, reload, and pickup sounds plus the enemy and player death animations in the last hour. There wasn’t any animation at all until three hours before the jam ended. There wasn’t any player/enemy art until six hours before it ended (except the crossbow).

If I’d finished the technical stuff earlier and didn’t have to go back to it in such a large degree, there would have been more time for the assets. But when I started constructing the levels from tiles and experienced issues with slopes and ladders, I had to put the art on hold. And when I needed to implement audio and animation, I had to remember all the quirks of Unity that I’d long forgotten, which I should have experimented with before the jam so I didn’t have to run around in circles during the crammed hours of Ludum Dare.

Also, I made the music early on in one pass per track, and I should have spent more time on those, maybe even chosen NES or Sega Genesis as the basis and had them fit more nicely together.


At the end of it all, I felt like the 48 hours hadn’t happened at all, that I was going to sleep on Friday night and the whole thing had been a vivid hallucination. Since the game exists, I guess that isn’t true.

Now that I know what the 48 hour limit feels like, I can prepare for Ludum Dare 38’s compo. The framework code I’ve put together from this jam should be a huge boost.

As for any advice for those wishing to enter Ludum Dare:

  1. Finish all technical stuff early: game flow, core mechanics, additional mechanics, and temporary animations, sound effects, and music. Make a complete and playable (maybe even releasable) boxes and lines prototype with zero assets. If you have an audience, release that version to them and get feedback on pure gameplay.
  2. Focus. Do design, code, art, sound, music, animation, or testing, but do not jump back and forth. Set aside multi-hour chunks where you only do one thing. You get 48 (or 72) hours. Allocate them.
  3. Leave at least six hours for polish. This includes technical testing, refining assets, and adjusting game values to ensure maximum balance and fun.
  4. Spend time getting good default controls. Don’t put too much effort into a readme. People won’t read – they’ll download, launch, and play your game. Even though Unity has a nice launcher where they can see and customize the controls, they won’t. (Apologies if this sounds cynical but it’s true. >_>)
  5. Package your game in a zipped folder containing a folder containing all your game stuff. The extra top-level folder makes it easier for people to drop it into a folder where they’ve extracted other stuff. Include a shortcut or link to your Ludum Dare page so they can rate your game even if they closed out of the page, and don’t forget all your social media links!
  6. Do the 72-hour version. The compo is for lunatics. xD

Leave a Reply