Gurgamoth: Lessons in Iterative Game Development

Today we are launching our debut title, Gurgamoth, a flying fighting game where the level is your weapon.

From a purely business perspective, I would never recommend making a local multiplayer game.  The market is niche, crowded, and players will be very vocal and critical about lack of online.  Publishers and press will largely ignore you.  You’ll be fighting an uphill battle from the beginning to get your game attention.

However, from a design, production, and passion standpoint, Gurgamoth was a great game for us to build.  It was a chance for us to improve our process, to refine the way we build games, and to establish ourselves as a team that makes great products.  With our budget and constraints, we would have struggled to make another game as good as Gurgamoth, and I’m glad we’re releasing it as our first title.

We started with one mechanic we loved: bashing opponents into spikes.  That mechanic came from an unexpected source: a bug in someone else’s game.  After seeing it, we saw the excitement the bug provoked and spent a few weeks thinking of how to design a game around it.  We took that idea to a game jam as an excuse to build the game outside of our normal work hours.  Game jams are great for slicing scope down to the bare minimum.

Starting with a simple core

We’ll probably never start with a perfect game loop.  It took us a lot of refining to nail the feel and interplay between mechanics in Gurgamoth.  We started very simple, perhaps even too simple.  Gurgamoth began as a one button game because it was based on a single mechanic we wanted to explore.

But even with a lack of interesting depth in the beginning, the core mechanic felt compelling enough to keep us going.  There was something really enjoyable about about pushing people to their death.  It was better that we started simple in the long run, because we didn’t spend time on extra features we had to cut later.  Instead all of our flaws with our core design were exposed from the very beginning.  Had we thrown in extra moves and features, they may have covered up the flaws in the initial design.

Identifying what’s broken before fixing things.

When playtesting, people will often give suggestions on how to make your game better.  We find it’s much better to watch how people play the game and figure out what’s not working.  The initial flaws in the game we identified after the game jam:

So we slowed the game down a lot -- over 50%.  I’d recommend slowing a game down for testing, even if you feel your game is at the perfect speed.  When you take speed and reflexes out of the equation, you expose the strategies and choices players have at their disposal.  Once we slowed the game down, a new set of issues around those decisions.

Here’s where we started adding complexity.  We added a dodge to trick your opponent into smashing themselves into spikes or to give yourself better positioning for your attacks.  Now the game started to have interesting choices.  New problems emerged:

Dodging and attacking looking the same was a visual problem.  It’s here that we really started investing time into polishing the visuals of interactions.  It’s important not to put too many art hours on things that will change later, but at some point, placeholder art may become a blocking factor for people understanding what’s going on in your game.

When in doubt, we chose the quickest solution

Spamming was a huge problem.

Our first solution was to add fuel to player attacks.  It was a intimidating change for us, mechanically and thematically, but we made it without hesitation because of one of our core philosophies: if it’s cheap, try it.  I’m excluding in this write-up all the dead branches we went down.  However, though they were many in number, they were mostly inexpensive.  

Any time we had an easy solution to a problem, we tried that first.  Often times it paid off.  Just as often, it revealed aspects of the problem we didn’t understand at first and how we could better solve the problem.  The attack fuel successfully limited spamming, but it felt weird having mana bars that didn’t tell you how many attacks you could do.  The bar became individual charges.

Once we fixed the spamming issue, the core gameplay was in place.

After we had a solid core, we expanded from there

At this point, we had a fun but shallow game.  Our biggest problem was that people were putting the game down after a few rounds.  So we looked at how other games were solving the problem.  The more we played, the clearer the problem became.  Every match in our game felt the same.  When we played other local competitive games, matches had stories.  Without adding more complexity, we wanted to add more variety.

Here the powerup system was born and everything fell into place.  Having random powerups and effects to add variety is not an original concept, but I’m glad we waited until we needed to add them.  Because our core loop was established by this point, we could design our power-ups around the established flow of the game, to enhance key moments or fill in missing gaps.

We also finished adding more levels.  We tried to build each level around a different type of hazard, interactive and static.  Those designs were also born out of having established a solid core.

We playtested as frequently as possible

Our secret weapon and one our unfairest advantages is the city of Seattle.  Seattle has a highly active but fragmented game dev community.  The fragmentation works well for us; each group hosts different weekly events.  We took Gurgamoth to every meetup we could.  Every week we had different options, including the Indie Social, Critique Circle, Beer Wednesday, Indie Support Group, Game Dev Night, and weekend prototyping meetups.  When opportunities came up, we took Gurgamoth to Vancouver and Portland, both of which also have active game dev communities.

It adds a lot of extra work and time on the evenings and weekends, but we love attending these events and being part of the community.  Plus, because of the constant feedback, we always knew what was wrong with our game.  Not a week went by, even during the holidays, where we didn’t have an opportunity to have someone play the newest iteration of the game.

As a warning, playtesting with game devs is dangerous.  They often skip the “Identify What’s Broken” step and move into suggestions for how to fix it.  And their suggestions are often really appealing!  But it’s best to step back and figure out or ask what they’re trying to fix.

Despite all these lessons, there are downsides to the process:

However, the upsides are pretty big:

This is our workflow as it stands, and we’ve been iterating on the process since we started Galvanic.  The way we build games changes over time, but keeping an iterative spirit means being open to change, incremental improvements, and tackling the right problems.  We’re proud of Gurgamoth as an example of how that system can work.

Gurgamoth comes out on Steam and Humble Store on February 16th.  Galvanic will be at GDC and Pax East 2106.  Say hi if you see us!