Phase Shift: Ludum Dare 30 Postmortem


This past weekend’s Ludum Dare game jam was my second (and the third overall game jam I’ve participated in); here’s my entry if you want to play it yourself.

My first thought was to take the theme–“Connected Worlds”–literally, and make a game around multiple planets–perhaps a simple 4X game or something based on orbits–but that felt a little too obvious. (In retrospect this was a good call, since there were quite a few games along those lines.)

My second idea was to do an action game where you can shift between different dimensions to avoid obstacles, from a top-down perspective using abstract, minimalist graphics (mainly to get around my lack of art ability). To add some tension, there would be an explosion you’d have to escape before it reached you. This felt a little more promising, so I decided to go with it.

I’d never done an action-oriented game for a game jam before; my previous game jam entries had been an adventure game and a puzzle game. So, how’d it go? Well…

What Went Right

  • Graphics: I experimented with a variety of colors and effects to make the minimalist visuals look pleasing, finally settling on the white/blue scheme for the twin dimensions because it made them both easy to see at once without clashing too much (especially during the animated transitions). I added a bloom effect to the scene for a little color, and then as a final touch put in a perspective camera with the two dimensions on different z planes; the parallax helps convey the separation between the active dimension and the inactive one.
  • Audio: When you’ve got almost no talent in music and sound production, it helps to have great tools. Thanks to the magic of Ableton Live and NI Komplete, I managed to put together some barely-passable sounding pulsing techno beats in just under an hour. The sound effects (all four of them) are just little musical flourishes written in Ableton and tweaked a bit in Adobe Audition.
  • Procedural level “design”: The procedural level generation algorithm is incredibly, ridiculously simple, but with some tweaking it managed to produce results I’m quite happy with. I tested and refined it quite a bit and am happy that it produces difficult but winnable levels at least most of the time.

What Went Wrong

  • C++/D3D: Every time I do a game jam I contemplate using higher-level tools but always end up going with what I’m famliar with. C++ and D3D are what I spend most of my time with at work, but it’s become increasingly clear that they’re greatly limiting my reach (to Windows only) and how much I can get done in a couple days. For my next LD, I’ll catch up with the rest of the world and use something like Unity. I’d like to never have to debug a GPU crash during a game jam again.
  • Inadequate framework code: Related to the above, but I hadn’t even implemented anything to maintain a consistent update rate, nor any support for postprocess shaders like the bloom–both things that took up time I could have used making the game better.
  • Focus: My eternal bugbear with these events. It is really, intensely difficult for me to stay focused on something like this for 48 hours straight. (For example, this distracted me for about an hour at one point.) It’s slightly disheartening to consider how much more I could accomplish if I could make better use of the limited time I have in game jams. Something to work on, I suppose…

I’m fairly satisfied with what I came up with, even though there are so many things I could have done better. Can’t wait for the next LD!

9V Battery Discharge Experiment

During a break on working on my Ludum Dare 30 entry (which I’ll post about a bit later), I conducted this little experiment:

You might want to watch it in HD on Youtube. The changes are subtle!

It’s a timelapse through a macro lens of a 9V battery (with the outer skin removed) being discharged for 20-25 minutes or so. I’d have liked to run it longer but my camera ran out of power! I discharged it the rest of the way off-camera and it looks rather dramatically different from a new one.

Note that only cheap, generic 9V batteries look like this on the inside! Brand-name batteries tend to be constructed of a set of 6 roughly AAAA-sized cylindrical cells. Which is kind of neat in its own right, but doesn’t give you a nifty view of what’s going on inside like these cheap ones do. 🙂

Week 1: μShooter

The Microview is a tiny Arduino-compatible device with a built-in OLED screen. It’s really nifty, and I’ve been looking forward to mine ever since backing the Kickstarter earlier this year. The other day it finally arrived, so as my first weekly project, I’ve made a simple game on it: a minimalist Gradius-style side-scrolling shooter.

The source code (an Arduino sketch) is available here! It expects an analog input (just one axis) on the Microview’s analog pin 5 and a button input (active HIGH) on digital pin 0. You could easily switch it to use two buttons for the movement instead of a joystick (it doesn’t even use proportional input). Here it is on a breadboard:

I love that the joystick alone is bigger than the μView.


  • Two types of enemies, a ‘diver’ than speeds toward you at high speed and a ‘tracker’ that moves a little slower but veers toward you when it gets close.
  • High score kept in EEPROM so it persists between runs.
  • No timing whatsoever, aside from a delay(10) in the main loop. Framerate is surprisingly consistent (and pretty good!) despite that. I’m guessing updating the OLED is the bottleneck.
  • Fills up less than half of available program memory and only ~800bytes of SRAM on the microcontroller, so there’s plenty of space for new features. 🙂
  • Text-based graphics in glorious 1-bit color!
  • Poorly organized, barely commented source code and bugs, bugs, bugs!

This was a quick one–about 3-4 hours of effort (including fixing the Microview). I’ll be participating in Ludum Dare 30 over the weekend, so I’ll hopefully have a second game to post by Sunday night! (Not on the μView though. It’d make it rather hard for people to review…)

One Project a Week

Lately I’ve often found myself sitting at my desk at home, staring at my computer screen, trying to decide between a bunch of different hobby projects I’ve been meaning to pursue and ending up doing nothing.

So, I’m going to try something new: every week I’m going to work on a small, self-contained creative project, and post about it on here when I’m done. I’m inspired here by Ramil Ismail’s Game A Week concept, but with somewhat looser rules, and a more general goal: to head off the creative paralysis that comes from too many ideas and not enough time.

The projects will be:

  • Reasonably self-contained, in a way that I can consider each one ‘done’ by the end of just one week.
  • Creative in nature: games, code, engineering, writing, music. (Edge cases I’m less sure about: game modding, lego models.)
  • Different every week. If I want to come back to a project, it’ll be separate from the new one that week.
  • Unrelated to my day job; done entirely in my spare time.
  • Posted on here in some form by every Sunday night.
  • Really, really rough, given the limited time I have between work and other obligations, and given that many (most) of the projects will be in areas I’m new to and/or not very good at. Seriously, most of this stuff will be terrible. But it will all be a learning experience!

Posting the projects here will be mostly for my own benefit; although I’m always working on something in my spare time, I rarely get up the courage to share any of it. I think doing so will give me a useful deadline and some extra motivation to make these things as solid as I can in the limited time I’ll have.

That said, maybe I’ll even come up with something of interest to other people. Let’s see how this goes!