What the heck happened to Clippy? Ribbon Hero 2 released
Posted by Lost Garden [HTML][XML][PERM][FULL] on 26 April 2011, 3:37 am

Last year, Ribbon Hero, a game that teaches people how to use Microsoft Office came out.  It was one of the few gamification projects that tried to be an actual game instead of being just lame slathering of points and achievements.  Now comes the sequel.

David Edery and I have been helping the team over at Office Labs take that initial experiment and fulfill its fascinating potential.  I'm super proud of what Jen and crew made.  You can download Ribbon Hero 2: Clippy's Second Chance at http://www.ribbonhero.com

In it, you find out what the heck happened to Clippy after he was fired for being...well, an internet meme for failure.   'Tis a lurid tale of shame and angry mobs.  Apparently a spoonful of narrative makes it far more likely that folks finish.

Lessons in gamification

I've worked with a large number of teams on the applying game design real world activities.   Not all are successes. Why did the Office Labs team succeed in releasing a polished, effective, enjoyable game when so many gamification projects fail to live up to their goals?  Here's my take:

  • Identify the core game loop:  Ribbon Hero is a game first and foremost.  At the heart of the game is a light challenge where you demonstrate your knowledge of using Office.  The team searched for and found a fun activity to build their product around.  Very few gamification projects invest in the extensive prototyping necessary to identify their core loop.  As a result, they end up throwing away their budget  finishing a crap core mechanic. Your team needs to be willing to iterate in order to converge on the fun. 
  • Support the core game loop by killing extraneous features: Most application teams believe they win if they complete features.  A good game wins by providing a great experience and more often than not this means actively removing and streamlining features.  Any feature that isn't fundamental to the core game is a stumbling block.  New features that cause confusion actively destroy value. Ribbon Hero 2 has fewer features than Ribbon Hero 1, yet is a substantially better game.   I've noticed this key concept goes against what most application teams dream about at night. Your team should adopt the mindset that features are your enemy and subtract all those that do not support the core loop. 
  • Master the art of polish:  Game mechanics are like musical instruments, not patterns you apply and get some predetermined result.  The difference between a well-executed point system that supports a player's intrinsic motivation and a pre-packaged leaderboard API is the difference between a violin concerto and some imbecile screeching away on a busted fiddle.  Polish matters.  A good team takes the extra months to smooth away rough edges, emphasize rewards, add tiny details and make the entire experience glow.  During polish, no new features are added.  Instead, you observe and live with the game, making it better in a thousand little ways. 
  • Get long term buy in:  A game project often costs 3 to 10 times as much as a basic feature that serves the same functional task.  During large parts of the project (prototyping, early production and late production) the project appears to either be completely schizophrenic or stagnant with little visible change.  Very few companies other than game companies are culturally capable of dealing with such frustrating progress signals.  The Ribbon Hero team trusted the process of game development enough to double down on resources and extend the schedule when they needed.  Your team needs to do the same. 
  • Willingness to learn:  The team knew nothing about game development when they started. Instead of taking the easy path and trying to turn a game into an application, they admitted that their previous expertise wasn't enough.  In an act of humbleness that I find rare, Jen and crew buckled down to the task of learning a radically new discipline.  They visited GDC, participated in game design workshops, prototyped crazy ideas, and trained themselves to foster moments of delight. They found out that game design is to application development what dance is to running. And in the end, after years of training (and re-training), they learned to dance. 
Very few teams successfully apply game mechanics to real life because making a game is an exhausting iterative activity.  It takes immense political will, dedicated resources and deep belief that the right experience, not just the right feature, can change the world.   Games are no silver bullet.  Instead, real gamification is a master-level exercise in passionately pursuing great usability and user experience.  Most such projects fail because few teams have the skill, the patience or the values to pull off making a great game.

Was it worth it?  The metrics will be the final judge.  However, I joked with the team that if the Ribbon Hero managed to get played by enough people, it is likely more effective at helping Microsoft's brand than any of the last billion dollars they spent on PR.  This simple game is probably the most human thing to come out of Microsoft in years.  Take that for what you will, but I'm happy to have been part of the journey.

take care,

GDC 2011: The Game of Platform Power
Posted by Lost Garden [HTML][XML][PERM][FULL] on 17 March 2011, 8:20 pm
Here are the slides and notes to my GDC presentation, "The Game of Platform Power".   In our industry, history repeats itself again and again, but each new generation of developers often fails to learn past lessons.  Platforms in particular have a well established life cycle and their relationship with a developer changes as they mature.    Yet, I regularly see developers completely caught off guards as their new favorite platform suddenly stops being their friend and starts treating them as a harvestable resource.  Don't be surprised.  This is the way of things and it has happened dozens of times in the past.

My small hope is that by naming and illuminating some of the common phases and practices of platforms, developers will be able to better deal with the inevitable shifts.  I would like nothing better than smart game developers to divorce their businesses from the platform life cycle and build direct relationships with long lasting communities of passionate gamers.

Gdc 2011 game of platform power
View more documents from Daniel Cook.

I will note that I have nothing against platforms despite what my occasionally spicy rhetoric may suggest. I respect and appreciate them like a biologist appreciates a large predator. I've personally walked many miles in the shoes of platform developer. (I spent 10 years building platforms and I loved it.) It is a hard path and platforms do their best. However, ultimately I feel it is better for everyone to be a strong advocate for the users and the game developers that directly serve them.  In the long view of history picture, these two are the essential players.

take care,

List of Game Artists
Posted by Lost Garden [HTML][XML][PERM][FULL] on 9 March 2011, 9:17 pm

A very large number of game developers come to Lostgarden looking for game art. (Apparently I'm on the first page of results if you search for 'free game art')

Of those folks that show up, some are happy to find my collections of free art.  A whole slew of other write me asking if I can make art for them.  Unfortunately I haven't done contract art for decades and now pretty much exclusively focus on game design.  My artist days happened about three careers ago. :-)  But still I hate the idea of not being able to connect talented teams with amazing artists.

This post is an experiment.   If you are a talented artist looking to do freelance game art, add the following information in a comment below:

  • Your name
  • A link to a gallery of your work
  • A note on if you are wiling to work for revenue share or you prefer upfront payment only. 
  • Some means of contacting you.  For example bob [at] gameart.com

The goal is to build up a living directory of talented game artists.  If you've worked with an artist on a game and you know they are open for work, do them a favor and post their portfolio here using the format above.    Post a link to this page on any forum or list where game artists hang out.

All the best,

PS: I'm actively looking for an illustrator for a project, so if you post a link there's a good chance at least I'll be checking out your portfolio. :-) (The current gig involves dozens of adorable panda illustrations.)  And there seem to be an unending stream of new projects that need art rolling into Spry Fox all the time. 

The Declaration of Game Designer Independence
Posted by Lost Garden [HTML][XML][PERM][FULL] on 5 February 2011, 4:32 pm

On a cool, clear Austin weekend, a group of experienced game designers gathered for their yearly retreat.  At night they swapped stories of an industry in turmoil.  As social games and mobile games rewrite the landscape, power struggles between business and design dominate and designers find themselves being sidelined or abused.  And the products they work on suffer horribly as a result.  It is a time when musty old assumptions are questioned.  It is also a rare opportunity to identify universal best practices that can help us navigate new platforms, new genres and new gaming experiences.

So during the day, we asked ourselves some hard questions.  When was design successful?  How do designers hurt their own credibility and effectiveness?  This is a group that has shipped hundreds of games serving well over 100 million players. Over the past two decades, we've personally seen game titans rise and fall.   Surely there are patterns and cycles.  So we listed dozens of examples of great design environment and dozens more of times where design remained shackled. And over and over again, the same themes came up.

To guide game designers and the profession forward we wrote down a Declaration of Game Designer Independence. This document is primarily for the designers who run their own companies or the creative directors who own the creative process.  It is also for the designers in the trenches, who aspire to a leadership role.

The following is a code for how great, visionary designers should behave. It rises up from an immense well of hard fought experience accumulated over decades of real world design.  When followed, these practices sustain an environment where design thrives and revolutionary games are regularly brought forth into the world.

The Declaration of 

Game Designer Independence

1. Without game design, there is nothing

You can get rid of visuals, music, business or technology and we will still make great games.

2. Designers must drive the vision of the game

We are prime movers, not replaceable cogs.

3. We dedicate ourselves to the lifelong mastery of design

Dilettantes need not apply.

4. We strive to be renaissance designers

We fluently speak the languages of game development and business:
  • We speak the language of creative. All art and music ultimately serves the game play.
  • We speak the language of production. Game design determines the scope and need for the content that production shepherds.
  • We speak the language of engineering. Technology is one tool that enable the experiences designers choose.
  • We speak the language of business. Modern monetization, retention and distribution are directly driven by game systems.

5. We will not be silenced

We tirelessly promote our vision both internally and to the public.

6. We fearlessly embrace new markets and trends

We then reinvent them to be better.

7. We demand the freedom to fail

Design advances through experimentation.

8. We have a choice:

Create with our own voices or sell our talents into servitude.

My personal thoughts

Not everything here is easy.  To live up to this declaration, you likely need to be a better designer than you are right now.  Still, always remember:  You are not a slave. You are not a servant.  You are not a cog-like employee.  You are a creative force.  And most importantly you have a choice for how you wish to spend your time on this earth.  You can choose to take control of your life and change the world for the better in the process. 

I personally left a large company with a steady paycheck in order to take control of my creative destiny.  Now I've got multiple game designs speeding towards completion, I'm working with people with souls and the future looks amazing.  This is easily the most productive and exciting time of my life.  And the only reason it happened was because I realized a fundamental truth:  Design works best when it leads, not when it serves. 

If you support the Declaration, drop a comment below. 

take care, 

PS: For a more in-depth look at our report, check out the Project Horseshoe website.  There are some wonderful reports this year. 

Happy 2011: Celebrating frontiers in Game Design
Posted by Lost Garden [HTML][XML][PERM][FULL] on 31 December 2010, 7:51 pm

When the frontiers go away, culture turns inward and begins rotting.  For a brief period of time at the turn of the century, we saw our beloved game industry fall into the trap of thinking 'there is nothing new under the sun' as risk adverse publishers and platform owners made bigger bets on more-of-the-same.

Thankfully, new frontiers emerged as the old inward looking industry has shattered into multiple billion dollar markets seeking to bring gaming to the rest of the world. Mobile and Social games are just the tip of the iceberg of the evolutionary explosion that is pushing games into every crevice of society. Look around! The grand spirit of exploration and innovation is once again thriving like almost no other time in gaming history.

To ring in 2011, here is a list of frontiers in game design.  This list is not complete, but it gives some hint at the vast breadth of games still left to be designed.  If you come across someone who claims that all games have already been designed or that game design is a solved problem, show them this list.  And then challenge them to stop fiddling about with over-exploited games from decades past and make something new and wonderful that will change the world.  Go west, young man.

What is a frontier?

My rules of thumb for defining a game design frontier:
  • Can you easily create a new genre of game?  A game like Flight Control defines the line drawing genre on mobile devices.  This is an entirely new and deep placespace that designers will be exploring for years to come.  
  • Can you use an old genre to reach a new audience?  It doesn't matter that social games use systems beloved by 14-year old boys playing BBS door games 20-years ago.  The frontier arises from adapting those systems into a game enjoyed by 45-year old moms. 

Frontiers in Game mechanics

Game mechanics are the systems that beat at the heart of the game.  They are unique combinations of rules, feedback and interfaces that create a playspace within which the player gains deep skills.  Of all the frontiers, new game mechanics creates the boldest and most wide ranging opportunities. 
  • Social games:  Games that tap the social networks in order to improve relationships and facilitate developer controlled distribution.  Facebook has staked out an obvious stand, but email, mobile phones and Twitter all have roles to play.  Any system where you can communicate asynchronously with other people enables social gameplay. Think big and don't be blinded by erudite idiots flapping their lips about Farmville.  One lone tree does not define the forest of opportunity. 
  • Board and card games:  The wave of new design that came out of Germany is still spreading and recombining in new ways. New mechanics appear on a regular basis and new genres (such as the deck building game popularized by Dominion) keep popping up.  Board games are the ancient soul of game design and the fact that innovation is still possible after thousands of years gives me immense hope for the future of games. 
  • Touch-based game:  All games are built of a foundation their most fundamental interactive verbs.  For years, the most basic verb has been 'push the button'.  Now we have a radical new vocabulary of swiping, flicking and pinching.  If a platform game is about the joy of movement using buttons what foundational new genres will emerge from touch interfaces? 
  • Motion-based games:  Take all the possibilities of touch-based gaming and multiply the design challenges by 10x.  Using the human body as a controller rips asunder our most basic assumption of how to interact with a machine. Also our bodies are intimately tied to how we feel emotion and experience the world. There are deep skills and new pathways of applied psychology just waiting to be turned into games. 
  • Story games:  The old genre of roleplaying games has spawned a new set of stripped down mechanics that minimize combat and maximize player generated stories. 
  • Art games:  How can systems convey messages?  Jason Rohrer's work exemplifies both the aesthetics and the power of this game design movement. 
  • Performance games:  Game no longer need to exist in the living room.  Performance games involve groups of people coming together to play new games.  They turn streets into a Pacman games or Grocery carts into a multi-player game of Asteroids. 
  • Music games: A product such as Rock Band 3 hints at what can happen when games help unlock mastery of centuries of music and culture.  Games can act as training systems that rely on intrinsic motivation and are scalable to millions at minimal incremental cost.  At stake is nothing less than the radical commoditization of learning to play music by reducing both monetary and psychological entry barriers.   
  • Exercise games:  What if exercise was social, inexpensive, varied and fun instead of a repetitive, expensive chore?  The new generation of gamers will be athletes, not couch potatoes.  The next 5-year increase in human life span will come from gamers living healthy lives reinforced by the games they play. 
  • Gamification:  Games are applied psychology and can used to improve the experience of almost any process in the world today, from blogging to CRM to using Microsoft Word.  Games are the next evolution of modern user experience and usability design. Instead of merely asking how to make a task possible or efficient, games ask "How do we transform a task into a delight?"  Games can return humanity to the mechanical processes of the modern world. 
  • Location games:  As mobile phones with GPS proliferate, we can track our position in the physical world across huge populations of potential players.  What are game designs that make location and a sense of place matter?
  • Pan-media games: Alternate reality games weave stories and community driven puzzles across websites, social networks, TV ads, chat, toys and print.  How do we make powerful games that layer an alternate world over the top of our world and enable communities to interact with our evolving dance of creation using all the modern media available?  Why limit yourself to a single screen?
  • Augmented reality games:  Image processing lets us place virtual objects in images and video, annotating and transforming the everyday into reality plus. 
  • Creativity games:  When you ditch the idea that games are acts of absolutely authorial control, you realize that the act of playing is an act of creation. Let's multiply this player impulse, not constrain it.  User generated content games like Minecraft or Spore hint at the creation of of dozens of future communities of creative individuals.  Inside these community are artistic works enabled and facilitated by the game worlds we create.  What happens when designers give up direct authorial control and empower millions of players to build a utopia?
  • Conference games: Anywhere there is a concentration of like minded people, you can build a game that creates deeper connections.  A slew of conference games, played with pamphlets and business cards transform the often unreliable networking process into a joyful act of structured exploration.  Can you help connect the minds of the professionals who are busy pushing forward business, research and more?
  • Education games:  At the pace of a tortoise moving towards a treat spotted many hours ago, the educational community has started making educational games worth a damn.  Since games enable players to gain an experiential understanding of complex models, they are one of the few ways of teaching wisdom instead of rote book learning. The tricky bit? Games are great at teaching, but you need to make great games first and foremost.  The influx of real game developers driving the efforts has produced wonderfully playable titles like CellCraft and there are dozens of similar projects occurring throughout the world. 
  • Massively concurrent games:  What games can you build with 10,000 people playing at once?  1 vs 100 was a start, but there are opportunities in stadiums, movie theaters, flash mobs and of course online. As populations of players scale, the psychology of player inactions shifts and entirely new designs need to be deployed.  Yet the payoff is impressive; if 100,000 people spent fifteen minutes doing something meaningful, what could they accomplish?
  • High retention games: With the advent of metrics, we are finally realizing how few people play our games for any length of time. The last third of your game?  Sorry, didn't play it.  Metric combined with iterative design finally give us the power to turn our games so they actually work as we think they should work.  With the next generation of metrics, we are gaining new insights into intrinsic motivation.  What makes people tick?  What makes them happy?  What improves their lives? As a result, we have the tools to make better games. You can no longer fake it and try to claim success with handwaving comments about art and meaning.  If your game sucks, people leave. Can you make empirically validated games that deliver enough meaning and value that smart, informed people want to play for long periods of time?   

Frontiers in Business models

  • Games as services: For much of the past two decades, games have been treated as consumable media: you play a game, beat it and move on to the next tasty treat. When a game is run as a service, we are running an endless game that grows and evolves with the community.   Most are inherently multi-player and can just as easily be described as economies, governments or clubs as they can a game.  Such games are not media.  They are entirely new cultures, some of which will outlive their creators.  
  • Free-to-play games:  Games have finally broken free of the shackles of a single fixed price model.  Now players can try a game, see if they like it and pay a little or a lot in order to experience more. This single development opens games to massive audiences that never before would have paid 60 bucks for a new experience they may not enjoy.   
  • Downloadable console games:  With smaller download budgets and long tail competition, larger developers are forced to give up many of their wasteful AAA ways and find the fun in small packages.  Though platforms and publishers are desperate to maintain their to old and demeaning practices of control and leverage of contractually enslaved developers, market pressures have so far enabled small bursts of innovation to flourish on consoles for the first time in many years.  Enjoy the now fading days of summer while it lasts. 
  • Downloadable PC games:  The indie movement combined with relatively hands off distribution partners like Steam offer both a means of making money and freedom to create new types of games.  Online communities help drive marketing and it is telling that the downloadable smash hit of the year, Minecraft, came out on PC, not the console. 
  • Sponsored games: Traditional companies have awoken to the fact that hundreds of millions of people play games and they want to either own this ability (Disney) or to have the experiences that games create associated with their products. 
  • Viral distribution systems: Developers are traditional screwed because middle men control monetization and distribution.  Viral distribution systems lets savvy developers empower players to distribute their game, reducing the power of the middle men and freeing developers from entangling relationships. 
  • In game payments and offers: The vast array of payment system puts monetization in the hands of the developer, not the distribution channels, creating a new path for developers to gain independence from the sharecropping models practiced by publishers and retail channels.  There are rotten spots growing in the form of Facebook and Apple's emerging payment monopolies.  Ultimately, the value driven by the game design is what player are buying.  With this in mind, smart developers should carve out niches where they keep the majority of the value and payment providers are slowly but surely forced to become low cost providers of baseline services.  
  • Publicly funded games: Outside of the United States (where we are still arguing about evolution), games are considered a meaningful art that contributes to the economy and culture of a country.  Canada, Australia, Singapore and many others offer low cost grants for teams that want to make games.  Most new teams need a traditional publisher like a slave needs an owner.  

Frontiers in platforms

  • Browser games:  Browsers are everywhere and games played in browsers represent one of the largest gaming platforms on the planet.  Flash is the current mainstay and 3D is barely present in the form of Unity.  But the important thing about browser games is the reach.  
  • Mobile games:  We are starting to carry games with us wherever we go.  What will you do with a billion potential players, always on internet, GPS, address books, in-game payments, augmented reality and a device that is within reach every waking second of the day?
  • Tablet games:  Games for tablets mean new UI conventions and new multiplayer models (gather everyone around the table)  The cross pollination between tablet games, smartphone games and board games is going to create some inevitable classics.  
  • The plethora of screens:  eReaders are really just the tip of the iceberg.  My electric toothbrush has a screen now and I play a game on it every night. Anything with a screen can play games.  They don't need to be fast screens.  They don't need to be big screens.  Great games happen in the player's head.  All we need as game designers is some basic feedback systems and an input method.  With that, we can put games anywhere. 

Fading opportunities

There are really only three fading opportunities that come to mind.
  • Retail games:  The retail market has long been a cesspool of corrupt distribution practices, crippled monetization, entrenched middlemen and oppressed developers meekly serving the Man.  It is still possible to innovate here, but your chances are reduced by an order of magnitude for every layer of management piled atop the line developers. 
  • Casual games:  There are three, maybe four stagnant genres left powering (Hidden object/Adventure, Time management, Match Three) the casual games market.  With the deadly drop in prices during the recession and the enormous power of portals like Big Fish, developers have retained almost zero bargaining power.  Innovation rarely flourishes and the deadly creep towards bigger budgets and winner-takes-all releases is in full swing.  Games with bloated production values like Drawn just make me sad.  We've been there.  We went down the path of prettier graphics.  Notice that the adventure genre has died before?  Ever wonder why?
  • MMOs and virtual worlds: Somewhere along the line, the MMO genres calcified. Old mechanics turned into religious commandments, bright experiments floundered and innovation stopped. Instead of building better games, we got prettier graphics and more baroque consumable content. The next deluge of overstuffed AAA games just hasten the genre decline with their expensive and inevitable implosions. There was a brief ray of hope with F2P RPGs and kids MMOs, but this spurt appears short lived.  The interesting lessons of these games have been stripped out and rendered down into the overly simple rules that drive many social games.   I have some hope.  It is still possible for independent companies to enter the market without the help of publishers/operators and create a new game that turns genre conventions upside down.  If anything, it will be a team from the social games space or the browser space.  Such a team could create an accidental variant of an MMO that ends up reigniting the market.  Fingers crossed.


In the past few years, we've seen the emergence of two multi-billion dollar markets in the form of social and mobile games.  This is only the beginning.  Expect another billion dollar market to emerge in the next 5 years and at least three new billion dollar markets to pop up over the next ten years.  The game industry is dead.  Long live the game industries.

The people who tap these opportunities will not be those that stayed at home sucking down a steady paycheck from an aging company mired in incestuous politics and egotistical dreams.  It will be the designers who strike out and tackle the frontiers head on.  Be the settler of a dangerous new land.  Define the new face of games for the coming decades.

Happy New Year.  May you have an amazing 2011.

PS: Big thanks to the crew at Project Horseshoe and Nick Fortugno in particular for starting this conversation one late night when we had absolutely no right to be up and still talking.  What are we? Giddy teenagers at a sleepover?

Story as evolutionary success or failure lessons
Posted by Lost Garden [HTML][XML][PERM][FULL] on 12 December 2010, 2:32 am
Idle thoughts for a rainy December evening.

Viral player stories.  When you create games with deep systems, player run into amazing, emergent scenarios on a regular basis.  From these moments of player experience grow myths and legends.  Players tell them.  Press repeats them. Your game goes viral without requiring any of the whirring, queasy machinations of your local social network dealer.

Why does this occur?  It happens without prompting.  It requires no points, no bribes.  It is as if, after the right experience, the urge to tell stories bubbles up innately from inside even the least imaginative human.

A story, at an evolutionary level, is a lesson in success or failure intended to improve the survival rate of the tribe.  This is why we create them.  This is why we share them.  This is why we consume them.  Like play, story (even fiction) serves a function. Good stories were at one point a matter of life, death and reproduction. Humans have a nose for truths and when we spot them amidst the maelstrom of daily experience, we instinctively share them.

When we, as game designers, create meaningful systems whose depths are only revealed after a process of deep mastery, players instinctively extract stories from their experiences within these playscapes and pass them on to their friends and family. "When I kicked the soccer ball, my foot slide on the wet grass and I heard a distant sickening crunch in my knee." To experience a unique lesson that you've learned in your bones after a thousand trials is to hold a treasure.  And being human, we can't help but share. Over and over and over again.

A critical realization for a game designer is that meaningful success and failure, the basis of stories, can only exist in the context of the systems and value structures we design.  A gripping tale of trust crushed in a game such as Eve exists because a designer made a very explicit set of rules that defined the concept of economic value and politics and trust.  Remove the value structures inherent in the design and the stories go away.

One sign of a great game is therefore not the story that the designer tells, but instead one that contains mechanics robust enough to yield player experiences rife with lessons that must be shared. As an exercise, look at the mechanic (apples, trees, 9.8m/s^2) and the story of gravity (Apple falls on Newton's head) as two distinctly separate elements. The designer's role is not to tell the story of Newton and the apple. Players will perform that service just fine.  Instead, our unique role in the process is to define and polish the system of gravity.

Don't build games in order to tell a single story. Build meaningful systems that create an explosion of culture, spread by the players who are absolutely thrilled to share what they've learned.

take care,

Nethack, Populous, Lemmings, Sims, SimCity, Minecraft, Spelunky, Fantastic Contraption, Dwarf Fortress, Team Fortress, Ultima Online, Civilization and some I've forgotten.  Any others that you feel compelled to share?

Steambirds: Survival: Goodbye Handcrafted Levels
Posted by Lost Garden [HTML][XML][PERM][FULL] on 3 December 2010, 12:53 pm

Steambirds: Survival, the sequel to our original steampunk airplane strategy game was just released today.   You can go play it right now at Steambirds.com.

Steambirds: Survival takes place on a grim fall morning at the start of the Battle of London.  The British forces are taken by surprise as thousands of Axis steam-planes descend upon the doomed city.  Outnumbered and outgunned, your heroic mission is to delay the invaders long enough that a handful of civilians might escape the genocidal gas attacks.  You have one plane.  How long can you last?

David has a great post about how we integrated microtransactions, but today I wanted to focus on a couple of design lessons that came up while building Steambirds: Survivial.
  • Removing handcraft levels as a method of finding deeper fun
  • Create game modes, not levels 
  • Corollary: Focusing on static levels decreases the depth of your game.

Find deeper fun by killing levels

Steambirds: Survival started with the observation that the core mechanic of maneuvering planes was fun independent of the level design.  When we were building the first game, we'd toss in enemy planes nearly at random and interesting combat scenarios would emerge.  My personal design process is highly exploratory:  I examine a working prototype, identify whiffs of an opportunity and then attempt to amplify those desirable moments in the next iteration. The lack of levels was one such opportunity.

What if we built a version of Steambirds that relied entirely on randomly generated levels where planes came at you in ever increasing waves?  In essence, create the Steambirds version of Gears of War 'Horde mode'.  This path harkens back to the escalating arcade mode found in Asteroids, Space Invaders or most traditional arcade games.

At first, we randomly spawned planes and saw how the game played out.  Then we polished the systems until the game was fun to play every single time. I observed several higher level attributes of this design process.
  • No preferred perspective: We were forced experience the gameplay from a variety of perspectives.   When I create static levels, it is  easy to quickly fall into a rut where I start polishing the experience for one or two 'correct' paths.  If a specific scenario is too powerful, I might simply adjust the health of an individual enemy instance so the player has less difficulty. The result is localized polish that translates into shallow gameplay. With random levels, this class of tweaking is impossible.

Fig 1: Polishing a single scenario and a single success path leads to polishing only a narrow portion of the playspace
  • System-level iteration: In order to polish the experience, we instead needed to iterate and polish at the system-level, not the content level.  Most changes occurred in the planes, powerups and scoring. These are systems that affected the entire player experience.  In the end, a much broader playspace ends up being polished. 
Fig 2: Polishing a variety of scenarios leads to polishing a broad set of systems that yields a deep playspace
  • Depth through new systems:  When the game wasn't engaging, we added new systems such as having downed planes drop powerups. A more traditional approach might be to manually create more detailed scenarios with surprise plot points where a pack of planes pop out of a hidden cloud when you collide with a pre-determined trigger.  However, by instead focusing on new general systems, we created an entire universe of fascinating tactical possibilities.  Do you head for the heal powerup or do you turn to face the Dart at 6 o'clock?  That's a meaningful decision driven by systems, not a cheap authored thrill. 
The self imposed constraint of avoiding the creation of static content in the form of hand crafted levels resulted in a game that is in my humble opinion, more enjoyable than the original Steambirds.  Personally, I'm going to continue using this philosophy of limiting static levels in future games because I see the following benefits
  • More game for less overall effort:  You can play Steambirds: Survival for dozens (if not hundreds) of delightful hours.  Yet development time was considerably less than if we had handcrafted an equivalent number of puzzle levels. . 
  • Deeper gameplay with a longer mastery curve.  I've played a lot of Steambirds: Survival and I still find new skills and tricks that keep me coming back.  At a certain level of depth, a game transcends being a disposible blip and turns into a life-long hobby.  We aren't quite yet at a hobby-class activity with Steambirds, but this design process inevitably leads us there.  As a designer, I feel like I'm wasting my life when I create a disposable game. I feel like I've contributed in a meaningful way if I can create an evergreen activity that attracts a community that last far into the future. 

Create game modes, not levels

As designers, we have access to a much broader exploration of the space created by a set of game rules than is available to the player.  During development, it is common to run crazy experiments where speed is doubled or health knocked down to nothing.  Most of these variations are unplayable, so we chop them from the final product.

Yet a handful of tweaks end up being fascinating.   I think of these areas much like the Goldilocks zone for planets.  In order for life to exist, a planet must be close enough to the sun to be warm and far enough away so that it isn't boiled.   These two factors create a thin band around a sun in which a habitable planet may exist.  The same thing happens with games.  You push a particular variable to far and the game stops being enjoyable.  But within a certain range, the possibility for fun exists.  This experimentation helps use define the valid playspace for a particular set of mechanics. 

For Steambirds Survival, we took some time to discover the limits of the combat system.  We spent hours tweaking various variables, and testing to see if they were fun.  The goals was to build a multi-dimensional map of where the fun lurked in the Steambirds mechanics.  In the end, we took snapshot of the various gameplay variables in 24 initial states and saved these out as unique planes that you can play.  The long range sniping Aught Nine plays quite differently from a delicately swooping Chickadee-S518  The result is really 24 game modes, each of which is infinitely playable.

Level design vs initial conditions

How is this different from level design?

  • Instead of creating content that can be enjoyed only a handful of times, we are setting up game modes that can be played a very large number of times. 
  • How each mode unfolds is primarily determined by game mechanics, not a set of scripted events.  As a result there is a very wide range of possible scenarios, not a single predetermined outcome. 
  • Modes are modular, robust and loosely coupled so that tweaking critical values is rarely damaging to the mode's fun.  Level design is fragile because you are trying to squeeze fun out of a very narrow playspace.  One tiny mistake and the experience is broken. However, when you have a big broad playspace and you've plunked the player smack in the middle of a wide Goldilocks zone, you have a lot of room to push variables about without harming the rich pleasures of the game. 

Mapping the playspace

Here's the process I used to map the playspace and create the various play modes. 
  • Identify: Identify the variables.  Many of the important variables in the original Steambirds were hidden away in code.  Andy surfaced these in an XML file so they could be readily tweaked. 
  • Explore: Methodically explore the space.  I created a matrix of planes, each with one variable pushed to the extreme.  Then I played them.   The majority were unplayable and I'm not sure a single one made it into the final game.  However, through the process of testing concrete variations, I gained a sense for what worked and what didn't.  I was mapping out the Goldilocks zone. 
  • Theorize:  Now that I had some data, I created theories for fun planes.  "I think that a slow, short range plane that needed to trap enemies in webs of poison trails would result in interesting tactics" 
  • Test:  Then I would change a few variables and try it out.  Did the theory yield a new way of playing the game?
  • Refine: At this point, we'd iterate on the plane many, many times to get the feel just right. 
  • Cull: We made a lot of planes.  Some were more fun than others so those got chopped and the good ones stayed.   This follows the philosophy of designing from a position of plenty, where you are overflowing with good content and can choose to put forth only the best. 

    Static levels decreases the depth of your game

    Let's take a step back and look more broadly at what this simple observation means for the industry at large. There is a very real opportunity cost associated with creating static level content.  In fact, it is baked into the pre-production and production stages suggested by the popular Cerny method of game development.  During preproduction, you test and finalize your game mechanics.  By locking down your game systems early on, you reduce your production risk when building  large amounts of static content.  Heaven forbid you change the jump distance on your main character after you've built 20 expensive levels based off that value.

    At first glance this staged approach seems like a sane and rational practice. In fact, it originally came about as a way of giving design a place to iterate within the increasingly rigid development schedule. However, it also requires that you limit your iteration upon your mechanics at some point in your schedule.   Yet such a design lock down conflicts with how design actually occurs in the real world.

    Consider the common scenario: a designer, after playing the game for several months, finally groks a fundamental relationship in the system that will make the game immensely more enjoyable. This actually happens all the time...designs often need to sit for a while before they reveal their true nature.  We are closer to mathematicians exploring a new class of equations than we are authors banging out another variation of the Hero's Journey.  And like mathematicians, insight rarely occurs on a predictable schedule.

    In a procedural game, a new design insight translates into a quick experiment that tests the idea.  Many of our big design changes in Steambirds: Survival took minutes.  The largest, a new progression system, took a week.  In a game with a heavy production burden, a new design insight instead provokes immediate push back.  Almost all other disciplines have something to lose since almost any mechanics change occurring in the middle of production has two follow-on effects:
    1. Design changes during production threaten to invalidate many man years of labor.  The producer sees a threatened schedule.  The level designers see destroyed levels.  The gameplay programmers see destroyed scripts.  The narrative designers see altered plot lines and discarded cinematics. The reality of modern development is that any design change in production has a large political cost
    2. If the change is accepted, large amounts of new content needs to be implemented.   Even if the design change is the right thing to do for the player, it is often economically not feasible.
    As a result, polishing and improvement on the game design is almost always locked down prematurely.  It is not random chance that nearly every postmortem wishes they had a longer preproduction phase.  The entire Cerny method creates logistical constraints that unwittingly damage the team's ability to build and iterate on deep and meaningful systems.

    Agile methods help here by allowing teams to lock down content on a more modular level, but this is a patch,  not a solution.  Ultimately static content is inherently difficult to refactor.  The marginal cost to change content is often equal to original cost of creation.  The reliance of the design on structurally brittle content like levels and narrative lies at the root of the problem of premature design lock-down.

    After many years of living this reality, modern AAA development teams have retreated from most meaningful exploration of deep game systems.  Over time, economics and production logistics shape design as surely as the currents in the ocean shape the rocky shoreline.  If you look at games like God of War or Uncharted, you see the end result:  Mechanically safe and simplistic games heavily larded up with a constant streams of static content.  There is no meaningful systems to learn nor choices for the player to make.  Instead, players submit themselves to a constant stream of pretty pictures whilst bashing buttons to advance.   By following the siren's call of 'evocative' static content, most AAA teams have managed to suffocate the playspaces that make games great.

    As a movie-trained consumer looking for mindless escape, I understand the appeal.  As a game designer, I find this direction repugnant.  We have a unique medium capable of immersing players in a rich systematic understanding of complex models of the universe.  It is time for a very different philosophy of design that minimizes static content and level design and maximizes the impact of game mechanics and meaningful systems.

    With Steambirds: Survival, we were able to create relatively major changes to the gameplay late in development.  What little static content existed was highly modular, contained few dependencies on other systems and was therefore quite robust in the face of changes.

    I highly recommend that you distance yourself from handcrafted static levels. Cull linear structures and content dependencies. Treat production as a form of waste that should be stripped from your development process.  These elements destroy your ability to iterate on your design and suck you into a mediocre and limited vision of what games can become.


      When I look at back at the origins of electronic games with their infinite arcade modes and their procedural levels, I see the seed of something great.  Somewhere along the way we took a wrong turn, away from interesting interactive systems and towards static disposable content.  For decades we've been investing outrageous sums of money in production activities that actively diminish the key value proposition of our interactive craft.

      My goal with the games I work on is to shift the balance back toward gameplay.   Throwaway bits of plot and puzzle are still useful as training that gets players into the game. They are great as the occasional dash of spicy emotional seasoning.  We have such things in Steambirds, modularized and tucked in the background where they belong. But they are not, nor should they ever be, the meaty center of the experience.

      What I've been describing with my last few posts is a philosophy of how I prefer to design games...a school of efficient game design, if you will.  The pillars I've discussed to far are simple stated:
      • Use design to lower costs: By following efficient design practices, we can build world changing games at low cost.  Escalating cost curves are a symptom of broken design practices. 
      • Always evergreen: Deeper, more meaningful systems yield lifelong hobbies, not disposable media.
      • New games: Design from the root using iterative, exploratory design to create unique, differentiated products.  Clones are projects for wage cogs and poor designers. 
      • Small teams: Leverage the immense creativity, flexibility and productivity of small teams of co-creators.  Large teams destroy efficiency. 
      • Robust play spaces: Create broad landscapes of possibility that can easily withstand both player and designer induced variation.  Avoid brittle structures.
      • Lean Content: Unchain our ability to iterate on design by reducing our debilitating dependency on puzzles, levels and other static content.
      • Leverage Players: Our designed systems seed value structures that empower players to create stories, community and culture.  The deepest dramas happen in the players' heads, not in our labored delivery. 
      The existence of a school of game design does not mean that all games need to follow these constraints and processes.  If anything we need passionate variety more than we need a theocracy of design.  Instead, a school of design acts as one (hopefully of many) beacons for thinking designers.  We look to the past and call out our long history of mistakes and successes.  We look to the future by building concrete works of art that boldly promote the lessons learned.

      Design is first and foremost a conscious act and we should take an educated and thoughtful stance on what styles of design we pursue and what ones we reject.  Steambirds: Survival is a simple game, but it is one that is design with intent. To make games due to habit, fads, instinct or pursuit of a mundane paycheck means that you are wasting not only your life but the lives of all your players. A thing blindly created is always a thing blindly consumed. What is your stated philosophy of game design?  What are the beliefs that drive your creation?

      Give Steambirds: Survival a try.  There is still so much more work to do, but this should give a small taste of where we are heading.

      take care,

      Steambirds: Now out for iPhone, iPad and Android
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 11 November 2010, 6:26 pm

      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.) 

      The Cutest Kindle Game Ever: Panda Poet
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 9 November 2010, 4:08 pm

      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.

      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 company, 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.

      Triple Town released for the Amazon Kindle
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 15 October 2010, 1:19 pm

      I like taking interesting chances.  On new games, on new markets and new ideas.  This week Spry Fox released a delightful original puzzle game called Triple Town for the Amazon Kindle.  If you have a Kindle you can download it over at Amazon.

      To my knowledge, this is the first indie title publicly available on the Kindle.  An industry first, low dev costs, high potential payoff and a chance to try out an original game idea.  What more could you ask for?

      There are many design lessons, but I'll focus on three:
      • Evergreen designs are not puzzles
      • Reinvent old genres from the root
      • Create better games faster by killing visual and technological crutches. 

      The problem with puzzles

      For many years I've been a fan of the Grow series of games by Eyemaze.  In these, you slowly add elements to the world, the elements interact and the world unfolds and blossoms before you.  With so many games being about destruction, any game that involves building something from nothing holds a special place in my heart.   And they are so simple to play!  Just click and go.

      Yet the Eyemaze games also bug the game designer in me.  They are single-shot puzzles.  You figure them out and then you are done. The delightful animations are consumed once.  The cause and effect sequence is discovered once.   Each new version of Grow takes months, if not years to produce. And the player burns through all that painstaking labor in minutes.

      Puzzles are a class of inefficient design. Avoid them. Why design one eureka handcrafted moment when you can design evergreen mechanics that yield thousands?

      So I gave myself a challenge:  Design an infinitely replayable Grow-style game.

      Triple Town is based off a promising prototype that grew out of this original Grow challenge.  It is its own game, but it keeps a simple UI, the delight of watching your map grow over time and of course the focus on building instead of destruction.  There are no pre-baked levels or consumable episodes and you can easily play for hundreds of hours.

      We've intentionally set up Triple Town to be an evergreen title.  This gains us a slew of benefits. Once a long lived core mechanic has been established, it can be ported to almost any platform, any time in the next decade.  If you are going to build something, you might as well build something that is designed from the start to last.

      Reinvent old genres from the root

      I also set another challenge for myself.  What if we reinvented the entire match-3 genre?  I'm fascinated by the longevity of popular genres and have a short list of well worn mechanics that I'd love strip down to their bones and rebuild from scratch.  What if designers took a chance with their genre designs?  What if instead of slavishly copying the 10th generation of a successful design, they went all the way back to the first prototypes that demonstrated a hint of deep fun and then made a few key decisions that were different?

      Lasting genres tend to rest upon deep possibility spaces. How many variations of chess can you imagine?  Howe many are fun? Despite our cultural inclination to settle upon one common variant,  there is rarely a single 'fun' genre formula. Given time and enough prototyping, there are thousands of fun games in the possibility space defined by a genre.

      It occurred to me that game design, like any evolutionary process, is sensitive to initial conditions.  If you want to stand out, you need to head back in time to the very dawn of a genre, strike out in a different direction and then watch your alternate evolutionary path unfurl.

      Folks that play Triple Town have called it the Civilization of Match-3 games.  The play is quite simple:
      1. Every turn, you get to place 1 new piece on the board.  In other Match-3 games, you only manipulate objects. 
      2. If three or more pieces of the same type (like a tree) are next to one another, the last piece you place is transformed into a higher value object.  So you start out placing bits of grass and eventually build out a land filled with castles, cathedrals and floating cities.  In other Match-3 games, you spend most of your time destroying tokens. 
      3. There are a variety of wild cards, wandering creatures and other object that you also place which clutter the board, but offer unique opportunities if placed correctly.  In other Match-3 games, the board rarely feels like a 'place'. 
      4. The game ends when you can no longer place anything on the board.  You get a score, see how you compared and then try again. 
      Like all good games, the game play evolves in the player's head.  At first, they randomly drop down objects.  Then they start thinking ahead several moves.   They learn how to turn enemies into resources.  The board disappears into zones of influence and control. There comes a moment where you end up thinking "Just one more turn and I'll finally finish my grand pattern."  The panic of imminent defeat and the elation of last minute recoveries never seems to get old.

      Upon casual inspection, Triple Town is very much a match-3 game.  After all, an early player skill involves matching 3 or more items.  That's the definition right?  Yet, everything else is different.  Tactics are different, strategies are different, the emotional experience of play is different.  When someone plays Triple Town well, they feel pride in what they've created.  They want to take a screenshot and share it with their friends.  I've never felt that with a match-3 game before. Reinvention at the root, it seems is indistinguishable from innovation.

      Another game that executed this design strategy well is Plants vs. Zombies.  It is certainly a tower defense game. Yet, by prototyping from the roots of the genre, the devs discovered a set of mechanics that play quite differently than most.  As a result, PopCap carved out a unique value proposition in the market that no other company has been able to successfully clone away.

      Kill visual and technological crutches

      When I tell fellow developers I designed a Kindle game, they have difficulty grasping how such a feat is even possible.  The graphics are primarily black and white.  The E-ink screen flashes and refreshes at most  handful of times per second.  What?  No rumble? Can you make a great modern game with no animation, no color and limited processing power?

      Of course you can. In many ways, these constraints focused development on the gameplay.  With the vast resources available to modern game developers, we often lose track of what matters.  Is the player making meaningful choices?  Are those conveyed in a crisp, clear manner?  Is the core play space deep enough that players can go for hundreds of hours?

      Or is the player's interest being artificially juiced by millions worth of throw away spectacle?  Strip away the sadly lumbering zombie bulk of an 80-person team.  Strip away the cocaine frenzy of marketing rah rah. The pure psychological heart of a design's game play is what stands the test of time.

      I would encourage anyone who considers themselves a professional game developer to build and complete one project with the following constraints:
      • Limited resolution
      • 2D, Black and white graphics
      • No animation
      • No sound
      • Minimal computation
      If you cannot use your existing game development skills to make something fun, you've likely spent your life worshiping at a false altar. The overworked tricks these constraints restrict (pick your favorite: AI, Music, Physics, 3D rendering, etc.) are debilitating crutches, not the essential soul of our grand and enduring art.  I found something immensely satisfying about ditching the fluff and personally confronting the primal source of why games work.

      There are practical benefits to knowing what matters.  We were able to get to a playable production-ready state in a few weeks.  And if our playtests are any indication, players will happily spend just as much time and get just as much delight as they would have out of an ostentatious AAA monstrosity.  What low bang-for-the-buck features are drowning your game?


      With Triple Town, we delivered a quality original game on a new platform all under tight time constraints.  Key to hitting that goal were smart design choices.  As a designer you need to answer questions that have immense business and technical impact.
      • How do we create an evergreen title? Try avoiding puzzles and instead tap deep play spaces.
      • How do we stands out from the inevitable crowd?  Stop cloning and start designing from the root.
      • How does design shape project scope?  Focus on game design and ruthlessly trim the fat.
      Ultimately, good design is an essential strategic tool for your business, not merely an implementation detail.

      The other piece that got Triple Town out the door was the team.  Huge kudos go to Hal Wasserman, the main developer on the project.  Hal, more than anyone else, made the game real.  Like all Spry Fox games, we built up a fresh team around the project, worked together as co-creators and reveled in doing something new.

      This experience has solidified my belief that passionate, talented developers with ownership of their output are one of the few groups on this planet who will ever have a shot at making a great game. For the rest, bound by the golden handcuffs of mediocre corporate slavery, the compromises are too great.

      Give Triple Town a try.  Or drop by David's blog for a bit more business insight into why we targeted Kindle in the first place. (Short version: Untapped market, Launch title, Low dev cost = Opportunity)

      take care

      Announcing Spry Fox (my happy new company)
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 15 September 2010, 12:35 pm

      How do you change the world?  For me one of the brightest opportunities to have a meaningful impact is by creating games. Video games, board games, games inside applications...you name it.  We are living amidst an explosion of game innovation that will shape the very culture of our society. In the past 15 years, I've had the honor to work at some of the biggest companies in our industry and seen this opportunity growing.  And I'm humbled by the fact that well over 16 million unique players have been delighted by the games I've designed.  Averaging a million plus players a year is a good start.

      Now it is time to push games even further. I’m pleased to formally announce the birth of Spry Fox, a new kind of game development studio that I’ve co-founded with my good friend, David Edery. The fearless Tom Buscaglia is our general counsel.

      What do I mean by "new kind of game development studio?" Put simply: we focus on the business and design aspects of game development. We do not employ developers and we do not outsource. We create games by partnering with other talented individuals whose development abilities we respect, and everyone shares in the profit. In this regard, Spry Fox functions somewhat like a modern movie studio -- we form teams around a project that everyone is passionate about, and the team disbands when the project is done (or, in the case of a free-to-play game, when the projects stops generating meaningful revenue). With a bit of luck, a team will gel nicely and may reunite many times (ala a Kevin Smith production), but it isn’t strictly necessary. We work together on what we love, and we part ways when our interests diverge.

      Such a system puts the incentives where they belong: the team is focused on making a great innovative game, not on compromising the soul of their idea (or the creators) to ensure the survival of the studio.

      Game studios of this sort have been attempted in the past, but the most prominent attempts have focused on larger, more expensive projects, which plays against the strengths of the distributed model. More importantly, previous studios appear to have been fixated on the debatable benefits of "outsourcing," as opposed to building true partnerships with outside individuals and firms who are treated as integral to the creative process and who share in the profit. We believe that by building small, tightly-knit teams, we can make this work.

      Most importantly, we have no interest in becoming yet another middleman in the increasingly crowded digital publishing space. When I am involved in a project, I play a major role in every aspect of a game’s design, including building the UI, architecting the major gameplay loops, fine tuning the balance, mentoring and directing the art production (when I don't just pop out the art myself.) When David is involved in a project, he is deeply involved in the design (particularly with an eye towards monetization systems), the in-game writing, and all aspects of the business including marketing and distribution. We are not publishers. We are co-creators.

      Spry Fox is focused primarily on emerging opportunities in the digital game market. For now, this means two things: web-based free-to-play games for various demographics, and downloadable titles for emerging platforms like mobile. Our reasons for focusing on these two things are straightforward:
      • There are strategic benefits to focusing on under-served markets
      • As noted earlier, our development model likely works best with smaller teams
      • We don’t enjoy waiting two+ years to discover whether our game will resonate with fans or not.
      Some of you might wonder if developing "web-based free-to-play games" qualifies as targeting an under-served market. I've written about this in the past and I’d argue that there is no opportunity more compelling at this moment in time. The ratio of quality content to potential consumers is vastly out of whack on the Web relative to the console ecosystem or the iPhone app market. Despite the fact that 99% of all Internet-enabled PCs have Flash installed, boasting an audience more than 10x the size of even the most popular game console, you can literally count on one hand the number of really good Flash-based F2P games in any particular genre. That's our kind of market.

      Because our teams are (and will continue to be) relatively small, we need to focus on design methodologies that deliver the greatest amount of bang for the buck. That means user-generated content, procedurally generated content, and multiplayer mechanics that don't require a constant influx of expensive content. So that's exactly what we've started doing.
      • We’re building on my previous work with Andy Moore to create a bigger, more engaging, multiplayer version of Steambirds that will fully capitalize on that IP’s potential (with an intermediate version in the meanwhile).  Can we resurrect turn-based games for an entirely new generation of players?  Why not try?
      • We’re working with Andre Spierings to evolve the impossibly cute Bunni into the fully social experience we have always known it could be.  I've been immensely inspired by the vision of what Spore could have been. 
      • And we have two downloadable games and one exceedingly unusual flash MMOG in the works, (but unfortunately I can’t share any more information about those projects at this time!)
      As these projects ramp up, I've been having immense amounts of fun doing some consulting across a large slice of the gaming universe (console games, f2p games, serious games, etc). Here I've again been partnering with David over at Fuzbi. Unfortunately, there is limited time to work with everyone, but I'm happy sharing my thoughts on design with forward-looking teams passionate about changing the world.

      I can’t wait to share more with you all soon. Thanks for reading this post and for all your comments and encouragement in the past. And if you think you'd like to work with Spry Fox (or Fuzbi), don't hesitate to drop me a line. We're more than a little busy right now, but the future is always just around the corner. :-)

      take care,

      Visualizing the Creative Process
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 16 August 2010, 11:00 pm
      As I coach new developers, I've taken to scribbling out the same useful diagram for visualizing the creative process again and again on coffee-ringed napkins.  In order to limit my future abuse of culinary paper wares, I've reproduced my images in a more formal fashion in this essay.

      The conversation usually starts with the following statement: "Creativity is like a snake swallowing a series of tennis balls."

      And when confused looks inevitably results, I sketch some variant of this odd little picture:
      Using this as a starting point, we start chatting about joys and pitfalls of creativity.
      • The Brainstorming Phase
      • Failures in brainstorming
      • The Culling Phase
      • Failures in culling
      • Cycling
      • Failures in cycling

      The Brainstorming Phase

      We all start with an idea.  It could be a small inspiration or a large insight.  Immediately, you begin a process of brainstorming and daydreaming.  This is a time of infinite possibility and promise.  I use the term brainstorming broadly to include any activities that expand the options or possibilities of a project.  The traditional image of a group of designer types sitting in a room with a whiteboard is indeed part of the brainstorming phase, but it is really only one of a much broader spectrum of activities.
      Brainstorming starts out small and expands over time

      There are several activities that occur during this phase
      • Ideas: Generate new ideas related to your initial insight. These are proto-experiments. A half jotted note in a notebook "Solar powered underpants!" is an example of an idea. (This is a real idea.  It has been hot in Seattle lately)
      • Thought experiments: Invest energy in your ideas to understand how they might be built and thinking through the theoretical impact of each idea.  A spec concerning "A Method for inserting a small fan one's shorts to reduce ambient temperature" is an example of a thought experiment.
      • Real world experiments: Build working models from physical materials or usable code so you can experience your idea first hand. A working model of underpants plus a small metal fan (plus a ready supply of bandages) is an example of a real world experiment.
      • Cross fertilization: As you work through ideas, you see new possibilities.  I've discovered through much trial and error that escaping to a coffee shop with air conditioning is immensely more effective than other attempted alternatives.

      A multitude of experiments arise during brainstorming

      Brainstorming is ultimately the act of kick starting experiments. Even when you dream up a completely off-the-wall idea, you are stating that "There is some potential in this direction." You've formed a postulate at the fuzziest possible level.  Future steps during the brainstorming  involve making more detailed predictions and modeling the results.

      When brainstorming is successful, we end up with a portfolio of experiments These go by a variety of different names in software development:  features, user stories, use cases and 'the thing Bob made while screwing around on the weekend.'

      Problems with brainstorming

      The single most common flaw during the brainstorming period is that creators do not build enough testable experiments.  This mistake comes in a variety of flavors.
      • The creator already knows what needs to be done
      • Experimentation is considered expensive
      • The original idea is brittle

      The creator already knows what needs to be done

      Creator pursues a single solution

      Why waste time on expensive experiments when the right answer is obvious? The flaw in this thinking is that creativity is an iterative process in which you synthesize the final result from a variety of sources and thousands of potential solutions. It is not purely a deductive process with a single right answer.

      When you fail to experiment broadly, you are building your solution from an anemic set of mental and technical resources. It is the equivalent of trying to design a bridge when the only material you've tested is paper.  You can certainly build a bridge, but it will not be nearly as good compared to someone who experimented with a broad range of materials and construction techniques including steel or concrete.

      To understand the power of a portfolio of experiments, consider some simple statistics.  If 4 out of 5 experimental systems are bound for failure and you create only one experiment, you have a 20% chance of overall success.  On the other hand if you create 10 experiments, you have a 89% chance of finding a success.  In practice, your chance of success is even higher since ideas cross pollinate.  By learning and adapting to your new knowledge you'll uncover new options that are often far superior than the original set of experiments.

      (Note: If the goal of experimentation is hands on knowledge, try including a wide range of participants that can bring a variety of pertinent skills to the table.)

      Experimentation is considered expensive

      Each individual experiment is expensive

      In the example above, a savvy counter of beans might note that 10 experiments is likely to cost 10 times as much as a single experiment.  Yet all this extra money only increases the additive chance of success by a mere 450%.  So the team compromises and invests in a handful of expensive experiments.

      The solution here is to use less expensive experiments, not fewer experiments. What can you make in a day? What can you make in an hour? Instead of using teams of 5 to 10, what can you learn with a team of 1or 2?  By focusing on lightweight experimentation and rapid turnover between experiments you can pack more experiments into your brainstorming phase.

      One technique I love that keeps experiments small is Post-it note design docs.  Since your experiments must fit on a sticky note, you are forced to keep the scope small and easily implementable.

      The original idea is brittle

      No matter how hard you try, you only can come up with a handful of ideas

      Sometimes you start with an idea that seems brilliant, but as you try to expand upon it, you keep running into walls.  You know you've found a brittle idea when you try to bend the concept in interesting new directions and it collapses again and again.

      Over time, you get learn to recognize brilliant yet brittle ideas early in the creative process. My test is to try to think up 20 or 30 crazy variations on the idea. If I can imagine that most of those variations would be exciting to build, then I know I've discovered a robust idea that is worth investing in further. If I can't, then I have a brittle idea.

      It is too easy to invest months, even years of your life trying to "make it work." Instead there are a couple techniques for making the idea more robust:
      Put the idea aside: The single best thing you can do is to put the brittle idea on the back-burner.  Over time, if the idea is in fact brilliant, it will find its way back into your creative process.  A different perspective, be it brought on by time or new experiences, can be an essential ingredient in softening the idea's previous constraints.

      I wrote up an idea for a game called Cute God a while back, but none of the prototypes really gelled.  It was a design with a thousand problems and very few good solutions. Instead of belaboring the point, I consciously stopped redesigning it.  Years later, some of the original combinatorics ideas found their way into a game called Triple Town that should be released later this year.  Ideas you cull are never really erased.  Instead they turn into fertile soil from which the next generation of ideas are grown.

      Radical simplification: What is core experience that you are trying to achieve?   Write a single sentence or draw a picture that represents that experience.  Put that on the wall in front of you. Now brainstorm a dozen different incredibly simple ways of creating the essence of that experience for the user.  Toss out all your complex systems and constraints and start over with just the core.

      Recently a friend and I went through this exercise on a game concept that was born from a pencil drawing of dozens of stick figures attacking one another.  The brilliant, yet brittle design was a Toribash-style fighting game where you could move individual joints for each of the stick figures in an epic multiplayer battle.  As an exercise, we went back to the original drawing and asked "What was the simplest way to get that image up on the player's screen" and "How do we  evoke the coolness of a dozen stick figures blasting one another with shotguns." Out goes the rag doll physics.  Out goes the complex UI.  Out goes the multiplayer.  The resultant idea was robust, easier to implement and still captured the emotional joy of the original inspiration.  At the very least, this exercise helped the designer look at the problem in a new light and question their original (brittle) constraints.

      This process can all be summed up "If your design is difficult, cheat."

      Culling Phase

      There is an entire second phase of of the creative process called culling.  Inevitably, not all experiments are good experiments.  Some show immediate value and others are plagued by obvious flaws.

      During the Culling Phase, you need to kill flawed experiments so you can double down on good ones.

      Culling boils down all your experiments to a refined nugget of value

      No one really talks much about this unpleasant part of creativity.  We lionize the eureka moments of brainstorming and end up ignoring the agonizing process of trimming and shaping those meandering experiments into something coherent and valuable.  This is a huge mistake.

      Critically culling your experiments is an essential step to any successful creative act.  Culling focuses the creative act, ensures projects are finish-able and ultimately yields a more  powerful final experience.  When I start painting, I place down a thousand brush strokes.  But only one stroke appears on top and is visible to the viewer.  Each previous stroke is an experiment that leads me towards that final visible stroke. Once I've learned enough from my experiments, I make an informed decision, place the optimal mark and move on.

      Those who fail to cull, fail to create meaningful projects.  You can spot a newbie designer from a thousand yards by suggesting they kill a feature that doesn't seem to be contributing much.  Their nostrils flair and their voice rises. A litany of denials, excuses and accusations pour forth.  And you know immediately that their project is going to be an incoherent piece of crap.  This is a good coaching moment. :-)
      Good experiments get more love and the questionable ones get trimmed

      Culling is composed of several activities
      • Determining your culling criteria:  You need to know how you are culling up front so you don't end up making arbitrary decisions. The single best way I've found of defining culling criteria is to write down what success looks like. For example, in Bunni 2, we say that the game is a 'social stickerbook'.  Anything that doesn't fit that vision is worth questioning.
      • Deciding what to invest in further:  Look for opportunities to amplify obvious value in your existing experiments.   For example, in Half Life 2, one experiment was this risky concept called a 'gravity gun'.  When a real world prototype was made, players loved it. Valved decided to invest further and tried to figure out how that gun could be used throughout the entire game.
      • Deciding what to remove.  If something doesn't fit your culling criteria, it is better to cut it early and spend those resources elsewhere.  In Bunni 2, we dabbled with a combat system.  However, after we built a simple version, we realized that it really didn't fit our culling criteria so we put it on the backburner.

      Problems with Culling

      There are several common issues that come up during the culling phase
      • No explicit culling criteria
      • Experiments are not tangible.
      • Assuming more is better
      • Fixing every problem
      • Focusing on problems not opportunities
      • Judging features not core experiences.

      No culling criteria

      Often people get so caught up in the amazing optimism of brainstorming, they fail to agree upon explicit culling criteria.  Instead the particular politics or opinions of the day hold sway and features are randomly invested in.  Culling does occur, but in a haphazard fashion that is just as likely to kill good features as bad.

      When you leave your culling criteria vague, you are saying that it is okay for everyone to have slightly different opinions about what is good and what is out. This leads to unnecessary conflicts.  You need to bite the bullet and have the hard conversation about what your shared vision for the project should be.  I like the term 'culling criteria' since it ensures buy off from everyone that, yes, you will mothball experiments for the greater good of the project.  The act of explicitly stating a small set of common goals ensures that everyone buys into something bigger than their individual efforts and passions.

      I put 'goals' at the top of almost every single design document I write.  Though this is the shortest part of the design, it is often the section most critical to success.  Experiments will blossom in dozens of directions, but the goals keep the project on track.

      The experiments are not tangible

      Mere opinion is the only indicator if an experiment is good or bad

      Often due to fear of creating expensive experiments, creative folks spend far too much time in the land of ideas and thought experiments.  Some call this documentation and invest in it like some religious protection from mistakes.  As a result, very few real world experiments are built.  With nothing concrete to react to and judge in a critical fashion, it becomes difficult to apply the culling criteria in an objective fashion.

      The solution is to make your ideas real as quickly as possible. Paper prototypes, 24-hour game jams, role-playing with a friend...create your idea in the physical world. To get a bit geeky, a vast portion of conscious cognition emerges as a post-processed rationalization of our body's physical interactions with the world. Feed your subconscious cognition by creating systems you can touch, see and play with directly.

      Instead of merely wearing down a single golden path in your mental thought experiments, you'll accumulate the wisdom that only comes from a thousand real world observations.  You'll see players smile when they stumble.  You sense the stickiness of a dialog that asks you to 'click continue'.  You'll give yourself the richest possible source of information about the problem space in the shortest amount of time.

      Recently I wrote out a design for a simple word game called Panda Poet.  It was completely obvious how the game played on paper.  The rules were crisply defined and I could easily play through the experience in my head and imagine the delight that would result.  All it really needed was a quick implementation and the project would be done.

      So we implemented the first prototype. The result was completely unplayable. The interface was fundamentally broken.  The feedback loops were not functional.  In the first 10 minutes of playing a physical prototype, I learned 10 times as much about the problem space than I had learned in the previous days spent designing on paper.  Panda Poet was almost a failure, but by building multiple real world prototypes, we learned enough to salvage the design.  It should be out later this year.

      Assuming more is better

      If you started something, you feel obligated to release it.

      As a creator it is easy to get caught in the belief that more is more.  Yet, the people consuming our creations rarely feel this.  They have limited time and limited mental resources to spend on our work.  Instead, they see all the extra 'stuff' as mental noise that actively harms their enjoyment of the project.

      Imagine that you have a painting of a duck and you start randomly adding static in the form of blobs from other pictures to it.  You can add a lot of static and still tell it is a duck. But the static detracts from the image.  The end user would likely be much happier if you just gave them a great picture of a duck.

      The same thing occurs when you fail to kill experiments. You are actively adding low quality noise to your creation.

      Creators that fear rigorously editing their creations suffer from the sunk cost fallacy.  They assume that since they spent effort making something, value will be lost if it is removed.  Often they consider their work 'precious'. However, there is no inherent utilitarian value in a feature simply because it took a lot of effort to build.  The user doesn't see your effort.  They only see the messy and imperfect noise that come from not rigorously culling your flawed experiments.

      Practice killing your ideas:  David McClure has a great saying, "Kill a feature every week".  Culling with wisdom and discipline is a skill worth training much like any healthy habit.  You practice and it slowly and steadily gets easier.   You begin to see each feature and experiment as a small step in a much larger process, not a rare and precious thing that must be protected.

      Be objective: Another technique is to use object, data-centric criteria.  By boiling down decisions to numbers and metrics, you give yourself permission to make emotionally difficult decisions.  This can be taken too far, but is particularly useful if you have a group of people that have divergent subjective opinions on a topic.  Again, real world experiments facilitate this approach.  There is an objective measurable reality to how people react to art.    Understand this fact and used it to facilitate your culling.

      One implementation of this technique is the use of Fun ratings.  I have a survey built into many of the games I work on that asks users how fun the game is on a scale of 1 to 5.  It is one thing to tell someone that their game sucks.  That statement comes across as a purely subject and potentially insulting opinion.  It is another thing to have 10,000 people say that your game rates 3.1 out of 5 and to know from historical data that you need to reach 3.9 in order to have a chance at financial or critical success.

      Fixing every problem

      Every problem with every feature must be solved

      A related issue is that creators often attempt to fixed all the problems with their failed experiments.  This is particularly common on projects that are thought of a series of modular features.  The creator lists out the problems with each feature and then methodically fixes each in an attempt to bring the feature and therefore the project up to a reasonable level of quality.

      The impact of this technique is painful to witness.
      • The expense of 'completing' the projects blossoms and progress across the board slows to a crawl as multiple objectives are pursued simultaneously.  Adding more resources often only slows down the project more (ala the Mythical Man Month.)
      • Quality still decreases.  It is rare that each feature is completely aligned to the central value of the project.  You end up with a project that is being pulled in a variety of directions all at once.  The result is like student art where a new artist meticulously polishes every single shape in the drawing, but the end result is a hideously disjointed experience.
      A good rule of thumb for game development is that every experimental feature you start takes 30 times as much effort to finish.  So one day prototyping yields one month polishing.  If you try to polish everything, the surface area of your project grows huge in very short order.

      I once worked on a failed online game that suffered from this issue.  There were about 5 different project owners, each of which assumed that their job was to point out the flaws in the game and mandate (on threat of death) that the team fix them all.  The team would scramble to plug holes one after another.  In very short order, the game turned into an incoherent mass of half polished features.  In hindsight, a cleaner set of culling criteria that resulted in killing broken features would have resulted in a more focused project of higher overall quality.

      The solution is to focus less on the problems and more on the opportunities. You win when you generate value. If you release an unpolished version of a something genuinely interesting and wonderful, it is amazing what people will forgive.

      In Steambirds, the levels were tossed together with a semi-random assortment of planes.  The writing on the mission text was highly questionable.  The graphics were one iteration past the initial prototype art.  There was an invisible wall that caused players to die inexplicably.  It could have easily turned into a 12-month project.

      However, what we did right was polish the heck out of the core mechanic of movement and attacking.  Of all our experiments, it was a robust and interesting gem that resulted in a powerful user experience.  In the end, by focusing on the heart of the game, none of the other issues really mattered.  We saved months of labor by focusing on what worked and killing or ignoring what didn't.


      Brainstorming and culling occurs in an iterative cycle.  In each cycle, you create experiments and then cull back to the valuable core.  Then you repeat.  Each complete cycle spawns a new spurt of ideas and experiments that must be culled in turn.

      Each cycle results in accumulating more value for the customers of your labor.  When you've generated enough value, you stop.

      Cycling problems

      There are a couple issues that occur during this process.
      • Not iterating.
      • Not delivering value to the customer.

      Not iterating

      Often creators stop after a single cycle of brainstorming and culling.  I see this quite often in groups that come from a waterfall-centric culture.  Planning is treated as the equivalent of brainstorming and initial implementation.  Culling is treated as scope reduction and bug fixing.  After one long cycle, the product releases.

      The solution here is shorter, lower cost cycles.   Any of the various agile methodologies cover this ground extensively.  To facilitate more cycles, I ask the question: How do I decrease cycle time so I can fit more learning cycles into my project? I've asked this question for art, for games, for UI design and for application development.  In all situations, the more cycles I can pack in, the happier I am with the end result.

      Not delivering value to the customer

      The exact opposite of not enough iteration is to continue to iterate indefinitely and never release the value you have accumulated to a wider audience.  There is always room for improvement and always new value to generate.  You can get stuck in the trap of constantly cycling through the creative process and never feeling that your product is good enough to release.

      Here are two good solutions I recommend
      • Timeboxing: Set a release date and release regardless of how far you've gotten. Pixar's Darla Anderson has a great quote that "we don't finish our films. We just release them" The predetermined release date is a forcing function that ensure they pack in as much value as possible before they are forced to put something out.  It also ensure that you stop working on a flawed experiment.  The emotional distance that comes from releasing can be extremely helpful in realizing that you need to take a break from a particular great white whale that is eating your life.
      • Release criteria: Another alternative is to set objective goals that trigger a release.   For Flash games, I know that when I've hit a 3.9 fun rating, I can release the game.  Certainly, I could invest further, but it really isn't worth it.


      All these thoughts and pictures can be summarized in a very short list.
      • Brainstorm: Create lots of low cost, real word experiments.
      • Cull: Rigorously apply agreed upon culling criteria to weed out the weak ideas and reinvest in your most promising experiments.
      • Cycle: Repeat the process until you generate meaningful value.
      • Practice: Across multiple projects, practice all stages of the creative process so you constantly improve the myriad of skills involved in brainstorming, culling and cycling.
      Or if you are a visual learner, just reference this picture:

      take care,

      Wordcamp 2010: Why we turned Microsoft Office into a Game
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 15 May 2010, 10:13 pm

      At the start of May, I gave a talk down in San Francisco on how game design can plug a gaping hole in the current practice of application design.

      Here is the pdf with the speaking notes included. This contains a bit more than the actual talk.

      take care

      PS: Does anyone know of a way of sharing slides that allows people to see the notes? For most of my talks, the visuals are almost meaningless without the words that go along with them.  As a last resort I've fallen back on PDF. My sordid attempts so far include:

      • Slideshare: Slideshare seems to have slyly turned off the ability to publish notes.  Brilliant move. 
      • Scribd: Mangles documents and doesn't publish notes. 
      • Google docs: Google docs mangles the slides and looks horrendous. 
      • Blogger: I even made a vain attempt to manually import the images into Blogger and hand edit the post. However, Blogger was apparently never built to handle more than one or two spot images.  As soon as 61 images collided with  the byzantine HTML formating lurking at Blogger's black heart, formatting errors abounded. One day someone clever will realize that there is a clear user need to have a robust online WYSIWYG text editor that handles the basic use case of combining text with images.  The end user doesn't give a damn about standards if they cause hours of meaningless suffering.  Abstract to fit the user's mental model. 

      Goodbye lostgarden.com. (Hello www.lostgarden.com)
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 25 April 2010, 12:30 pm

      Google, in their infinite statistically derived wisdom, shut down an obscure feature on Blogger called "FTP publishing". For the past 5+ years, this is how I've been putting words up on Lostgarden.com.

      It turns out that a pipsqueak 0.5%, a mere Seattle-sized city worth of users, were insisting on hosting their own files on disreputable non-Google servers. It was a grand deviant run, but compared to the scalable majority, we were tagged as a tad too exceptional.

      That's okay. Out with the old, in with the new. After a week of me half-heartedly poking the fiddly bits of my DNS entries, my brilliant and amazing friend Chard gently took over. In a few hours he expertly managed to get Lostgarden.com working on one of Google's custom domains. Huzzah!

      All the old posts are still around. All the old links should redirect transparently. If your RSS feed is broken, you may need to reset it by going to this link: Burn the Lostgarden Feed.

      What's new

      As the rather emotional conversion process unfolded, I decided to make the plunge and swap out my template. It is primarily a visual change, but there are a few nice things that come along.
      • Back and Previous links. In the old template, there was a big hairy drop down for browsing backwards in time. Now we are somewhat modern and can simply click to the previous page.
      • What I'm reading: My shared items from Google Reader now appear in the left side bar. These are updated on a far more regular basis than the main blog and many of them contain overly long, snarky comments. Immense entertainment.
      • My sexy mug: Yep. That's what I look like. Surprised?

      A small personal note

      Sun has returned to Seattle, at least for few short blossoming months. After years of soul grinding illness, my wife has started feeling a little better. A small break in the clouds, if you will. As I stare out the window at a thousand shades of effervescent green, I am once again struck by the thought: This remains one of the most singularly amazing times to be creating games.

      All the best,

      Project Horseshoe 2008: There and back again
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 10 November 2008, 9:40 pm

      I’m writing this on the long flight back from Project Horseshoe 2008. The last bittersweet night, we stayed up till five AM playing games and talking about games. The conversation shifted from the slow death of games as we knew them, to fresh games that will change the world, to the little tips we use to thrive each day. There is something distinctly surreal about chatting quietly with such an intimate knowledgeable group during the wee hours of the morning, there on a lonely porch in the uncharted depths of Texas. And yes, there were indeed baby racoons.

      This year, I took a risk. If you’ve been following this blog for a bit, you know that I’ve been working on skill atom techniques for modeling gameplay. I’ve written about it. I’ve used it myself. There has even been a talk or two. Yet, aside from a few furtive emails with other happy heretics, I’ve never had a chance to do the following:
      1. Explain the model to a crowd of natural skeptics, working designers who have been successfully building games for years.
      2. Get them to tear it apart.
      The cautionary tale of the secret paint formula
      I’m reminded of a story that Norman Rockwell used to tell. He once became good friends with a fellow painter who was famous for his rendering of luminescent, sensual skin tones. The painter used a secret formula for his paint and he guarded it jealously from potential imitators. When the painter died, he willed his greatest gift, his secret paint formula to Rockwell.

      Rockwell excitedly tried out the formula, but ultimately found it disappointing. The paint was too slick and difficult to control, so he gave up on it and instead fell back on his own preferred techniques. The real secret had never been the paint formula. It was just one little piece of the painter’s vast organic, highly individual process. The real secret was the intuitive wisdom that comes from making a thousand paintings. Sadly, such a thing is not transferable to others. When he died, his specific way of creating paintings died with him.

      Are skill atoms the same thing as the secret paint formula? Are they a glossy coat of theoretical hand waving that only works for the people who invented it? Many people I’ve talked with see ‘game grammar’ as nothing more than a time wasting intellectualization of a fundamentally intuitive activity. I went into the weekend with this thought very much at the forefront of my mind.

      Why stop there?
      If all we had done was validate or invalidate the skill atom model for simple games, it would have been a useful weekend. But by god, this is Project Horseshoe and people are nothing if not psychotically ambitious. To up the ante, our group decided to apply skill atoms to multiplayer games. I’ve never done this.

      How do you model a deeply psychological behavior like bluffing? Gifting? Competition? Collaboration? Goodness! I didn’t have a lot of answers prepared for this topic and honestly expected that the skill atom model would immediately collapse under the weight of all the crazy things that happen as soon as you add two or more players to a game design. All it would have taken is one smart designer to raise a single counter example and my fragile model would burst apart, defeated by reality.

      Some questions that I had included:
      • Could we even begin to talk about multiplayer with skill atoms? The alternative is that this is a model that is limited to only single player experiences. That would be like coming up with a model of physics that worked for one ball in a vacuum, but wasn’t useful for something useful like say…building bridges.
      • Would the system scale to complex systems? Often when you use a diagramming technique (like UML or state diagrams) to understand real world projects, the resulting diagrams becomes so convoluted that the model does more to confuse than to illuminate.
      • Would the system be useful to designers during every day work? It is much easier to come up with a academic system of analyzing games that works best if you are an ivory tower dweller who can devote hundreds of hours to breaking down each interaction into pretty diagrams filled with obscure invented lingo. However, I’m looking for utilitarian tools that can be applied in that critical 10-minute gap between playing a prototype and deciding what to try next.
      • Can this system be taught to other designers? Like the secret paint formula, most game models I run across are only useful to their inventors. If I can’t observe other designers applying the model successfully without my intervention there is something horribly wrong with the approach.
      We ripped the skill atoms apart. We analyzed multiplayer M.U.L.E. We looked at charades and then took on football and buffing in MMOs. We used skill atoms to prototype a new multiplayer game about gifting using a bag of plastic Indians. At some point, not so long from now, our group will come out with a report. In that report, we’ll be blunt about what we found. What worked? What was flawed? The results are fascinating.

      Our team’s report will be one of several reports to come out of Project Horseshoe by groups of game designers just as crazy and inspired as we were. If any one of these reports starts gaining momentum, the world of gaming as we know will change. It turns out that moving our industry forward isn’t about complaining. It is about getting smart people together where they have the time and the space to think. Grab a beer (Aventinus Double Bock, no less), join the mind meld and use the vast pool of centuries (!) of game design experience to come up with real solutions. Then follow up again and again and again.

      In that spirit, I can't wait to share our final report with everyone.

      Time for some much needed sleep, chock full of dreams.

      PS: Warm kudos to George, Linda and Teresa for putting Project Horseshoe on. It is obviously a labor of love and is utterly unique compared to the other events and conferences I’ve attended. If you ever get an invite, don’t hesitate to go.

      Tidbits from the garden
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 20 November 2008, 9:45 pm
      A few odds and ends have collected in my inbox lately.

      Video of the Princess Saving Application is up!
      All the videos from the night are posted up on OfficeLabs.com. My talk starts 10 minutes into the first video and lasts approximately 30 minutes. There’s also a bit of Q &A after all the talks finish up. You can get the original slides here.

      <a href="http://video.msn.com/?mkt=en-US&playlist=videoByUuids:uuids:d0cabdcc-97bc-4799-a579-4da3b73f865b&showPlaylist=true&from=msnvideo" target="_new" title="Microsoft Office Labs & Engineering Excellence IxDA Event Part I Daniel Cook">Video: Microsoft Office Labs & Engineering Excellence IxDA Event Part I Daniel Cook</a>

      FishingGirl update
      I’ve seen some sneak peeks of the FishingGirl prototypes and people are making great progress. It will be possible for someone to win a gold medal this time around. If you’ve started a prototype, finish it! There is solid fun lurking in that design and you still have a couple of weeks left to build something wonderful.

      Some observations:
      • The store and the acquisition of the various rods adds a great sense of exploration and progression to the game.
      • The gameplay improves substantially if you give your fish a small dash of intelligence so that they move towards your lure if it is in their sight.
      • Making the game winnable. There is a story arc to the game and it feels incomplete if you don't let the player finish.
      Skill atoms in action
      Tex, over at the delightfully titled Tin Man Tex’s Slap Dang Blog, put together skill chain describing his mod. I liked how he intuitively started writing down skill atoms and then only later began connecting them together in a skill chain. Analyzing a game using skill atoms has an element of mind mapping to it that is pleasantly organic. Check it out. I hope to see more such examples in the future.
      Other prototyping notes
      BuschnicK created a nicely fleshed out version of Play with your Peas. It is a faithful implementation of the game and deserves a very solid silver reward. However, I still think the fun hasn't been completely uncovered.

      At this point, we've had some reasonable implementations of the original concept. I suspect that the design may require some big changes to make it work. So here is a question: Why isn't Play with your Peas mind-thunderingly fun and what could be done to improve it?
      Best wishes and may you have a sinfully glorious Thanksgiving.

      Post-it note design docs
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 6 December 2008, 2:53 am

      I happen to fall into the artist-designer skill set, so I often find myself trying to prototype ideas on teams rich with programmers. As such, I'm always looking for better game development techniques that work well for this particular team mix.

      Here is a very lightweight prototyping process using Post-it notes that I quite enjoy.

      1. Initial idea: I sit down with an available programmer (and artist/UI designer depending on the system) and we chat about how to test out a new bit of gameplay. Usually this is an idea that has been bubbling about since the night or week before.
      2. Post-it note design: I jot down a quick bulleted list summarizing our discussion on a single post-it note. We go over it one last time so there everything is clear. The list isn't very detailed. Mostly it serves as something to jog our memories if we forget what we were talking about.
      3. Build it: The programmer and artist go off and build the items on the list. It might take 2 hours or two days. They are encouraged to solve problems creatively and they can always just give me a shout if something doesn't make sense.
      4. Play test: When most of the items on the Post-it note are playable, I get called over and we play test it the experiment together. If the results are comprehensible by mere humans, we pull in some play testers for 3-4 minutes to observe some real players interacting with the mechanic for the first time.
      5. Review: Afterwards, we discuss our observations and write up another Post-it note worth of improvements.
      6. Repeat or Stop?: The process repeats until we run out of time or give up. Sometimes we give ourselves a day per experiment, sometimes two days. In the land of Scrum, we treat the experiment like a time boxed task.
      7. Rate: At the end, the gameplay experiment is rated according the scale below.
      8. Save: The code is saved off, a few choice notes are recorded in a doc containing our 'list of experiments' and we move on. Bits of code, even from failed prototypes, are often reused in future gameplay experiments.
      Rating system
      The rating system is delightfully crude. The goal is to triage experiments quickly.
      1. "A": These experiments were obviously fun. Players laughed, smiled and generally exhibited the emotions we were looking for. If in doubt, ask "Was this fun? How so?"
      2. "B": These experiments showed a hint of fun if you knew what you were looking for. However, it is going to take more effort to expose the fun in a manner that is visible to the players.
      3. "C": There wasn't any fun. The experiment fails.
      A portfolio of fun
      One of my favorite aspects of this method is that you end up with a mini-portfolio of game design ideas. Instead of putting all the design risk in a project on one or two unproven mechanic, the team now has a half dozen or more proven bits of fun to build upon. If some don't fit into the game or get abandoned for other reasons, that's alright. You can afford to lose a few and the end product will still be fun. Think of it as designing from a position of plenty.

      Contrast this with a prescriptive 'design doc' approach where you are forced to pick, without much evidence, a main mechanics for production. Even for the most experienced designer, 50% to 80% of your 'educated' selections are going to be complete dogs. Every unproven mechanic you polish ends up being a massive drain on your budget and your reputation as a designer. You might hear gentle comments like, "We spent 3 months of dev time on this lump of an idea and it isn't fun?"

      It doesn't take very many expensive failures for the project's perceived 'design risk' to blossom to the point where conservative minds seek to kill the project. I think of this as designing from a position of sudden death.

      Some basic observations
      Here's a quick list of things I've observed when prototyping.
      • Failed experiments happen a lot. Don't be surprised if C-rated experiments occur 50% to 80% of the time. Everyone on the team has to be aware that not every experiment is going to be a success, but the learning process is still worthwhile.
      • Designing on your feet is a critical skill: Each consultation and analysis might last only 10 to 20 minutes and you need to leave folks with that all important sticky note filled with impactful, yet inexpensive changes. It pays to have lots of ideas and a deep understanding of game mechanics so you can quickly pull together a list of incisive comments. If you can't, you likely are not suited to be performing the designer role.
      • Listening matters. The designer doesn't need to come up with all the solutions. Everyone on the team is bright and has great ideas. As a designer, your role is to herd all ideas (yours and others) into something that serves the next step in the prototype.
      • You need programmers: If there aren't programmers dedicated to prototyping, the prototyping isn't going to happen. You can drop down to paper prototyping, but it usually doesn't prove out many types of mechanics (especially ones involving timing and interfaces.)
      Advanced observations
      These are some notes that are a bit geekier, but can save you large amounts of pain.
      • Meta game mechanics are harder to prototype: The systems that link together the various gameplay experiments are harder to playtest. They operate on longer time spans (hours instead of minutes) and often require that the core gameplay is already fun.
      • Build a meta-game architecture that allows for loose coupling of gameplay experiments: Most successful games have an architecture that allows the team to plug in new bits of fun as they are found. The linear 'level-story-level' pattern used by most FPS is one example. The 'hub with many sub levels" used by Mario 64 is another. Any of these allow you to plug in a new experiment independently of the other gameplay experiments. If you don't have a modular architecture, you run into situations where a fun new system breaks many of the other bits of fun you've already discovered.
      • Integrating tightly coupled gameplay experiments is a pain: If I independently find a fun new type of weapon and an interesting enemy AI, the combination of the two is often a non-trivial issue. The new weapon many work with an old AI, but be completely useless with the new one. Integration yields a whole new set of experiments. Plan for time to rediscover the fun all over again.
      There are some interesting benefits to the Post-it note design method:
      • Scales nicely to large prototyping efforts: One designer can serve multiple programmers. This works nicely on teams where there are more programmers than designers and you need to get a lot of prototyping done quickly.
      • Failing quickly is fun and educational. You learn a lot with each failure and can move onto the next experiment with a much better idea of what doesn't work.
      • Provides a quick death for bad pet ideas. It is much harder to resurrect pet ideas when you have concrete, playable proof that it won't work. Finding out early which one of my favorite ideas is idiotic saves me a lot of political pain.
      • Fun prototypes are quite convincing: A fun, playable crazy idea works a lot better for winning over other team members than any amount of hand waving or documentation.
      • An easier team to assemble: Finding a competent game designer and a competent programmer can often be easier than finding a competent programmer-designer. Well developed hybrid skill sets are very valuable, but can be quite rare. A side benefit of having a team is that you end up cross training your designers and programmers. You create designers who can speak to programmers and programmers who can riff on some of the design.
      The value of dime-a-dozen designs (A brief aside)
      One often hears the negative comment that game designs are a dime-a-dozen. And in a waterfall design process, an incessant stream of ideas is indeed a problem. If you attempt to squeeze all those ideas into a typical waterfall development process, you end up with an immense amount of waste. Each designs need documentation, concepting, implementation, testing and bug fixes. In response, project owners will often ask for just one good idea.

      There is another path. A lightweight prototyping method takes your flurry of crazy ideas and converts them at moderate cost into a well sorted portfolio of working designs. All those ideas are not, in fact, worthless or wasteful; they are the essential fuel that feeds a good prototyping process. Each idea either teaches you something or provides you with a success.

      The way to make the process work without getting gunked up is to make prototyping incredibly lightweight. Other than our focused conversations, I spend my time on a total of two design docs: The first is the brief list of rated prototypes and the second is a set of discardable, temporary Post-it notes. Design waste in the form of unnecessary artifacts is minimal. Most of the 'programming waste' is better classified as low cost learning.

      Those wild flocks of churning, swirling ideas end up not being worthless at all. They simply need to be funneled into the project with the right process for their value to be realized.

      The "Post-it note design process" has likely been reinvented in one form or another hundreds of times across the history of game development. It is so basic that it feels odd to even write it up in any sort of formal fashion.

      If you have a designer and a programmer, give it a shot. It is certainly a good functional alternative to the popular process of sticking a lone programmer-designer in a room and asking them to 'find the fun'. Both can produce great games. Pick the one that works best for your current team composition.

      This process does have an cost since you need to devote at least two people to finding the fun instead of putting all decisions on the head of the designer. However, the end result is well worth it. After all, it is far smarter to spend team time uncovering a portfolio of the right mechanics than it is to 'save your programmers' so they can be off running really fast in the wrong direction.

      In the end it really isn't about programmers, designers, design documents or features. It is about the team working together to make the right product. Everything else is just ego and waste. And for some reason, it is quite difficult to invest much ego or waste in a little disposable Post-it note.

      take care
      Post-it note fanboy

      Fishing Girl Prototype results
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 20 December 2008, 10:22 pm

      Here is a story about a fellow named Andre, who created a Lostgarden game prototype, sold it for $4000 and started down the path to a new career in game development.

      Andre lives down in a rural section of Australia. Due to the limited infrastructure in the region, he makes due with a gimpy modem that sputters along, randomly disconnecting at the worst possible moment. There aren’t very many tech jobs in the area, but he is unable to move due to family obligations.

      Early on in life he dabbled with art, graphics programming and games, but there isn’t much call for such things locally. To make ends meet, he grinds away, year after year, developing website after website.

      Andre is the sort of smart, industrious fellow that has immense potential. He dreams of creating amazing and wonderful games. Every email I receive from him is bursting with ideas and
      snippets of working games that he jotted down in his spare time. Yet the ‘traditional’ path into games is closed to him.

      When opportunities are limited, people often settle for limited opportunities. I grew up in a rural area and I’ve seen many bright wonderful people end up in dead end jobs due to the emptiness of their environment. It can be hard for people raised in areas of plenty to understand, but if no one else ever talks about what is possible or open a door to new ideas, you can go through life bound by invisible cultural blinders.

      Prototyping challenges are opportunities
      I created the prototyping challenges on Lostgarden.com as an onramp for new game developers. There are no excuses. The art is free. The design, though never perfect, is enough to get you moving in the right direction. There are dozens of free game engines for you to use. All this, combined with the internet (even accessed on a gimpy modem) opens all sorts of doors. All you need to do is make a game.

      Over the past month or so, Andre built a version of Fishing Girl in Flash. He quickly built out the original design and then iterated upon it until he had something playable. A bit of data:
      The best bit of news is that Andre was able to sell the Fishing Girl game for $4000 + a performance bonus. Yes, you can sell Lostgarden prototyping challenges for cold cash. I highly encourage it since A) people should be paid for their hard work and B) the lessons you learn by finishing a game for the public are invaluable.

      Now Andre has a little bit of income and a lot of validation to feed the development of his next game. These days when I talk to Andre, he has big plans for a whole career doing what he loves. That is pretty darned cool.

      Gold medal (1st ever)

      Andre gets my first gold prototyping award. He earned a score of 77% (103 out of 134 points). Here is what he did to earn it:
      • 15 minutes of fun: The rule of thumb for a gold medal game is that you need to make about 15 minutes of fun. Most prototypes barely get to the 5 minute mark. Many people are playing through Andre’s FishingGirl twice and spending upwards of an hour on a single play through.
      • Found and extended the fun in the design: In order to build 15 minutes of fun, he iterated on the basic design and added his own touches like lure-seeking fish and wonderfully animated endings.He realized that a game design is not a blue print. It is a starting point for practicing the iterative process of design.
      • Made a complete experience: There is a strong narrative arc throughout Andre’s Fishing Girl. You fish, you advance, you discover something surprising and you save the little boy. It is a game you can start and then feel good about finishing. The vast majority of people who say they want to make games start building them but never finish them. The act of making a polished game that players can finish teaches you more about game design than any number of incomplete engines or piles of features.
      Silver medals
      Folks have been working away like busy bees on this design. I expected to give out mostly bronze medals, but there were three prototypes that were recently updated, each of which kept me interested for five minutes.

      There is still opportunity for each of these to reach for a gold medal. I’d love to see some more variations on the Fishing Girl game. If Andre’s Fishing Girl is the equivalent of Asteroids, who is going to make Galaga?

      • Eric (65%): http://ericw.ca/files/FishingGirl/setup.exe. A great last minute entry that has delightful Fish AI and an innovative combo system for catching fish.
      • Ben (46%): http://sites.google.com/site/walkersoftwareprojects/files. Ben has a simple game here that still managed to get me to try to fish up all the little fishies. The mechanics are lacking a bit of juiciness, but basics are there.
      • Shade (41%): http://www.exodia.org/og/?p=24. Shade has some interesting line physics here. To riff a bit , with this type of system and line collision, you could do some wonderful things with obstacles in the sea. Players would need to drape the line perfectly over different objects to get to a particular spot in the ocean to catch a rare fish. This protoype has the ‘juiciest’ of the game mechanics, but it needs a bit of tuning so that it doesn’t feel quite so loose.
      Bronze medals
      There were also a couple of solid technology experiments.

      • Dale and Greg: http://beta.sharendipity.com/assets/1900/: The good folks over at Sharendipity put together the basic fishing mechanics and it is running on their new Flash client. (Woot!) They initially implemented casting and fish swimming as two separate apps. As a side note, this prototyping path can be tricky to gain useful feedback from since the most exciting gameplay opportunities often come from the interaction of the combined systems. It is often better to integrate early, but keep each system simple so that you don’t need to deal with undue complexity. You can always add complexity to a system if you identify enjoyable skills that are worth investing further in.
      • Pete: http://blois.us/FishingGirl/ Our first prototype in Silverlight. Sweetness. He has a tight casting mechanism.
      Areas of improvement
      Every time you build a game, you learn lessons that let you build it better the next time. If anyone wants to create a better version of Fishing Girl, here are a couple things you might be able to improve. These comments uses Andre’s game as a starting point.

      Problems: The following are problems that kept users from enjoying the game fully.
      • The floating shops are a pain: You constantly end up hitting them with your lure. Having a single floating store that is inside the distance of your longest cast may help. The position prevents you from hitting it unless you try. Instead of selling one item, the store would have a rotating list of things that you can buy. Once you hit the store, it reappears elsewhere. The alternative is to let the player go to the store at any point, but this removes some of the fun of trying to cast at a specific distance.
      • It is hard to aim exactly with the rod: Slowing down the rod might be one way of improving accuracy. Speeding up the ‘boring’ parts of the swing the beginning and end might be another way of giving the casting a better feel.
      • Less repetitive music: People get bored of the music rather quickly.
      • The later portions of the game become boring: Try having fish reproduce at a certain rate if they get below a certain population threshold or make the larger fish more interesting to catch. I’d still like to keep the possibility of ‘fishing out’ the area so that an extinction ending is possible.

      Opportunities: The following are glimmers of fun that could be accentuated in a future version.

      • There should be more things in the ocean: There is immense opportunity for bonus objects to be hidden in the ocean. For example: Treasure chests, Glowing orbs that spawn rare fish or deadly fish, Temporary lure or rod power ups that only last a certain amount of time
      • A fish collection: Imagine that every time you collected a new fish, you got a stamp for that fish in a collection album. It is a like butterfly collecting, except with fish. Some people would need to “catch ‘em all’ which would extend gameplay. With a bit of color cycling or special effects, you could easily create dozens of different fish with different costs and rarities.
      • More fish movement: The fish have generally simplistic movement. Fish that dart at a lure or that move very quickly or very slowly might add some interesting texture. It is worthwhile to see if the catching of a single large fish can be made more interesting.
      • More lure types: The types of lure could be expanded up on. For example: Lures that only work on fish of particular colors, Lures that are more or less bite resistant, Lures that attract some fish and repel others. , Lures that upgrade some fish into more valuable fish, Lures that allow you to capture multiple fish or a set of fish in a row.
      • More levels: There is a single level. It could be interesting to have the girl jump on a boat and travel to a new island with more fish. An alternative progression is for the sea to evolve over time. Once you collect certain fish or reach a certain amount of money, kelp can slide aside or a cave entrance can be blown up that introduces new fish and new treasure.
      • Fog of war: One of the exciting bits of fun that emerged from the prototyping was a sense of discovery as you are able to fish out further and further. A feature that should add even more mystery to game is fog of war system similar to those found in RTS games. The area around the lure could show you the fish nearby. Areas that you hadn’t explored would be opaque. Areas that you had explored would show markers or partially transparent versions of fish you had seen. Combined with ‘rare’ fish that could only be found in certain areas, this would give players a much stronger sense of ‘exploring’ the ocean.
      • Add a serious ending: One of the key endings in the original design is the ability to cause all the fish to become extinct. It adds an interesting twist to what would otherwise be a mindless game. The system is built so that users slowly fish out the small fish and eventually gain new technology that allows them to fish out the larger deeper fish. This systems-based narrative parallels the pattern of fishing in the real world and seeks to teach a small lesson. The dynamics could be augmented by systems that catch large numbers of fish at once so that it becomes quite easy to overfish. The addition of a ‘save’ system that lets you come back later to harvest fish (and score) for long periods of time would encourage manageable fishing tactics.
      I hope everyone enjoyed this prototyping challenge. These challenges are evergreen, so just because I’ve given out the first round of awards doesn’t mean you should stop developing! Keep going. I would like nothing better than to give out another gold medal. If you update your project and want me to take a look, just drop me an email at danc[at]lostgarden.com. I can be a bit slow at responding, but I will write eventually.

      As the years go past and my hairline continues to recede, I find that I have a debt that I am obligated to pay back. Very few of the current generation of game developers started from scratch. We’ve all looked at tutorials or snagged bits of free code. We’ve built upon tools like Flash or engines like Quake or Source. We’ve been inspired by existing designs or read books that have opened our eyes. Once upon a time, I too was in Andre’s shoes and it was only due to the opening of an unexpected opportunity that I’ve arrived at where I’m at today. If these prototype challenges ease another eager game developer’s path in even a small way then my time on this blog is well spent.

      Happy holidays. Go make some great games!

      References and notes

      Project Horseshoe: Multiplayer Game Atoms
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 12 February 2009, 5:54 pm

      The 2008 Project Horseshoe reports are up! We wrote about how to diagram multiplayer games using skill atoms. Truly a brilliant weekend. The discussion was quite wide ranging and as a result the write up became a bit...long. However, the results should spark a few brain cells. Let me know what you think! :-)


      Best wishes,

      PS: There are some great reports up this year so be sure to browse around a bit.

      Review of "The Art of Game Design" by Jesse Schell
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 19 February 2009, 4:56 pm

      Recently I wrote a review for Jesse Schell's new game design book. You can read it up on Gamasutra.

      Here's a brief except:
      Though the elements of game design are well described, practicing designers won't find a lot of new insights that haven't been covered elsewhere. Luckily, the book also includes some more utilitarian tools in the form of 100 "lenses", or questions that help you iterate on your current design.

      A designer's job often consists of asking questions. Almost as soon as you start building a game, you need to ask "what should be improved?" There are nearly an infinite number of questions one could ask and often finding the right question to ask is key to coming up with the right solution.

      The 100 Lenses are a set of time-tested questions that you can ask about your game. Are you using your elements elegantly? Could your pacing be made a bit more interesting by using interest curves? What is the balance of long term and short term goals for the player? One of my favorites is Lens #69, The Lens of the Weirdest Thing:

      "Having weird things in your story can help give meaning to unusual game mechanics -- it can capture the interest of the player, and it can make your world seem special. Too many things that are too weird, though, will render your story puzzling and inaccessible. To make sure your story is the good kind of weird, ask yourself these questions:

      What's the weirdest thing in my story?
      • How can I make sure that the weirdest thing doesn't confuse or alienate the player?
      • If there are multiple weird things, should I maybe get rid of, or coalesce some of them?
      • If there is nothing weird in my story, is the story still interesting?"
      • These are the sort of questions that get me looking at my game designs from a new perspective and can really jolt the creative juices. Not all of the questions will be useful.
      However, somewhere in the list are at least two or three questions that even the most experienced designer wished they had asked sooner. By having the questions at your fingertips, you can ask them earlier.
      Thoughtful writing on game design always get my brain churning in interesting new directions. With Jesse's book, I was reminded what a broad ranges of disciplines that game design ultimately includes. I have taken a narrower route and spent the last couple of years focused on a rather specific set of tools related to rapid iteration and skill atoms. Yet there are dozens of fascinating nooks and crevices in our evolving craft that one could profitably invest their life exploring.

      take care

      What is your game design style?
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 2 March 2009, 12:38 am

      I was about to ask a friend what sort of games she liked to make and I realized that I didn't even know how to frame that question in an intelligent manner. I've noticed that games have distinct styles. These are not visual styles. Nor are they styles associated with prefered process of development. Instead, they are unique styles of game design, how you mix and match mechanics, story, player agency and feedback. What do you emphasize? What aspects of the the player's experience do you highlight with your design choices?

      A spectrum of game design styles
      It is a broad topic, so I'll just jump right in. Here are some styles that I've noticed. You can think of these categories as pieces of a spectrum that cover all major aspects of the final game design that the player experiences. Though they are all present, each style is emphasized to varying degrees in a particular title.
      1. Copycat: make a game like another game that is interesting.
      2. Experience: Make a distinct moment of game play that looks and feels interesting.
      3. Narrative: Make a story that is interesting
      4. World: Make a place or world that is interesting
      5. Systems: Make systems and objects that are interesting.
      6. Player Skills: Make verbs for the player that are interesting.
      Let's give a brief description of each of these styles and how I've seen them work.


      A copycat designer takes an existing game genre and builds a new work within it. The term 'copycat' is descriptive and not derisive. I personally steal with great gusto from other games and consider an elegantly pulled off theft to be an essential skill for any practicing designer.
      • Copycats borrow liberally from the best elements of past works and mix them together with minor design innovations to create the new flavor of the month.
      • If design problems arise, a good solution is often readily available in a historical product in the same genre. The best copycat designers have encyclopedic knowledge of other games in their genre.
      • The goal is almost always to make something better or 'more correct' than what has been on the market previously.
      Most working designers are copycat designers. On the supply side, there exists a natural urge for a player who deeply loves a particular genre to attempt to do a better job. This provides a constant wellspring of new copycat designers. On the demand side, the market's lust for sequels ensures a wide range of jobs that need good copycat designs. Helping this dynamic is the fact that it is quite easy to learn to be a copycat designer. Find a game you like and copy it. You don't need to know theory or have a strong philosophy of design. Over many years of labor you'll likely get quite good at making polished variations on the initial blueprint.

      • Competition is intense. Most of the time you are fighting over market share in a crowded genre. You can avoid the competition by building a strong established brand (which costs lots of money) or you can be first to a popular new platform (which requires technical resources and the ability to predict future markets)
      • Costs are high. All the polish required results in long development cycles with large teams and large marketing budgets.
      • Risk aversion dominates: Both copycat players and developers are risk averse. Players want their comfortable fix and developers don't want to introduce undue design risk in an already financially risky project. This often leads to bigger titles that are not always better.

      An experience designer has a vision in their head of how the game will eventually look, feel and sound. They seek to create an emotional moment for the player that matches their vision.
      • Experience designers start with a mental image of the game. It could be a still shot. It could be a scene. The scene is laden with strong emotional and evocative detail.
      • Everything in the game exists to serve and bring to life that vision.
      When I think of games that demonstrate the Experience style, I immediately think of Flow and Flower. Graveyard is also a good example. Starting with a target experience has a lot of benefits. You can change your art, mechanics, story and other game elements to match the experience. Experience designs have the added benefit of making the original designer valuable and nearly irreplaceable. The vision resides primarily in their head and they can act as the final arbiter of whether or not the actual product meets their vision.

      • Designs based on a vision are difficult to communicate. On larger teams, communication mistakes can multiply and bog down the project.
      • Teams can wander down dozens of different paths and still not reach the ephemeral vision in the designer's noggin.
      • Occasionally other game play elements are poorly fleshed out. You can easily end up with something that is pretty, but isn't all that fun to play.

      A story designer has a tale, usually a linear sequence of evocative events (or graph of such events), that they wish to tell. Games are the stage upon which the story is performed.
      • The game is conceived as a narrative arc and gameplay is often relegated to mini-game set pieces strung together to support the creation of the arc.
      • Design efforts focus on the use of symbols and pacing to evoke emotion. When the designer kills or removes a character and there is nothing the player could have done, you know you are dealing with a Story Designer.
      • The game is a success if players react strongly to the story that has been woven for them over the course of their play.
      Story designers are quite common in larger scale games. Many AAA titles sports a very specific 'roller coaster ride' structure that has narrative design at it's heart. Examples of games built by Story Designers are everywhere. Choose your own adventures are the classic case, but I'd be curious if even a game like Passage was ultimately conceived as a tale with fixed endings (albeit one where authorial intent was enforced by a predestined algorithm).

      • Most story-based games can only be played once or twice before they are no longer interesting. They deliver their tale and then their value is spent.
      • Every little bit of must-see narrative steals a smidgen of agency away from the player. Instead of letting the player author their own story, the designer steps in and forces their own narrative upon the player. This limits the player's ability to try and learn new things.
      • Failure is rarely an option, or at least not a serious one. After all, there is a story that must be told. Many times players are shunted from plot point to plot point with minimal gaming fuss.


      A world designer begins by envisioning an imaginary space. They picture how it might be if they escaped into it as a player.
      • Place is a critical organizing concept. Items, people, organizations lives in specific places and their spatial relationships give meaning to the world. It is quite common for world designers to think in terms of maps, architecture, towns, races, guilds, districts etc.
      • Much of the flavor of the place is created through the use of historical detail. The underlying assumption is that the world existed when the player was gone and it will exist when the player leaves.
      • World designer will often lean heavily on fresh content in the form of new vistas to create a sensation of being in the world. They will often use the same game mechanics throughout, but delight the player by varying the setting from location to location.
      The classic example of a World Designer is found in the paper RPG world. A GM will start with a map of continents and flesh out civilizations, races and alliances. This creates a playground for imaginative adventures. Games like Ultima, Oblivion and World of Warcraft also have a strong World style.

      • World designs can often result in bloated games. There is so much stuff in the ever evolving world in your head that it is hard to know when to stop adding. New systems and verbs are created to support the exploration of every nook and cranny and few mechanics interconnect in crisp manner.
      • World designs are usually an immense amount of work. It is far easier to make a single scene or a situation than it is to flesh out an entire world.
      • Designers can focus so much on building the space that they forget to fill it with interesting things for the player to do. The result is mechanical place that feels lifeless.
      Systems designers begin with a curious and intriguing set of rules that interact in unexpected ways.
      • Designs often begin with a set of objects, properties and interesting ways that the objects interact.
      • Common sources of inspiration include probability, combinatorics, spacial relationships, physics, timing and economic game theory.
      • The goal is to create a challenge for the player, be it a short term challenge in the form of a puzzle or a long term challenge in the form of a deep possibility space.
      • Truly deep systems often lay bare their mechanics in order to provide advanced players with absolutely clarity on their inner workings. The result is less room for details like narrative or world building.
      Many of the industry's most original forms of gameplay were conceived by people inspired by systems. With simpler rule sets, you find games like Tetris. Complex systems yield creations like SimCity or Populous.

      • You'll often end up with a system that is fascinating to the designer, but not that enjoyable to the player.
      • Many systems oriented designs come across to players as overly abstract. There isn't a clear entry point into the design for new users in the form of a friendly metaphor or setting.
      • Systems can be quite difficult to balance due to all the various emergent interactions.
      Player skills

      Designers that focus on player skills create a set of actions (or 'verbs' in Chris Crawford lingo) for the player to perform. Then they create systems that help them learn those skills.
      • You start by writing out the type of verbs that you want the player to perform.
      • Then you figure out systems to go with those verbs
      • You figure out what additional skills are discovered when the systems are put in front of players.
      • Finally you figure out the right feedback systems to teach people those skills in an enjoyable manner.
      Miyamoto is a good example of a designer inspired by player actions. When developing games he tends to focus on what the player is doing. Mario was originally named Jumpman after the key action you performed in the game. WiiFit came about by asking what sort of game could be built around the joy of weighing yourself. Mario 64 started as a playtest bed where all you could do is run around a small room and exercise the basic verbs of the game.

      • Game play occasionally devolves into a series of disconnected mini-games when designers grab the easiest system available to represent a particular action. For example, in FishingGirl, I used a Frogger-style mechanic to represent fishing. As a simulation it was quite limited and was barely connected to the other mini-games associated with of casting and purchasing lures. In something like God of War, they turn the action "Kill boss monster" into the simplistic mini-game "Simon".
      • After coming up with a set of fun actions, narrative and world are applied as a skin to the results. The result are surreal worlds involving mushrooms, exploding barrel graphics and other videogame-isms.

      Rising design styles
      The following styles are starting to appear within a few pockets of game design community.

      : Designers that focus on encouraging particular types of interactions between multiple people. They have skills of event coordinators or party planners and focus on atmosphere, breaking the ice, moving people from activity to activity as well as efficient build up and take down of the event. Important organizing concepts include 'Events' and 'Social spaces'. MMOs, Party games, and social networking games tend to attract Social designers. It is my believe that the next generation of great designers will be social designers.

      Business: Design that focus on business try to squeeze as much money out of players as possible. I meet designers operating in online games and gambling games with this design slant. Typically, you encounter it in ex-designers who have moved onto publishing roles. It is an extremely powerful perspective that is unfortunately rather rare. As free-to-play becomes more popular, gameplay and business model will become even more interwoven.

      Product Utility: Designers that focus on player value first identifies some form of utility that the product bring to the player. Product Utility designers often come from a more traditional product design background and focus on creating innovative solutions to observed problems. Yahoo, Amazon, Iminlikewithyou, and numerous web 2.0 companies a busy using the motivational aspects of games for utilitarian purposes. In short, this is social engineering with a purpose.

      Pick your style!
      Most designers tend to mix a couple major styles together. For example someone who enjoys working on licenses might start with a world style and do a deep dive to understand the world of the license. Then they augment that with a copycat design. Or someone who works on art games could mix a strong narrative with a systems oriented set of mechanics.

      My suspicion is that most designers will have trouble applying all these styles to a game equally. First, each style can easily take years of intense labor to master. Secondly, games need focus in order to clearly convey their intended value. Too many dominant ingredients fighting for the player's time can weaken the end result. It is a bit like cooking. :-)

      As an exercise, take a look at various games out on the market and see if you can figure out the handful of styles they've stirred together. Halo is classic Copycat with a heavy coating of Narrative to make it seem like something bigger than your typical game. Desktop Tower Defense a straight Verb and System game, barely seasoned with any other styles. Ian Bogost refers to Jason Rohrer's work at 'Proceduralism'. I see a fascinating mix of Narrative and System styles.

      So pick two or three styles for each game you build. Prioritize one as primary and others as secondary (in case there is a conflict at some point later in the design.) Don't ignore the remaining styles since you'll certainly need dashes of them to make the game function. However, be conscious of the dominant style of game you are making and make the hard decisions on what to focus on up front.

      Understanding design styles to reduce team conflict
      Inevitably there will be people on your team or in your audience who are fans of the other styles of game design. I regularly run into good people working in the game industry who passionately want to tell the sort of emotional stories that they see in movies. Story and Experience are paramount to them. However, any sort of Systems conversation inevitably devolves into a muddled Copycat discussion.

      You can use the game design styles above much like how personality tests are used to resolve conflicts between people with different work styles.
      1. Identify your personal style. Which of those styles above do you love? Which ones do you find dull or unpleasant?
      2. Identify the style of the game you are working on right now. It is very common for this to be something different than your personal style. Publicly declare the style of game you are making so the entire team can agree upon the game's direction.
      3. See if you can understand the preferred style of other people around you that tend to hold forth passionately on game design.
      4. Realize that having people on the team who are passionate about a variety of different styles is a good thing. Just because you occasionally feel the other person is coming from a bizarre and alien perspective doesn't mean that they don't have something valuable to contribute.
      5. When the opportunity comes to up to add in a dash of 'spice' in an area outside your personal style, see if you can tap into the passion of someone who prefers that style. We can't lead all the time in all areas, nor is it a good idea to try.
      My style
      I almost always approach a new design from a Systems perspective. I find an interesting set of objects that interact with one another in interesting ways and then attempt to build a game around it. My typical process is to try lots and lots of systems, throw them at kleenex testers and see which ones are 'fun'. This is labor intensive, but you can keep the costs down by using small agile teams and simple prototypes. It yields games that are lower on the copycat factor. However, they also have a bit of a surreal aspect to them since experience, story and world tend to be re-imagined on the spot to fit the latest mechanics.

      Lately, I've been moving more in the direction of a Verb style. With Systems, I'll often end up creating a game that is fun to design, but not fun to play. By focusing on the verbs and how the systems help the player learn to manipulate the system, my prototypes "find the fun" more often. If games create pleasure through exploratory learning, it makes sense that focusing on verbs and skills are one of the more direct paths towards creating engaging game play.

      Narrative is my main weak point and something I should work on.

      One thing I get out of this exercise is that there is not one True style of game design. For every Miyamoto and Will Wright creation there is a game like Monkey Island or Full Throttle pushing story and experience. People love all these games. Game design style, like style in almost any consumer market is a matter of taste. The good news is that now I can name the various styles and discuss them in a less vague fashion.

      I also realize that I've been leaving certain powerful perspectives out of my palette of game design tools. When I was younger (and driven more strongly by raging hormones), experience-driven games mattered immensely. I vividly remember working on a game about sickness and trying to convince my fellow teammates that it was of utmost importance that black cancerous growths fall off the player and scuttle away on their own. As I aged, I've moved onto more intellectual and less emotional designs. It might be fun to bring that side of my design back one day.

      Of course, this list of game design styles is a work in progress. So I'll end with some questions.
      • What style of game designer are you? Do you fit into one of these approaches?
      • Is there another design style that is missing from this list? Can it be expressed by a combination of the other styles?
      Take care,

      Game design in 2020
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 9 March 2009, 4:41 pm

      My short essay on future games was selected to be part of the recent Gamasutra 'Games of 2020' feature. The treatment is tongue in cheek and I owe anyone I photoshopped a free beer.
      You can read the whole thing here:
      The result of all this is that I am now able to attend this year's GDC. If anyone wants to meet up in San Franciso (March 23rd to March 27th), drop me a note at danc [at] lostgarden [dot] com.
      take care

      Danc's Miraculously Flexible Game Prototyping Graphics for Small Worlds
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 15 March 2009, 1:36 am
      Don't you think it is time for some new free graphics?

      The originals
      The original set of miraculously flexible prototyping graphics have been out there for a couple of years now. In that time, they've been used in mini-MMO's, shooters, RPGs, platformers and dozens of various projects that lurk in the dark squishy nooks of the ever fermenting, communal indie mash.

      However, they had some issues.
      • They were in a format that wasn't readily accessible to most users. In particular Flash games didn't make as wide a use of them as I would have liked.
      • They required a rather tricky placement system that most tile based engines had difficulty handling.
      • Very few games used the shadows system and without the shadows, they tend not to look very good.
      There were also a couple other areas I wanted to explore.
      • HD pixel art: There is an emerging artistic style that showed you could keep the intricate iconic style found in pixel art, but modernize it in such a way to take advantage of the crispness found in modern high resolution displays. The result found in games like Pixel Junk Monsters, Patapon, and Loco Rocco is distinctly game art. It tends to be 2D and highly evocative. But is also is information dense and full of distinct iconic symbols that have meaning during game play. When there is a trade off between realism and functionality, functionality wins.
      • Vector art: I've done immense amounts of raster art over the years, but lately I've been playing with more vector art. The tools have gotten to the point where you can do some pretty nice stuff rather rapidly without needing to ever go to bitmaps. They are rendered natively in Flash or Silverlight and you can play with scaling without worrying about loss of detail.
      • Arbitrary placement: Once upon a time, you needed to use little square tiles for everything. Nowadays, there is no real need to make a tile based 2D engine. With arbitrary images with full alpha and lots of fill rate, you can put together a game like a sticker book. Drop down your graphics at arbitrary positions and layer like a madman. Games like Aquaria look great and tiles are nowhere to be seen. There's a good tutorial on the topic here: http://gametuto.com/in-game-c-map-editor-tutorial-with-indielib-engine-that-dosent-use-tiles-but-pieced-images-like-in-braid-or-aquaria-games/

      Small World

      So I started a new graphics set that took all these into account. The theme I chose was the 'Small World', an intimate place of green trees and blue ocean seen from above. For ages I've been fascinated by tiny worlds that you could imagine keeping like a bonsai garden on a table top.

      What types of games can the Small World graphics be used for?
      • Turn-based strategy games
      • Real time strategy games
      • RPG's
      • God and Sim games
      • Tower defense (the original inspiration for this set was Pixel Junk Monsters)
      • Crazy innovative games that will shock and amaze the world.
      What does the set include?
      • 70 high quality sprites
      • The original Illustrator CS4 .AI file
      • The exported Flash CS4 .FLA file
      • The exported Flash CS3 .FLA file
      • The exported Flash 10 .SWF file (with linkages)
      • Land
      • Forests
      • Buildings
      • Dialogs and buttons
      Having the source files allows you to easily manipulate and edit the graphics so you can make variations or combine pieces together. You should have enough pieces to easily prototype attractive little worlds full of forests, fields and cities.

      What doesn't this set include?
      • I have some characters that fit this set, but those will be coming along at a later point.
      • I haven't had time to cut out all the bitmaps. This is coming shortly unless someone else cuts them out first.
      • Other formats: In general there are a billion minor formats that all have their passionate proponents. Convert at will. :-)
      The License
      Much of the email I get involves questions about how various graphics can be used. Though I love hearing from you, it has become apparent that the license needs to be clarified so that I can spend more time making stuff for you and less time writing back about the legal issues.

      A second issue is that there have been some unfortunate incidents where players have taken talented developers publicy to task for 'stealing' my artwork or 'copying' game designs. 'Open source game designs' are admittedly a cutting edge concept in our IP-clutching world, so there is some education to be done.

      As of today, I've created a separate Lost Garden Licensing page that outlines the license for these graphics. If you plan on using these graphics, be sure to read it. The basics are that they are free to use in both commercial and hobby projects under a standard Creative Commons Attribution license.

      The goods
      So what are you waiting for?

      I'll be releasing some prototyping challenges that make use of these graphics in the future, but for now just have fun and give them a shot. They were a blast to make.

      take care

      PS: I also included graphics that allow you to make arbitrarily sized islands composed of splotches of land stuck together. This is a tricky technique that only advanced users will undertake. First lay down the water. Then lay down all the Land-Bottom graphics. Then lay down all the Land-Mid graphics. Finally draw all the Land-Top graphics. By layering the graphics in this order, you can create islands that merge together visually.

      Bunni Sneak Peek
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 26 April 2009, 5:59 pm
      I had an immensely good time collaborating with Andre on Fishing Girl earlier this year.  He was looking for a new project and so we started idly chatting about random ideas. One thing led to another and he is now nearing the finish line on a new Flash game called Bunni.  I thought Andre might enjoy a little bit of public encouragement as he enters the final stretch.  

      I've been wracking my brain and I don't know of another game out there that is quite like Bunni.  Imagine if Animal Crossing had a long lost mutant sibling that coalesced out of a creative flurry in a mere four months.  There is no clever twist on shooting, block stacking, or 2D platforming. It is not an innovative music game.  Nor does it involve playing with time or bizarro spacial dimensions.  If there are any puzzles, I apologize since they weren't intentional. In fact, it isn't a very hard game. I've yet to find a single hidden object, probably because there aren't any.  Despite lacking all these critical things, play tests end up lasting for hours. 

      I don't want to give away too much about the game, but I can share a single, mildly cluttered screen shot.  Yes, that is a pirate bunni.  And no you can't have one unless you are very, very special. 

      Bunni: First Screenshot. Likely to change in inexplicable ways. 

      Oh, and as a bonus, here are some t-shirt designs. Let me know which ones you like the best.  (I tossed together a storefront as well just for fun.  The internet is so awesome.)

      Broken Hearted


      In Love

      Long road to love

      take care

      Engineering Emotions: More predictions come to pass
      Posted by Lost Garden [HTML][XML][PERM][FULL] on 2 June 2009, 6:03 pm

      Back in 2007, I wrote about some hypothetical technologies like real time motion capture, voice recognition and biosensors that were on the horizon that would have  a dramatic impact on how we design emotional games.  Those technologies are now becoming mainstream with console accessories like Microsoft Natal and the Wii Vitality Sensor.  Others techniques like feeding player's input into internet API's like search and social networks are already easily implemented using basic capabilities available to even the most limited game devices on the market. 
      In the essay Constructing Artificial Emotions, I described a 'crazy' futuristic game design called Bacchus: 
      "Bacchus is a multiplayer dancing game with a religious theme. The selling point is its ability to evoke intense emotions.

      Imagine if you will, a decrepit theater filled with writhing, dancing people. The lights flare and swoop in time and the people chant in unison. A massive screen shows a mirror image of the hall like some surrealistic portal into an alternate universe. Instead of blokes and lasses in street clothes, the on screen spirits are clad in ornate ritualistic garb. The movements on each side of screen are eerily synchronized. The pitch of the chant rises.

      The screen zooms in on a girl in the center of the room. The crowd, as one, turns and watches her figure on the screen. She begins to dance. At first her movement is controlled and intricate. The screen pulsates and she yells to its beat. The room takes up her words and amplifies them, giving them god-like resonance. Bass mixed with reverb mixed with primal, guttural passion. Her dance becomes wild. The pace increases and she begins to confess.

      The theater reacts. Each word she utters shimmers on screen, merging with ghostly photos from her past. In a beat, the entire room witnesses her sorrow over the death of her mother, her time alone in an empty apartment, and her first kiss. An inhumanly beautiful electronic chorus rises, matches and turns her words into a song. Her movements become a blur. Her glowing eyes are ecstatic. At the peak, her spirit on the large screen explodes in light and the girl collapses to the floor in fervent religious swoon.

      The crowd goes wild. The screen zooms out and the next god dancer is chosen. 

      Later, the girl writes to her online friends that the night she danced was the single most powerful spiritual and emotional experience in her entire life. It was the night she was touched by a higher power while playing a video game."

      The original essay is an admittedly difficult read, but I recommend revisiting it.  In short, psychological experiments show that by intentionally mixing physical states of excitement with the appropriate context a designer can concoct emotional responses that are indistinguishable from naturally occurring emotions. The design techniques described within are no longer futuristic daydreaming.  A basic form of Bacchus could be made in the next few years. 
      In the past games have been limited in the types of responses they can evoke in players because the range of human activities that we could model and reward were limited.  We've admittedly designed amazing experiences that only rely on the limited ability to press a button.  However, a cursory inventory of the human body and mind is surprisingly more comprehensive than a twitching thumb.  We can move our amazing and capable bodies, we can engage in complex social interactions, we can become excited or depressed.  All these basic elements of our humanity have been outside the realm of game design because we could not track them, build models around them or reward desired behaviors. 
      Now we can. 
      With these new tools and a mass market that embraces them, we have a vast laboratory of millions of players.  Early mini-games will act as experiments in the engineering of human emotions.  Initially, we'll focus on found fun since that is what our audience is currently trained to consume.  With time and enough experiments, we'll begin to notice that with the ability to manipulate body, mind, social context and excitement level, we gain the ability to evoke deeply meaningful emotions. Imagine visceral sorrow, lust, anger, happiness, cruelty, generosity, stress and contentedness.  All the emotions reproducibly evoked in psychology lab experiments become our creative palette. 
      Every game becomes a reality television show starring the player. 
      Every game designers becomes pragmatic engineers of the player's emotional experience, dissecting and reconstructing the ephemeral moments of human nature.  Our games turn into intricate systems of hardware and software that play players like a willful instrument. 
      Hardware like Natal, MotionPlus, Sony's wands and the Vitality Sensor are really just the beginning. There is an entirely new class of middleware that tracks the torrent of new sensor information and teases out useful patterns of human behavior.  Fresh emotional game mechanics that are as new to the world as moving objects in Spacewar! must to be invented from whole cloth. There is great work to be done. 
      Once again, I'm reminded what an exciting time it is to be a game developer. 
      take care

      << Newer Entries · · Older Entries >>

      Show: [ALL] [NEWS] [BLOGS] [PODCASTS]

      Updated Today:
      A Green Mushroom [HTML] [XML] [FULL]
      Engadget Gaming [HTML] [XML] [FULL]
      Eve Bloggers [HTML] [XML] [FULL]
      GamesRadar [HTML] [XML] [FULL]
      Lineage II [HTML] [XML] [FULL]
      Massively Overpowered [HTML] [XML] [FULL]
      MmoQuests.com [HTML] [XML] [FULL]
      Ogrebear's Thoughts [HTML] [XML] [FULL]
      Rock Paper Shotun [HTML] [XML] [FULL]
      Updated this Week:
      PC Gamer Podcast [HTML] [XML] [FULL]
      The Old Republic News from Bioware [HTML] [XML] [FULL]
      Updated this Month:
      Chimps in Space [HTML] [XML] [FULL]
      Heartless Gamer [HTML] [XML] [FULL]
      Morphisat's Blog [HTML] [XML] [FULL]
      The Instance [HTML] [XML] [FULL]
      Troll of Fire [HTML] [XML] [FULL]
      Van Hemlock [HTML] [XML] [FULL]