Well this is a fine Howdy-dooo! Spacecar, HAMMBall, and the Return To Project GOA

Why do I even keep this blag around if I never update it, huh?

Oceans of Glass Pickguard for Kyle Hussey's Guitar

So this has been a long time coming. Project GOA got a tad stale and I decided to make a racecar roguelike that no one can play, after that I dove into Unity 3D to make a pinball roguelike that got tremendously bloated (but was an entirely refreshing experience), and now I’m coming back to totally revamp Project GOA into a gravity Left 4 Dead-like. Long story short: I just try to do all of the too many things.


Two years ago, GOA was going pretty well. I had jumped on the survival game bandwagon super hard and it was starting to cost me. I had wanted to make a Don’t Starve experience on miniature planets crafted from modeling clay and crystals. The design was pretty solid, but my experience was not quite there for something so complex. Especially in something like the Blender Game Engine. In order to make object in the BGE perform actions and calculations you have to connect little input nodes into other nodes that have outputs such as “move in a direction” or “create this new object”. This is done for pretty much everything unless you know something about python scripting – which I just didn’t feel like doing. GOA was becoming a little stale in my head, so I decided to put the project on hold for the time being.

At PAX East 2014 I got to meet up with the voices of the Gamers With Jobs podcast along with some friends. During dinner I jokingly mentioned an idea for a racecar roguelike, something where the racetrack would continuously generate randomness in front of the player, and a few eyes went crazy wide at the thought. I was really pumped for the idea and upon my return built the prototype in two weeks, only to find that one of the scripts I was using for the wheels of the car wouldn’t export with the rest of the project. Every time anyone tried to play the exported game, the wheels would fall off and drift into space. Here’s an overzealous video of the only way you can experience the prototype: on my computer. Getting that script to export remains a mystery.

So I had finished something! This felt good. And not only that, but it was something some of my friends just couldn’t get enough of.  It had a kind of Trackmania meets Dogfighter vibe, and we would race for hours. But something about the whole project just didn’t feel like it was quite there. As much as I enjoyed the ease of being able to graphically plug one thing into another in order to make a character run around, it seemed too “magical”, and I felt I wasn’t really learning anything useful for the kinds of projects I wanted to do. It was also really chunky, the physics were broken all over the place.

For a little while last summer I hovered around trying to decide if it would be worth it to try either Unity or the Unreal Engine. I really wanted to make a retro-shooter similar to DOOM but with modern graphics over the 2D sprites. This meant realtime lighting, reflections, everything that’s the “physicality-based-rendering” push going around these days. Unreal had the prettiness I wanted to play around in, but I was leery of using another graphical system for building stuff, and I wasn’t sure I wanted to deal with the $20 monthly fee. Unity Free looked far more approachable for someone who likes a lot of control, despite it’s less-pretty-ness. Again, this was shooting far too high, but I dove into Unity nonetheless, conquered some tutorials, started working a little on the shooter idea, and immediately realized I needed a smaller project. I floated around until HAMMBall happened.




As the story I like to tell people goes, a new barcade had opened up on Portland, and my coworkers and I wanted to check it out. Turns out I never knew I liked pinball games so much, there’s just something about it being based in real-world physics that got me real excited. I wanted the ball to burst out of the game itself so I could just keep playing between all the machines at the same time. That was when I realized I wanted a pinball roguelike, and thus, HAMMBall was born.

I went into a design frenzy. I could use the Unity “rollaball” tutorial as a basis! What if the pinball was a hamster in a gigantic hamsterball? How should I set up the physics layers? This could take place in the same universe as the retro-shooter I was designing before! Terrain starts with “Feature Objects”, which then generate “Structures”, which then generates “Biome” objects, which then leads to… Maybe the hamster is an ex-con? I just learned about static variables! He’s innocent, and exacting his revenge on those who put him in jail! I can make a huge city out of lots of hand-drawn sprites! Can I apply damage based on physics forces? Ohhh it’s a wrecking ball!

HBAll_ 17 Scan 2 HBAll_ 18

And so on.

One of the biggest things I learned was that I should probably not continue designing the game as I worked on it, which is basically the number one thing everyone says you shouldn’t do. It is the essence of feature creep. It IS feature creep. But I couldn’t stop.

Ultimately, about 6 months later (three months ago), I finally realized HAMMBall was just too dang bloated. The terrain generation was terrifying, I had no idea how I was going to get combat to be interesting, and the structure I had laid down for making new entities was just a huge pain. But I had learned. Lord had I learned. I could tell because every time I opened an old script I now could optimize it, or I could make it work correctly now because I understood the difference between “Vector3.Up” and “Transform.Up”. But I needed to step back. I may step back for a few years.

You can play the last, most recent iteration of the game here, if you want. The last thing I did was add some sound effects and some freebie music I found somewhere.


This was when I spent a few months working on buffing up my website. I got some fantastic help rendering out animations from my friend Alex Morrow and his computer, and we built the nifty animation reel I now have on my front page. During this time I did some heavy thinking about what to do next. Each of my next couple designs were a tad heavy on the side of complexity, or the side of content. I allowed myself the freedom to just roll with those projects without any kind of intent to build them. I have a stack of similar projects sitting in my room just waiting for the day I revisit, modify, cannibalize, or even tackle them.

For the first time in about a year, my girlfriend and I played some Left4Dead2. We had both forgotten how much good ol fun those games are. There’s just something super satisfying about fighting your way through a huge horde of entities together that really appeals to me in a way most other combat games don’t. I just don’t like fighting my friends, or even anonymous players-who-no-matter-what-I-do-are-better-than-me. I’m sure plenty of other people have written about co-op games and why they like them, so I won’t. I just wanted to make one.

I mentioned earlier that my projects can sometimes sit around waiting to be cannibalized, and this is now the case with Project GOA. This time I’m done with the slow-paced survival game, instead I decided I wanted to make “Left4Dead” in “Super Mario Galaxies”. GOA Hordemode. Fighting zombies on miniature planets! Weird gravity mechanics! Guns! It could take place one billion-billion years in the-

Now, wait, hey, I know what you’re thinking. That sounds wayyyyy in the realm of “Content-Heavy” AND “Complexity-Heavy”. Far worse than HAMMBall ever was, but I found I could break down the two concepts into fairly concrete, simple parts. Honestly. It took me about a week to make my own gravity system for both radial and directional gravity, AND to have a player character that could run around seamlessly between them. I found the Photon Network addon to be a pretty great and simple tool for achieving basic multiplayer. And as for content: 10 guns, 10 terrain types, and 10 “zombies” that are all simple geometric shapes with no animations seems much more attainable than the amorphous “I can add stuff whenever” mentality that plagued HAMMBall development. Though I am maintaining an air of caution just in case.

And this time I actually finished a basic design document FIRST.

And at that, as of this moment I am nearing completion of the entire play-cycle. The Players start on a green planet at one end of the game, with the goal being to reach a red planet at the opposite end. Currently the game generates about 15 other planets with random terrain, bouncy cube enemies, and a few guns for the players to interact with. Each planet also spawns a Tower, which upon unlocking through a Left4Dead style “crescendo” will grant a chosen bonus to the players, as well as a booster that can rocket them to another, nearby planet.

Currently, as of right now, the only big thing I need to do is build the conditions for endgame, which involve bringing a number of “puzzle pieces” to the end planet and solving the last “Master Tower” puzzle while surviving a final, crushing crescendo. After I am able to run an entire game from start to finish, I can then add in the remaining content, tweak balance, and play test with some friends (before more tweaking). After this I have an “expanded” design for two sets of 10 more pieces of content that will dramatically intensify the game. The project was originally designed to have these “extras” in it, but for the sake of time I’m going with a reduced version of the game for now because it is plenty playable and fun without them. I may not need an “expansion” at all.

Next time I want to talk about where I got my inspiration for the look and feel of the game, as well as how I got some of the systems to work. I may also do some more backtracking to talk about how some of the things I learned in HAMMBall changed my overall process with this. In the meantime, here’s some screenshots: (Note: VERY IN PROGRESS!)