Thursday, November 11, 2010

Steambirds: Now out for iPhone, iPad and Android

Have I mentioned that this was a busy week?  Monday saw the release of our new Kindle game Panda Poet.  Yesterday, we release not one game, but two games.  The first is Steambirds for iOS.  The second is Steambirds for Android.

Indie legends Adam Saltsman and Eric Johnson from Semi-Secret handled the iPhone and iPad versions.  They've been leveraging their experience with Canabalt and Gravity Hook to help navigate the wild west of AppStore relevancy. Check out that gorgeous new title screen...there are also all new plane graphics.  You can pick up the iPhone version for 99 cents or you can splurge on the HD iPad version for $1.99.  You are so totally worth it.

Victor Chelaru from Flat Red Ball handled the Android version.  They did some amazing work optimizing the UI to work on Android phones.  The performance was tweaked until the whole experience feels smoother than the silky fine fur of a baby beaver's bottom.  Try it and you'll see what I'm talking about. There is a limited launch promo price of 99 cents that only lasts till November 17th.  Then it gets expensive.

Long ago when I was first playing around with the Surface at Microsoft Research, I dreamt that one day in the far future I'd be able to play a game just like Steambirds.  There is just something incredibly tactile about a big screen and those little chunky planes that just beg to be dragged about.  The thought of it makes my fingertips vibrate. The touch friendly Steambirds UI plus the big screen on an iPad were meant for each other.


Here are two very basic design lessons from this particular set of releases.
  • Strive for simple interfaces.  We often get caught up in adding buttons; new feature = new button. But my favorite designs are ones that start out feeling almost too simple.  There are big benefits. Simple interfaces are easier to transfer to highly divergent platforms.  Simple interfaces are also easier for new users to learn.   There doesn't need to be a trade off; you can have both a simple interface and immense gameplay depth.  This is probably the one design challenge that I obsess about more than any other: how do you create layers of depth in the player's mind, not in the user interface? It isn't the easiest problem to solve, but when you see it, you know you are in the presence of great design. 
  • If you've got gameplay magic, bottle it up and spread it wide and far.  10 million unique users have played Steambirds.  The gameplay resonates quite broadly. The question is not 'which platform should I target?', but instead "how do I reach as many customers as possible across all viable platforms?" 
Alright, I'm breathless.   If you have an Android or iOS device, grab a copy of Steambirds and let me know what you think. Think of it as a vote for deep, great indie games on your phone.

All the best,
(...heading back to his design cave to make more games...the year isn't over yet and we've got more goodness to release.) 

Tuesday, November 9, 2010

The Cutest Kindle Game Ever: Panda Poet

Panda Poet, our next Kindle game, just became available for purchase. Panda Poet is my take on an anagram-style word game boosted by an epic dose of procedural pandas.

 Just like with Triple Town, I played with several key design philosophies:
  • Designing from the root: Instead of expanding on an existing genre, I went back to first principles and re-evolved the mechanics using rapid prototyping. 
  • Evergreen gameplay:  Instead of making a series of fixed puzzles, I designed a system that results in an ever-changing playspace of meaningful choices.  
  • Gameplay first:  Instead of larding up the game with low bang for buck story, graphics or whiz-bang technology, I designed a clear set of game rules.  From these emerge layers upon layers of gameplay that evolve in the player's head as they master the system. 
The result is something that feels a bit different than your typical word game while still being easy to learn and difficult to master.  There's a stronger territorial element and while making words is easy, making the right word is an exercise in excellence.

I have one short lesson and one long lesson from this project.
  • Short lesson: Pandas are cute
  • Long lesson: First prototypes always suck

Short Lesson: Pandas are cute

One thing Panda Poet does much better than Triple Town is that it has a strong visual hook, specifically Pandas.  Though it could be sold as an abstract game of territory, I early on decided that letters convert into rectangular Pandas.  I built a very unique tileset with dozens of panda pieces that lets us make a panda of any size or shape desired. This means fat pandas and skinny panda.  Little pandas and huge panda.  Lots of cute pandas.

In order to bring players into the powerful and engaging value structure created by abstract game mechanics, you need to give them a doorway. Setting and theme are one of the single most powerful ways that you can draw new players into the game.  I was showing Panda Poet to a playtester.  After the playtest, she came up to me and said "I wasn't really paying much attention at first.  Then I saw the word Panda.  Pandas! And everything was suddenly awesome."

What happens is that with a single carefully chosen image or phrase, you can light up an entire area of the human brain.  Evocative past experiences and cultural references come rushing up to the surface.  Wham, the theme triggers biological instincts associated with googly eyes and cute rounded shapes.  The brain is primed with a set of patterns and expectations that make the game feel familiar, not alien.

In one fell swoop, the game goes from "abstract territory-based word game" to "The Cutest Kindle Game Ever.  With Pandas."  The meat of the game is still found in the rules and mechanics, but correct theme provides the light candy coating that gives players a reason to start the meal in the first place.

Kudos to our resident cutologist Aya for her essential work on getting the panda eyes appropriately droopy. Key.

Long Lesson: First prototypes always suck

The Feature Model

I had a good discussion at this year's Project Horseshoe (which was amazing...still recovering) about publishers and risk.  Whenever a game design proposes a new game mechanic, there is immense pressure that it succeeds the very first time.  Here is the standard feature-oriented thought process:
  1. From a production and software development standpoint, a new mechanic is a feature.  The logical thought is that a game increases in value based off the number of features they accumulate over the course of the dev schedule.  
  2. Dev time is insanely limited and valuable.  A game is only going to get a dozen or so features so every single one needs to count. 
  3. If you try out a new mechanic and it fails, then you've wasted valuable development time that could have been spent elsewhere.  As a result, you've directly contributed to there being less features in the final product and therefore less value.  Because you screwed around, the game may fail. 
  4. There is no way in hell that the team is going to spend more time iterating on something that obviously didn't work out the first time they trusted you. 
  5. The next time you suggest anything, it will be looked on with suspicion.  If your prototype design fails in a public enough fashion, you may have irrevocably damaged your reputation at the company. 

First prototypes always suck

Now this is where the reality of design gets dicey.  Every single one of the designs I've prototyped always sucks the first time. It really doesn't seem to matter how much thought I put into it.  Some designs have been honed by days of thinking, some by months, some by minutes.   Some designs are peer reviewed by programmers, by producers, by other designers.  Some are not.  And in every situation, the initial prototype is unplayable.   Early on, I assumed I was incompetent so I started asking around.  "Oh, yeah.  My first prototypes alway suck too" was the consistent response from dozens of veteran designers.

The minuscule chance of success decreases 
as the opportunity cost and weight of upfront design increases.

Admittedly, I generally work with new mechanics.  Certain systems like progression and level techniques are well understood and a bit more predictable.   And if you build the same game in the same genre three dozen times, there are handful of patterns that you learn are worth trying if you need a low risk success.  But for the other 80% of interesting design problems that arise, the first prototype alway sucks.

Panda Poet was no exception.  I thought it would be.  When I first wrote down the design, it was a thing of crystalline clarity.  The gameplay loops were perfect.  The feedback crisp.  I could play the game in my head to such a degree that if anyone asked a question about any permutation, it was trivial to mentally model the system from a particular angle and spit back the obvious result.

When Brian Tosch, a man of immense fortitude, programmed the first version of Panda Poet, it was utterly unplayable.  It wasn't his fault.  He created an impeccable translation of the rules into code.

A design written on paper and a design in your head is always a fluffy success story.  A design created in code (or a paper prototype) is a working machine that must function according the unyielding rules of player psychology.  The first is fantasy.  The second is unfakable physical reality.  And the reality was that the first prototype sucked.

So because we don't follow the feature model at Spry Fox, we iterated.
  • I looked for the minor moments of delight amidst the vast space of potential failure. Those subtle elements were amplified.   A good designer is a wise guide, not just a prophet. 
  • Secondarily, experience-killing flaws were identified, then removed.  A good designer is ready to cut in order to save. 
  • Within five or six iterations we had a playable game that is very close to its final form.  This is the fastest I've seen a design converge.  Many games takes dozens of iterations.  A good designer knows when to continue and when to stop. 

Design happened not as a risk-free proposal, but as an ongoing process of experimentation, failure, review and improvement.  Good designs converge over a series of experiments; they are never born full fledged.

The Feature Model is Busted

When a team demands that a designer's first prototype be a success, the reality is that they are asking that the project be saddled by a design that sucks. In in the words of Douglas Martin, "The alternative to good design is bad design, not no design at all."

Any design processes they have in place that seek to avoid failed prototypes are likely no more effective than ritually sacrificing chickens.  The document writing, the peer reviews, premature application of metrics, the incisive comments from producers and executives at best are a starting point.  At worst, they represent a massive opportunity cost that actively suffocates the iterative process of fruitful design.

How value accumulates in games

But what about the expense of iteration?  Surely that will sink a project by limiting the number of features that can be packed in. No. You are thinking about how value accumulates in games incorrectly.
  • A single game mechanic correctly executed is worth 10,000 times as much as the addition of a new feature. If this seems unreasonable to you, consider the staying power of Go, Tetris, Bejeweled or even Soccer. Then consider a feature-rich extravaganza like Warhammer Online.
  • If you can put one amazing game mechanic into your game, you can deliver more value to the player than if you managed to add 100 new features.
From this perspective, it is suicide to shut down the ongoing iterative process of design in order to ensure that you squeeze in more features before release.  We could have easily spent our limited time adding multiplayer or cute animations to Panda Poet.   Yet if the core gameplay didn't work, all those artistic and technological marvels would be impotent wasteful additions.


The primacy of the design process at all levels of game development is the one true path to creating successful games.  Large companies, built off the backs of designers and teams long buried, often believe that they can manage away risk by vilifying the time spent on the designer's expensive, iterative process of finding the fun.   As an unexpected consequence, they manage to destroy the very source of joy that drives players to purchase their games in the first place.   Sequel by sequel, the feature folks run their franchises into the ground.  Sadly, designers are either burnt out or reduced to muttering doc writers cowering in the corners.

It doesn't need to be this way.
  • Plan on your first prototype sucking.  It is a start, not a destination. 
  • Embrace iteration on failed experiments as an essential part of the development process.  
  • Honor designers for the skill and wisdom they demonstrate guiding the game towards a more enjoyable state.  
  • By following this process, you'll likely end up with a higher value product that contains more fun and fewer features.  
It must be stated that game development is a team sport.  Panda Poet would not be the game it is today without Brian Tosch's amazing dedication, programming or the thousands of micro-level design decisions he made along way.  Kudos all around.

take care

PS: If you have a Kindle 2 or Kindle 3 and live in the US, you should buy Panda Poet:

PPS:  It seems to be accumulating 5 star reviews.  That is always a positive sign.  For reference, our previous game, Triple Town remains the highest rated app on the Kindle.