Working With Constrained Resources

One thing we, as a team, pride ourselves on is the ability to move fast and iterate quickly. We're able to try out new ideas with real players, and respond to how things are going. It's a really great way to develop a game, because it means that you don't spend a lot of time polishing up something that ultimately doesn't work.

The way we build stuff is to build an "MVP", or Minimum Viable Product to test out a feature/game/whatever, and then if it shows the correct kinds of promise, we can then polish it up as needed. To me, this is the best way to work. It prevents tons of lost effort, we validate our assumptions & hypotheses as fast as possible, and it lets us develop extremely fast.

But it has its drawbacks.

With Give Me Fuel, we've been working on the game for about seven months as a team. Before that, two of us had been developing prototypes for about another eight months. So all told, it's been a good long while that we've been working on this. But two engineers, one artist, and one designer isn't a lot. So for us, we're building a very small game to try to validate the hypothesis that the core card mechanics we have are fun as a videogame. We've already validated that for us it's fun as a card game.

The other thing that we're trying to validate - a core assumption we're making - is that there's an audience of gameplayers out there that want something strategic that they can play in seconds with their friends. This is, to me, a hole that has as-yet not been filled by anything other than word games (and to some extent, Clash Royale, Supercell's new game addresses an adjacent space).

And while one way to validate that is to spend a lot of time making something supremely polished and beta test regularly & roll out in different territories, etc. etc. - that's a path you can take if you have a tremendous amount of money and time. We don't have either of those things. For us, we have to test our assumptions with very little time and very little money.

Which means that when we launch, this isn't going to be the most polished thing in the world. It's not going to be the apex of our total abilities. It's not going to be the best possible representation of our work and our ideas, in an absolute sense. It's going to be the best we can do with the resources we have. And while that sounds like I'm underselling the game as a cop-out, I assure you that's not the case.

I'm incredibly proud of what we've built. I'm also almost certain that you will see a lot of rough edges and wonder why things are the way they are. And for us, yes, we understand. Here's the thing. Either the core of this game has to be fun enough that you're willing to overlook the rough edges or we've done one of two things:

  1. The game isn't fun enough, and no amount of polish would help.
  2. We made the wrong call about how much polish was necessary for players to understand the core of the game.

The scary thing is that (2) is always a possibility. In a world where there are literally tens of thousands of options to choose from, who in their right mind would choose an unpolished, fairly rough game?

And the answer to that is, someone who isn't being served well by those tens-of-thousands of games.

Our goal is to make a social, strategic game you can play in seconds. If what we're doing isn't unique, and people stop playing because there's a better implementation of our core idea out there, we haven't accomplished our goal, or our assumption was wrong, and testing earlier rather than later is better.

If what we're doing is unique, and it's super rough, I believe that we will hear the response, and continue on the path. And because continuing on the path will lead to polish, and because we actually know how to develop a polished game, much of the rough edges will come off. The things that seem like quirks or failures will get ironed out. Most of those things are a matter of time and money, and not doing them was a conscious decision we had to make to not spend infinite time and infinite money on development.

It's a scary way to develop a game. You always wonder whether you're burying the fun under an imperfect implementation. It's always a judgment call. It's always easy to point fingers after the fact and say that we screwed it up. Maybe we will screw it up. I don't know.

But here's what I do know. Every game I've ever worked on has been wrong about something significant when it launched. Every. Single. One. In some cases, we'd spent months trying to anticipate user's reactions to things, and we were wrong. Months of effort to try to put ourselves in their shoes were wasted. In some cases, a feature just didn't work out as planned. But something always goes wrong. Often horrendously so. IF we spend months polishing everything, those things are going to be just as wrong - because they're not failures of implementation, they're failures of understanding.

If, on the other hand, we put out something rough, four months early, and then take that feedback and iterate on it for four months, rather than iterating on the idea that's trapped in our own mind, at the end of that time we'll have fixed dozens, if not hundreds of real problems people are having as we work toward the idealized version of our game. And as a result, we'll be much, much further along than if we'd put the last bits of polish and shine on the game before releasing it.

It's a method of development & release that requires a lot more interaction with the players. It's tricky, because it also requires that players trust us a bit. At least the very early ones. But I hope that we're building something that will reward a little bit of effort, and a little bit of trust, and that you'll join us on this journey - it is a journey - as we develop this game, and this company, into something we hope that you'll love.