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. 

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.

Conclusion

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 designed based on a passionately held ideals. 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,
Danc.

Go to Source

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

Go to Source

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

And when confused looks inevitably result, 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.

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

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

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

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

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.

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.

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

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

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 objective, 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 subjective 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

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.

Cycling

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.

Conclusion

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

Go to Source

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.

• WordCamp PDF with images and notes

take care
Danc.

PS: You can embed PDF files in slide share!  This allows me to share my presentation with notes.  That took me a long time to figure out.  Thank you, Rashmi!

Go to Source

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

Go to Source

take care

Go to Source

This year I’ll be giving two talks, both during the prime napping hours of day.

The Convergence of Flash Games and Social Games
Wednesday (March 10, 2010) 1:45pm — 2:45pm

IGDA: Working to Death – Game Developers and the Future of Work-Life Balance
Thursday (March 11, 2010) 1:30pm — 2:30pm
With Erin Hoffman (IGDA Board Member, Quality of Life SIG cofounder, Moderator), Hank Howie (President, Blue Fang Games)

take care
Danc.

PS: Steambirds is out. That means you can play it. Right now. If you like it, you owe Andy a beer. http://armorgames.com/play/5426/steambirds

Go to Source

The game
Steambirds is a rare treat. The magical design equation = Steampunk + Turn-based strategy + Air combat.

Despite my immense love of turn-based strategy games, I’ve found two problems with the genre over the years. First, very few people make them any longer. This is simple silliness and is easily rectified. Second, and perhaps more damning, most turn-based games that exist take forever to teach and play. The gaps and chinks that once appeared in my youthful schedule are now jam packed with accumulated tasks, looming responsibilities and the vast pressure of my imminent demise. I’m lucky to squeeze in even a few minutes of playtime at the end of a long day.

With Steambirds, the devs managed to make a deep strategy game where a single match is over in minutes. It fits into my life. The interface is super streamlined so even casual players can learn the basics in 30 seconds. My wife, not exactly a hardcore gamer, has been playing for days now. How cool is that?

I’m a fan. Here’s a simple question that should be asked of all games: Who is responsible for making this wonderful experience?

The problem with game development heroes
Here is what I have observed: If a game is built by a large team and published by a mainstream publisher, you cannot know who is responsible for the game.

As an exercise, name a modern developer whose work has changed your life. If you are a mainstream gamer, you’ll likely name the talking head behind the latest console smash. Chances are that the individual you think of as the key creative force is:

• A cog in a much larger machine. Only rarely does an individual contribute more than 1% of the magic that makes a large title sparkle. There are just too many cooks in the large scale game development kitchen for individuals to shine.
• Not directly responsible for the market success of the title at hand. Much of the success of AAA titles is based off brand and marketing budgets that weigh in at double the development cost. Without the expensive propaganda the drives a finely honed message into our consciousness, many of the ‘most popular’ titles would be little more than footnotes.
• Made spokesperson by the direction of marketing. Talking heads, even ones with the title of ‘designer’ or ‘producer’ are often selected for their ability to A) deliver a message or B) coast by on their past history. Few tell an authentic story based on their personal contribution to the game. Real contributers are hidden behind the anonymous whitewash of the studio name.

The game media, trained to vacuum up press releases and pre-packaged interviews, never asks the probing question “What did you actually do?” or “Well, if you didn’t, who did?” Marketing handlers merely selects a plausible face and media blindly crowns them as worthy creative visionaries.

Idols, even false ones, fill a uniquely human need for worship. Both gamers and journalists are desperate to adore, to celebrate, to follow the brilliant individuals that birthed our favorite games. When presented with the mechanistic, faceless truth of modern game development, we reject reality and seek something, anything that fits our preconceived notions of creative genius. A paper hero constructed of marketing materials fits the fan’s need and is gladly assembled for each game launch.

But do we really need to settle? Are artificial heroes necessary? What if there were real gaming celebrities out there who are actually worthy of our veneration?

How a fan should select an authentic gaming hero
Here’s an exercise for selecting someone in the game industry to admire.

1. Is the game worthy?
2. Are you being lied to?
3. Are the authors identifiable as a real human being?
4. Is their contribution meaningful and authentic?
5. Does their contribution predict future enjoyment?

As we step through each of these, I’ve got a bold claim that I’ll state up front: The only people that we, as fans, can claim with 100% certainty are worthy of our appreciation are small teams of independent developers.

Is the game worthy?
You can think about the worth of game in terms of Reach (the number of people it impacts), Depth (the depth of the experience) and Innovation (the degree to which the game moves the industry forward.)

Reach: An indie title like Steambirds will almost certainly will reach millions. It will be played by more gamers than 99% of all games on any game market. Take your pick…Xbox, Wii, PS3, DS, iPhone. In terms of broad popularity, Steambirds will have a bigger reach than the vast majority of games ever released during the history of gaming. Let that sink in for a moment.

Depth: For a percentage of players, a game made by one or two people can be just as compelling as any bloated AAA monstrosity. The elegant birds flying upward in Adam Saltsman‘s Canabalt spark deeper feelings within me than any of the overwrought hair porn smeared haphazardly across Bayonetta.

Innovation: A game like Steambirds doesn’t play much like the vast number of clones that continually flood the market. From one perspective, it is another turn-based strategy game that has clear roots in existing (albeit obscure) boardgames. Yet compared to the dozens of FPS, physics games, platformers, tower defense titles and match 3 games, a project like Steambirds is delightfully unique. It innovates in terms of UI. It innovates in terms of genre pacing and mechanics. It even takes place in an original setting. (One where the fusion reactor was invented in the 1800s!)

I use Steambirds as an example, but there are dozens of indie titles that fit any sane definition of worthy. When you objectively measure game on worth instead of paid hype, you realize that games built by independent developers are rapidly becoming the defining experiences of a whole new generation of players. Just the other day I was chatting with my doctor, a gray haired lady in her fifties. She started excitedly talking about the great new game she was playing, a title called Osmos. This isn’t some mainstream or casual title…it is pure indie gaming. It hit me: our stereotypes are broken. The fact that a game is ‘indie’ no longer limits it to being a niche product.

Greatness is now independent of development budget. It is no longer defined by team size or marketing campaigns. A great game is a great game, be it a AAA marquee title or a 2D project made by two guys with a dream.

Are you being lied to?
If there is a publisher, there is always spin. It is built into the incentive structure associated with funding and marketing a game portfolio.

With an indie game like Steambirds, there is no vast publisher machine with a financial need to twist and massage the truth. You are connected directly by blogs, forums and interviews with the developer. Many times they are the ones responding to your emails directly. There are no endless lists of people who may or may not have actually ever made something. Unlike most most pro developers, the human beings responsible for every lovingly crafted detail of indie games even have names. You can look them up. They have ugly, honest, human websites, not extravagant confections excreted by nameless outsourced minions.

Honesty and transparency should matter to true fans. It is worth dedicating your passion and energy to something real, not a lie.

Are the authors identifiable as real human beings?
For Steambirds, I helped a bit on the design and graphics, but real creator of the game is Andy Moore, who worked alongside Colin Northway on the phenomena called Fantastic Contraption. The musician is by DannyB, the sizzling dynamo behind games like Canabalt and Super Meat Boy. In some ways, it is a game made by indie superstars.

It matters that Andy Moore is a real person, not a cog playing a role. I’ve met him last year in Austin and together we drank some fine microbrews. Along with a crew of other indies, we partook in an ill fated 2am adventure through the back alleys of Austin in search of a magical rumored cupcake deli. As we were chatting, he told me how after Fantastic Contraption, he sold off everything that didn’t fit in a suitcase. This practice is called ‘rightsizing your life‘ and it shows a dedication to game development that I find both rare and admirable. The fact that his lovely girlfriend puts up with his artistic journey is even more admirable.

Now, he lives to make games. Just last weekend, he was tapped as a mentor for the Global Game Jam and stepped up at the last minute to bail out a failing team. By the end of 48 hours, they had created a giant grotesque caterpillar that barfed rainbows. The crowd gave him a standing ovation.

You won’t find such stories told at press junkets. In fact, you may not even be able to find out the names of the people who actually worked on the game. Merely having accurate credits is still somewhat of a controversial topic for many large developers.

Games made by real people…there is something inherently valuable about the human story behind a game’s creation.

Is their contribution meaningful and authentic?
Andy programmed every line of code in Steambirds. He isn’t a 1% contributer. He is a majority contributor. My rule of thumb is simple: If you remove a person from the project, does the project still get finished? Does it still reach it’s potential? I challenge you to find such a person on most non-indie projects. You typically won’t. The cogs are treated as replaceable components (even when they aren’t.)

After the project started, I found out that Andy is an amateur pilot. Steambirds was not merely a job. It was an opportunity for him to express his love of airplanes as a game. This intrinsic motivation is the difference between Van Gogh placing his turbulent emotions on canvas and an assembly line mechanically painting signage.

Personal passion and the size an individual’s impact matter.

Does their contribution predict future enjoyment?
You haven’t played Steambirds. But you may have played Fantastic Contraption. And you may have heard the tunes in Canabalt. There is a direct mapping between the creative skills expressed in Steambirds and your impressions of the author’s past efforts. Much like how you might check out the album of your favorite band, you should also be inclined to check out the newest game from your favorite indie developer. Their creative blood courses through their entire body of work.

No such link with the past exists on games made by larger teams. 8 times out of 10, the name of both the publisher and the development company on the box have no coherent connection with the people who made the game. The team logos are, in effect, meaningless badges that exist purely for the sake of marketing. If someone says that they like or dislike an EA game, they obviously have no idea what they are talking about.

• A publisher’s brand is a business shell, not a developer that creates authored experiences.
• Publishers often switch up teams on a title by title basis. The group that made the game that you enjoyed is unlikely to be the same team that was contracted to make the sequel.
• Large teams experience massive churn. Some groups lose upwards of 50% of their developers from game to game. The original people who made your beloved game may not even make games any longer.
• Power shifts within a large developer often alter creative direction in unpredictable ways.

A clear, strong connection between the author and his works helps you, the player make meaningful judgement about whether or not you want to try future games. Without this simple, obvious connection, you are just a sucker caught up in a cynical branding shell game.

True fans know who makes their games
In summary, when you really love a game, be it a small title or a large title, do the following:

• Find out who actually made the game you love.
• Look for games where vision and ownership are clearly visible.
• Reject the marketing machine.

As I look at this list, I am delighted by the indie game movement because for the first time in many years, players can once again associate the efforts of a human being with their great game experience. I want to be celebrate the individuals who makes the games that change my life. I don’t want to be a suckered by some expensive snow job. Indie games let me be a fan who is cheering on someone authentic and deserving. That is pretty darned cool.

take care
Danc.

PS: Steambirds is currently in bidding over on FlashGameLicense.com. Wish Andy luck!

PPS: Whoa…my mind is blown! Some eagle eyed commenters pointed out a great little space strategy game called Critical Mass by Sean O’Connor that has a very similar control system…and was created in 1995. I love it! It is awesome when two smart team independently stumble on the same solution decades apart. Convergent evolution in action. This also points out the importance of seeking out old masters for great ideas. If we had known about Critical Mass, perhaps we’d have a few dozen less UI prototypes. Credit to an original innovator where credit is due: Go check out Critical Mass.

Go to Source

The amazing thing
Imagine Microsoft Office turned into a video game. One where learning a productivity app is a delight. One where the core loop of gameplay involves using and gaining skills in Word, Excel and PowerPoint.

It sounds a bit unlikely doesn’t it?

Well, I’m happy to announce the availability of Ribbon Hero, a new download from Microsoft that turns using Office into a game. I’ve been helping the fine folks over in Office Labs with the design and we are all immensely proud that this is getting released to the public. Huge kudos to Jen, Jonas and the rest of the team. CNET calls it “Brilliant“.

Go download it now. You can challenge me on Facebook with your elite formatting skills.

The coming revolution
Ribbon Hero, in part, was born from a speech I gave back in October 2007 on applying the design lessons of Super Mario Bros. to application design. I made the following bet:

• If an activity can be learned…
• If the player’s performance can be measured…
• If the player can be rewarded or punished in a timely fashion…
• Then any activity that meets these criteria can be turned into a game.

Not only can you make a game out of the activity, but you can turn tasks traditionally seen as a rote or frustrating into compelling experiences that users find delightful.

The foundations of user experience design are incomplete
Games offer a very different value proposition than what you get from traditional usability design. The essence of modern UI design is summed up by usability guru Steven Krug’s proclamation “Don’t make me think!” We are taught, as UI designers, as website developers and as software creators that our target user is a shallow dullard. The prototypical user is presented as incapable of reading, barely cognizant of what they desire and are best served by products that offer a least common denominator feature set.

This user model is well supported by empirical data. Sit in on any usability test and your subjects will flail about, click on the wrong things and ignore most obvious visual cues. We assume that users are idiots because we see them behave like idiots whenever we test them.

The results of our current design philosophy are wonderfully simple apps that allow new users to perform one or two universal tasks in as streamlined a manner as possible. These are the Googles, the Twitters and the Diggs of the world. They focus on ease of acquisition and limit their functionality to the 20% of features that serve 80% of the population.

Yet, as applications grow, the “Don’t make me think” philosophy stumbles.

• Users grow. Given the opportunity, new users rapidly become intermediate and expert users.
• Different users, especially skilled users, want to master different tasks. Finding one or two universal tasks that matches all users is nearly impossible.
• New opportunities emerge. As both the developers and the users gain experience with the software, they discover new use cases and tasks that create immense user value. Many developers are faced with the task of either bolting on new use cases or creating entirely new software, fragmenting their brand and user base.

Google Documents is slowly becoming just as much of a usability monstrosity any major text editor (Notepad excluded). Even apps that offer a more limited creative palette such as Mint.com, Ebay and Amazon try desperately to maintain their simplicity. We attempt to leverage pre-existing skills. We carefully layer beginner, intermediate and expert functionality. We use the democracy of split testing to eliminate minority use cases.

Yet, despite the fact that Web 2.0 started with a fresh new philosophy of minimalism and a clean slate, it is rapidly converging on the same frustrating and complex usability solutions found in desktop applications. The current state of the art is missing something fundamental.

Game design focuses on improving user skills
Game design, as applied to application design, brings several powerful ideas to the discussion that are either missing or underrepresented in existing descriptions of UX design.

• Users are learning machines: All users have immense inherent potential to learn and master new skills.
• Exploratory learning is fun: Given the proper environment, users will, of their own free will, explore an unknown task. They will try, fail and then finally gain enough insight that they grok the core problem at an intuitive level. When this moment of mastery occurs, users smile.
• Exploratory learning can be engineered into repeatable systems: Moments of delight and skill acquisition are highly reproducible. All you need is a well designed and balanced system of interconnected feedback loops that helps guide and encourage the formation of new skills.
• Learning in games is both modular and user directed: Once you have techniques for reliably teaching users new skills, you can modularize your application and let users decide what they want, when they want it and how much that matters to them.

If you start with the idea that users are learning machines, all our observations about usability tests snap into place. Of course, people stumble when they use an application for the first time. They don’t understand the interface because it is new to them. And users will stay at that inexperienced level if we do not make an attempt to teach them how to improve. We’ve diagnosed a burbling baby as a hopeless invalid, blind to the fact that babies grow, learn and flourish.

When users play a game, they spend hours first slowly building up basic skills. Then they assemble these building blocks into complex stratagems. Ultimately, they expertly wield the systems of the game like a finely honed tool. By the time the game ends, the player is no longer the same beginner that started. The design of the game directly helped improve their mental model of the world in a profound and measurable manner. The whole time, the player is having fun.

To me, the rich lessons of past 30 years of modern game design are lessons about human potential. Let’s start with the assumption that people are amazing. We have built pyramids. We have created clockwork contraptions that move mountains and measure the universe. Every day, we navigate a crazy quilt work world of technology, geography, language and culture. Surely we are capable of more complex interactions than typing a word in a plain vanilla search box.

Instead of only treating our users like idiots, how can we follow a design philosophy that actively empowers our users to fulfill their vast potential? The techniques gleaned from game design are one very meaningful path worth exploring.

Practice matters more than theory
Now, it is one thing to talk about how game design can improve application design. It is a completely different task to grab a hold of Microsoft Office, the epitome of traditional application design, and turn it into a playable game.

Ribbon Hero is not the best game in the world. Not yet. However, even in its basic state, it does all the wonderful things that games do in the context of one of the world’s most used, most serious applications. People learn. They improve. And they enjoy the process. Such a highly valuable class of user experience has eluded traditional design for decades.

If these miracles can be done with Microsoft Office, how might game design change the applications you want to build in the future?

take care
Danc.

References

• Download Ribbon Hero: http://www.officelabs.com/ribbonhero
• Description of iterative development process:http://channel9.msdn.com/posts/LarryLarsen/Behind-Ribbon-Hero
• Initial impressions of Ribbon Hero: http://blogs.zdnet.com/BTL/?p=29685
• Mixing games and applications: http://lostgarden.com/2008/10/princess-rescuing-application-slides.html
• What activities can be turned into games:http://lostgarden.com/2008/06/what-actitivies-that-can-be-turned-into.html
• Building fun into your software designs:http://lostgarden.com/2006/12/building-fun-into-your-software-designs.html
• Don’t make me think: http://www.sensible.com/chapter.html
• Layering: http://lostgarden.com/2007/02/one-billion-buttons-please-should-we.html

Go to Source

Go to Source