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: http://amzn.to/cOnHOD

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.