Spheres Postmortem

Posted by
May 19th, 2013 7:38 pm

This was my fourth time doing Ludum Dare, and I’ve written a brief postmortem about how it went.  Hope people enjoy the game.


Things that went right:


Although I didn’t like the theme at first, it ended up working really well with my skill set.  I’m pretty bad at making art, and the theme required minimal art assets.  The final game ended up with only two sprites.  I’m considerably more confident with music, but the design I came up with for the theme also required minimal art assets.  One .wav file with a single note produces the whole soundtrack, with the player’s help.  The creativity this allows the player is one of the most important aspects of the game.

Lots of programming/design time:

With little need for art/sound assets, I figured I’d end up with a surplus of time for level design.  This was the main reason I decided to do a game with static levels in the first place; I wouldn’t have had the time for that if I were making more sprites/music.  This didn’t quite end up being the case, as programming took longer than I expected.  Still, this was a positive overall.  It let me fix most bugs and increased overall polish.

Quickly implementing key features:

Though I spent the majority of the competition programming, most of the ‘big stuff’ went pretty quickly.  The launchers, saving/loading levels, and the sound logic went smoothly thanks to past experience with XNA.  As noted below, physics bugs (and a couple editor problems) were the only real time-consuming issues.

Overlaps in gameplay/design:

When making a game on such a short timeframe, it’s important to get as much ‘bang for your buck’ with your time.  That’s one of the things I like about music games like this; the audio, game design, and programming are all tightly linked.  I didn’t have to spend a bunch of time making music tracks, because that was what level design was.  I could iterate on all three at the same time.

The same thing applies to Free Play mode.  I made a simple editor for myself, which was trivial to expose to the player.  This lets the player make his own puzzles/music freely, and it didn’t cost me much time to add.


Things that went wrong:

Physics bugs:

As many commenters have noted, there are some noticeable physics bugs in the game; the worst being balls getting stuck in platforms.  These bugs are extra annoying in my game because they can end up producing notes extremely frequently, producing really harsh sound.  I spent a significant amount of time during the competition trying to fix these bugs and lessen the annoyance when they do occur.  This did help in the end, but it was pretty demoralizing focusing on the issue so much and not fully fixing it.

‘Wasted’ time:

I spent more time not working on the game over the weekend than I planned going into it.  A surprise visit from a friend from out of town took up a few hours.  It was worth it, but there would have been many more levels if that didn’t happen.


Although the problem has been fixed, my initial release had a couple issues.  I didn’t include the XNA Redistributable so the game crashed for some, and others were unhappy that it required an install.  I’ve had similar issues in the past, but at least I did a better job fixing them this time.

Hardware issues:

One of my monitors failed comically early in the competition.  I spent some time trying to fix it, couldn’t, and was left with a sub-optimal setup.   Not a huge deal, but I’m sure it had some effect on my productivity.



I’m really happy with the result of this Ludum Dare.  It’s a much stronger game than my previous attempts.  There are a few things I could have done differently that would have led to a better product, but those are just further learning experiences.  I’ve definitely improved my craft and look forward to LD27!

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]