Focus in Game Development

What's a camel?
A camel is a horse put together by a committee..

At my former employer, Ensemble Studios, one of the core tenets of the culture there was a sense of shared design.  That is, it was really important to the founders of the company that everyone in the company - be they artist, designer, producer, or programmer - feel like they could participate in a game's design in a meaningful way.  And this wasn't really just hand waving - we actually worked really hard to actually execute on that notion.  And you can imagine the appeal of such an idea to the typical newcomer to the company - the concept that regardless of what role you play in the game's development, you could still speak your mind, and still count on that idea at least be entertained, if not executed, in the game's design.

This worked phenomenally well as the company was small, but as you can imagine, as the team size grew, it became exponentially difficult to reach design decisions that made everyone happy.  And it became almost impossible for any singular vision of a particular game, or even of any particular portion of a game, to survive, as it weathered the brunt of multiple raging conference meetings and play sessions of people either championing or lambasting it.  This was a pretty important lesson that I took with me from Ensemble.  Shared design had its pros - those of buy in, participation, and a feeling of connection to the game.  But it also had a pretty dark underbelly, as progress on the game could be significantly delayed when even the simplest of design decisions had to go through the company ringer and attempts to get buy in from everyone - whether they were involved or not.

So one of the things I was absolutely most excited about when I set about making Atomic City was that I could execute with focus.  I may not have a big team to work on all of the aspects of the game, but I did have a singular vision.  I could form a plan, execute the plan, and I could entirely avoid the days or even weeks of discussion that would inevitably accompany every decision made, as it would have been at my former employer. It may sound selfish, or a bit hedonistic, but when you've sat through those interminably long design meetings that consume entire days, and sometimes weeks, over whether or not Victory Points in an RTS are a good idea, it's hard to understate just how appealing the notion of making a decision and executing that decision is.

So, if you're a reader, then you know Atomic City started off as a prototype for an MMO.  And I had a pretty solid definition of the set of design mechanics that would form the root of that MMO.  And I was pretty darn excited about them, because they formed a carefully constructed blend of mechanics that were familiar to MMO players, but also presented some interesting innovations on some of those fundamental concepts.  And history has taught us that small innovations to a core familiar gameplay are the key to a new MMO's success.  At least, in my opinion.  But when I didn't succeed in getting a publisher to byte on the MMO, I set about stage two of my business plan, which was to turn the prototype into a "small" singleplayer game for the PC, with a definite story - beginning, middle, end.

Now, I play a lot of City of Heroes.  And there are quite a number of design tenets in CoH that I really like.  And if you've played Atomic City, you have undoubtedly noticed City of Heroes' influence on that game's design.  And for a significant portion of when I'm playing CoH, I often play solo.  And so are a whole lot of other people I know.  So honestly I wasn't too bothered about the idea of taking Atomic City's MMO prototype and turning it into a single player game.  After all, it's exactly how I play most MMO's I play!

Original prototype, complete with ability bars

So I set about doing exactly that.  I was still able to remain pretty faithful to my original design.  My design focus was not in any real jeapordy, and though building the content (the zones themselves) took far more effort, time, and expense than I had originally forecast, I wasn't too worried, because I had been able to keep right on marching with my tightly focused design, and execute on that design.  So sometime around November of 2010, I had crafted several complete zones, and I pretty much had completed the programming and design of an RPG like game built around abilities and talents.  I had already implemented over 45 abilities, split along three different talent trees, that were designed in such a way that the player would specialize in either plasma, beam, or missile weaponry.  There were offensive abilities, buffs, debuffs, damage over time abilities, and even some healing abilities.  Players and mobs had offensive and defensive stats, armor, and chances to hit, miss or evade.  You specced out a hotbar with four abilities, and you could get different hotbars for when you were on foot or on a vehicle.  So I took my almost completed game, that really had for the most part only zones left to build, and I showed it to a fairly good sized groups of trusted friends, peers and former colleagues, and began collecting feedback.

And it was.. almost a complete disaster.

Because by far and away the biggest amount of feedback I got, from among that group, was that the core gameplay really.. just wasn't fun.  Somewhere along the way, I had broken an implied promise that I had made to the player.  I put a gun in their hand, but told them they didn't shoot it, they fired abilities to use it. And I put them on a vehicle that had guns attached to it, but I told them they didn't shoot those guns, they fired abilities that used those guns to do cool things.  What was the most fascinating, was that those exact same mechanics, when presented in an MMO (CoH) that couched those weapons with other more "ability type things", like firing bolts of ice from your hand, worked just fine.  The player was able to buy into that design mechanic in that game without problem.  But when presented in a single player game that had its focus on shooting guns and getting on vehicles and shooting more guns - well players didn't want to fire abilities that used guns, and see Miss Miss Miss roll up over a fleeing mob's head.  They wanted to point those guns at those mobs and hold the mouse button down until they were dead.

And suddenly, my game's much heralded tight focus wasn't worth shit.  To make matters worse - it didn't test poorly with everyone.  With people that typically didn't play video games, they loved it, because it was so gosh darn easy.  You didn't have to put any crosshairs on anything.  You pointed the vehicle in the general direction of a mob, pressed '1', and explody-shooty things happened and you felt really good!  And those, honestly, were the type of people I wanted the game to appeal to.  So I had actually succeeded in my goal - I had built a very casual friendly 3rd person RPG action game that involved weapons and hoverbikes and was fun for anyone that wouldn't normally play these games.  But extraordinarily unfun for anyone that had ever picked up a game like this before, because of their already preconceived notions.  Hell even I wanted to just shoot the gun at the mobsters, once I let myself think about it.

So I was faced with a huge dilemma.  Monumental.  Because you don't just wave a wand and fundamentally change the precepts and assumptions around which months and months of code was built.  I had to decide - do I stick to my guns and finish the game as I had originally conceived it, or did I acknowledge the feedback I was getting, and undertake the monstrous task of fundamentally changing the game's core mechanics to make it more action oriented. Would I abandon my focus and do exactly the kind of thing I had railed on designers at Ensemble for doing.

Well if you've played the game, you know what I chose.  Because the game didn't come out for another 8 months later, and the game is very much a 3rd person action shooter game, and all of those RPG mechanics were mothballed when I changed the game's design.

The moral, of today's parable, if you will, is that design fails when it's practiced at either extreme.  When you have a company of even a few dozen people, much less a hundred of them, and you try to meet the needs of every one in the company in your design, your game is going to flounder in a morass of indecision, argument, discussion, and watered-down-compromise-based design.  But if you build an entire game on a single person's vision, in what is essentially a design vacuum, you run real, genuine risk of building something that just isn't really, all that fun, or is going to do well.  And that is easy to see when that single person is someone else and you're the one picking on his design.  But it turns out it's quite a bit harder to see when that person is you.

I still don't know if I made the right decision for Atomic City Adventures.  I feel like I did, because in the end I liked where Atomic City ended in terms of its design, and I feel like it's a helluva lot more fun than it was when I was "almost finished" back in November.  And I'd be interested to hear what you think as well.  And if you haven't played it yet, well for cryin' out loud go pick it up and give it a try!  And come back and tell me what you think.