Thunderbeam Development Access

    In 2011, my friends James Curry, Scott Lee and I decided to set an open-ended goal for ourselves to create a videogame in the graphic-adventure style, but incorporating innovations we had seen in modern independent games.  After a few months of experimentation, we determined the project would be a good opportunity to collaborate with friends who were visual artists and musicians, and we decided to fundraise in order to compensate them (one of the best things to come out of this project is the fantastic original soundtrack by The Octopus Project). It was still in the early-days of game projects on Kickstarter, and we were untested as game developers, so we were told to set our fundraising target relatively low. We’d still have to continue working at our day jobs, developing the game in our spare time in order to save money. James  and Scott would focus on building our game engine, and I would produce and art direct the game, while we shared high-level design and scripting tasks. Our early design documents were ambitious, but we estimated we’d have a shippable version of the game completed within two years. It's now a good deal later than we thought, but here's a look at what we have been building.

    In Derek Yu’s book detailing the creation of his game, Spelunky, he lists 15 guideposts important to completing and shipping an independently made game. In retrospect I see that we failed to follow most of those rules. In regard to our game engine and tools, we failed to heed Yu’s rule, “don’t roll [create] your own tech if you don’t have to.” Unity wasn't as robust tool for creating 2D games back in 2011, so using it wasn’t an attractive option. Other available game engines of the day either didn’t support our development machines or our distribution target (in 2011 we were really psyched to put out an adventure clicker on the iPad), so we became heavily invested in a game engine we wrote ourselves, as well as in our own tools for level design. This became particularly problematic as we found that Apple’s development tools and platform are fast-moving targets: portions of our codebase became obsolete with each new update, and large amounts of rework (without significant new features) kept us perpetually treading water to keep afloat.  

    The project was also affected by the unpredictable events that are simply part of life: Family members passed, babies were born, jobs were lost or more demanding jobs were gained. We ended up hiring contract programmers to help work on the engine, and while each new programmer had their own ideas about which supporting technology stacks to use, each has added important and great features and touches to the game, especially Paul Slocum, who first implemented our scripting system, and Rusty Moyher, who has added a huge amount of hooks to that system, as well as helped reign-in what was a hopelessly over-scoped fiasco of a project.

    With the benefit of hindsight, I see so many things we could have done differently, but I am also proud of this strange thing we are still continuing to make. We have made something interesting in this almost SCUMM-like scriptable adventure game engine, and we've decided to expose this scripting layer to players in case any enterprising hackers would like to experiment with it. It's our hope that we may find a community of folks to join us in our affectionate tinkering with this long-incubating oddity. 


Files 573 MB
Apr 01, 2019

Get Thunderbeam Development Access (Mac)

Buy Now$7.00 USD or more