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.


  1. I wish I had a Kindle so I could buy your games. My folks have two, so I'll see what I can work out. Thank you.

  2. Dan, do you think this is generally applicable, or is it specific to games?

  3. A huge problem with prototypes at the AAA end of the development continuum is that those teams are not optimized for rapid iteration. Teams grow too big too early in a project, usually because they're already marching towards vertical slice and they need to start making expensive art assets. If you've planned poorly, which is typical in our industry, you've got 20 people twiddling their thumbs because you're still iterating on core design ideas. That dramatically increases pressure to get out of prototyping and into production.

    Another aspect is that your exciting new feature may be something that is layered alongside a fully developed existing set of features. If you want to add a jetpack to a shooter, for example, you can't really experiment with the jetpack feature and learn its effects on gameplay until you've got the rest of the gameplay working reasonably well. That means you have to push prototyping a feature until well into development, by which time you've got a huge team and burn rate and you can't screw around with that damn jetpack another week.

    Ideally, a team building the Next Great Shooter or whatever would turn to some existing chunk of code and content. This might mean prototyping your game within Gary's Mod for Half-Life 2, for example. I know the team that did Shadowrun started with the Halo 2 codebase and assets and did all their gameplay experiments in there, not bothering to create new assets during prototyping.

    Our industry could definitely use strong guidance on how to do smarter prototyping on large-scale game projects. I think studios are too in love with getting their own stuff up and running and would rather spend their time on that than doing unshippable but vital creative work within someone else's code base & assets. And of course, if you show up at a publisher pitch with five-year-old assets from Gary's Mod, they won't care how great your gameplay is because they'll want to see it skinned with expensive art.

  4. Danc,

    Fact: When someone tells you that X is the one true Y, they're probably wrong.

    I do sense (from a distance) that you're headed *towards* something though, and I'd like to share my excitement about that.

    Keep doing what you're doing, it's obviously right.

  5. I'm a sad panda because I don't have (and frankly, don't want) a Kindle and thus I cannot play your games, which sound awesome.

  6. Those pandas look unfortunately like creepy skull heads. I need to stare at it for a while to convince my brain that the long black line is arms and not a mouth. And I can only hold that interpretation in my head for a few seconds.

  7. I wasn't really paying much attention to this post at first. Then I saw the word Panda. Pandas! And everything was suddenly awesome.

  8. Great. Now I can't unsee the skull-heads.

  9. Mory, I had the same problem! ;)

    Is it impossible to buy this content outside US, or is it just because the SDK is still in Beta stage? I'm planning on buying a Kindle 3 and getting the KDK... Sounds like a great platform for developing certain kind of games (and reading books)

  10. Thanks so much for posting about the experience of design Panda Poet and Triple Town. I'm not a game designer, but I do work on mobile phone applications, and it's really inspiring to see such excellent and innovative products coming as a result of a well-thought-out design process.

  11. It would be awesome to have a PC port of the games :) All of us without a Kindle want to play it.

  12. i prefer the iPad... It just seems like the "copies" is good when they arrive, but with the next release of iPads they are behind again... lots of competions this days to win one as well, if you dont have one... Have you noticed the new campaign from the it security company sophos... easy to win if you like to share things... :) mostinvincible.com

  13. I would love it if somebody reviewed panda poet and triple town..

  14. Wait a second...

    "If you've got gameplay magic, bottle it up and spread it wide and far."

    Why do PP and TT only run on Kindle then?

  15. "Why do PP and TT only run on Kindle then?"

    Despite the fact that Spry Fox has released 4 games in 3 months, I've had to face the hard, cold reality that game development is not instantaneous. ;-)

    We'll have to have a 6-month retrospective to see how our Spry Foxen development strategies are working out. I know...6-months...an eternity.

    PS: There are about 50 reviews of Triple Town up on Amazon.com. They are far more statistically significant, reflect the target audience more closely and are less polluted by bizarre financial incentives than any review that you will find on an official gaming site.

    See: http://www.amazon.com/gp/product/B0045XUX7I/

    take care

  16. Ah, I meant to say "video (review)" (who has the time to read these days ;) - still trying to force me to read the "triple town / the problem with puzzles" article here)

    I noticed there is kindle software for win/mac but it's not possible to play games using this software if I understand correctly.

  17. "who has the time to read these days ;)"
    Maybe people who own a Kindle :D

    I would have bought your app if I had a Kindle, it seems very interesting, and I am curious to test a new kind of game.
    It would be cool if there was some flash version around...
    Congratulations for your work.

  18. There's a corollary here which I'm only recently starting to accept. The "funnel model" (which I've been spouting off about and believing in up until recently) where you make a bunch of prototypes and pick the most promising one(s) is broken - because almost all prototypes suck at first.

    And yeah, I've had the same experiences.
    Spider-Man 2's swinging mechanic was invented for Spider-Man 1, and it sucked at first so we buried it. (And I stubbornly dug it up again later.)
    Schizoid was originally just uberschizoid, a mind-bending one player game that almost nobody (but me) liked - good thing Richard suggested to make it co-op.
    And none of our other work has quite made it out of the "this sucks" phase yet...

  19. Dan, I live in Japan and, along with several friends, would love to try both Triple Town and Panda Poet. Is there any way we can acquire your games?

  20. Did you make up the song that you play in the game? It is very cute!