Game design deep dive: The creation of Gunhouse

Gunhouse has had a long and difficult road to release. It began life as a game jam game, then changed into about five different things, and was eventually released on the PlayStation Mobile platform in 2014. Since then we’ve brought the game to iOS, Android, Windows Phone, Jump, PS4, Vita native, (with physical Limited Run versions!) Switch, and soon Steam and Itch.io.

We clawed this game out of obscurity and into profitability, and it only took us five years to do it (which is a story for another time). I’m happy with the game as it is now, but I want to focus this deep dive on how the game’s design changed over its first 18 months of development. This was our first game as a studio, so we learned a lot of very embarrassing and obvious things while making it, just like everybody else who makes their first game.

A prototype Gunhouse splash image, showcasing many unused features. 

I’ll be taking an unusual framework for this discussion – the game was of course designed and executed by us – but we had a lot of moments when we got stuck, and discussions with folks outside the company helped us get back on track. I thought it would be interesting to highlight those moments when other developers helped us get our proverbial grooves back.

(And before I get into all that, I want to make sure I mention the team – Jim Crawford was the coder, and helped me massage the game design. Rich Vreeland aka Disasterpeace did the music. Juan Ramirez is the artist, and Andrew Toups and Jack Menhorn did the SFX. I was the director/lead designer. A lot of programmers have worked on subsequent ports, cleaning things up, improving UI, etc – Shane Marks, Nuno Antunes and Michael Kerwin especially.)

Gunhouse Origins.

So what’s this game all about? In its final design, it’s about matching tiny blocks in order to turn them into bigger blocks, which players then slide to the left side of a house to load guns, each of which have different attacks and patterns. If they load these puzzle blocks to the right of the house, they’ll load special attacks, which affect larger areas. When the puzzle phase ends, after a time limit, enemies come to try to blast your house and steal your precious orphans. You use the guns and specials you’ve loaded during the special phase to defeat them in a sort of light tower defense mode. 

Here’s a trailer to give you an idea.

Every gun and special attack has a pattern for you to learn, which complement enemy patterns, giving the game some strategy. You also have prompts from the game about what color of gun or special to match next. Matching that correctly gives you an ammo bonus, so there’s some strategizing there as well.

That's the game in a nutshell, but the first version of the game was completely different. It looked like this.

That sure is a different game, there! Gunhouse began as a game jam game from the Molyjam, and ended up as a project funded by Sony, and then by Microsoft, and then by us, eventually becoming the thing you see in that first trailer. 

The project really began when I lucked my way into a Sony contract. Sony was looking for games to fill out their new PlayStation Mobile platform, and asked if I had anything in the works. Since Gunhouse was already a prototype, I submitted that for consideration, with the line "single screen action game" next to it. I said we could make it in three months. That was enough to get a contract, somehow, but this first step, agreeing to do it so quickly, was a rather large mistake, because I really didn't know what I wanted to make yet. The game wound up almost taking a year and a half. Hooray!

I may not have known what I wanted to make,  but I did know that the current game wasn't good enough to put our names on. And I had no idea what I really wanted to make. But I decided we should stick to the initial Molyjam game prompt: “You live in a little house made of guns. You need many guns to fight invaders but also need to keep a roof on top of your many children.” I quickly came up with a concept that we had discarded during the initial game jam, and we prototyped it, and it was a massive failure. So were the next 5 ideas (which I’ll cover in a separate article). I needed to go back to the drawing board.

An early Gunhouse puzzle sketch... can't find the original properly-sized one!

I liked the idea of a puzzle and tower defense hybrid, so I went back to pen and paper. I drew a box the size of a PlayStation Vita screen, since that was our main target platform at the time. Then I marked off how much of it I thought I could reasonably use for puzzles, while still leaving room to show our big and colorful enemies. I divided that puzzle space into a grid of squares that I could definitely touch with my whole fingertip. Now I had a 3x6 grid to work with. But I had no idea what to do with grid that small! I needed a house, guns, enemies, and a puzzle grid to all fit on a 966x544 screen or smaller. 

Design discussion part one: Kris Piotrowski

While I was banging my head agains the wall, Kris Piotrowski, creative director at Capy Games (the company behind Sword and Sworcery, Super time Force, Below, etc) was visiting from Toronto. I had a rough puzzle idea, but I wasn’t sure what it was *for.* I talked to him about the problem, and he said something like: "You have a puzzle grid, and you have guns, and you've got a house. What if somehow the puzzles load ammo for guns?"

That kind of kicked my brain into gear. I still had to figure out how this would work, but having any point of direction to latch onto got me out of my rut. My problem went from "what could I possibly do with this small puzzle grid," to "how do I solve the challenge of this tiny puzzle grid." 

After that it took probably a dozen revisions to get to the system we have now, but it's a fun mechanic to do in and of itself, even without the guns. Our human desire to construct things makes the building of blocks an easy sort of fun to grab hold of. 

The final puzzle grid in action.

That discussion yielded a really small but important change. I went from thinking about the problem as just a problem to thinking about it as a kind of puzzle in itself. This is when I realized the importance of showing my game to people that had never played it, and this was just at the paper prototype phase. So thanks, Kris!

Design discussion part two: Joe and Trish

Once gotten our first solid try at what the puzzle system would become, and had implemented what we thought would become our tower defense system, we had an opportunity to demo the game at E3. 

Back then, the game really demanded a lot of player attention. You loaded guns from the puzzle grid in real time, and aimed those guns manually by dragging their line of sight toward enemies. Enemies followed a pre-determined wave, culminating in a boss.

The main damage indicator was when enemies managed to steal orphans from your house by bringing them fully offscreen, and you had a little orphan counter telling you how many you had left.

We knew we had to make a good impression at E3, but things were just feeling off for me. Stakes felt too low, and too ambiguous. I needed more feedback for when your house took damage, and a greater incentive to defend it. I was on the tail end of a business trip in Seoul, and the friend I was staying with (hi Joe!) suggested the idea of “jammer” blocks of some kind. 

We wound up implementing them just before E3 – these were blocks that enemies would shoot. If they turned black, you would have to tap them to eliminate them, or else they would muck up your puzzle grid and you wouldn’t be able to move anything. Here’s a prototype of that.

Amusingly, because we had black and white blocks with a bit of red in our prototype phase, you can actually see this much better in the prototype than you can in the final game! When we took this to E3 it was immediately clear that the jammers were a failure. 

Nobody, I mean nobody(!) could see them, and I first saw this with my friend Trish, who through no fault of her own just couldn't figure it out.

I’d stand there telling people “you’ve got to tap those jammer blocks to get rid of them.” They’d say  “okay.” Then their screen would fill with black jammer blocks and they’d die. No matter how I tried to describe, coax, or cajole, the only thing that worked was physically tapping the screen for them to show them what to do. It was a spectacular feedback issue!

Check this updated video and see if the jammer blocks read to you. Also please note our sole damage indicator, that "orphans left" text at the bottom left. Not great!

Frankly, even if the jammer blocks had been easier to see, they also slowed down the game and made it a chore to play! In the end, in a fit of total madness, I had a genius idea: what if we just had hearts at the top of the screen. And enemies shooting your house and orphans being stolen loses health. What a genius!! I came up with the most basic of all health depictions and it sure did work better than all my prior fancy plans. Sometimes simple is best!

Design discussion part three: Cliff Bleszinski

After dealing with people not seeing the stupid jammer blocks all day at E3, brimming with frustration at what we had created, I showed the game to Cliff Bleszinski at a party. Since at that time he was still at Epic, and still the “Gears of War guy,” and this was a party, he had about two minutes to play the game while his wife (hi Lauren!) held his beer. So this ultimately became an exercise in interpreting flash, on-the-spot feedback.

Cliff doesn't pull punches, and has a really deep knowledge of games that he's able to apply to the way he designs. As a show of respect here's a picture of him in a bunny suit.

After playing it, the very first thing he said was "so, what is this, like level 48?" He knew, of course, that this was actually wave one of a three wave demo. "Yeah, it's pretty tough," I admitted. But he said "no, it's not tough, it's impossible! Especially for new players!" He was right, of course – all the realtime puzzle and tower defense stuff was just too demanding of the player, to the extent that they didn’t even know where to look.

He played it a bit more, and asked me "Why are there three guns? Why not more? Why not fewer?" Remember, at the time you had to manually aim each gun - you kind of slid your finger out from each gun to target enemies, which was pretty tough to manage. I started thinking maybe I needed to have fewer guns, like maybe just one big one, or make all guns aim in the same area. At one point we actually prototyped making all guns focus on one part of the screen if you tapped there, which basically worked, but this was just another band-aid. I was missing the big picture. 

The real point was this: There needed to be a reason for there to be three guns. Expanding this a bit, if I couldn’t think of a reason for everything in the game, I had to find the reason. To sum up the Cliff experience, at the end of his two minute playthrough he said to me: "Maybe the game should be turn-based, if you're going to ask for that much from the player."

This comment particularly wounded me, because I had considered a phase-based system from the very concept phase, and never implemented it because it seemed too limiting. And what would a turn even consist of? I couldn't figure out what shape that would take at the time.

      
The very first Gunhouse concept images by Juan Ramirez. There was a tower defense and puzzle phase - the idea was you would actually zoom into the house when the puzzle phase began.

This discussion ultimately led to one of the most important changes we made in the game though, and it came from Cliff revitalizing that idea - the separately-defined puzzle and action modes. 

I had to think about it a lot before I accepted it, but once we implemented separate puzzle and action phases, everything got clearer. That earlier discarded idea was just what the game needed, in fact. I felt  foolish for discarding this idea in the first place. It’s obvious, but this really helped inform my future as a game designer – the more you can figure out from the very start, the better off you are later on. I’m not the perfect example of holistic design yet, but it’s a process!

Design discussion part four: Rami Ismail

Rami Ismail is the everything-but-designer at Vlambeer (Nuclear Throne, Ridiculous Fishing, etc). Rami is extremely giving with his time, and sat down with me amid the chaos of the E3 show floor, even though his laptop and all his equipment had just been stolen. He was one of the last people I talked to about the game at E3, so I came straight up to him with a lot of caveats and self-doubt. I was all ready for him to not like the game.

Here's Rami beating a bunch of us at Ascension. 

Rami took the time to really play my game, the way basically nobody else had. He was methodical, and paid attention to every decision he was making, and didn’t talk until he was done. As a result he not only figured out the puzzle system quickly, he also played it the way I had intended. He tapped the jammer blocks to get rid of them. He targeted the enemies by drawing his finger from each gun, all as I had intended.

But I could tell he still wasn't really having any fun. After about 10 minutes of concentrated play, he handed my Vita back. He says to me, "You've definitely got something here, but I'm going to be very honest with you because I feel like that's the best kind of feedback you can get. There is something in what you've made, but there's too much of it. You need to figure out what you're doing."

In essence, Rami felt, like others did, that when you're looking at the puzzle, you're ignoring the action. When you look at the action, you're ignoring the puzzle. So what is it, an action game, or a puzzle game? He says to me, "Figure out what your game is and focus on that." Also, it was clear to him from my description that I wanted to make a strategic puzzle game, but strategy was not being supported by the design at the time.

The conclusion from all these E3 discussions was that we had too much stuff, presented all at once, in order to create a strategy game that simply wasn't there. I told Rami I realized this, and he said "But wait! Don't get depressed about it. You're in the perfect position right now. You've got a new mechanic that nobody has done before, a great art style, it's just not focused. All you have to do is focus in."

And he was right. We focused. We trimmed the fat, and dialed in on what worked. After many trials, we implemented something that wasn't turn-based, but which had a phase system that would block off the puzzle grid when it was time for action, and when you ran out of ammo from the action phase, the puzzle grid would show back up. The puzzle phase would be available for a certain amount of time, and then it would get blocked off again. When you were in the puzzle mode, we desaturated the background in order to focus your attention on the puzzle, and enemies froze in place. In action mode, it was all about attacking enemies. Here's the comparison.

Gunhouse's action phase, with the "puzzle door" closed, versus the puzzle section with the action paused and desaturated.

With this change, the game was instantly more fun. But we still had the problem mentioned by Cliff - why did we have three guns? We had made them auto-fire, which solved some of the confusion, but there was a lot more to figure out.

Gunhouse design lessons part five: Tim Ambrogi 

By now, we were at PAX. I wasn't on the show floor, but I was working from my laptop in a nearby coffee shop. At this point, we had gone through what you could call The Big Streamline, after all our feedback at E3. We had tried our best to remove all the band-aids, and stripped our game down to what we knew worked. It was much, much better.

But we still had a problem of the guns. They weren't different enough from each other to feel like you were making real decisions. While pondering this question, Gunhouse's programmer Jim Crawford brought Tim Ambrogi, designer of Jamestown, over to my table. He had already played the game, and had a bunch of ideas.

Tim Ambrogi

He started telling me, "You've got a great puzzle game here. Seriously, I have never seen a system like this, and that's really exciting. You could just ship a game with this puzzle mechanic and nothing else, and people would buy it." I didn't believe him, but it was kind of flattering, so I kept listening!

He saw the problem with our guns, too, but he had a suggestion. "Have you ever considered keeping guns and enemies in specific lanes?" I had not considered this at all. I immediately envisioned our game as a Plants vs Zombies clone, and got a little sad. I love Plants vs Zombies, but I didn't want to lean so heavily on someone else’s idea. I bristled at the idea.

But he was set on it. "It really could do something, it'd give more intentionality to what guns you put where, especially if the guns do different things," he said. And Jim agreed. They left, and I thought about this real hard while I scowled at my beverage.

I realized that most important thing this would do is answer Cliff's question: Why three guns? Well, you have three guns because enemies come in three lanes. And then we could have some enemies that didn't stick to lanes, and were trickier. I couldn't deny the allure of this idea, and it was one of the biggest unsolved problems in the game. So we tried it.

The whole thing definitely worked way better than I thought it would. I designed patterns for each gun's attack, and suddenly I cared whether my dragon gun was on top or bottom, because it shot down in an arc, and had no range at the bottom, but was super destructive at the top. As you can see in the above screen, the vegetable gun is shooting straight over the heads of the guys below, so I should have put it one slot lower. The guns problem was the last major thing we had to figure out, and without the push we got from Tim, this would not be the game it is today. And, thankfully, it feels very little like Plants vs Zombies in the end.

Ultimately I had a hard time solving this problem because I was looking at it the wrong way. I was focused on the guns themselves, mechanically. All I really needed was to give them a better context and framing. It was such a simple change, ultimately. We had three guns, so three lanes for enemies made a huge amount of sense, I just couldn't see it because I was stuck in the mire of my own design.

Design discussions part six: Simon Carless

By now we had gathered a huge amount of valuable feedback and ideas from our peers, which was great, but the hardest part of that was figuring out what to take from it.

We got a lot of feedback we didn't use, of course. There were ideas that were restrictive or reductive, and aside from the jammer blocks, we didn’t go down too many rabbit holes. Some of these ideas that were cool, but too grand in scope for our already over-time and over-budget game. 

But we wanted to make the game better, which meant we had to listen to difficult feedback. Essentially, we had to figure out what everyone's statements really mean for our game. Cliff Bleszinski only played the game for two minutes, so it would have been easy to dismiss what he said. But figuring out how his kneejerk reaction applied to the direction I wanted to go was extremely valuable, especially when I combined his feedback with what other people had already  told me.

This process of learning how to learn is exemplified in what we call our element system. This was added at Jim's suggestion. When we first implemented it, it worked like this: In puzzle mode you'd see which gun was going to be was most powerful in the next action phase and so you'd try to load up a bunch of that type. When it was time for action, all enemies would be weaker to that element, so if you powerloaded those guns you were doing well. You could also see the next two elements coming up, so you could plan for the next round. 

We wanted people to care about which guns they used, and we figured making enemies weaker to specific attacks at specific times would get you to care about which gun you loaded moment to moment.

This basically worked, and when I showed it to my former boss Simon Carless at one of our East Bay Game Developer meetups, he said he saw how it could be used strategically, and thought it was very interesting.

Simon Carless

That was gratifying to hear, and I turned that over in my head as I walked home, because it felt like a victory. But suddenly I realized the most important part of his sentence was the conditional. He said it "could" be used strategically. It wasn't happening by default, or necessity - it was a possibility he could foresee if he spent a lot of time with it. And that really wasn't good enough. This feedback meant that the system wasn't working immediately, or obviously. So the next week we streamlined the element system so that it gave you a gun type to match and left it there. If you matched that gun by adding it to your house, you'd get a big MATCH! animation, bonus weapon strength, and a new match would show up in its place. 

The final matching system at work.

People understood this as a strategy immediately, and could use it to their benefit without having to spend a lot of time with the game. Again, by making it simpler, the strategy was in no way diluted - it was just refined. Complexity wasn't helping us make the game more core-oriented, it was just making the game less playable and less interesting. So I have to thank Simon for reminding me of that, even though his comment was entirely offhand.

That's really the beauty of playtesting to me - the comments that stick with you are often just tossed out there. They're quick first-impressions and surface reactions, but they can carry a lot of meaning beneath the surface, if you figure out how to dig for them.

This is a skill that I'm still learning, and will probably be learning for some time. There was an interesting parallel between taking feedback and the act of improving the game - in both cases we were culling the wheat from the chaff. There were gems in the feedback, and in the game, we just had to sift through everything to find them. 

When getting feedback, I find it helpful to think about how I would view that feedback if it weren't for my own game. How would I feel about a turn-based system in a puzzle game other than Gunhouse? Well, I'd be open to it. Why not? It's easy to get hung up on the idea that you've come up with this perfect little package that is going to drip straight from your brain into the world. But without players, your games have no purpose. The players ultimately make your game, and you want their experience to be as good as possible. You really have to listen to them, and try to absorb what they tell you, even if it's painful. If a bunch of people are telling you the same thing, there's a good chance they're right. 

But they could be wrong, too! And I absolutely do not believe in blindly following player feedback, or simply doing what’s popular. Player feedback should help hone the game you want to make, not define it.

In the end, a lot of what made this game better was what we were able to learn from our peers. If we had been too precious about our designs, or too sure of ourselves, or even worse, too uncertain of ourselves, we would not have been able to take the right lessons and apply them. 

Gunhouse isn’t perfect, but it’s got a unique mechanic and a different vibe, and it has kept our studio alive through some dark times. Thanks again to everyone who helped us get through the rough patches, and our rocky studio start. Especially big thanks to Jim Crawford, Juan Ramirez, and Rich Vreeland for believing enough in the project to see it through! 

Now go buy the dang game on Switch!!