When we left our jobs to form Galvanic, the four of us started with six months of funding (from friends, family, and our own savings) and the goal of getting into PAX Prime.  PAX represented a chance to get The Rust Belt into players’ hands and to see whether we had a game people would love.  PAX was also perfect for us since we are Seattle locals; we were happy not to have to budget for airfare and lodging, which can easily be over half the cost of showing at a big convention.  Since PAX draws over seventy thousand people, we hoped we could find a handful of people who were really excited about our game.

Lesson 1: Scope for a Vertical Slice

It’s easy to start with too big of a scope, especially when we’d been unchained from our day jobs and given free reign to build the game of our dreams.  However, the amount of content we planned for our PAX build could have been accomplished in a weekend game jam.  Our goal was having something we could iterate on over four months to get it close to perfection.

At the creative agency we’d previously worked at, we often had projects that lasted from three weeks to three months, so we went into The Rust Belt with a solid idea of the scope we could deliver.  The strategy we’d formed over previous projects was to focus the first week entirely on the player’s core mechanic.

Rust Belt started as a concept for a space junker game, and the mechanic we wanted to experiment with was tethering large derelict spaceships with a grappling hook and dragging them back to base to salvage.

This is what the game looked like after a week:

In the first week’s build, the player could only harpoon objects in front of them.  We relied entirely on Unity’s physics system to handle movement.  Different objects had different masses, so each one drastically changed the way the player moved.  The tether was a simple distance joint between the player and the harpoon.  

I wanted to test Unity’s new UI system and make it easier to iterate, so I threw in some input fields to tweak the feel of the vehicle.  This made it easy to fire up the game and change things on the fly outside of the editor.  We dropped those after a few weeks, but I appreciated having them in early builds.

With this simple setup, we discovered dragging things around was fun!  Smashing them into other objects was fun!  Throwing them from across the screen into an incinerator was fun!

We were surprised to find the game played like we were driving a tow truck.  We had wanted to make a desert driving game since pitching a minigame for the new Mad Max movie.  So we spent our second week playing around in a completely new setting.  We added the ability to aim the hook with the mouse and built out a boxed level to drive around.

Lesson 2: Show Your Game Off Frequently

If we could get into one day conventions, we did them.  If there were local events where we could show our game off to strangers, we attended them.  The longer we held off on getting our game into players hands, the more plaque built up around our game’s designs.

At two weeks, we showed the game off for the first time.  Seattle has a sizeable indie community that hosts monthly critique circles where you can bring prototypes and get raw feedback.  I can’t emphasize enough how influential these events have been for us.  Immediately, we saw that our game had some appeal.  People were excited about the art and the core mechanic.  We also got feedback that driving was too floaty, aiming the tow hook was nearly impossible, and throwing objects accurately was too challenging.

If the game had no appeal, this would have been the perfect time to revisit the core mechanic or cancel and start from scratch.  Since we focused on the core player mechanic, two weeks was enough time to build a prototype that conveyed our vision.  It’s far better to find out our vision isn’t working early than wait several months or a year to realize we’re building the wrong game.

We were glad to hit the right notes early though, as our first major deadlines were looming.  At the one month mark, we had the Indie Megabooth submission and Power of Play, a local game developer convention.  We spent the next two weeks preparing for those.  We added a tile-based wall system, switched from a sprite-based ground to Unity terrain, added different objects you could break for resources, a fuel mechanic, and a goal at the end of the level: a water tower you could pull down to take back to town.

We knew what we were submitting was not a great game.  There were no enemies or challenges and the driving still felt off.  The team thoroughly discussed whether we should show the game at all at such an early stage.  I am a strong believer in failing early, and I’m glad we overcame our concerns.  Power of Play was the most useful experience we had leading up to PAX.

We had dozens of people play the build and we took 20 pages of notes while watching them.  People were excited about the game and had great feedback, both about what they liked and about what they had trouble with.  If we had not shown it at Power of Play, we would not have solved the initial problems players had by PAX.

As a direct result of Power of Play, we switched controls from screen relative to tank controls, set up an auto-aiming system for the hook, and added a minimap.  Since we had been working with prototype-quality code up to this point, we decided to scrap most of what we’d written.  It took us the better part of the second month to rewrite the prototype and incorporate all the feedback we’d gotten from the convention.

Lesson 3: Failure is a part of the process

We expected to get rejected by everyone, especially when our game was young and looked terrible.  We didn’t take it personally; instead we tried to figure out why we were rejected.  Iterating on those problems made each subsequent application more likely to succeed.

While we were rebuilding the game, we found out we didn’t get into Megabooth.  This wasn’t a big surprise to us, as we felt like our submission would not stand up well against indies who were closer to release.  But we were disappointed to find out all the other exhibitor booths were sold out too.  We moved forward with the belief that we’d failed to get into PAX.

We added enemies and rudimentary AI to the game.  We built a simple intro level that taught people the game.  Because we’d watched so many people play the game by this point, we had a good feel for what instructions to give players and how to pace out the level.  We submitted our updated build to another local conference, Seattle Indies Expo, and got accepted.

In the middle of the third month, we attended the Intel Buzz conference as part of their Developer Showcase.  We showed off an early version of this teaser trailer and an updated build of the game.  As part of the competition, we took home second place.  Showing off the progress we’d made in the months since Power of Play was invigorating.  On a whim, we sent that trailer and build to our contact at PAX.

A week later, we got an invitation to PAX Rising, a new curated section for promising indie titles.

Lesson 4: Polish

A small polished game is more appealing than a large, ungainly one.  A game will attract more attention if it looks finished and fun.

With renewed purpose, we spent the fourth month fleshing out the levels we’d built so far and polishing as much of the existing content as possible.  Royce, our 2D Artist, did a pass on the player’s face and doodads for the levels.  Having a full time artist on the team, especially one as talented as Royce, made it so we could quickly build out content.  Taylor, our animator, brought things to life that had previously been static and added new sounds to all of the object interactions.  I rebuilt the levels to incorporate the new building objects players could retrieve to upgrade their town.  John, our engineer, built a town section the player could return to in between levels.  Finally, we added an offline analytics system so we could record player data during the show.

A week before PAX, we stopped all work on the build and started testing.  While it was painful to drop some of our planned features, we were able to fix all of the game breaking bugs before the show.  I’ve seen too many people add last minute features.  Even if the feature was great, we would risk ruining our players’ experiences with an unstable build.

PAX Rising was incredible for us.  We got to play the game on the PAX Twitch stream twice, once with Rami Ismail.  We had over five hundred people play the game, including streamers, members of the press, and other game developers.  Our two machines were rarely empty; we logged 63 total hours of play time during the show.  The feedback we got will help us craft the rest of the game over the next year.  And on top of that, we found an audience of people who are excited about The Rust Belt.  That’s a lot more than we had going in.

We found this process very beneficial.  Scoping small meant we could iterate quickly and not get bogged down in creating content.  Showing the game off frequently kept us from going down empty design rabbit holes.  Being willing to fail early made success more likely in the long run.  And polishing the game relentlessly meant we had a game to show that was appealing even from an early stage.  We hope thishelps you get into your next convention and that we will see you at a future PAX!