Postmortem: Space Battle Zero

Three months after my first Ludum Dare, I came back ready for more in LD 43. As I guessed in my last postmortem, I decided against the restrictive compo this time (48 hours, everything from scratch) to take advantage of the more relaxed rules of the jam (72 hours, 3rd party assets allowed). This freed me up to focus on design and programming instead of asset creation. The theme this time: “Sacrifices must be made,” and my entry: Space Battle Zero.

Anyway, I’m going to try something a bit different with this postmortem. Instead of attempting to frame it in terms of what went well (or not-so-well) on the development side, I’ll focus more on following the thread of design through the process. Start with breaking down the original concept, then cover how the design evolved during prototyping and the process of paring down the scope to meet the deadline, while maintaining as much of the vision as possible. And finally, I’ll go over what I’d change about the game if I were to continue developing the idea knowing what I know now.

Continue reading

Tales from the Back Burner: Stack

Sometimes we learn more from our failures than our successes. In this series, we’ll take a look at some of our projects that didn’t pan out, and see what lessons can still be gleaned from them.

What was it?

Stack could be pitched as an innovative brawler-style free-for-all about hoarding, hauling, and hurling super-powered stacks of blocks. Think Super Smash Bros. crossed with NES pariah Bible Adventures. Wait, where are you going? I swear it’s better than it sounds!

The setting: a 2d platform-littered arena

The cast: 2-4 players vying for control of a limited supply of valuable blocks

The objective: collect stacks of blocks and carry them back to your goal. Meanwhile your opponents will do anything in their power to collect them first. Luckily, blocks are good for more than just scoring points – many have powerful offensive capabilities, like the rocket and flame blocks. Each match is a chaotic struggle between collecting as many blocks as possible, and expending blocks to prevent your opponents from doing the same.

How’s it play?

Players scramble around the stage, picking up blocks and carrying them in a large stack over their heads. As a stack grows, it becomes more unwieldy, and blocks at the top are at risk of falling off if the player runs into low platforms (not to mention providing a bigger target for attacks from other players). Individual blocks can be tossed in to a goal for individual points – even from far across the stage, if nothing else gets in the way – but running into the goal with an entire stack earns the player a big “touchdown” bonus. These differing incentives (large stack = lots of points, small stack = agile and less vulnerable to attack or mistake) provide plenty of opportunity to develop and refine strategies, react to counter-strategies, and develop personal mastery of the game.

The blocks themselves are a blank slate on which to paint an array of surprising and delightful gameplay concepts. It starts simply: a vanilla block is worth one point; a gold block is worth many. But throw a fire block at an opponent and they’ll burst into flames, periodically shedding blocks off their stack until the fire is put out. A direct hit from a rocket block will blast the entire stack out of an enemy’s hands. Hit a seed block with a water block, and it’ll suddenly grow into a vine that provides a convenient ladder to higher platforms. A well-lobbed milk bottle block will drench an opponent, attracting a swarm of hissing cat blocks, tying them up and causing them to drop their stack (cat blocks can also be picked up and thrown, but they don’t like it and will try to escape!).

What went wrong?

Stack was incredibly fun to design and showed a reasonable amount of promise as a game concept. The reason I decided not to move forward with it had little to do with the idea and everything to do with competitive analysis. Couch multiplayer games are already a well-served market segment. Even putting aside AAA heavy hitters like Smash Bros., Steam is littered with quality indie offerings like Towerfall, Ultimate Chicken Horse, and countless others.

What’s more, even with full confidence in my ability to compete on quality, the fact remains that the segment itself is very challenging in terms of market size. Titles cost just as much to bring to market, but in all but a few cases only one person has to buy the game in a group of friends for everyone to enjoy it. A few more might shell out based on an enjoyable experience at a game night, but most players would be happy with a few fun play sessions and quick to move on to whatever the new, exciting release was. This means these games tend to have a short tail.


  • An interesting idea doesn’t necessarily mean a viable product
  • Competitive analysis is a critical component of the decision-making process. With limited bandwidth to work on ideas it’s important to dedicate time only to the ones that offer the best chance of success
  • Study the size of a potential market. Lots of competition doesn’t always imply a profitable segment. Red oceans are red from the blood of competitors, not customers after all

Postmortem: Introvert vs. Extrovert

On an unexpectedly-obligation-free weekend in August, I decided to take a crack at my first Ludum Dare. I’m no stranger to game jams, but this was a different beast altogether. Taking part in the Compo meant I would be responsible for hand-creating 100% of the code and assets in my game. It was going to be a busy 48 hours.

From my vantage point in Central Europe, Ludum Dare 42 kicked off on 11 August 2018 at 12:00 AM. I stayed up to catch the announcement of the theme – running out of space – and… went to bed. The opportunity to sleep on my idea and wake up refreshed and ready to be productive gave me a huge boost that a few dreary-eyed hours of programming would not have. And after two solid days of work – with healthy breaks for rest, food and sleep – I ended up with a nice little entry.

Continue reading

Voyager 2.0: from drawing board to device (in under 2 months)

About 2½ years ago, I started a new job that limited how much I could work on independent projects (let me tell you, not a fan of policies like this). Still, rules are rules and Voyager, along with my other projects, was put on ice. It was in fine shape at the time, so there didn’t seem to be any harm in leaving it in cruise control.

About 2½ months ago, everything had changed. I was my own boss and beginning the Latin American leg of our journey. BuildDown had shipped, other projects still too green to talk about, and I was looking for a quick win. Voyager was an obvious choice. Problems that had trickled in while I was hands-off grew larger and more serious. The solutions were relatively straightforward… they just needed doing. There were also neat ideas I’d been sitting on for years that I regretted not having in there. A little bit of love would go a long way, so my course was clear: I was going to turn around an update to Voyager, and I was going to do it fast.

But what were those problems anyway, and where did they come from?

Continue reading

BuildDown, Monetized

Part 2 of a discussion of game design decisions made for BuildDown. Part 1 is here.

BuildDown is a simple, action-oriented game, which made it somewhat challenging to figure out how to monetize. There are no levels, so I can’t exactly sell more content. The mechanics are not friendly to puzzles to force such a content model, either. Instead, I had to weigh the various popular approaches to see which played best to the strengths of the game.
Continue reading

BuildDown, Redesigned

Part 1 of a discussion of game design decisions made for BuildDown. Part 2 is here.

One of the first projects I wanted to tackle on the road was to revisit BuildDown, the first game I ever released. I thought it would be relatively easy to rewrite in Unity and have access to the broader mobile market. But there was another reason I wanted to revisit it. The original was something I was proud of, but I always felt like I had left something on the table. Rebuilding it on a new platform was an opportunity to reinvent it, both in game design and software architecture, and to exercise and refine those muscles for future projects.

The basic premise of the game is to merge blocks of the same color into new blocks, which can in turn be merged until they reach an inert state and cannot be merged any further.


Those inert blocks must be lined up along the bottom row to make them disappear.


There’s something I find really compelling about this core mechanic. It combines the pleasure of addictive and soothing actions (like popping bubble wrap) with the basic desire for organizing or tidying up. Creating order from chaos, satisfaction with a job well-done, and things fitting perfectly into things.

Continue reading

GGJ2014: Unnatural Disaster

Global Game Jam 2014. It’s late Saturday night, on the eve of our home stretch. My team was well ahead of schedule. We’d gone with an unusual project, a card game, so we’d been playtesting in no time, working well together all weekend and making great progress. Many hands make light work, and with ten people on our team, work was plenty light.

But with everything going so smoothly, it was almost as if I was missing out on the real jam experience. Looking around at the other teams struggling to finish, I almost felt… guilty. So, I decided to up the challenge for myself a bit. As the clock rolled over midnight – less than a day to go – I popped open Unity and started working on a second game, this time on my own.

I called the project Unnatural Disaster.

Continue reading


A while back I had an idea for a game about launching rockets. Way out of my comfort zone, right? Basically it would be a blend of the engineering and rocket building of Kerbal Space Program, but with a greater emphasis on moment-to-moment skill instead of meticulous planning. I took about a day to prototype the idea, and while I’m not sure if I’m going to do something with it in the future, I did find myself spending a lot more time playing with it than I did building it!

[unfortunately, the Unity Webplayer has been sunsetted, so this demo is no longer available]

Directions: Hold mouse button down to thrust, release to separate stage. Hold down A or D to steer left or right. Reset with Esc.

While the implementation was extremely basic, it was effective at proving the idea and teaching me some interesting things that might be useful later.

Continue reading

The Evolution of Aiming in Voyager

Voyager is a game is about science. Not just in the “you’re launching a space probe” sense, but in that the core loop is about experimentation. Make a hypothesis (I need to launch at about 45°), perform the test (3, 2, 1… LIFTOFF), observe the result (missed wide right!), refine the hypothesis (let’s try 30° next time). It took a long time to figure out how to make this process feel natural and intuitive.

In order for it to work, the game needed three things:

  • Feedback: I need to be able to tell how my current aim differs from my last aim.
  • Determinability: If I do the same thing two different times, I should get the same result both times.
  • Precision: I should be able to execute the move as I intended. If I try to launch at an angle of 19°, I should not accidentally launch at 20° or 18° instead.

Solving feedback was the easiest part. The aiming mechanism is very explicit, with an arrow showing the direction and relative power the probe will launch in. Previous launches are shown as dimmer arrows, so the player can easily line up a similar shot and tell how their new one differs. It also straight up tells the user the angle and power of their shot in text, so the values can be written down and reused later. And finally, in-flight probes leave a trail of breadcrumbs, so it’s easy to tell when and how a trajectory diverges from an older one.

Aiming Launch

So much feedback

Continue reading

Global Game Jam 2015

This year was my second time participating in the Global Game Jam, and my third 48-hour jam overall. Along that storied history, I’ve learned a few things about how to be an effective and successful (defined here as ending the jam with a playable prototype that isn’t embarrassing for something made in a weekend) jammer. Here are some of those learnings, distilled into handy, categorized-tip form.

Continue reading