Blog Directory

 
Listee Account | Admin Account
 
Home -> Games Blogs -> Ranking -> Profile
 
Lost Garden
  Digg It!

Rating: 3.9/5 (25 votes cast)

Blog Title: Lost Garden

Readable essays about game design and game development. This blog describes practical, pragmatic tools for improving how we make games.

Blog Details

Overall rank: 36427
Number of inbound blogs: 196
Number of incoming links: 312
ATOM: ATOM feed
Last update: 2008-04-13 20:05:58 GMT
Estimated value: $211,401

Analytics

Incoming clicks since last reset: 0
Outgoing clicks since last reset: 27

Latest Posts

Tidbits from the garden

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

Project Horseshoe 2008: There and back again


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

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.

Fishing Girl: Game Prototyping Challenge



Earlier this summer, I mentioned that I was starting up a Mystery Project for local Seattle weekend coders. Summer has turned into Fall and the Mystery Project is still going strong. So we decided to kick off a Winter session of the Mystery Project!

In this post, I wanted to do two things:
  • Extend an invitation to any Seattle developers who would like to participate directly in the Mystery Project.
  • Share some Mystery Project graphics that we’ve made this summer part of yet another delightful Prototyping Challenge.


Winter Mystery Project
The Mystery Project is an innovative small Flash MMO that experiments with many of the design concepts I’ve been writing about on this blog. We meet up every Sunday at a local coffee shop and share what we’ve done and what we’ve learned. The project is the main focus, but I put a big emphasis on helping everyone on the team develop new skills and explore exciting ideas. If you are in Seattle, our meet up has become a rather unique opportunity to explore true next generation game design.

The team is pretty solid, but I’m looking for at least one additional, talented programmer. The project is in Flash/Flex with the server-side game logic written in Java.

Being part of the team means a serious time commitment. Expect to put in at least 10-15 hours a week. Making games needs to be your hobby and your passion.

If you have solid Flash/Flex/Java programming skills and you live around Seattle, drop me a note at danc@lostgarden.com. Ze Mystery Project lives (at least for the winter)!

Fishing Girl Prototype Challenge!
Due to the ‘coffee-shop mentoring’ model I’ve got set up for the Mystery Project, there are dozens of talented programmers who live outside of Seattle who can’t participate in our weekly chats. This makes me sad. So I decided to share some of our graphics as part of a brand spanking new game prototyping challenge. Free graphics + new game prototyping challenge = Happiness.

Fishing Girl is a simple fishing game played with one button. It illustrates a design pattern called sequentially linked mechanics. Often when you try to simulate a complex exercise like fishing, you can’t easily create a single game mechanic that captures the entire experience. Instead, you string together a series of activities. Each activity is simplistic by itself, but in sequence yields a good approximation of the complex experience. The fishing game is split into the following activities:
  1. Casting
  2. Positioning the lure
  3. Hooking a fish
  4. Reeling in the fish
  5. Scoring the fish
  6. Buying new equipment.
Each section should take 1-3 evenings to prototype in Flash. String them all together and you have a fishing game. The nice thing about this challenge is that it is all about bite sized chunks that are easy to build and iterate on.

The Wife Test (How Prototypes are scored)
My wife, as I mentioned in previous posts, is quite ill and I’ve wanted to do something nice for her. She absolutely adores fishing games, so Fishing Girl is designed for her. Any prototypes that someone is kind enough to make will be played by my wife with me watching her reactions intently. Luckily, she doesn’t find this overly irritating. :-)

In order to capture her casual gamer feedback, I’ve added a simple scoring system for this challenge. Each section of the game is worth a number of points. 50% of the score for each section will be whether or not my Bejeweled/WiiFit-playing wife finds the prototype to be ‘fun’. This is Miyamoto’s “Wife Test” applied in a quite literal fashion.

I’ll still be giving out the LostGarden Medals and still, no one has won the epic Gold Medal. It sits out there, tempting and shiny, just waiting for the right prototype to provide 15 minutes of fun. This challenge will last two months. But if something comes in later, I’m always happy to take a look and offer comments. Just list a link to any prototype in the comments section of this post.

The setup (10 points)
The player is a small bear-like creature, the Fishing Girl who sits at the edge of the ocean. She has a fishing pole, a glowing lure on the end of the pole, a money count and that is about it. In the ocean are numerous fish of various sizes that swim back and forth, but we’ll get to those later.

Casting (10 points)
Casting the lure out into the ocean involves two clicks:
  1. If you click your button once, the girl will pull back her pole to cast.
  2. If you do nothing, the pole will return to the default position.
  3. However, if you press a second time in the middle of her swing, she will cast the lure outward into the ocean.
  4. The closer the second click is to the peak of the swing the further the lure travels.
  5. When the lure hits, a number is placed at on spot on the ocean where it lands. This records the distance and lets you know exactly how far you cast.
Casting acts as a simple timing mini-game.

Help text (Bonus!)
  • Click to start casting
  • Cast!
Positioning the lure (20 points)


Positioning the lure in the water is the centerpiece of the game. You'll be spending a lot of your prototyping time here. :-)
  • When the lure hits the water, it starts to sink downward in an arc. When it starts out, it sinks almost straight downward. The tension on the rope pulls it inward towards the player, hence the arc. We don’t have time to model the complex line physics, so instead we say that the lure moves along an arc of a circle whose radius is defined by the distance from the tip of the pole to the point at which the lure hit the water.
  • Holding down the button reels in the lure. This changes the radius of our arc, but does not change rate at which the lure is moving along the arc.
  • The empty lure, unencumbered by fish reels in quite quickly. Using this system, we can now place the lure at any point within the sea.
Positioning the lure acts as a timing and spatial skill mini-game.

Hooking a Fish (25 points)
In the ocean there are fish. In order to hook a fish, you must place the lure in front of the fish’s mouth. The fish will lunge forward and become hooked. The entire time, you are carefully timing the slow downward arc of your lure. There are three pieces to this mini-game.
  1. The Fish
  2. The Lunge
  3. The Lure
The Fish (10 points)
Fish are objects in the sea that move back and forth in predictable patterns. Fish come in different sizes, rarity and movement patterns.
  • Movement: Back and forth. There are others patterns such as circles or swarms, but that would be extra.
  • Size: Small, Medium, Large, Extra large.
  • Rarity: Common, uncommon, Rare, Very Rare. This is used during “Scoring the Fish”
Fish are spread throughout the water with more valuable fish located further from shore. Try to have a good mix of big fish and small fish. You can start testing with one fish, but ultimately, you should have 10 to 20 or else the game won’t be very interesting.

The Lunge (10 points)
Now that you have your fish floating about, you can implement catching them.
  • Each fish has a collision box in front of its mouth.
  • If the lure enters the collision box, the fish will move forward towards the lure and attempt to become hooked.
The Lure (5 points)
Lures come in different sizes: Small, Medium, Large. The size determines which size fish you can catch:
  • If the lure is too small, it will be snapped and the cast is over.
  • If the lure is too big, it will be ignored.
  • If the lure is just right, the fish will be automatically hooked.
Help Text (Bonus)
We display help text at the appropriate moments
  • Position lure in front of fish!
  • That fish was too big for this lure!
  • That fish was too small for this lure!
  • You hooked it!
  • Reel in!
Choosing which fish to hook acts as simple tactical choice where the player is asked to pick the most optimal outcome. The time pressure of the moving fish and lure makes this choice interesting.

Reeling in a fish (20 points)
Once you’ve caught the fish, you need to get it back to the surface. Reeling in the lure works the same as before but the larger the fish, the slower it comes back up. Reeling in the fish is an exercise in keeping your fish away from other, larger fish that will happily eat your fish if it comes their way.
  • Fish still go for your fish if it appears in front of their mouth.
  • If they latch on, they take a bite out of your fish.
  • Three bites and you lose your fish. Each bite also reduces the value of your fish.
  • If your fish makes it to the surface of the water, you’ve caught the fish!
  • Reeling in the fish successfully acts as a timing and spatial skill mini-game.
Everything up to this point has been training for the player. Expect to spend considerable time here balancing, iterating and making this section feel good.

Reward for catching the fish. (5 points)
When you catch the fish, a small celebration animation plays that shows you the fish that you caught. There are several pieces to this segment.
  • Revealing rarity
  • Awarding Money
Revealing rarity (2 points)
When the fish is held up by the fisherman, the fish that you’ve been reeling in is revealed to be either a common (1), uncommon (2), rare (3) or very rare fish (4). Each type of fish has a distinct image associated with it.
  • The rarer the fish the less likely it is to appear.
  • A text label appears that say the name of the fish and the rarity. For example “Ancient Shoefish (Uncommon)”
  • Bonus!: If you want to get really fancy, you can display a simple text modifier to each fish that also modifies it's value. For example "ancient" increases value by 50% while "skanky" reduces value by 20%.
Awarding money (3 points)
  • The value of the fish is also displayed. A simple scoring equation might be size * rarity * modifier * 10. Feel free to play with the values to get the right balance.
  • The amount of money the fish is worth is then added to the piggy bank counter that has been sitting on the screen this entire time.
The revealing of the modifier acts as a gambling element that keeps the outcome interesting of each cast exciting until the very last second.

The store (10 points)
Floating out in the sea are various markers that represent item upgrades. If you hit the marker exactly with your cast and you have enough money, you will purchase them. Otherwise, your lure will bounce off and sink as expected. These artifacts do the following:
  • Bronze rod: Your basic rod. It casts a short distance off shore.
  • Silver rod: Cast further
  • Gold rod: Cast even further
  • Legendary Rod: Cast far and reel in heavy fish quickly.
  • Small Lure: Catch small fish.
  • Medium Lure: Catch medium fish.
  • Large Lure: Catch large fish. Note that there is no extra large lure, so there are always larger fish that pose as obstacles.
  • Bomb lure: Explodes and kills the first fish that touches it. Even if it is a very large fish.
  • Boy: Far on the edge of ocean is a Boy. He is inordinately expensive. This is how you win the game. And for the record, he is indeed, quite the catch. (What happens when you use an explosive lure on the Boy is up to your discretion...perhaps this is another way of winning.)
Bonus: You start with three small lures. When a large fish breaks your line or steals your fish, the lure is lost. At this point, you need to either buy more lures (which are expensive) or stop playing for the day. If you want to get fancy, you have some method of switching between lures. Otherwise, you can simply replace your current item with the most recent acquisition.

The store acts as a simple meta-game that encourages you to keep fishing in order to advance.

Progression (Bonus!)
As you catch more fish, the ocean gets more and more empty. This adds to the difficulty of finding fish. Fish always stay in approximately the same area until caught. Players will note where fish are located and be able to maneuver into position on subsequent casts.

If you wait long enough, more will respawn. If you fish out all the fish, there are no more fish left and you get a simple message “There are no more fish left in the ocean. There will never be any ever again.”

Design notes
The game is about spotting a high value fish, maneuvering your lure into position while avoiding the bigger fish and finally maneuvering your fish back through the landmines of larger fish.

In essence, Fishing Girl is Frogger using a polar coordinate system, a frog that insists on drifting to the left and only the ability to move forward.

Conclusion
So those are the rules! I've created this graphics this time in Illustrator and I've taken pains to make them appealing to Flash developers. Let me know if I've got the formatting right. I'd love to see some Prototypes of Fishing Girl playing in a browser.

So download the graphics and have fun! As with all prototyping challenges, this is a grand exploration of a new play space and there will be all sorts of interesting surprises along the way.
  • Download Flash Project (.FLA CS3): This is an import from Illustrator into Flash. There are no animations, but this might be useful if you don't have access to Illustrator.
  • Download Adobe Illustrator (.AI CS3): This has the original artwork. From here you can go to .XAML for Silverlight or bitmap.
  • Download FishingGirlPNG.zip: Bitmaps versions of all the images used.
  • Download FishingGirl.swf: A swf export of all the vectors. This is good if you don't have CS3. You may have to dig a little to find what you need, but everything should be in there.
Best of luck! If you are intrigued by these graphics, you'll love what the Mystery Project is turning into.

take care
Danc.

Update 11/1/2008: Added bitmaps and swf of all images.

Lostgarden Podcasts


Ryan Wiancko over at IndustryBroadcast.com has started recording selected Lostgarden essays. If you find yourself regularly sharing a few spare moments with your tank-like Zune, why not download an essay or two? Ryan's dulcet tones reading riveting game design minutia make for a perfect panacea to downtime boredom.

Or perhaps you know a friend. You know...the sort that never reads any of the mind-boggling important links that you send him (or her) on a Friday afternoon. Now he can put a pause on his 560th listen of Ride the Lightning and instead cultivate a more soothing, perhaps even 'intellectual' pastime. Gently remind him that the world is changing and that one day very soon, perhaps Tuesday, smart people will be again valued. Ryan's site is a magical auditory pill that can reduce his BrainAge to at least 31.
So what are you waiting for? Your iTouch, so jealous of your boss's glittering iPhone, is hungry.

take care
Danc.

PS: I've also added a link on the side bar named "Podcasts" in case you need to find the Ryan's site later. He's got all sorts of tasty stuff there from Jamie Fristrom and others. More keeps coming every week. Ryan's on fire!

The Princess Rescuing Application: Slides


Last Thursday, I gave a talk on game design to the local Seattle chapter of the IxDA, an interaction design group. About 100 folks were in attendance and the catered finger food was downright delicious. Other speakers included George Amaya, who spoke about recent research on social/party games, and Mark Long, CEO of Zombie. Mark gave a lovely presentation on how narrative and storytelling immerse players. His new game looks gorgeous.

My talk was on building an application that rescued princesses. The goal was to give interaction designers some insight into how game design might be applied to the domain of more utilitarian applications. The talk was recorded and should be up sometime this week. When it appears online, I'll link to the video from this post.

Here are my slides both in PDF format and as the original PowerPoint.

The notes fields are heavily annotated with more details about each visual. For those of you who attended, this deck also includes a third section on game design patterns that I didn't have time to cover in the time allotted.

take care
Danc.

Theme and game design

Recently I was chatting with some friends about the role of 'theme' in game design. Theme, in this discussion, was the setting of the game, be it fantasy, sci-fi, military, etc. At first blush, the typical game designer's use of theme appears a bit primitive.

  1. Limited range compared to the wide variety of themes in movies or books. Games recycle a half dozen major themes or in some cases invent their own surrealist themes that make little sense outside the context of the game. Books, despite being grouped into narrow genres, have explored many thousands of powerful, evocative settings. You have books about bored European manuscript editors exploring the bizarre world of the pseudo occult and you have books set inside the mind of a quadriplegic. The disparity in variety is intriguing.
  2. Crudely applied. Theme is applied in broad strokes at the beginning of many games, but almost always plays second fiddle to interesting game mechanics. Goombas are mushrooms, but this matters little beyond the fact that they are squat, match the scale of the world and can be squashed. If a novelist lazily integrated a character into their book's theme the way that game developer do on a regular basis they would never be published.
The result is that theme is often seen as an interchangable 'skin' that can be applied after the fact to a set of working game mechanics. The task is typically left to marketers to round up a popular license so that it can be painted onto the latest hot collection of game mechanics. This attitude towards theme affects the very fabric of game development.



And yet, something interesting occurs when we work this way. Very few licensed games turn into major long term franchises. They often feel incomplete and the pieces ill matched. On the other hand, seminal 'grown from scratch' games like Bejeweled, Mario, Quake, GTA or Sims end up doing amazingly well. Despite their surreal and often disjointed themes, they are surprisingly fun. In these titles, the theme of the game mechanics and the theme evolved hand-in-hand, often undergoing major switches half way through before settling into a successful partnership.
  • The Sims was a game about architecture that morphed into a game about playing dollhouse.
  • Grand Theft Auto was a cops and robbers chase game where you were the cop. It evolved into a game about being a free roaming criminal.
  • Quake was an Aztec style world where you tossed about a giant Thor-like hammer. It evolved into a nameless soldier battling against the mutants in a series of brown dungeons.
  • Bioshock was originally about Nazi's on an island.
If you start to dig into how game generate 'fun', many of these thematic transformations are, if not inveitable, certainly commonplace. It turns out that most game designers are not complete idiots when it comes to integrating theme and setting into their game designs. Designers aren't ignoring theme. They are simply using theme in a manner appropriate to the medium in which they work.

Some logic behind the madness
If you look at games as being about exploratory learning, they tend to teach the player a series of skills. First the player learns basic skills (how to press a button) and overtime assemble a scaffold of skills that lets them engage in more complex scenarios like 'save the princess'. Each moment of learning gives a burst of pleasure.

These basic skills are utilized over and over again. If the player fails to learn them, the rest of the game is lost on them. Games reward involvement, yet there is a high cost the player must pay in terms of initial learning necessary to become involved.

"Theme" from this perspective, is shorthand for a collection of preexisting mental tools, skills and mental models. I think of it as a tool chest of chunked behaviors that the designer can rely upon to smooth out the initial learning curve.

The theme you select directly influences how you present your initial skills to the user. By saying "Pirates", I turn on a particular schema in the player's brain and a network of possible behaviors and likely outcomes instantaneously lights up. If they see a pirate with an impressive sword facing a small soldier, the goal of fighting the enemy is self evident. With a small visual cue, I've eliminated minutes of painful initial learning.

There is a fascinating moment in the sequence of exploratory learning where players say to themselves "Oh, I recognize and have mastered this situation already, so let me demonstrate my excellence." Because of the triggering of the theme, the challenge appears possible and
attainable. If on the other hand, I had substituted the pirates with gray blob A and orange blob B, the player might be quite confused and not even bother to pick up the controller.

Why so few themes?
To a certain degree this perspective on games explains the limited number of themes used in games compared to books or movies. A book uses theme as a hook to get people interested in plot and character dynamics. There are lots of potential hooks and the more unique they are, the more intrigued the reader is to find out more. This encourages a proliferation of fascinating settings.

On the other hand, a good theme in a game is one that triggers a number of clear mental models that are applicable to the game mechanics at hand. If you push too far outside the experience zone of potential players, you make them feel inadequate.

It also suggests that occasionally a literary theme simply is not needed. Sometimes it is better to just tell the player, "Hey, it is a game and like any game you've played, we'll educate you as you go." The same triggering of appropriate schema occurs. If it is enough to grease the wheels of learning, then our mission as a game designer is accomplished.

"Skinning" game designs is a bad practice
When you look at game design from the 'games as learning' perspective, the idea of creating an slap-on aesthetic skin for a set of game mechanics starts to break down. In the best games, mechanics and theme evolve in lockstep over the course of the many iterations. If a mechanic isn't working, you have a couple choices. You can adjust the rules or you can adjust the feedback that the player receives. The two act in concert to produce the player's learning experience.

A good portion of the time, it makes sense to adjust the feedback side of the equation. What if people don't understand that the pirate is their character? Maybe it makes sense to make the pirate wear a right red outfit and the enemy a bit more evil looking. When you do so, the theme of the game shifts ever so slightly. Over hundreds (or thousands) of tweaks, a theme for the game might emerge that is quite different than what you originally envisioned. This is often the case for the best game in the history of our industry.

In fact, the final theme may be semi-incoherent if you attempt to analyze it as a literary work. However, that doesn't matter because it provides the moment-by-moment scaffolding of feedback that helps the player learn their way through the game. As long as the game is fun and delivers value to the customer we can often toss the literary definition of theme out the window.

In fact, you start getting into trouble when you make the theme so rigidly defined that you can't adjust the feedback for specific game mechanics. What if you are dealing with a license where the pirate isn't allowed to wear a red outfit? That design option, which may have been the best one available, is taken off the table. The hundreds of little trade offs that occur when theme coherence wins and gameplay loses diminishes the effectiveness of the game.

So you can't just 'skin' a set of game mechanics. When you do makes the attempt, a well executed iterative process of game design will often result in a game that is quite different than its source material. A poorly executed process results in a game that plays poorly.

Conclusion
There are a couple lessons here.
  • The most effective game themes exist primarily to facilitate the learning process for the player. This may be a traditional narrative theme, but it doesn't need to be.
  • Theme evolves in lock step with the rules of the game over a process of many iterations. You might as well plan for it. Early on develop vertical slices of your game. This will help you converge on working combinations of theme and rules. As you go allow for iteration on production assets.
  • Locking in your theme too early and too rigidly can stunt the exploration of more effective feedback systems. A bit of flexibility often yields better gameplay.
take care
Danc.


Rules of Productivity Presentation

How do we get more work done? It is a question that every manager and every passionate worker faces. Yet, for the most part, teams operate on gut instinct and habit. The results are less than optimal.

Over the years I've been collecting small pieces of research on various factors that actually seem to improve productivity. I've assembled eight of these experiments into a PowerPoint presentation. Feel free to use the graphs and data within to spread these practical ideas throughout your own teams.

Topics covered include:

  • The idiocy of prolonged overtime
  • The unintuitive connection between doing more and making better products.
  • Ideal team sizes and work environments
These lessons are particularly applicable to the game industry since it has some of the least educated management of any group in the software industry. In general, this is not their direct fault. We simply have a culture that tends to look inward (or at the movie industry) for solutions. A broader education on management and work practices, despite its ability to dramatically improve our games, typically takes a back seat to meeting the latest arbitrary, urgent deadline.

Download the presentation here:
take care,
Danc.

Shade: Prototyping Challenge results

It is time to give out awards to the Shade Prototyping challenge!

Every prototyping challenge I release is a grand exploration of a particular gaming system. The concept often sounds coherent on paper, but in reality it is composed of a series of small experiments involving movement, pacing, emergence and more. After every prototype, it is worth sorting through the experiments and seeing which ones are worth investing in further and which ones should be left behind.

Game design is a process, not a bolt of lightening from the blue. You build an experiment, reinvest in the things that work and try to fix the things that are broken. After iteration upon iteration, the game emerges. In this spirit, these awards are not the end of the Shade project, but instead are an opportunity to identify the next steps.

Even in these simple prototypes, Shade shows promise as a game concept. It just needs pass upon pass of polish to turn into something glorious.


Bronze awards

First, the bronze awards. These go out to the wonderful souls that made a game.

Of great interest was the fact that most people attempted 2D implementations of the concept. This makes sense considering the wide availability of 2D tools and skills on the market. Now that I have a better understanding of the dynamics of the game, I may release an updated version of the challenge in the future that includes a set of 2D graphics and a tweaked design that allows for an easier 2D implementation.


Silver award
We had one Silver award this time around.


The silver goes to Aras Pranckevicius for his lovely 3D implementation of Shade using Unity. I got a solid 5 minutes of fun out of his prototype and lots of ideas on what to do next. You can play it here:
Without further ado, let's get into a critique of the game as it stands now. I'll be use Aras's prototype as the baseline since it include a large number of interesting experiments in action.

Moments of genuine fun
First we'll start with the elements that were distinctly enjoyable. These are seeds that can be extended much further. You always want to try to identify these dynamics early since they can act as a focal point that guides the project. When you start cutting experiments, knowing where the core fun lies can help prioritize your culling.

1) Searching for the perfect mushroom is exciting: I had a surprisingly enjoyable time finding a good sized mushroom to take back to the drop point. Scarcity emerged as a major theme of the game. Potential improvements that can focus in on this include:
  • Increase the types and varieties of mushrooms. The act of finding something valuable in the scarce wilderness has all the hallmarks of a hugely addicting activity.
  • Create different growing cycles: Have some rare ones grow slowly or only grow quickly in the presence of other plants. If the player harvests them all at once, they are gone. This adds a resource management element to the game the reinforces the sense of scarcity and value.
2) The dynamically changing world is exciting. I didn't know where a mushroom might appear. In an early prototype, mushrooms would grow in the shadow of other mushrooms. The fact that the world was living and growing was immensely satisfying.
  • Implement Munchers and Bushes: These will add immensely to the gameplay by creating a dynamic ecosystem.
  • AI Seed transporters: Add simple AI driven characters that pick up seeds and move them to new locations will very quickly create amazing patterns. For example, one type of seed transporter might move small mushrooms 2 feet away from any other mushroom. Another might move seeds into the shadow of a smaller object. These simple rules will create all sorts of interesting patterns.
  • Vary the sizes of elements: Have some objects the grow very large. These will dynamically change the landscape over time and in turn create a wildly varying shadowscape.
  • Add more elements that grow in the shadows: The patterns that came about from mushrooms growing in the shadow of mushrooms was one of the more interesting emergent properties of the simulation. It was cool! Combined with a moving sun, all sorts of interesting hedges should pop up.
Moments of potential fun
The following elements were intellectually interesting, but didn't quite leave me as entertained as I was hoping. This is quite common and just means that you need to invest a little further in the idea.

3) Jumping from shadow to shadow
: It was interesting picking my way back through the 'shadowscape' of the level. A journey back to home base where I needed to precisely plan my movements gave the mushroom hunting experience a nice tension. However, in the prototype level there were a lot of sunlit areas and relatively small obstacles. As such the decisions made on the return journey weren't that interesting. Some improvements
  • Bigger, more maze like obstacles: I notice that when I'm walking around outside, I often have to make a distinct choice: should I got left around a large building sitting in my path or right? I rarely remember the future shadow terrain on each side of the building so I end up making a short term decision to reach the easiest shade. This often hurts me in the long run.

    By adding bigger obstacles that take time to navigate and that block off other options, the player is asked to make movement decisions that have a cost. In the best of worlds, players will find themselves jumping from shadow to shadow only to end up further and further from their goal. Some will heroically find their way back. Others will remember their failure and carefully plot out the terrain the next time around. Either way, it creates more meaningful decisions.
  • More contiguous areas of shadow: Taller objects would help as would objects that are skinny at the base and bulbous on top like trees. The amount of shadows is something you'll need to balance for.
  • Hungry monsters: The tension can be ramped up by including shambling monsters that move towards you when you have a mushroom in tow. Normally, they can be quite docile and may not even move. But as soon as you get a mushroom, they turn red and make their way towards you. One touch and your mushroom loses extra power. This adds some tactical and time-based pressure to your shadow picking steps.
4) Mini Map
The minimap solves an important problem: How do I find my way back home. However, it also removes a bit of the tension that comes from wandering and finding new paths.
  • Use a beacon system instead: Instead of a mini-map, a directional highlight like the ones used in Shadow of the Colossus or Knytt would do the trick quite nicely. A little glow at the edge of the screen or a compass that always points towards home help orient the player, but don't give away the terrain.
Things that didn't quite pan out
The following are things that didn't quite work and I don't see useful ways of making them a key part of the experience.

5) Gathering long strings of mushrooms: Once you start gathering long strings of mushrooms it becomes hard to keep them out of the sunlight. I noticed that as soon as I gathered more than one mushroom, I would simply zip to the goal as fast as humanly possible and ignore all tactical decisions. This is an example of a fun idea that actually reduces the complexity of the rest of the game.

Conclusion
The prototyping challenge doesn't really end until someone creates a game worthy of a gold award. So far gold is still within reach. There are some extremely promising mechanics at play in the shade prototype and I'm open to discussing and iterating on further tweaks if anyone wants to take the design further. Feel free to post to this thread if you come up with something cool. Who is going to grab the first ever gold award in Lost Garden history?

For inspiration, I leave you with this simple game that also uses some of the growing ecosystem elements we see hints of in successful Shade prototypes. It was built in 48 hours and easily has more than 15 minutes of game play. If this fellow can find hours of fun in a short prototyping exercise, I'm convinced that you can take your existing Shade prototypes and turn them into something wonderful.
Best wishes,
Danc.

Soul Bubbles: A classic game ill treated by expert reviewers


I wanted to turn your attention to a delightful little title called Soul Bubbles. I had a chance to play an early version of the game and was impressed by its lead designer, Olivier Lejade, careful attention to the difficulty level of the game.

When it finally launched, I was intrigued to see its aggregate reviewer score hovering at 77%. That is a middling score, but I expected better. Yet when I glanced at the user rating, it was pegged at an impressive 92%. From the user's perspective, we are talking about an instant classic, with a higher aggregate user ratings than either press favorites Halo 2 (91%) or Halo 3 (89%).

Why the disparity? When I looked closer, the professional reviews with lower scores almost all commented on the difficulty level, the one area I knew for a fact that the developers spent months polishing. Alex Sassoon Coby over at Gamespot intones ominously,"The shallow difficulty curve and lack of challenge in the main goals are the only things that let Soul Bubbles down."

Yet, users have the opposite reaction to the same exact features. One fellow gushes "It's very easy to get into thanks to the excellent tutorials, which introduce you effortlessly to the physics-based gameplay as you go along. The game's 40 levels will keep you busy for some time, but chances are you'll play the missions back to back only to be left craving for more!"

There's something odd happening here. Is Soul Bubbles a simplistic, middle of the road experience or is it a classic new game that deserves to be promoted as one of the more playable and innovative games of the year?

The answer tells us a lot about what it takes to make a great game and also happens to highlight one of the grand philosophical flaws in modern game criticism.


Games are about learning skills
First, a bit of background. Games, particularly one built around exploring innovative new game systems like Soul Bubbles, are all about learning new skills. There is a lot written on the topic, there are some articles at the end of this essay for you to peruse. The short of it is that learning new skills yields fun.

You can think of a game like Soul Bubbles as a bit sheet of bubble wrap. Each challenge is a little bubble of fun waiting to be popped. Most games are like this. However, once you've learned a particular challenge, doing it again is usually less exciting. By playing, you've been changed. You've learned the challenge and you'll never be able to revisit that challenge and relive the same emotion that you felt the first time through. You can't re-pop the bubble.

People who play a large number of games tend to rapidly morph into expert gamers. Reviewers, specifically, are almost by definition experts. In order to multiply their meager paychecks, they train themselves to quickly plow through dozens of games. They've crunched through so many levels, powerups, puzzles and collectibles that they are walking encyclopedias of game design techniques.

Since the act of learning is where a large amount of single player fun arises from, many expert gamers find it more and more difficult to derive pleasure from each new title. Games often reuse mechanics and the even an innovative game like Soul Bubbles starts feeling the same. It's like handing the reviewer a sheet of bubble wrap with all the bubbles already popped.

The result is that an initial game activity, such as a tutorial, that would delight a new user instead appear at rote obstacles that need to be skipped past as quickly as possible. Reviewers will use their impressive pre-existing mastery to zip past carefully constructed levels in the hope of find a challenge that will teach them something new. For most, this is subconscious behavior. They just know that they are looking for the thrill that they once experienced as child playing games for the first time. Due to the fact that they have changed, that they are now experts, only the most refined and challenging games still give them a hint of that sweet learning delight. Everything else is labeled 'crap.'

The Expertise Bias
This phenomenon is well understood in the game development community. Game developers also suffer from being experts. Not only do they have encyclopedic knowledge of exist game mechanics, they also have an intimate understanding of how their game is supposed to operate. Surely with such vast expertise, they would be the ideal critics.

Yet, because games are a learning activity, expert game developers often have surprising difficulty understanding how new users will react to their creation. Things they feel are incredibly important end up not mattering. Elements they dismiss as trivial annoyances end up stopping players dead in their tracks. The very fact that designer knows their game intimately makes them a poor critic.

Observation is the solution
The well documented work around for the expertise bias is to observe other people, who aren't experts, play the game. The best designers follow a simple process:

  • Observe target players
  • Take notes on potential issues.
  • Leverage their intimate knowledge of the game to come up with elegant solutions.
Valve does it, Nintendo does it, Microsoft does it. Admittedly, the process is time consuming and not always the easiest path. However, testing with real users is the only proven way to accurately ascertain a game's difficulty and balance.

By observing real people in your target audience learning for the first time, you can realign your heavily biased perception of the game to be more in sync with reality. It becomes readily apparent that 'obvious decisions' do in fact need improved tutorials. Entire systems that you thought were essential are often ignored as players telegraph their delight in simple things like picking up shiny coins.

Game developers have learned the hard way what happens when you ignore the practice of observation. Periodically, schedules become tight and the expensive act of observing real users ends up on the chopping block. Someone with more ego than wisdom stands up and proclaims that they can use their infinite expertise to balance the game using brain power alone. Inevitably their products suffer.

They are fighting the fundamental physics of our medium. Experts, in the absence of observation, make for heavily biased critics.

A tale of Soul Bubbles
Mekensleep, the developers of Soul Bubble, are enlightened developers. They spent months polishing and balancing the difficulty of their game. They held playtests, they observed real users playing for the first time and they fixed the problems that they ran into. They knew that that Soul Bubbles featured some very unique movement and herding mechanics, so they were under no assumptions that they could use their expertise to predict a user's initial reactions.

In the process they learned a lot about how their customers wanted to play Soul Bubbles. Their target player picks up a few games a year and plays in short burst for a long period of time. Many are not looking for intense competition or a massive challenge. Instead, they want a way to relax and explore a delightful world.

As a result Soul Bubbles targets exploratory and easy fun play styles. These feel very different than the traditional hard fun that is the mainstay of many titles played by the core. Yet they are equally enjoyable and often more profitable. Much of the game is about peacefully exploring with the levels designed so that around every corners there is something new to learn or play with.

Through a rigorous and iterative process that involved going to real users, they nailed the difficulty level. That is why the aggregate user ratings are up at 92%.

The flaw of expert reviewers
The reviewers of Soul Bubbles didn't observe real users. Instead, they reacted to the game as expert gamers. The tutorials were a bore, the game could be 'beat' in a short amount of time and the number of times they were forced restart were low. So reviewers told their audience that they should not buy the game on the assumption that the player would likely feel the same thing that the reviewer felt. This represents a basic philosophical approach to game criticism.

I read a short essay by Andrew Doull that sums up this philosophy with the gem of a quote "Fundamentally, the process of being a game critic is the same as being a game designer (is the same as being a game player). That is, it involves the exploration of a possible game space, and trying to validate whether that game space is interesting."

To me, this represents a fallacy of epic proportions that results in badly designed games and inaccurate reviews.

Due to the fact that games are learning systems, good game critique requires two elements.
  1. An expert understanding of the game: Playing the game, knowing mechanics, player psychology, design patterns gives the critic powerful tools for understanding and reacting to what they are witnessing.
  2. Observation of representative users: Expert knowledge biases the priorities of most players, so it is critical to see how real users react to a title in order to get actual target audience data. Having sat through hundreds of hours of observing users, you don't actually know how the virgin value of an inactive system until you see others use it.

Game reviewers only follow one half of this unified process. Since most reviews eschew observation of others (often for timeliness), there is nothing to counter balance their expert bias.

Games are not movies. Please repeat...again and again and again.
There are good historical reasons why experts fail to incorporate player observation into their game reviews. The concept of a review comes from reviewing movies, books and plays. These are what I think of as 'empathetic media'. The process of enjoying these works follows a clear psychological pathway.
  • The viewer observes a universal stimuli, such as a pretty girl in a movie,
  • They empathize with her situation based off their extensive memories of related situations
  • Finally they recall and synthesize an emotional response.
The best works of linear media deal with broadly identifiable stimuli, archetypes of human experiences. Most people have experience with loneliness or the boy winning the lovely girl. Empathetic media gains its mass appeal by dealing in universal truths.

When a reviewer watches a movie, they are asking themselves the question "Do I, as a passable representative of humanity, react strongly to the stimuli in this movie? If so, there is a great chance that others will as well." There is very little expertise bias involved in this exercise. It asks the reviewer to empathize with the stimuli like any other person would.

There is a big question if games work well as empathic media. Their stories are weak, characters flimsy and their exploration of universal truths are usually laughable. Instead, games tend to be strongest when they focus on learning, exploration and first time experiences. Games, more than any other media, are less about reacting and more about changing who we are.

Because the deep, underlying theme of games is change and learning, you need to take into account your level of mastery and the level of mastery of the target audience in your criticism. Otherwise, you end up, like in the case of Soul Bubbles, being the PhD student claiming that Physics 101 is a waste of time because you've 'been and done that' already.

Traditional reviewing techniques taken from the world of empathic media are ill suited for critiquing games. They lack the essential observational techniques that working game designers have found to be so important.

Looking into the future

So, yes, the current game reviewing system is broken. As is often the case with games, we've adopted wholesale the techniques of movies and literature without asking if they even make sense in the context of our brilliantly vibrant new media. I'm certainly not the first to say this.

Yet with single player games, the hack still almost works. Single player games have generally followed a linear path padded with cutscenes, where a reviewer will typically have a similar experience to that of most other players. As such, the expertise bias usually only throws off scores by 10 to 20%. Long term, this practice shrinks the gaming community and it has certainly caused a few developers to miss out on royalty bonuses, but overall it clunks along.

Yet, the world is changing once more. As you introduce multiplayer games into the mix, social dynamics take over and who you play with has as much impact on the experience as which quests you take on. The types of learning and the experiential paths that each player takes are exploding. One player's experience playing with his new girlfriend will be radically different than that of a old school guild settling into the game as a respite from World of Warcraft. An empathetic expert reviewer will not be able to speak for everyone in a convincing fashion.

It is again instructive to observe how developers are using an observation-based understanding of the game to create a proper practice of game criticism. Right now there are hundreds of teams building complex metrics and logging systems that track their player's experiences on a minute level of detail. The best have psychographic and business dashboards that tell them how people are reacting and where problems are emerging. In the future, developers will be observing, tracking and improving the experience of individual guilds and social groups. Practical game criticism, the sort performed by actual game design teams, will be even futher fueled by deep observation and timely intervention.

Unfortunately, these tools are not available to most reviewers. In the coming years, developers will have a vastly superior understanding of how customers are reacting to their game than reviewers will. This is already the case for many titles, such as Soul Bubbles, and the trend will only continue.

What is the future role of professional reviewers?
What role does the expert reviewer have in this situation? As the audience for games broaden, as the benefits of a single expert judging an entire game diminish as their opinions become even more divorced from the actual experiences of real players. The air of objectivity dissipates and the reviewer becomes no more than yet another guy with an intricately detailed, heavily biased opinion.

This represents an intriguing crisis in game criticism. There are many paths for the ex-reviewer to wander down:
  • The news announcements: The factual (though still flavorful) announcements of new games, events and updates. The goals is to let people know that something is happening.
  • The analysts: The elitist community that uses their expertise to deconstruct games according to various theoretical frameworks. The goal is a deeper philosophical understanding of games (and strutting rights within their small incestuous circle.) This is my world. :-)
  • The tourists: Every Man players who approach writing about a game like a travel journalist on a safari. The goal is to evoke the emotions that the individual reporter experienced, not to predict what everyone's experience might be. They succeed if they provide simple entertainment.
  • The opinion mavens: The high energy personality who crystalize the trends and fashions of their target culture. The goal is to pick hits in a heavily biased but entertaining fashion and enhance the maven's personal brand.
  • Ranking sites: Sites like gamerankings are still of questionable value, but over time sites that use a broader range of data will emerge. The goal is to provide a public thermometer that, with reasonable accuracy, states if the game is worth trying.
I already see this evolution occurring. I've given up on reading reviews and instead find myself frequenting gaming blogs, the news portals of our age. Many traditional reviewers are popping up in more experientially-focused sites like The Escapist or Rock, Paper, Shotgun. Even next generation ranking sites are appearing in the form of portals like Kongregate. And what is Zero Punctuation if not our very own flavorful equivalent of Oprah the Opinion Maven?

Closing thoughts
Go out and try Soul Bubbles. It is a great example of what happens when a developer balances their title for their target audience and not the expert reviewer. If you are an expert reviewer, play it with an eye towards seeing how a first time user might experience it. It is an interesting and remarkably difficult exercise. Then give the game to someone who isn't an expert gamer and watch them play it. I suspect that they'll highlight elements that you didn't even realize were important.

If you are serious about providing objective insight into a game, either a title you are building or one your are reviewing, your expertise is not enough. In fact, your vast mastery of game related skills is mostly likely causing a giant bias in your judgments. You need to fight this bias by observing other players over and over again. They will do things with the game that are a source of wondrous insight. Your expertise becomes a tool for making great changes based off these insights, not one for predicting a priori exactly how all users will react to the game.

As for the current review industry, it is built on the unstable foundation of expert opinion in the absence of actual player observation. As games evolve and become ever more about first time learning experiences, the traditional game review will become increasingly irrelevant. It is arguable that they've already stopped informing most buying decisions and now serve as little more than entertainment for the hardcore niche. As the value proposition of reviews falter, the vast, churning, capitalist forces of creative destruction will replace them with a much richer set of game criticism that offers real value to its readers.

It's a beautiful day outside, so I'm off to pop a bit more bubble wrap,
Danc.

References


Directory of Posts

Lost Garden has turned into a rather substantial archive of game design thoughts. In order to help you find essays that you are interested in, I've finally performed a bit of house cleaning and tagged all 180+ posts. Go forth and explore!

Quest: Which essays are "Worth Reading"?
I'm looking for the essays that you found to be more influential on your thinking about games. I'd like to bubble those to the top of the site by marking a handful with the Worth Reading tag. I've tagged a few, but I'd love to hear your thoughts.

Popular

Game Design Science Game Design Craft Game Prototyping Challenges
Resources
Game Observations
Conferences and Articles
Personal Feel free to send any comments or errors to danc [at] lostgarden [dot] com.

Shade: A game prototyping challenge


As a redhead, there's a little game that I play every day in summertime called "Stay in the Shade". The rules are simple: make it to my destination as quickly as possible while avoiding all possible sunlight. This involves hopping from shade patch to shade patch. The cost of failure is the dread Irish Tan. These bizarre antics were inspiration for a game design called Shade.

As with any of the designs you find on this site, I heartily encourage you to prototype it and use it as a learning project. I know that there is a group of you itching to try out the latest 3D engines with sex-a-licious real-time shadows. This is your chance to finally use the technology in a way that produces meaningful game play.

I'll give out the much coveted Bronze, Silver, and Gold Lost Garden badges to anyone who creates a worthy prototype.




Basic gameplay
You play the part of a rugged mushroom rancher who must collect adorable sentient mushrooms living in the shade. All you need to do is run up to a planted mushroom and touch it. It will pop out of the ground and start following you around. Lead it back to the start location and you'll be awarded multiple point based off its size.

Unfortunately, it is a scorchingly hot day. You can meander about the landscape of giant grassy blocks with impunity due to your meglo-awesome wide brimmed hat, but the mushrooms wilt quickly in sunlight. To lead them back successfully, you'll need to keep to the shadows and plot the optimal path home.


Basic Elements
  • Player: The player can move about on a 2D plane using the arrow keys or a joystick.
  • Blocks: Strewn about the landscape are blocks that cast shadows.
  • Planted mushrooms: In the shadows of the blocks, planted mushrooms will slowly spawn over time. If left alone they will slowly grow in size.
  • Mushrooms: If the player runs into a Planted Mushroom, it will pop out of the ground and start following the player's motions exactly. If multiple mushrooms are collected, they will follow in a line behind the player. A mushroom can last in direct sunlight about a second before they expire. This amount of time is cumulative and is shown by slowly shrinking the mushroom as it is exposed to more sunlight.
  • Homebase: This is a spot on the ground that you need to lead the mushrooms back to in order for them to be counted.
  • Mushroom score: In the upper right hand corner of the screen is the HUD. The most important element is the Mushroom score that shows you how many mushrooms you've collected so far today.
  • Day timer: The day slowly progresses from morning to evening over 15 minutes. The shadows change position as the day progresses.
Winning the game
The game is over at the end of the day. Total mushrooms collected is entered into a highscore table.

Technology

We've had lovely real time shadows for quite some time, but very few designs take advantage of the technology. Luckily there are an immense number of cheap 3D engines that can pump out real-time shadows. Some options:
Not so long ago, this tech was the exclusive domain of techsperts like id and Epic. But now there are no excuses. And the very clever folks will figure that you can make this game in a 2D engine with a little finagling.

Art

Since this design is likely a 3D game, I'm not providing art assets. I recommend that you use cubes and other primitives for the various elements in the scene. They are inexpensive, highly effective and can always be replaced at a later point with more advanced models once you've proven out the gameplay.

With this type of game, a good amount of pleasure will come from the motion of the mushrooms following the player and the movement of the shadows over time. Slick graphics can enhance this, but they aren't necessary to find the fun. Again, no excuses.

Advanced gameplay
Once the basic gameplay is in place, there are immense opportunities for more interesting variations.
  • Movable blocks: Blocks that you can push around allow you to create optimal paths for harvesting mushrooms.
  • Muncher: Once a planted mushroom grows to a certain size and it is hit by the sun, it turns into an AI driven creature called a muncher. Munchers find a nearby green block (also known as a bush) and start munching on it. This reduces the size of the block and therefore the amount of shade it provides. Munchers can be stunned and killed by running into them repeatedly.
  • Bush seed: A dead muncher turns into a Bush seed. A bush seed is an object that can be collected by running over it with the character. If you press a button, the bush seed is planted on that location and begins to grow.
  • Multiple days in a row: What happens to the landscape if you let the world run for multiple days? With the inclusion of bushes and munchers, we have a self balancing ecosystem. As you plant more bushes, there is a greater chance that mushrooms will turn into munchers, which in turn reduce the bushes. Can you turn a simple landscape into a mushroom plantation?
Balancing
This is the sort of game that lives or dies based on balancing all the various elements. There are a number of variables that you'll need to mess about with
  • Size of the blocks
  • Number of blocks and shadow area
  • Spawning rate of mushrooms
  • Size of mushrooms
  • Amount of sunlight to kill a mushroom.
  • Speed of the character
  • Size of the map.
  • Size of the viewport onto the map.
I don't have the answers. You'll get the answers by iterating on the basic design dozens, if not hundreds of times. Keep me updated and I'm happy to provide feedback on works in progress.

The Lost Garden Awards
Once again I'm giving out the always desirable Lost Garden badges for any prototypes that result.

  • Bronze Medal: You built an interesting software toy. If you make an attempt at a design and it is interesting to futz about with, you get the Bronze Medal. Most people never get a Bronze medal due to the simple fact that they prefer to sit around and think rather than make something. Simply by doing (instead of not doing), you join an elite club.
  • Silver Medal: You found the fun. You've iterated on your design and have identified a few key elements that make the game enjoyable. There is at least 5 minutes of interesting play. It likely isn't polished and some of the higher order reward loops are broken, but the core is there. If past challenges are any indication, I'll give out only a handful of Silver Medals per challenge.
  • Gold Medal: You made the fun repeatable. The game that you've built is entertaining enough that I'm willing to play it for 15 to 20 minutes. This is a hard level to reach and it is only populated by the most elite cadre of weekend warriors. An entire production team could be seeded by your efforts. To reach this level, you've made some critical design steps beyond the initial concept and built unique and sustainable gameplay based off dozens of game play iterations. To this day, no one has won a Gold Medal. You could be the first.

You need to post a public, playable version in order to be eligible. I'll issue the rewards about one month after the initial challenge is posted. If something comes in after the original deadline has passed, I'll add it retroactively to the award post. If you win a Bronze or Silver, you can still come back later and make an attempt at the Gold. Anyone who gets a Gold medal is an automatic rock star in my book.

What do you get if you win? First off, you get the right to post a snazzy LostGarden medal on your website. Most importantly, you get that warm fuzzy feeling in your tippy-tip toes that stems from a job well done.

Conclusion
Shade is an interesting game design to me for the following reasons
  • Exploration-based play: The joy is in exploring the ever changing landscape and finding mushrooms and interesting paths back home. It is more strategic than action oriented.
  • Simple controls: All you need to play are directional controls and one button. It should be pretty easy to pickup.
  • Non-violent: In general there is very little combat. I like this. I can imagine the title having a very meditative feel.
  • Uses real-time shadows for some unique gameplay. Real-time shadows have been used for sneaking games, but little else. Surely it is time to expand the number of games that use this fascinating technology.
Enjoy! If anyone makes something and puts it online, I'm happy to discuss it on the website in a follow up post.

take care
Danc.

Past challenges
Mockup


What actitivies can be turned into games?

Techniques for designing consumer scales


Recently, my amazing wife picked up a copy of Wii Fit. No, this is not a review.

Here is something you may not know about my wife. For the past year, she's been dealing with a rather serious, debilitating illness. One side effect is considerable and undesirable weight loss. On the positive side, she has enjoyed shopping for a new wardrobe to match her more petite frame. On the less positive side, many stores no longer carry clothes that are small enough to fit.

So when the Wii Fit first booted up and cheerily prompted her to set a goal, she decided to try to get her BMI back up to the 'normal level'. Every day or so, she's been exercising, weighing herself and doing yoga. So far she has found the game to be convenient and highly motivational tool for helping her to track her weight.

We've had other exercise equipment around the house before, as well as gym memberships, yoga classes, etc. None of them has been as motivating as a simple set of exercises wrapped in a system of game-like rewards. My wife's experience with Wii Fit speaks volumes about games potential to turn an often mundane activity into entertainment that is delightful, exploratory and highly meaningful.

Thinking beyond scales
Yet, who would have ever thought that weighing yourself could be turned into a game? Miyamoto did, but then again he is widely considered to be an uber genius. The skeptical observer might imagine that successful cross-over games like Wii Fit are one-in-a-million success stories. Suppose it works for Wii Fit, but nothing else.

However, if the lessons of Wii Fit were broadly applicable, entire industries could be transformed. Games are a competitive advantage that can turn a commodity scale into one of the hottest consumer products of the year. In highly competitive markets, that is the sort of product design super power that lets innovative companies walk away with market share.

As I contemplate my wife's success with the Wii Fit, I'm struck by a multi-billion dollar question: What other activities can you turn into a game?

Almost anything
First, though there is no doubt that Miyamoto is a genius, what he does is reproducible by mere mortals. He is able to apply his game design skill (or at least his greenlighting abilities) to non-traditional games like Wii Fit because he understands game design at a very atomic level. Here is another way of looking at it. A craftsman builds tables the same way he was taught by his father and his grandfather can only build tables. But someone trained in mechanical engineering can use the fundamentals to build chairs, bridges, cars or even cathedrals. Similarly, by understanding the fundamental science behind traditional games, you can apply the theoretical tools of game design to transform wildly divergent activities into games. I've written about some of this in the past with essays on skill atoms.


It turns out that most learnable skills can be turned into a game. However, there are constraints. A skill must meet the following criteria before it can be turned into a game:
  1. Decomposable into simpler skills
  2. Skills can be nested
  3. Skills can be arranged in a smooth learning curve
  4. Skills are measurable
  5. Performance can be rewarded
  6. Skills are locally useful.
Let's look at these one by one.

1. Decomposable into simpler skills
Complex learnable skills can be broken down into sets of easily acquired core skills. Players can only learn so much at once and overly complex skills overwhelm all but the most persistent players. By breaking skills up into digestible chunks, you are now able to apply many of the basic techniques of game design.

In Wii Fit, the complex activity of "Becoming fit" is broken down into skills associated with using the board, testing balance, endurance activities and more.

2. Skills can be nested
Complex skills should build upon and reuse earlier skills. Advanced skills are best taught by the extension of existing skills, not introducing new metaphors.

Game design is built around the idea of core mechanics, skills that are exercised over and over again throughout the game experience. If you can't find a set of basic reusable skills that can be incorporated as the foundational elements of more complex skills, players will deem the activity shallow and lose interest.

In Wii Fit, the act of balancing while following rote exercises is used repeatedly throughout. It is an activity that is easy to learn, hard to master and contributes nicely to a wide range more advanced activities.

3. Skills can be arranged in a smooth learning curve
There is a smooth ramp from learning easier skills to learning more complex skills. Initial skills should take only seconds since they leverage existing skills. Afterwards, learning activities should build in complexity until they take minutes, then hours. If the initial learning ramp takes too long, players will be confused or bored and stop playing.

In Wii Fit, you can learn to use the board in seconds. Just step on it. However, more advanced games are slowly introduced until must spend hours of your time to unlock that last activity.

4. Skills are measurable
The game can detect when a skill is used correctly or incorrectly. Without this the game cannot provide timely feedback that pushes the player in the right direction.

The fact that Wii Fit is a giant sensor is perhaps to be expected. Within limits, it knows exactly what you are doing and when you doing something incorrectly. This is a dramatic difference from most exercise equipment or a workout video.

5. Performance is rewardable
The game can provide the player with a timely feedback and rewards. If the game provides feedback too late or in a manner that is disconnected from the original action, the player won’t learn.

Unlike traditional exercise equipment, Wii Fit judges your performance. It lets you know when you are doing poorly and it praises you when you are doing well. It is not a passive tool, but one that seeks to mold you. This is how games work and is an integral part of their success as a teaching tool.

6. Skills are locally useful
The skill can be exercised in a useful manner by the player in a variety of meaningful local contexts. If the skill isn’t useful, the behavior will extinguish.

Local utility is a tricky concept for many, especially those trained to think in terms of filling measurable customer needs. It basically means that the player finds an activity useful in the short term within the local context of the game. Grabbing a coin in Wii Fit may accomplish absolutely nothing in the grand scheme of the player's week. However, it does let the player unlock a new exercise. So for the moment, the player considers frantically gathering coins to be a completely utilitarian activity.

Skills that are eliminated by these constraints
What skills are eliminated by these constraints? Surprisingly few.

The biggest sticking point often ends up deciding how to measure complex skills. With Wii Fit, they needed to engineer an entirely new device. It is not uncommon to invest substantial amounts of effort just gathering the right data so that you can reward the proper skills accurately and in timely manner.

Machines alone have a limited understanding of many cultural human activities. In these situations, you need to build your games to use other human beings as measurement instruments. The rating techniques of sites like Hot or Not or Amazon.com are widely applicable.

The other constraints end up being easily worked around with a little bit of thought and prototyping to find what works.

Conclusion
When I look at our list of six constraints, it is obvious to me that there are a plethora of skills that are just waiting to be turned into games. Games like Wii Fit or Brain Training may seem exceptional strokes of genius, but in reality they are merely the tiny tip of an immense iceberg. Almost any human skill, be it physical, cultural, political or economic can be turned into a game that enlightens and enables.

As more leisure games emerge that mediate and accelerate the acquisition of skills, there is going to be a economic incentive to spread the science and craft of game design far beyond our tiny game industry. Game design is not just about games. It is a transformational new product development technique that can turn historically commoditized activities into economic blockbusters.

This morning, my wife came back from her morning Wii Fit session and proudly announced to me that she just worked her way back to her normal weight range. She is still on the light side and this odd little game was by no means the only source of her success. But it had its place as a tool that measured, encouraged and rewarded progress. As such it was worth every single penny.

When I look at Wii Fit and I hear the delight in my wife's voice, it is apparent that game design is again breaking out into the broader market. Obviously it isn't happening quite in the way many have predicted. The harbinger of game's ascendancy to all aspect of the modern life is not some piece of evocative art or Citizen Kane-a-like. Instead, our future appears in the form of a glorified bathroom scale. Still, if we can improve people's lives with a bathroom scale, just imagine how games can transform the rest of our world.

take care
Danc.

Lostgarden looking for brilliant programmer in Seattle

a mystery project

Summer project time! I've got an intriguing new design that is best explored by the sort of in-person rapid prototyping that I love. To that end, I'm looking to team up with a talented programmer or two from Seattle/Redmond. It's a bit like getting a band together.

My dream is to meet up every Sunday at a local coffee shop, riff about what we've done that week and come away energized and ready to build some more.
  • Location: Seattle/Puget Sound area is a must. (Otherwise, it is hard to do the coffee shop thing)
  • Skills: Solid Flash, Flex or Silverlight skills. Previous experience with Java, C++, or C# is great as long as you are willing to learn Flex. Back end skills are also helpful. The project is 'technically interesting' and is best tackled by someone who is more of a programmer than a scripter.
  • Time commitment: 10 hours a week for about three months. Anything less I've found doesn't make it worth your time.
I'd contribute art, design and Cheetos (organic or radioactive). If you are interested, drop me a note at Danc [at] Lostgarden [dot] com. Send along a portolio if you've got one and tell me a little bit about yourself.

Take care,
Danc.

Improving Bug Triage with User Pain



The traditional bug triage process is miserably inefficient. Over my decade in this industry, I’ve spent months of my life sitting in windowless offices manually reviewing (and re-reviewing) thousands of bugs. Often times, there are three or four folks on the triage team, typically the most skilled people on the team, sitting about and bickering for hours over the finer points of obscure bugs. Politics, boredom and arbitrary decisions are unfortunately common. The result is wasted time and poorly managed bugs.

So we came up with a better way.

User Pain is a technique I’ve been using for many releases across multiple teams. It involves sorting bugs on a single unified scale called User Pain that takes into account common bug ranking criteria. I’ve found that it can reduce the cost of triage, help teams ship on time and greatly clarify which bugs you should be fixing right now. This essay describes how User Pain works and some best practices for implementing it on your team.


Problems with current bug triage
Traditional bug triaging is a time consuming and tedious process. Bugs come into a bug database with little prioritization, the team leads sort and rate each problem and then assign them to the appropriate members of the team. This process tends to run into several issues:


  • Lack of shared criteria: Different people often value different aspects of a bug, which leads to unhealthy disagreement. A designer might think a usability issue is a critical fix, while a programmer might be concerned about a crash. With no common criteria, it is hard to build consensus quickly.
  • Wasted time: Often the highest skilled team members are required to triage bugs. They spend hundreds of hours poring over mundane issues again and again. This is time that could be better spent improving the product.
  • Bottlenecks: Bugs are often required to go through a review process so that precious developer time isn’t spent on bugs that would have otherwise been punted. The loop from the submitter to the triage team to the developer can cause delays for critical bugs.
  • Big undifferentiated bins of bugs: Since the incoming rate of bugs is often higher than the fix rate, large piles of bugs will accumulate for each developer. If a developer has 50 bugs on their plate, they will fix them in a semi-random order or rely on micromanagement by the triage team. The first tactic means critical bugs are sometimes left to be fixed until the end. The second means more time is wasted on reviewing bugs.
  • Triage burn out: After reviewing thousands of bugs, many triage teams stop caring or become fixated on a few bugs at the cost of reviewing others. The result is that some bugs are poorly triaged and the quality of bug ranking in the database is low.
These are the problems we want to solve with User Pain.

The basic system
User Pain is yet another technique inspirted by the world of Lean Manufacturing, the ancient mother of so many Agile practices. The technique was original developed in the 80’s as a method of efficiently classifying product defects on manufacturing lines. While some of the ideas are new to software development, the core concepts have been tested in intense product development situations for decades.

At with many agile techniques, User Pain isn’t all the complicated.
  1. Rank each bug on several criteria
  2. Combine those criteria into a single score called User Pain
  3. Sort all bugs by User Pain into a public list
  4. Start fixing the most painful bugs at the top of the list.
There is a distinct philosophy at work here. First, empower bug submitters to easily create well formed, well classified bugs. Next, give the team the tools and information necessary to make smart decisions about what to work on first. Finally, encourage practices that make it easy to put quality first. Instead of relying on expert managers, you rely on a well informed, empowered team. As a result, the User Pain system removes most of the need for a triage middleman.

Let’s dig into each step and explore the devil in the details.

Step 1: Rank each bug on several criteria
Bug submitters use a simplified bug submission page that clearly lists three factors: Type, Likelihood and Priority. Each factor has multiple values, listed in order of impact. At submission time, the bug submitter rates the bug.

Three bug rating factors
Here are the three factors that I’ve been using.
  • Type: What type of bug is this? For example is it a crashing issue, a problem with localization or a matter of visual polish?