I figured that it was time to share with my secret stash. I've been using Google Reader to tag interesting articles and publish them all to a single location. Occasionally, I've added snarky comments. You can find the entire treasure trove here:
This list is updated a bit more regularly than my blog, but since I don't believe in covering Lost Garden with link fests, I'll keep it as a hidden secretive thing. So shh...tell only special people.
I had an immensely good time collaborating with Andre on Fishing Girl earlier this year. He was looking for a new project and so we started idly chatting about random ideas. One thing led to another and he is now nearing the finish line on a new Flash game called Bunni. I thought Andre might enjoy a little bit of public encouragement as he enters the final stretch.
I've been wracking my brain and I don't know of another game out there that is quite like Bunni. Imagine if Animal Crossing had a long lost mutant sibling that coalesced out of a creative flurry in a mere four months. There is no clever twist on shooting, block stacking, or 2D platforming. It is not an innovative music game. Nor does it involve playing with time or bizarro spacial dimensions. If there are any puzzles, I apologize since they weren't intentional. In fact, it isn't a very hard game. I've yet to find a single hidden object, probably because there aren't any. Despite lacking all these critical things, play tests end up lasting for hours.
I don't want to give away too much about the game, but I can share a single, mildly cluttered screen shot. Yes, that is a pirate bunni. And no you can't have one unless you are very, very special.
Bunni: First Screenshot. Likely to change in inexplicable ways.
Oh, and as a bonus, here are some t-shirt designs. Let me know which ones you like the best. (I tossed together a storefront as well just for fun. The internet is so awesome.)
Danc's Miraculously Flexible Game Prototyping Graphics for Small Worlds
Don't you think it is time for some new free graphics?
The originals The original set of miraculously flexible prototyping graphics have been out there for a couple of years now. In that time, they've been used in mini-MMO's, shooters, RPGs, platformers and dozens of various projects that lurk in the dark squishy nooks of the ever fermenting, communal indie mash.
However, they had some issues.
They were in a format that wasn't readily accessible to most users. In particular Flash games didn't make as wide a use of them as I would have liked.
They required a rather tricky placement system that most tile based engines had difficulty handling.
Very few games used the shadows system and without the shadows, they tend not to look very good.
There were also a couple other areas I wanted to explore.
HD pixel art: There is an emerging artistic style that showed you could keep the intricate iconic style found in pixel art, but modernize it in such a way to take advantage of the crispness found in modern high resolution displays. The result found in games like Pixel Junk Monsters, Patapon, and Loco Rocco is distinctly game art. It tends to be 2D and highly evocative. But is also is information dense and full of distinct iconic symbols that have meaning during game play. When there is a trade off between realism and functionality, functionality wins.
Vector art: I've done immense amounts of raster art over the years, but lately I've been playing with more vector art. The tools have gotten to the point where you can do some pretty nice stuff rather rapidly without needing to ever go to bitmaps. They are rendered natively in Flash or Silverlight and you can play with scaling without worrying about loss of detail.
Arbitrary placement: Once upon a time, you needed to use little square tiles for everything. Nowadays, there is no real need to make a tile based 2D engine. With arbitrary images with full alpha and lots of fill rate, you can put together a game like a sticker book. Drop down your graphics at arbitrary positions and layer like a madman. Games like Aquaria look great and tiles are nowhere to be seen. There's a good tutorial on the topic here: http://gametuto.com/in-game-c-map-editor-tutorial-with-indielib-engine-that-dosent-use-tiles-but-pieced-images-like-in-braid-or-aquaria-games/
Small World So I started a new graphics set that took all these into account. The theme I chose was the 'Small World', an intimate place of green trees and blue ocean seen from above. For ages I've been fascinated by tiny worlds that you could imagine keeping like a bonsai garden on a table top.
What types of games can the Small World graphics be used for?
Turn-based strategy games
Real time strategy games
RPG's
God and Sim games
Tower defense (the original inspiration for this set was Pixel Junk Monsters)
Crazy innovative games that will shock and amaze the world.
What does the set include?
70 high quality sprites
The original Illustrator CS4 .AI file
The exported Flash CS4 .FLA file
The exported Flash CS3 .FLA file
The exported Flash 10 .SWF file (with linkages)
Land
Forests
Buildings
Dialogs and buttons
Having the source files allows you to easily manipulate and edit the graphics so you can make variations or combine pieces together. You should have enough pieces to easily prototype attractive little worlds full of forests, fields and cities.
What doesn't this set include?
I have some characters that fit this set, but those will be coming along at a later point.
I haven't had time to cut out all the bitmaps. This is coming shortly unless someone else cuts them out first.
Other formats: In general there are a billion minor formats that all have their passionate proponents. Convert at will. :-)
The License Much of the email I get involves questions about how various graphics can be used. Though I love hearing from you, it has become apparent that the license needs to be clarified so that I can spend more time making stuff for you and less time writing back about the legal issues.
A second issue is that there have been some unfortunate incidents where players have taken talented developers publicy to task for 'stealing' my artwork or 'copying' game designs. 'Open source game designs' are admittedly a cutting edge concept in our IP-clutching world, so there is some education to be done.
As of today, I've created a separate Lost Garden Licensing page that outlines the license for these graphics. If you plan on using these graphics, be sure to read it. The basics are that they are free to use in both commercial and hobby projects under a standard Creative Commons Attribution license.
I'll be releasing some prototyping challenges that make use of these graphics in the future, but for now just have fun and give them a shot. They were a blast to make.
take care Danc.
PS: I also included graphics that allow you to make arbitrarily sized islands composed of splotches of land stuck together. This is a tricky technique that only advanced users will undertake. First lay down the water. Then lay down all the Land-Bottom graphics. Then lay down all the Land-Mid graphics. Finally draw all the Land-Top graphics. By layering the graphics in this order, you can create islands that merge together visually.
My short essay on future games was selected to be part of the recent Gamasutra 'Games of 2020' feature. The treatment is tongue in cheek and I owe anyone I photoshopped a free beer.
The result of all this is that I am now able to attend this year's GDC. If anyone wants to meet up in San Franciso (March 23rd to March 27th), drop me a note at danc [at] lostgarden [dot] com.
I was about to ask a friend what sort of games she liked to make and I realized that I didn't even know how to frame that question in an intelligent manner. I've noticed that games have distinct styles. These are not visual styles. Nor are they styles associated with prefered process of development. Instead, they are unique styles of game design, how you mix and match mechanics, story, player agency and feedback. What do you emphasize? What aspects of the the player's experience do you highlight with your design choices?
A spectrum of game design styles It is a broad topic, so I'll just jump right in. Here are some styles that I've noticed. You can think of these categories as pieces of a spectrum that cover all major aspects of the final game design that the player experiences. Though they are all present, each style is emphasized to varying degrees in a particular title.
Copycat: make a game like another game that is interesting.
Experience: Make a distinct moment of game play that looks and feels interesting.
Narrative: Make a story that is interesting
World: Make a place or world that is interesting
Systems: Make systems and objects that are interesting.
Player Skills: Make verbs for the player that are interesting.
Let's give a brief description of each of these styles and how I've seen them work.
Copycat A copycat designer takes an existing game genre and builds a new work within it. The term 'copycat' is descriptive and not derisive. I personally steal with great gusto from other games and consider an elegantly pulled off theft to be an essential skill for any practicing designer.
Copycats borrow liberally from the best elements of past works and mix them together with minor design innovations to create the new flavor of the month.
If design problems arise, a good solution is often readily available in a historical product in the same genre. The best copycat designers have encyclopedic knowledge of other games in their genre.
The goal is almost always to make something better or 'more correct' than what has been on the market previously.
Most working designers are copycat designers. On the supply side, there exists a natural urge for a player who deeply loves a particular genre to attempt to do a better job. This provides a constant wellspring of new copycat designers. On the demand side, the market's lust for sequels ensures a wide range of jobs that need good copycat designs. Helping this dynamic is the fact that it is quite easy to learn to be a copycat designer. Find a game you like and copy it. You don't need to know theory or have a strong philosophy of design. Over many years of labor you'll likely get quite good at making polished variations on the initial blueprint.
Limitations
Competition is intense. Most of the time you are fighting over market share in a crowded genre. You can avoid the competition by building a strong established brand (which costs lots of money) or you can be first to a popular new platform (which requires technical resources and the ability to predict future markets)
Costs are high. All the polish required results in long development cycles with large teams and large marketing budgets.
Risk aversion dominates: Both copycat players and developers are risk averse. Players want their comfortable fix and developers don't want to introduce undue design risk in an already financially risky project. This often leads to bigger titles that are not always better.
Experience
An experience designer has a vision in their head of how the game will eventually look, feel and sound. They seek to create an emotional moment for the player that matches their vision.
Experience designers start with a mental image of the game. It could be a still shot. It could be a scene. The scene is laden with strong emotional and evocative detail.
Everything in the game exists to serve and bring to life that vision.
When I think of games that demonstrate the Experience style, I immediately think of Flow and Flower. Graveyard is also a good example. Starting with a target experience has a lot of benefits. You can change your art, mechanics, story and other game elements to match the experience. Experience designs have the added benefit of making the original designer valuable and nearly irreplaceable. The vision resides primarily in their head and they can act as the final arbiter of whether or not the actual product meets their vision.
Limitations:
Designs based on a vision are difficult to communicate. On larger teams, communication mistakes can multiply and bog down the project.
Teams can wander down dozens of different paths and still not reach the ephemeral vision in the designer's noggin.
Occasionally other game play elements are poorly fleshed out. You can easily end up with something that is pretty, but isn't all that fun to play.
Narrative
A story designer has a tale, usually a linear sequence of evocative events (or graph of such events), that they wish to tell. Games are the stage upon which the story is performed.
The game is conceived as a narrative arc and gameplay is often relegated to mini-game set pieces strung together to support the creation of the arc.
Design efforts focus on the use of symbols and pacing to evoke emotion. When the designer kills or removes a character and there is nothing the player could have done, you know you are dealing with a Story Designer.
The game is a success if players react strongly to the story that has been woven for them over the course of their play.
Story designers are quite common in larger scale games. Many AAA titles sports a very specific 'roller coaster ride' structure that has narrative design at it's heart. Examples of games built by Story Designers are everywhere. Choose your own adventures are the classic case, but I'd be curious if even a game like Passage was ultimately conceived as a tale with fixed endings (albeit one where authorial intent was enforced by a predestined algorithm).
Limitations
Most story-based games can only be played once or twice before they are no longer interesting. They deliver their tale and then their value is spent.
Every little bit of must-see narrative steals a smidgen of agency away from the player. Instead of letting the player author their own story, the designer steps in and forces their own narrative upon the player. This limits the player's ability to try and learn new things.
Failure is rarely an option, or at least not a serious one. After all, there is a story that must be told. Many times players are shunted from plot point to plot point with minimal gaming fuss.
World
A world designer begins by envisioning an imaginary space. They picture how it might be if they escaped into it as a player.
Place is a critical organizing concept. Items, people, organizations lives in specific places and their spatial relationships give meaning to the world. It is quite common for world designers to think in terms of maps, architecture, towns, races, guilds, districts etc.
Much of the flavor of the place is created through the use of historical detail. The underlying assumption is that the world existed when the player was gone and it will exist when the player leaves.
World designer will often lean heavily on fresh content in the form of new vistas to create a sensation of being in the world. They will often use the same game mechanics throughout, but delight the player by varying the setting from location to location.
The classic example of a World Designer is found in the paper RPG world. A GM will start with a map of continents and flesh out civilizations, races and alliances. This creates a playground for imaginative adventures. Games like Ultima, Oblivion and World of Warcraft also have a strong World style.
Limitations
World designs can often result in bloated games. There is so much stuff in the ever evolving world in your head that it is hard to know when to stop adding. New systems and verbs are created to support the exploration of every nook and cranny and few mechanics interconnect in crisp manner.
World designs are usually an immense amount of work. It is far easier to make a single scene or a situation than it is to flesh out an entire world.
Designers can focus so much on building the space that they forget to fill it with interesting things for the player to do. The result is mechanical place that feels lifeless.
Systems
Systems designers begin with a curious and intriguing set of rules that interact in unexpected ways.
Designs often begin with a set of objects, properties and interesting ways that the objects interact.
Common sources of inspiration include probability, combinatorics, spacial relationships, physics, timing and economic game theory.
The goal is to create a challenge for the player, be it a short term challenge in the form of a puzzle or a long term challenge in the form of a deep possibility space.
Truly deep systems often lay bare their mechanics in order to provide advanced players with absolutely clarity on their inner workings. The result is less room for details like narrative or world building.
Many of the industry's most original forms of gameplay were conceived by people inspired by systems. With simpler rule sets, you find games like Tetris. Complex systems yield creations like SimCity or Populous.
Limitations
You'll often end up with a system that is fascinating to the designer, but not that enjoyable to the player.
Many systems oriented designs come across to players as overly abstract. There isn't a clear entry point into the design for new users in the form of a friendly metaphor or setting.
Systems can be quite difficult to balance due to all the various emergent interactions.
Player skills Designers that focus on player skills create a set of actions (or 'verbs' in Chris Crawford lingo) for the player to perform. Then they create systems that help them learn those skills.
You start by writing out the type of verbs that you want the player to perform.
Then you figure out systems to go with those verbs
You figure out what additional skills are discovered when the systems are put in front of players.
Finally you figure out the right feedback systems to teach people those skills in an enjoyable manner.
Miyamoto is a good example of a designer inspired by player actions. When developing games he tends to focus on what the player is doing. Mario was originally named Jumpman after the key action you performed in the game. WiiFit came about by asking what sort of game could be built around the joy of weighing yourself. Mario 64 started as a playtest bed where all you could do is run around a small room and exercise the basic verbs of the game.
Limitations
Game play occasionally devolves into a series of disconnected mini-games when designers grab the easiest system available to represent a particular action. For example, in FishingGirl, I used a Frogger-style mechanic to represent fishing. As a simulation it was quite limited and was barely connected to the other mini-games associated with of casting and purchasing lures. In something like God of War, they turn the action "Kill boss monster" into the simplistic mini-game "Simon".
After coming up with a set of fun actions, narrative and world are applied as a skin to the results. The result are surreal worlds involving mushrooms, exploding barrel graphics and other videogame-isms.
Rising design styles The following styles are starting to appear within a few pockets of game design community.
Social: Designers that focus on encouraging particular types of interactions between multiple people. They have skills of event coordinators or party planners and focus on atmosphere, breaking the ice, moving people from activity to activity as well as efficient build up and take down of the event. Important organizing concepts include 'Events' and 'Social spaces'. MMOs, Party games, and social networking games tend to attract Social designers. It is my believe that the next generation of great designers will be social designers.
Business: Design that focus on business try to squeeze as much money out of players as possible. I meet designers operating in online games and gambling games with this design slant. Typically, you encounter it in ex-designers who have moved onto publishing roles. It is an extremely powerful perspective that is unfortunately rather rare. As free-to-play becomes more popular, gameplay and business model will become even more interwoven.
Product Utility: Designers that focus on player value first identifies some form of utility that the product bring to the player. Product Utility designers often come from a more traditional product design background and focus on creating innovative solutions to observed problems. Yahoo, Amazon, Iminlikewithyou, and numerous web 2.0 companies a busy using the motivational aspects of games for utilitarian purposes. In short, this is social engineering with a purpose.
Pick your style!
Most designers tend to mix a couple major styles together. For example someone who enjoys working on licenses might start with a world style and do a deep dive to understand the world of the license. Then they augment that with a copycat design. Or someone who works on art games could mix a strong narrative with a systems oriented set of mechanics.
My suspicion is that most designers will have trouble applying all these styles to a game equally. First, each style can easily take years of intense labor to master. Secondly, games need focus in order to clearly convey their intended value. Too many dominant ingredients fighting for the player's time can weaken the end result. It is a bit like cooking. :-)
As an exercise, take a look at various games out on the market and see if you can figure out the handful of styles they've stirred together. Halo is classic Copycat with a heavy coating of Narrative to make it seem like something bigger than your typical game. Desktop Tower Defense a straight Verb and System game, barely seasoned with any other styles. Ian Bogost refers to Jason Rohrer's work at 'Proceduralism'. I see a fascinating mix of Narrative and System styles.
So pick two or three styles for each game you build. Prioritize one as primary and others as secondary (in case there is a conflict at some point later in the design.) Don't ignore the remaining styles since you'll certainly need dashes of them to make the game function. However, be conscious of the dominant style of game you are making and make the hard decisions on what to focus on up front.
Understanding design styles to reduce team conflict Inevitably there will be people on your team or in your audience who are fans of the other styles of game design. I regularly run into good people working in the game industry who passionately want to tell the sort of emotional stories that they see in movies. Story and Experience are paramount to them. However, any sort of Systems conversation inevitably devolves into a muddled Copycat discussion.
You can use the game design styles above much like how personality tests are used to resolve conflicts between people with different work styles.
Identify your personal style. Which of those styles above do you love? Which ones do you find dull or unpleasant?
Identify the style of the game you are working on right now. It is very common for this to be something different than your personal style. Publicly declare the style of game you are making so the entire team can agree upon the game's direction.
See if you can understand the preferred style of other people around you that tend to hold forth passionately on game design.
Realize that having people on the team who are passionate about a variety of different styles is a good thing. Just because you occasionally feel the other person is coming from a bizarre and alien perspective doesn't mean that they don't have something valuable to contribute.
When the opportunity comes to up to add in a dash of 'spice' in an area outside your personal style, see if you can tap into the passion of someone who prefers that style. We can't lead all the time in all areas, nor is it a good idea to try.
My style I almost always approach a new design from a Systems perspective. I find an interesting set of objects that interact with one another in interesting ways and then attempt to build a game around it. My typical process is to try lots and lots of systems, throw them at kleenex testers and see which ones are 'fun'. This is labor intensive, but you can keep the costs down by using small agile teams and simple prototypes. It yields games that are lower on the copycat factor. However, they also have a bit of a surreal aspect to them since experience, story and world tend to be re-imagined on the spot to fit the latest mechanics.
Lately, I've been moving more in the direction of a Verb style. With Systems, I'll often end up creating a game that is fun to design, but not fun to play. By focusing on the verbs and how the systems help the player learn to manipulate the system, my prototypes "find the fun" more often. If games create pleasure through exploratory learning, it makes sense that focusing on verbs and skills are one of the more direct paths towards creating engaging game play.
Narrative is my main weak point and something I should work on.
Conclusion One thing I get out of this exercise is that there is not one True style of game design. For every Miyamoto and Will Wright creation there is a game like Monkey Island or Full Throttle pushing story and experience. People love all these games. Game design style, like style in almost any consumer market is a matter of taste. The good news is that now I can name the various styles and discuss them in a less vague fashion.
I also realize that I've been leaving certain powerful perspectives out of my palette of game design tools. When I was younger (and driven more strongly by raging hormones), experience-driven games mattered immensely. I vividly remember working on a game about sickness and trying to convince my fellow teammates that it was of utmost importance that black cancerous growths fall off the player and scuttle away on their own. As I aged, I've moved onto more intellectual and less emotional designs. It might be fun to bring that side of my design back one day.
Of course, this list of game design styles is a work in progress. So I'll end with some questions.
What style of game designer are you? Do you fit into one of these approaches?
Is there another design style that is missing from this list? Can it be expressed by a combination of the other styles?
Recently I wrote a review for Jesse Schell's new game design book. You can read it up on Gamasutra.
Here's a brief except:
Though the elements of game design are well described, practicing designers won't find a lot of new insights that haven't been covered elsewhere. Luckily, the book also includes some more utilitarian tools in the form of 100 "lenses", or questions that help you iterate on your current design.
A designer's job often consists of asking questions. Almost as soon as you start building a game, you need to ask "what should be improved?" There are nearly an infinite number of questions one could ask and often finding the right question to ask is key to coming up with the right solution.
The 100 Lenses are a set of time-tested questions that you can ask about your game. Are you using your elements elegantly? Could your pacing be made a bit more interesting by using interest curves? What is the balance of long term and short term goals for the player? One of my favorites is Lens #69, The Lens of the Weirdest Thing:
"Having weird things in your story can help give meaning to unusual game mechanics -- it can capture the interest of the player, and it can make your world seem special. Too many things that are too weird, though, will render your story puzzling and inaccessible. To make sure your story is the good kind of weird, ask yourself these questions:
What's the weirdest thing in my story?
How can I make sure that the weirdest thing doesn't confuse or alienate the player?
If there are multiple weird things, should I maybe get rid of, or coalesce some of them?
If there is nothing weird in my story, is the story still interesting?"
These are the sort of questions that get me looking at my game designs from a new perspective and can really jolt the creative juices. Not all of the questions will be useful.
However, somewhere in the list are at least two or three questions that even the most experienced designer wished they had asked sooner. By having the questions at your fingertips, you can ask them earlier.
Thoughtful writing on game design always get my brain churning in interesting new directions. With Jesse's book, I was reminded what a broad ranges of disciplines that game design ultimately includes. I have taken a narrower route and spent the last couple of years focused on a rather specific set of tools related to rapid iteration and skill atoms. Yet there are dozens of fascinating nooks and crevices in our evolving craft that one could profitably invest their life exploring.
The 2008 Project Horseshoe reports are up! We wrote about how to diagram multiplayer games using skill atoms. Truly a brilliant weekend. The discussion was quite wide ranging and as a result the write up became a bit...long. However, the results should spark a few brain cells. Let me know what you think! :-)
Here is a story about a fellow named Andre, who created a Lostgarden game prototype, sold it for $4000 and started down the path to a new career in game development.
Andre lives down in a rural section of Australia. Due to the limited infrastructure in the region, he makes due with a gimpy modem that sputters along, randomly disconnecting at the worst possible moment. There aren’t very many tech jobs in the area, but he is unable to move due to family obligations.
Early on in life he dabbled with art, graphics programming and games, but there isn’t much call for such things locally. To make ends meet, he grinds away, year after year, developing website after website.
Andre is the sort of smart, industrious fellow that has immense potential. He dreams of creating amazing and wonderful games. Every email I receive from him is bursting with ideas and snippets of working games that he jotted down in his spare time. Yet the ‘traditional’ path into games is closed to him.
When opportunities are limited, people often settle for limited opportunities. I grew up in a rural area and I’ve seen many bright wonderful people end up in dead end jobs due to the emptiness of their environment. It can be hard for people raised in areas of plenty to understand, but if no one else ever talks about what is possible or open a door to new ideas, you can go through life bound by invisible cultural blinders. Prototyping challenges are opportunities I created the prototyping challenges on Lostgarden.com as an onramp for new game developers. There are no excuses. The art is free. The design, though never perfect, is enough to get you moving in the right direction. There are dozens of free game engines for you to use. All this, combined with the internet (even accessed on a gimpy modem) opens all sorts of doors. All you need to do is make a game.
Over the past month or so, Andre built a version of Fishing Girl in Flash. He quickly built out the original design and then iterated upon it until he had something playable. A bit of data:
My wife played it and she likes it. It passed the Wife Test.
Played by about 280,000 people...100,000 in the last day.
The best bit of news is that Andre was able to sell the Fishing Girl game for $4000 + a performance bonus. Yes, you can sell Lostgarden prototyping challenges for cold cash. I highly encourage it since A) people should be paid for their hard work and B) the lessons you learn by finishing a game for the public are invaluable.
Now Andre has a little bit of income and a lot of validation to feed the development of his next game. These days when I talk to Andre, he has big plans for a whole career doing what he loves. That is pretty darned cool.
Gold medal (1st ever)
Andre gets my first gold prototyping award. He earned a score of 77% (103 out of 134 points). Here is what he did to earn it:
15 minutes of fun: The rule of thumb for a gold medal game is that you need to make about 15 minutes of fun. Most prototypes barely get to the 5 minute mark. Many people are playing through Andre’s FishingGirl twice and spending upwards of an hour on a single play through.
Found and extended the fun in the design: In order to build 15 minutes of fun, he iterated on the basic design and added his own touches like lure-seeking fish and wonderfully animated endings.He realized that a game design is not a blue print. It is a starting point for practicing the iterative process of design.
Made a complete experience: There is a strong narrative arc throughout Andre’s Fishing Girl. You fish, you advance, you discover something surprising and you save the little boy. It is a game you can start and then feel good about finishing. The vast majority of people who say they want to make games start building them but never finish them. The act of making a polished game that players can finish teaches you more about game design than any number of incomplete engines or piles of features.
Silver medals Folks have been working away like busy bees on this design. I expected to give out mostly bronze medals, but there were three prototypes that were recently updated, each of which kept me interested for five minutes.
There is still opportunity for each of these to reach for a gold medal. I’d love to see some more variations on the Fishing Girl game. If Andre’s Fishing Girl is the equivalent of Asteroids, who is going to make Galaga?
Ben (46%):http://sites.google.com/site/walkersoftwareprojects/files. Ben has a simple game here that still managed to get me to try to fish up all the little fishies. The mechanics are lacking a bit of juiciness, but basics are there.
Shade (41%):http://www.exodia.org/og/?p=24. Shade has some interesting line physics here. To riff a bit , with this type of system and line collision, you could do some wonderful things with obstacles in the sea. Players would need to drape the line perfectly over different objects to get to a particular spot in the ocean to catch a rare fish. This protoype has the ‘juiciest’ of the game mechanics, but it needs a bit of tuning so that it doesn’t feel quite so loose.
Bronze medals There were also a couple of solid technology experiments.
Dale and Greg: http://beta.sharendipity.com/assets/1900/: The good folks over at Sharendipity put together the basic fishing mechanics and it is running on their new Flash client. (Woot!) They initially implemented casting and fish swimming as two separate apps. As a side note, this prototyping path can be tricky to gain useful feedback from since the most exciting gameplay opportunities often come from the interaction of the combined systems. It is often better to integrate early, but keep each system simple so that you don’t need to deal with undue complexity. You can always add complexity to a system if you identify enjoyable skills that are worth investing further in.
Pete: http://blois.us/FishingGirl/ Our first prototype in Silverlight. Sweetness. He has a tight casting mechanism.
Areas of improvement Every time you build a game, you learn lessons that let you build it better the next time. If anyone wants to create a better version of Fishing Girl, here are a couple things you might be able to improve. These comments uses Andre’s game as a starting point.
Problems: The following are problems that kept users from enjoying the game fully.
The floating shops are a pain: You constantly end up hitting them with your lure. Having a single floating store that is inside the distance of your longest cast may help. The position prevents you from hitting it unless you try. Instead of selling one item, the store would have a rotating list of things that you can buy. Once you hit the store, it reappears elsewhere. The alternative is to let the player go to the store at any point, but this removes some of the fun of trying to cast at a specific distance.
It is hard to aim exactly with the rod: Slowing down the rod might be one way of improving accuracy. Speeding up the ‘boring’ parts of the swing the beginning and end might be another way of giving the casting a better feel.
Less repetitive music: People get bored of the music rather quickly.
The later portions of the game become boring: Try having fish reproduce at a certain rate if they get below a certain population threshold or make the larger fish more interesting to catch. I’d still like to keep the possibility of ‘fishing out’ the area so that an extinction ending is possible.
Opportunities: The following are glimmers of fun that could be accentuated in a future version.
There should be more things in the ocean: There is immense opportunity for bonus objects to be hidden in the ocean. For example: Treasure chests, Glowing orbs that spawn rare fish or deadly fish, Temporary lure or rod power ups that only last a certain amount of time
A fish collection: Imagine that every time you collected a new fish, you got a stamp for that fish in a collection album. It is a like butterfly collecting, except with fish. Some people would need to “catch ‘em all’ which would extend gameplay. With a bit of color cycling or special effects, you could easily create dozens of different fish with different costs and rarities.
More fish movement: The fish have generally simplistic movement. Fish that dart at a lure or that move very quickly or very slowly might add some interesting texture. It is worthwhile to see if the catching of a single large fish can be made more interesting.
More lure types: The types of lure could be expanded up on. For example: Lures that only work on fish of particular colors, Lures that are more or less bite resistant, Lures that attract some fish and repel others. , Lures that upgrade some fish into more valuable fish, Lures that allow you to capture multiple fish or a set of fish in a row.
More levels: There is a single level. It could be interesting to have the girl jump on a boat and travel to a new island with more fish. An alternative progression is for the sea to evolve over time. Once you collect certain fish or reach a certain amount of money, kelp can slide aside or a cave entrance can be blown up that introduces new fish and new treasure.
Fog of war: One of the exciting bits of fun that emerged from the prototyping was a sense of discovery as you are able to fish out further and further. A feature that should add even more mystery to game is fog of war system similar to those found in RTS games. The area around the lure could show you the fish nearby. Areas that you hadn’t explored would be opaque. Areas that you had explored would show markers or partially transparent versions of fish you had seen. Combined with ‘rare’ fish that could only be found in certain areas, this would give players a much stronger sense of ‘exploring’ the ocean.
Add a serious ending: One of the key endings in the original design is the ability to cause all the fish to become extinct. It adds an interesting twist to what would otherwise be a mindless game. The system is built so that users slowly fish out the small fish and eventually gain new technology that allows them to fish out the larger deeper fish. This systems-based narrative parallels the pattern of fishing in the real world and seeks to teach a small lesson. The dynamics could be augmented by systems that catch large numbers of fish at once so that it becomes quite easy to overfish. The addition of a ‘save’ system that lets you come back later to harvest fish (and score) for long periods of time would encourage manageable fishing tactics.
Conclusion I hope everyone enjoyed this prototyping challenge. These challenges are evergreen, so just because I’ve given out the first round of awards doesn’t mean you should stop developing! Keep going. I would like nothing better than to give out another gold medal. If you update your project and want me to take a look, just drop me an email at danc[at]lostgarden.com. I can be a bit slow at responding, but I will write eventually.
As the years go past and my hairline continues to recede, I find that I have a debt that I am obligated to pay back. Very few of the current generation of game developers started from scratch. We’ve all looked at tutorials or snagged bits of free code. We’ve built upon tools like Flash or engines like Quake or Source. We’ve been inspired by existing designs or read books that have opened our eyes. Once upon a time, I too was in Andre’s shoes and it was only due to the opening of an unexpected opportunity that I’ve arrived at where I’m at today. If these prototype challenges ease another eager game developer’s path in even a small way then my time on this blog is well spent.
Percentage values: The percentage scores may come across as somewhat low, but try not to interpret them from perspective of the inflated grading system used in schools.
Notes on Awards: If you won an award, feel free to post the appropriate award image and link back to this post. You should be proud of your efforts!
I happen to fall into the artist-designer skill set, so I often find myself trying to prototype ideas on teams rich with programmers. As such, I'm always looking for better game development techniques that work well for this particular team mix.
Here is a very lightweight prototyping process using Post-it notes that I quite enjoy.
Initial idea: I sit down with an available programmer (and artist/UI designer depending on the system) and we chat about how to test out a new bit of gameplay. Usually this is an idea that has been bubbling about since the night or week before.
Post-it note design: I jot down a quick bulleted list summarizing our discussion on a single post-it note. We go over it one last time so there everything is clear. The list isn't very detailed. Mostly it serves as something to jog our memories if we forget what we were talking about.
Build it: The programmer and artist go off and build the items on the list. It might take 2 hours or two days. They are encouraged to solve problems creatively and they can always just give me a shout if something doesn't make sense.
Play test: When most of the items on the Post-it note are playable, I get called over and we play test it the experiment together. If the results are comprehensible by mere humans, we pull in some play testers for 3-4 minutes to observe some real players interacting with the mechanic for the first time.
Review: Afterwards, we discuss our observations and write up another Post-it note worth of improvements.
Repeat or Stop?: The process repeats until we run out of time or give up. Sometimes we give ourselves a day per experiment, sometimes two days. In the land of Scrum, we treat the experiment like a time boxed task.
Rate: At the end, the gameplay experiment is rated according the scale below.
Save: The code is saved off, a few choice notes are recorded in a doc containing our 'list of experiments' and we move on. Bits of code, even from failed prototypes, are often reused in future gameplay experiments.
Rating system The rating system is delightfully crude. The goal is to triage experiments quickly.
"A": These experiments were obviously fun. Players laughed, smiled and generally exhibited the emotions we were looking for. If in doubt, ask "Was this fun? How so?"
"B": These experiments showed a hint of fun if you knew what you were looking for. However, it is going to take more effort to expose the fun in a manner that is visible to the players.
"C": There wasn't any fun. The experiment fails.
A portfolio of fun One of my favorite aspects of this method is that you end up with a mini-portfolio of game design ideas. Instead of putting all the design risk in a project on one or two unproven mechanic, the team now has a half dozen or more proven bits of fun to build upon. If some don't fit into the game or get abandoned for other reasons, that's alright. You can afford to lose a few and the end product will still be fun. Think of it as designing from a position of plenty.
Contrast this with a prescriptive 'design doc' approach where you are forced to pick, without much evidence, a main mechanics for production. Even for the most experienced designer, 50% to 80% of your 'educated' selections are going to be complete dogs. Every unproven mechanic you polish ends up being a massive drain on your budget and your reputation as a designer. You might hear gentle comments like, "We spent 3 months of dev time on this lump of an idea and it isn't fun?"
It doesn't take very many expensive failures for the project's perceived 'design risk' to blossom to the point where conservative minds seek to kill the project. I think of this as designing from a position of sudden death.
Some basic observations Here's a quick list of things I've observed when prototyping.
Failed experiments happen a lot. Don't be surprised if C-rated experiments occur 50% to 80% of the time. Everyone on the team has to be aware that not every experiment is going to be a success, but the learning process is still worthwhile.
Designing on your feet is a critical skill: Each consultation and analysis might last only 10 to 20 minutes and you need to leave folks with that all important sticky note filled with impactful, yet inexpensive changes. It pays to have lots of ideas and a deep understanding of game mechanics so you can quickly pull together a list of incisive comments. If you can't, you likely are not suited to be performing the designer role.
Listening matters. The designer doesn't need to come up with all the solutions. Everyone on the team is bright and has great ideas. As a designer, your role is to herd all ideas (yours and others) into something that serves the next step in the prototype.
You need programmers: If there aren't programmers dedicated to prototyping, the prototyping isn't going to happen. You can drop down to paper prototyping, but it usually doesn't prove out many types of mechanics (especially ones involving timing and interfaces.)
Advanced observations These are some notes that are a bit geekier, but can save you large amounts of pain.
Meta game mechanics are harder to prototype: The systems that link together the various gameplay experiments are harder to playtest. They operate on longer time spans (hours instead of minutes) and often require that the core gameplay is already fun.
Build a meta-game architecture that allows for loose coupling of gameplay experiments: Most successful games have an architecture that allows the team to plug in new bits of fun as they are found. The linear 'level-story-level' pattern used by most FPS is one example. The 'hub with many sub levels" used by Mario 64 is another. Any of these allow you to plug in a new experiment independently of the other gameplay experiments. If you don't have a modular architecture, you run into situations where a fun new system breaks many of the other bits of fun you've already discovered.
Integrating tightly coupled gameplay experiments is a pain: If I independently find a fun new type of weapon and an interesting enemy AI, the combination of the two is often a non-trivial issue. The new weapon many work with an old AI, but be completely useless with the new one. Integration yields a whole new set of experiments. Plan for time to rediscover the fun all over again.
Benefits There are some interesting benefits to the Post-it note design method:
Scales nicely to large prototyping efforts: One designer can serve multiple programmers. This works nicely on teams where there are more programmers than designers and you need to get a lot of prototyping done quickly.
Failing quickly is fun and educational. You learn a lot with each failure and can move onto the next experiment with a much better idea of what doesn't work.
Provides a quick death for bad pet ideas. It is much harder to resurrect pet ideas when you have concrete, playable proof that it won't work. Finding out early which one of my favorite ideas is idiotic saves me a lot of political pain.
Fun prototypes are quite convincing: A fun, playable crazy idea works a lot better for winning over other team members than any amount of hand waving or documentation.
An easier team to assemble: Finding a competent game designer and a competent programmer can often be easier than finding a competent programmer-designer. Well developed hybrid skill sets are very valuable, but can be quite rare. A side benefit of having a team is that you end up cross training your designers and programmers. You create designers who can speak to programmers and programmers who can riff on some of the design.
The value of dime-a-dozen designs (A brief aside) One often hears the negative comment that game designs are a dime-a-dozen. And in a waterfall design process, an incessant stream of ideas is indeed a problem. If you attempt to squeeze all those ideas into a typical waterfall development process, you end up with an immense amount of waste. Each designs need documentation, concepting, implementation, testing and bug fixes. In response, project owners will often ask for just one good idea.
There is another path. A lightweight prototyping method takes your flurry of crazy ideas and converts them at moderate cost into a well sorted portfolio of working designs. All those ideas are not, in fact, worthless or wasteful; they are the essential fuel that feeds a good prototyping process. Each idea either teaches you something or provides you with a success.
The way to make the process work without getting gunked up is to make prototyping incredibly lightweight. Other than our focused conversations, I spend my time on a total of two design docs: The first is the brief list of rated prototypes and the second is a set of discardable, temporary Post-it notes. Design waste in the form of unnecessary artifacts is minimal. Most of the 'programming waste' is better classified as low cost learning.
Those wild flocks of churning, swirling ideas end up not being worthless at all. They simply need to be funneled into the project with the right process for their value to be realized. Conclusion The "Post-it note design process" has likely been reinvented in one form or another hundreds of times across the history of game development. It is so basic that it feels odd to even write it up in any sort of formal fashion.
If you have a designer and a programmer, give it a shot. It is certainly a good functional alternative to the popular process of sticking a lone programmer-designer in a room and asking them to 'find the fun'. Both can produce great games. Pick the one that works best for your current team composition.
This process does have an cost since you need to devote at least two people to finding the fun instead of putting all decisions on the head of the designer. However, the end result is well worth it. After all, it is far smarter to spend team time uncovering a portfolio of the right mechanics than it is to 'save your programmers' so they can be off running really fast in the wrong direction.
In the end it really isn't about programmers, designers, design documents or features. It is about the team working together to make the right product. Everything else is just ego and waste. And for some reason, it is quite difficult to invest much ego or waste in a little disposable Post-it note.
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?
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:
Explain the model to a crowd of natural skeptics, working designers who have been successfully building games for years.
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.
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:
Casting
Positioning the lure
Hooking a fish
Reeling in the fish
Scoring the fish
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:
If you click your button once, the girl will pull back her pole to cast.
If you do nothing, the pole will return to the default position.
However, if you press a second time in the middle of her swing, she will cast the lure outward into the ocean.
The closer the second click is to the peak of the swing the further the lure travels.
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.
The Fish
The Lunge
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 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.
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.
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!
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.
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.
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.
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.
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:
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.
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.
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.
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
Worth Reading:<-This is a good starting place if you are new to the site
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.
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:
Decomposable into simpler skills
Skills can be nested
Skills can be arranged in a smooth learning curve
Skills are measurable
Performance can be rewarded
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.
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.
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.
Rank each bug on several criteria
Combine those criteria into a single score called User Pain
Sort all bugs by User Pain into a public list
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?
Likelihood: How likely are users to experience the bug? For example, does everyone run into the issue or do only a few users run into it?
Priority: Of the people who experience the bug, how badly does it affect their experience with the product?
These particular factors have been battle tested for many a release and were selected for the following reasons.
Good coverage: These cover the range of concerns expressed by most stakeholders. Type includes business priorities while Likelihood and Priority help classify user impact.
No overlap (aka orthogonal): A bug can be rated on one factor without affecting how you would rate the other factors. This allows you to rate each factor in isolation and greatly improves the objectivity of the results.
Small number: There are few enough of them that they don’t overload the bug submitter. It is easy to add more factors for various edge cases, but typically this results in a cluttered and confusing bug submission form.
Use anchored scales Now that we have our factors, each one needs a rating scale. At this point, we do something slightly tricky. Each point on the three scales is anchored to an objective description. Here are the anchored scales I prefer:
Type (What type of bug is this?)
7: Crash: Bug causes crash or data loss. Asserts in the Debug release.
6: Major usability: Impairs usability in key scenarios.
5: Minor usability: Impairs usability in secondary scenarios.
4: Balancing: Enables degenerate usage strategies that harm the experience.
3: Visual and Sound Polish: Aesthetic issues
2: Localization:
1: Documentation: A documentation issue
Priority (How will those affected feel about the bug?)
5: Blocking further progress on the daily build.
4: A User would return the product. Cannot RTM. The Team would hold the release for this bug.
3: A User would likely not purchase the product. Will show up in review. Clearly a noticeable issue.
2: A Pain – users won’t like this once they notice it. A moderate number of users won’t buy.
1: Nuisance – not a big deal but noticeable. Extremely unlikely to affect sales.
Likelihood (Who will be affected by this bug)
5: Will affect all users.
4: Will affect most users.
3: Will affect average number of users.
2: Will only affect a few users.
1: Will affect almost no one.
An anchored scale describes each point on the scale with specific, objective criteria. As long as the item being rated meets the criteria, you know what value it should be assigned. An anchored scale is preferred over a relative scale (ex: Please rate this problem from 1 to 10) since there is less subjective judgment involved in assigning the value.
Display the anchored scales prominently on the UI where bugs are entered Anchored scales are only useful if the team can see the descriptions.
On one team, we only displayed values 1 to 5 in a drop down list and asked submitters to remember what each value meant. This wasn’t very effective. People treated each factor as a relative scale and would rate items by ‘feel’ initially instead of referring to the definitions of each value. The end result was that bug ratings were heavily influenced by personal preference.
Instead, build a bug submission UI that lets the submitter read the descriptions as they rate the bug. Radio buttons work wonderfully since you can place all the descriptions right in front of the user. A drop down that contains the descriptions is also feasible.
This may seems like a minor issue, but people are usually in a hurry. If you don’t make the rating process painless, they’ll happily toss random data into your bug database. Improving the clarity of your bug submission UI is the single cheapest thing you can do to improve the quality of your bugs.
Who enters bugs This system is intended to be used by members of the development team. Artists, testers, developers, designers, project managers and producers all should be able to understand the criteria and enter well rated bugs. They'll need an understanding of the core scenarios and the target user. The better that you educate the team on what you are doing and who you are doing it for, the better your bugs will be.
This system does not work well for bug submissions by external users. They don’t understand the terminology and tend to create bugs that are poorly formed. A good solution is for a tester to reenter the user bugs with the proper ratings and format. It is a form of triage, but is a relatively minor cost in the grand scheme of things.
Benefits Using anchored scaled for rating bugs upon submission has the following benefits.
Less reliance on personal opinion: A tester who has some domain knowledge can quickly classify the bug into one of the buckets without relying overly much on their personal opinion. The result is that even when multiple people independently rate the same bug, the final user pain tends to cluster very tightly around the same values.
Harder to game the system: Anchored scales also make it harder to simply ‘bump the pain’ up for a bug that has become a hot topic. Due to the clarity of the rating categories, poorly rated bugs are usually flagged by the next person who looks at them.
Push triage to the submitter: When you can trust the ratings set by bug submitters, you can eliminate a large portion of the triage process. Provided that your submitters have basic domain expertise, 80-90% of the values that they set during the initial submission stay the same throughout the life of the bug. This means that there is less need for reviews to reset random values.
Step 2: Combine those criteria into a single score called user pain Once a bug is ranked on all three factors, you multiply the numbers together to get the User Pain score. User Pain is a single value that can be used to compare widely divergent bugs. User pain deals with the gray area in which most bugs live.
Obvious fixes: A bug that the users hate, blocks major user scenarios and affects everyone causes a big hit to perceived product quality. So it receives a very high pain score.
Hard calls: A bug that occurs all the time, despite the fact that it blocks only minor scenarios, still receives a moderately high score.
Tricky punts: A crash that is never seen by anyone receives a low score.
The basic equation for calculating User Pain is as follows:
User Pain = Type * Likelihood * Priority / Max Possible Score
User pain is auto calculated when the bug is entered and whenever the bug changes. After you calculate user pain for a set of bugs, you’ll find that you have a smooth spectrum of bugs ranked from 1 to 100% Pain.
Benefits
One value for comparing different bugs: Instead of forcing users to juggle multiple different criteria when comparing bugs, they only need to look at one. This means quicker judgments and easier sorting.
Fewer big bug buckets: No longer do you need to deal with huge swathes of undifferentiated bugs. Instead of dealing with 300 priority 2 issues, you typically will see much more manageable clumps of 3 to 5 bugs with the same pain rating. Bug Maturity, as described in the Appendix also helps spread out the bugs.
Step 3: Sort all bugs by User Pain into a public list Once you have your list of bugs complete with user pain, you need to display them to your team in an easy to understand manner. I’ve dabbled with custom queries inside bug tracking tools, but my favorite technique is to create the world’s simplest bug dashboard. The Pain List The Pain List is a webpage that lists all the active bugs in order of User Pain. You put the highest pain bugs at the top of the list and you make each bug a hyper link that takes you to the bug details in your bug database. Be sure to auto reload the list every 10 seconds or so the data is fresh and reliable.
The Pain List becomes your central dashboard for daily bug management. I’ve gone so far as to make it the homepage on my web browser.
Quality bars The team can use the Pain List to set easy-to-understand quality bars as exit criteria for your milestones. For example, they can say “In order to release, we want no bugs greater than 30 pain.” At the 30 pain threshold on the Pain List, you draw a line. Anything above the line needs to be fixed. Anything below the line you can ship with.
Quality bars can be more meaningful than traditional bug counts since you are implicitly taking into account the final user experience. Meeting this bar means that you’ve fixed all crashing and unpleasant bugs and the only issues that are left are minor cosmetic ones that are rarely seen by users.
Since you have a finely incremented spectrum of bugs, you can also precisely adjust quality bars based on your place in the release cycle. You could set a high pain threshold if you are dealing with new features. You can tighten the quality bar further for subsequent releases.
Benefits
One view: One view shared by everyone, including both testers and developers. You don’t have to worry about juggling divergent database queries.
Simple to understand for all parties involved. There are no specialized tools or incomprehensible graphs. Even management can know where you are at just by glancing at the list.
Clear understanding of status: If there are bugs above the quality bar, you need to start fixing bugs.
Step 4: Start fixing the most painful bugs at the top of the list Now that we have the Pain List, we can finally put it to use. Developers check the Pain List daily and fix the highest pain bugs on the list. If there are no bugs left above the current quality bar, they work on feature work. This basic heuristic is a surprisingly efficient method for managing quality.
Assigning bugs All bugs are assigned to Active upon submission, not a particular developer. When a developer sees a high pain bug that they want to work on, they assign it to themselves. The bug then goes through the standard process of being fixed, tested, and closed by the submitter. In general, developers should have no more than a half dozen bugs assigned at once. They pop items off the list, fix them and go back for more. Hoarding is highly discouraged. So is assigning bugs based on feature area.
Fixing bugs before feature work All bugs above the quality bar should be fixed before new feature work is started. If you follow this practice, you should exit each sprint with no more high pain bugs than you entered the sprint. Bug debt doesn’t accumulate.
This practice helps you build quality in as you develop. When this practice is paired with solid automated tests, you enter into a whole new world of high quality development.
My bugs At the top of the Pain List is a section that lists the current user’s assigned bugs. This both helps devs treat the Pain List as their entry into the bug database and it reminds them that they should finish the items on their plate before taking on new work. Since this list is short, it rarely interferes with browsing the Pain List.
Benefits
Developers always know what to fix: All they need to do is look at the top of the list and there is almost always a bug waiting for them to grab. As a result, developers never need to juggle multiple criteria in their head when deciding what to work on next. Nor do they have to wait on leads or managers to assign them bugs.
Promotes shared code ownership: The rule ‘fix from the top’ rarely correspond with ‘fix the code that I developed’. Short term, this is less efficient since developers may need to ask questions of the original developer about an area of the code. Long term, the broad knowledge of the code base that comes from fixing bugs outside area of expertise results in higher overall productivity and team flexibility.
Bugs that prevent you from shipping don't accumulate: The benefits of fixing bugs before features are numerous. The pain of shipping is greatly reduced. Testing is more effective since they don’t need to constantly juggle workarounds to problems that won’t be fixed for months. Finally, the team feels better because they know they are always building a high quality product.
Pitfalls There are a few pitfalls that emerge when you first try to implement a User Pain system.
Training the team There are likely people on your team that have been dealing with bugs for decades. Changing the bug tracking system will require retraining before you see positive results.
In my experience, new teams initially rank 80% of the bugs incorrectly because they A) do not use the rating scale or B) do not understand the target user. To fix this issue, keep making the anchored scales highly visible and keep promoting the major scenarios and target user. After people get the chance to enter a few dozen bugs, their pain ratings will become far more reliable.
The temptation to assign ‘cost’ You’ll notice that there is no place for ‘cost’ or technical risk of fixing a bug anywhere in the pain score. This is one factor that most developers immediately request. Despite the temptation, I recommend leaving it out.
It requires extra effort: 8 times out of 10 the developer actually needs to dig into the code to figure out what is causing the bug before they know how much it will take to fix. If you require ‘cost’ to be figured into the User Pain calculation, you bog down the entire system.
99% of the time it doesn’t matter. The cost of fixing bugs tends to fall on an exponential distribution. Many bugs are one or two line fixes. Others rarely take more than a couple of days. Only a very few are truly killer bugs. Flag the exceptions and use a generic bug velocity to track the rest and your results will be just as predictable as if you had costed each and every bug.
The temptation to automate exceptions The User Pain system is about automating triage. There is a temptation to attempt to automate everything. What about the 1% of the bugs that have the potential to push your release into the next century? When you do stumble upon a bug that will take more than a week to fix, flag it as a ‘killer’ bug. Killer bugs show up in red on the Pain List and an email is sent to the team.
It is now the responsibility of the team leaders to find a solution. They can design around it, postpone it, or even fix it. Now that they’ve been freed of the burden of triage, they have the time to attack the hard problems with great vigor.
The pain score helps keep killer bugs in perspective so that panic is kept to a minimum. There will be Killer issues that are very low pain. It probably isn’t worth delaying the product to fix these. On the other hand, a Killer issue that has high pain is likely to have a serious impact on schedule and should be addressed immediately.
There is a small lesson here. Never build a system, especially one involving people, that aims to handle every exception. You'll destroy what value the process adds by building in all the edge cases. Instead, allow people to raise an alarm so that smart minds can deal with the exception in a timely fashion.
Conclusion User Pain remains simple despite all the detail I’ve tossed your way. The team submits and ranks bugs. The system calculates user pain and pumps out a fresh list of prioritized bugs for everyone to see. The team fixes the bugs from the top of the list. Those are the essentials.
Teams thrive under this bug process. There is less thrashing and ambiguity. There is a lot less need for micromanaging every single little bug (and every single developer). With User Pain, the responsibility for creating a quality product is placed clearly in the hands of the team. They triage the bugs. They fix the most important ones early. The process exists to give them all the tools they need to make the right decisions. Again, it is about empowering people, not managing them.
User Pain doesn’t work for every team. Nor does it completely eliminate triaging. Anyone who thinks process is a panacea hasn’t worked in this industry very long. However, with your heart in the right place, User Pain is a substantial improvement over sitting in a room and manually reviewing hundreds of bugs. It makes the team more efficient, helps people make better decisions and focuses the team on building quality into the product.
Take care, Danc
Appendixes
Bug Maturity Setting quality bar is great for fixing high pain bugs. However, over time you will build up hundreds of older low pain bugs. Since you are triaging less often, the quality of such bugs can be quite low.
You can alleviate this issue is to add a Bug Maturity factor to the pain score. For every day that passes once a bug is entered, you increment its user pain by .2 points. Over time, old bugs slowly rise to the top of the pain list. You can adjust the rate of bug maturation to match the needs of your particular project.
This has two effects
Old bugs are slowly removed from the system: Either you decide to never fix them or you fix them.
Small bugs are fixed slowly: Instead of indefinitely leaving small bugs in your product, you end up fixing them in order to meet your quality bars. This helps prevent the accumulation of code cruft.
Tracking Charts
A basic line chart that tracks the number of bugs above your various quality bars works well for tracking bugs. You can compare this to your total bug count as a reference. The ideal trend is that your high priority bugs drop quickly. Warning signs include the following:
Focusing too much on feature work: The bug count across the board keeps rising.
Poorly directed bug fixing: The overall bug count is dropping, but the high pain bugs stays relatively constant.
Other metrics of interest include:
Total Pain: This represents the accumulated impact on the user of all the bugs in the system. Some teams use this as an additional gate to determine if the product should be released or not. It is another way of ensuring that the team doesn't ship with hundreds of small issues that end up causing the user substantial grief. This value is far more meaningful than bug count, but serves a similar purpose.
Average Pain: You can get a sense of the general instability of your product simply by looking at the Average Pain across all bugs. A high average pain, especially one near your quality bar, means that you have a lot of work left to do.
In every project, there are issues that that frighten the bejesus out of the team. They are so frightening that no one wants to talk about them publicly. The schedule might be impossible. There might be the lurking suspicion that Management does not believe in the project. More commonly, there is a major technical flaw that no one is handling.
Such problems linger over the team. A handful of people hold hushed conversations in hallways or behind closed doors. Secrecy reigns due to fear. There's fear of upsetting team morale. There's fear of losing face with management. There's fear of forcing the project to be killed.
Fear is contagious Team members are not stupid. A good development team works hand in hand with one another 8 hours a day. People observe body language. They take note when conversation stops when someone walks in the room. They become suspicious and wary.
Fear becomes contagious. Lack of information breeds rumor mongering as others step up to fill in the blanks with conjecture, often wild, about imagined consequences. Blame is bandied about as frightened people attempt to find comforting answers to imaginary scenarios. All the while, the problems do not go away. Instead, they fester, turning healthy teams into a paranoid self destructive wrecks.
It doesn't have to be this way. Nine times out of ten, the scary issues that cause so much panic are completely solvable. They simply need the harsh bright light of public acknowledgment shone upon them.
The Scary List Here's a technique that I've used on various agile teams to good effect. Every day, we have our team meeting and on one of the walls is a white board containing the heading 'Scary List'. When someone catches whiff of a problem or rumor that could potentially sink the projects, we jot it on the list.
Sometimes, this is enough. Just publicly acknowledging the issue and giving it a name can clear the air. It becomes okay to talk about it out loud. By naming your problem, it is no longer an amorphous mysterious rumor. Instead the team is faced with a defined problem. The ideas start flowing between team members. People discover the sort of solutions that only appear when everyone puts their heads together. Many times, individuals will quietly grok the issue and adjust course to correct it.
Other times, the problem is pressing and needs to be driven to a conclusion sooner, rather than later. At this point, someone volunteers to drive a solution for it. Every day, at the standup, the champion lets the team know how progress on the problem is coming along. In short order, most problems stop being quite so frightening.
Some problems are extra scary because the team feels like they are out of their control. For example, the team might get axed if some other group fails to deliver a particular component. Have a five minute discussion about what is under your control for a particular issue and what isn't. Again just making the assumptions public does wonders.
Next focus on those issues that you can control. Are there contingencies? Can the team flow like water around immovable obstacles? It's that crazy empowerment thang and it works.
When an issue is no longer scary, remove it from the list. It doesn't need to be complete. It doesn't need to be fully planned out. However, if the team no longer fears the problem, then it should be wiped away and converted into more mundane backlog items or tasks on the board. Otherwise, the list loses its impact. No one likes unnecessary fear mongering, even in the form of a process meant to manage fear.
The scary list is:
Simple: It is a hand written list. It takes five minutes to create and manage.
Public: The list is displayed in a large format in a public area frequented by the team. You can't miss it.
Fresh: Only currently scary items are on the list.
Actionable: You are either turning the scary items into less scary problems or you are removing items from the list.
Courage In the very first Agile book I read, there was a large section on 'Courage'. I must admit that I didn't really understand why it was there. The word 'Courage' seemed like such a fluffy bit of New Age nonsense that didn't belong in the crisp world of software engineering.
The Scary List is a simple technique, but it only works on a team where people have the courage to talk about their fears. You need the right cultural environment for this to occur.
No retribution against the person who brings up a sensitive issue.
The problem, once raised, becomes the team's problem, not an individuals.
The exercise is about solving the problem, not placing blame.
This doesn't happen naturally for most teams. They need to practice. You need to lead by example. If blame starts being thrown about, redirect the conversation to the problem at hand. If people claim that they can't do anything, identify the pieces that they can change. Eventually, people will experience success by using the Scary List. With that success comes the confidence to face the problems that frighten them.
I've been looking at 2D avatars lately. It's been a fascinating trip into a wierd little area of game art that I haven't dabbled in before. Like quite a bit of game art, there is a very obvious craft involved in the creation of 2D avatars. It reminds me a lot of the techniques that went into old school pixel art or tile creation. You build your pieces just so according to a very particular set of rules. Align the hand, align the head and voila, the end result look like a unique character.
I ran across a couple classes of 2D avatars that are worth describing. This list is by no means exhaustive and what you ultimately end up using completely depends on the type of game you are making. The different styles can be classified by:
Perspective: What view is the avatar seen from?
Construction technique: How is the avatar assembled?
Animation: How is the avatar animated?
Perspective Front view: A frontal view of the character. The benefit here is that the character is often symmetrical which reduces the skill needed to draw a character. The downside is that the character is almost always looking straight out at the viewer. May PlanetCute characters are a good example of this perspective.
Partial side view: A partial side view of the character where the character is rotated 45 degrees to the left or right. The example above is such a character. This character can interact with objects in the environment, but with subtle (and cheap!) animation of the eyes, look at the viewer. You can make avatars with this perpective move left, right in a believable fashion by simply flipping the avatar. Climbing ladders is less than compelling. :-)
4 (or 8) directions: For each of the cardinal directions you draw a new version of the avatar. The characters in Diablo are a nice example of this style. Having multiple directions is more realistic and allows you to show the general direction that a character is pointing. However, it is again more expensive. If you have an interchangable item on the character, you need to draw 3 different versions for 4 directions and 5 different versions for 8 directions. This multiplies your art expenses.
Isometric: This is similar the partial side view, but usually seen a bit more from the top. This is almost always done with multiple directions.
Construction
Interchangable parts: Most avatars are made out of interchangeable parts. You can swap out a shirt for another shirt. This allows for a vast range of different characters, but They all tend to be built from the same basic mold. Luckily, so does most of humanity, so this system tends to work well for humans.
One piece: Whirled and most single player games uses characters that do not have interchangable parts. All the animation is built into the character. The upside is that you can have great unique animations that really fit the character. Your dragon can breath fire and your balloon beast can float merrily along. The downside is that you need to make unique animations. This is expensive.
Animation
No animation: This is the simplest and is quite common with web-based games. If you can get away with it do so!
Cell animation: The whole avatar or the pieces of the avatar are animated by flipping through a series of frames. This tends to be a specialized skill and good 2D animators are hard to come by. Cell animation is highly evocative and has been the animation technique of choice for ages. The downside is that if you are using interchangeable parts, each part needs to be animated through all the possible animations. This means that the number of animations that your avatar supports is likely to be small since you don't want to bloat the cost of creating each item.
Vector animation: Each piece of the avatar is mapped onto a simple 2D vector rectangle that can be smoothly rotated, scaled and squashed. Add a simple skeletal animation system (the foot bone is connected to the leg bone which is connected to the hip bone) and you can do some reasonable effective animation. The characters in Book Worm Adventures are a great example of this style. If done correctly, this method lets you animate just the base skeleton and swap in parts as desired. The upside is that you can have a huge range of animations with the same basic art assets.
Little lessons learned
Optimize for ease of object creation, not richness of animation or immersiveness: If you are going for virtual item sales, your incremental profits can be broken down to # of items sold * price of items - production cost. You want lots of item variety and you want to keep your item cost down.
With this in mind, the format of your avatar begins to matter a lot. Animation is expensive and makes object creation even more expensive. Multiple directions for your avatar are cool, but are they really worth increasing your content costs by 500%? Most items are made out of at least two pieces, not one: When you build hair for a character, you have a section of hair that goes behind the avatar's head and a section that goes in front. I've been sketching it all out as a single piece and then chopping it up as needed during the cleanup stage.
Use flat shading or indistinct light sources if you are using vector animation: Since your pieces can be rotated in all sorts of directions, highlights will often look strange when rotated. The number of slots in your avatar represent sales opportunities: A character composed of a head and torso presents very little opportunity for players to customize their look and feel. After purchasing a couple of items, they are done. By allowing for tiaras, jewelry, wings, thought bubbles and other items, you win by creating additional sales opportunities. The player wins by having more ways of making their character unique. Style matters: I dress like the guy in The Fly. My closets is filled with row upon row of identical pragmatic clothes. I wouldn't know the difference between a cardigan and a camisole if my life depended on it (I actually had to look it up.)
Yet many avatars, especially those in online games, are ultimately about fashion and style. The cut of the fabric is important. The patterns matter. The colors...don't even get me started on the colors. It is no surprise that some online game companies (like StarDolls) build up such an expertise in fashion that they are launching their own real world clothing lines. So I've been reading women's fashion mags. It's a whole different world out there.
Next Steps I'll continue dabbling with these sketches. My character drawing skills are not the best, so at the very least this will be good practice.
Which style should I use? I'm leaning towards a side-view avatar with interchangeable parts that uses simple vector animation. The cost of production is low and the style seems to be the best fit for some of the game design ideas I've been mulling over. The current template has spots for custom headgear, a head, eyes, mouth, nose, top, bottom, feet and items held in left or right hand.
Here is one last sketch. Comments and critiques are welcome!
Gamasutra posted up an article that has been bouncing around in my documents folder for a little while. The original title was "A Services Strategy for Casual Games", but the new one is a bit more punchy.
One response that I've heard quite a bit is that portals will never allow user data to be released back to developers. This is quite true for most established portals that have traditionally focused on selling packaged goods online. However, middlemen adapt and markets flow around stupidity. More sophisticated variations on sites like http://www.mmoportal.com/ are bound to emerge. If a dozen portals don't want your business, find the one that does. Given time and a exclusive supply of successful games, they'll grow into a bigger fish that can help feed your team.
The portals are engaging in a kneejerk reaction to changing business models. In the long run, do they really think they can keep customer data away from developers when the games that players want are online services? Such companies just end up being a roadbump in the way of progress. A portal that gets irritable about giving up customer data guarantees that their cut of the pie is zero. This is their loss, not yours.
Online games have become an international business. In order to compete in the global marketplace, your game needs to appeal to players in countries ranging from America to Japan to China to Poland. None of these cultures speak the same languages, have the same cultural values or even celebrate the same holidays. If you are starting an online game company it is wise to starting contemplating the monumental task of localizing your service as early as possible.
There are two truths about localization for online games. One, it can dramatically multiply the number of customers that you reach. Two, it is more trouble than you might imagine. In this essay I look at how we might use we use techniques from game design to streamline this exciting, yet expensive opportunity.
The good and the badThe majority of players populating online games like Legend of Sherwood, Travian or World of Warcraft are from outside the United States. We have a solid 300 million potential customers, but the rest of the world has billions. After the core game is complete, localization can help you double or quadrupal your install base for a cost far lower than developing the game afresh. This is highly attractive to those folks with dollar signs for eyeballs.
Yet localization and globalization ends up being far more than a onetime cost for translating a few text strings. Popular games pump out an ongoing stream of new content that must be rolled out across multiple languages. The original team likely doesn’t even speak the language of the targeted countries so quality control is a huge issue. Even worse, most teams have little experience with the culture of the new country they are targeting. An expansion pack that celebrates Christmas as a family event may not translate well to your Japanese users who traditionally see Christmas as a holiday for lovers.
Larger companies end up creating comprehensive localization and globalization groups that can act as a giant drag on the software development process. Localization often ends up in its own silo with radically different organization and values than the main development team.
Help (for hire) Whenever there is a difficult problem that falls outside the core competency of a game development team, outside companies will emerge to help them solve the problem. For a fee, of course.
At the most basic end of the spectrum are translation services. These take your table of text strings and translate them into a variety of languages. Quality varies dramatically and there is typically the need to re-edit the text afterwards. Many companies start by just translating their strings and then realize that bringing their games to other countries is far more complex than a simple data manipulation problem.
At the other end of the spectrum is the full service operator. An operator is a company that takes an existing game, typically from a traditionally inward looking market like Korea or China, and runs a localized version of that game in another country such as Japan or the United States. Depending on the company, the operator will handle everything from localization, to handling foreign currency, to running foreign language support. Many will run the local servers for your game. OutSpark is a good example of an operator.
Rolling your own? Every time you deal with middlemen, even ones as innocuous as a translation service, you need to ask the question: What is the opportunity cost of rolling my own?
On one end of the equation are the operators that will take a percentage of your revenue for the lifetime of the game in return for expanding your market substantially. Woot, “free” money.
On the other end of the equation is a custom solution. If you can reduce costs, you might come out ahead. But what if it dilutes your focus as a company? What if you end up missing out on the economies of scale and experience that come from being a company focused solely on localization?
This decision is particularly tricky since middlemen make it their business to provide you with a very clear value proposition when you are examining their services. There is rarely anyone who can put hard figures on the benefits of rolling your own. The easy solution often becomes the outsourced solution promoted by the smiling salesman.
So this got me thinking: What would it take to roll your own localization service for an online game?
Constraints There are some constraints to this little thought experiment:
Inexpensive: The solution needs to cheaper than going with an outsourced group.
Leverages game development skills: Ideally we can leverage our core skills as a game development company. This means using game design to solve our problems, not hiring a mass of translators.
Doesn’t rely on building up services that other people could do better: We need to be wary about spreading the company too thin by turning into an operator in our own right. Though there may be some benefits from vertical integration, internally replicating systems that are already run efficiently by third parties is something to be approached with great care and a skeptical eye.
Research clues At GDC, I ran across two clues that point to a solution.
Leverage the community: I caught some offhand comments from the fine folks over at Three Rings about alternative ways of leveraging the community in order to avoid entering into partnerships with operators. What they’ll end up doing, I have no idea. Still the seed was planted in my little monkey brain.
Wikipedia as a game: Elonka Dunin gave a lovely talk on how Wikipedia can be viewed like a giant MMO. The mechanics happen to focus on user generated articles instead of killing monsters, but the fundamental rewards for writing articles is fundamentally game-like. The pertinent detail here is that Wikipedia users also translate articles on a regular basis. Wikipedia is one of the most comprehensively localized websites in the entire world and all of it is due to the user’s efforts.
User generated translation driven by game mechanics Let’s build a game that rewards multi-lingual players for localizing the text in our product. We’ve got all the necessary ingredients in your typical game:
Passionate players who speak a variety of different languages
In game reward systems that have already proven attractive to the player.
A mediated environment that allows us to pose tasks and record the results.
Instead of hiring expensive middlemen, we harness the volunteer efforts of our passionate players. Instead of managing the process manually, we create an automated system of empowering tools and reward systems that encourage players to do the right thing. Above all, we make the process repeatable so that we can run it over and over again at almost zero incremental cost. We are building an engine whose mechanical structure is derived from the physics of human psychology and whose brightly burning fuel is a steady stream of fun seeking players.
The reviewer pattern Here’s a basic structure of our translation game.
Identify: Identify players with base level skills are capable of performing a desired task.
Action: The players perform actions using in-game tools in the hope of receiving a reward.
Review: The game independently verifies the actions using other players for tasks that require human computation.
Reward: The game rewards the person performing the original action based off the verification process.
Repeat: High scoring people get more tasks of that type and greater rewards. Low scoring people get fewer tasks of that type.
This reviewer pattern is quite flexible and can be used for wide variety of tasks that are much broader than mere translation. It is particularly useful when you need to judge the quality of your player’s efforts and “quality” is determined by strong aesthetic or cultural factors. Language is an obvious example of this, but art, fashion, moral judgment and other classic human endeavors fall under this umbrella as well.
Let’s apply the pattern to the process of translating text.
1. Identifying players with the right skills Our imaginary game has persistent characters with extensive profiles. People can declare their real world skills including which languages they seek. Let’s say for a moment that we want to translate between English and Japanese. We would search the profiles of our thousands of users and find ones where players claimed proficiency in both languages. These users are tagged as potential translators.
2. Performing the task The next time the player approaches a quest giver, the game substitutes a translation quest for their typical “Kill 5 rats” quest. There are numerous framing stories one could use ranging from the scholar seeking to translate a mysterious scroll to a warlord needing an intercepted spy message translated so they can prevent an attack.
Promise of a reward: The player is told that if they complete the task they’ll get a certain amount of gold. If they complete the task well, they’ll be inducted into the secret Guild of Translators.
Task specific tools: If the player accepts the task they are presented with a screen that shows them the original text and a space where they can translate it into Japanese. They type in a translation, hit submit and get the basic translation rate. They are informed that qualified reviewers will be looking at their translation and we’ll let them know if they make it into the secret Guild.
On the backend, every text string of every object can be pulled from a set of string tables that have slots for all supported languages. You need a system that supports multi-byte characters, various text orientations, IME input and all the rest of the glorious minutia that goes into localizing simple strings.
To generate the quest, we look at popular items that aren’t translated into languages for which we have translators available. A few strings, such as the name or the description are bundled up and given to the player as the source material they need to translate.
3. Review the results The vast majority of translations will be of poor quality. This is the reality of free labor done as an idle hobby. We want to separate the truly talented reviewers from the masses so that we can ultimately put them on a pedestal as an example for everyone to strive towards. In the process of tagging our translators, we also tagged people who spoke Japanese.
Again, we give these tagged users quests. This time they need to read the text and rate it quality on a 7 point scale. There is also a small text field where they can type in comments. They are also told that they’ll get a bit of money for doing the task, but they’ll get even more money if they do it well.
Unbeknownst to the individual reviewer, we also give the same text to 10 others to review. We collect all the scores, lop off any outliers and calculate the average score. This is the rating for the translated text.
Translations that get ratings above a certain threshold (such a 6 out of 7), are automatically published to the world at large.
4. Reward the translators and reviewers Translator rewards: Once the final score for the translation is determined, the original translator receives a message that contains a quality reward. If they scored 6’s and 7’s, they get huge rewards and are inducted into the Guild of Translators. They get a special cloak, and are promised future awards if they continue to do such a wonderful job translating. If they score lower, they get lesser rewards and may not be invested into the Guild. They are given a second chance as well as access to the comments that were left by the reviewers.
Reviewer rewards: We also reward reviewers based off the quality of their reviews. Those players scoring closest to the average score get mega points and an increase in their reviewer level. Those players that scored furthest from the average get no points and their reviewer level can even drop. Over time, competent reviewers whose opinions reflect the majority should rise to the top. When we calculate average scores for a particular bit of text, we can use weighted averages that take into account the level of the reviewers involved.
5. Repeat the process Whenever text is added to the system, the translation system jumps to action. Translation quests are generated, translators translate them and reviewers review the results. Over time the text of the game is slowly but surely translated into other languages, driven by the demand and passion of the users.
The system is built to constantly improve the results. The highly rated translators and reviewers are showered with in game gifts and rewards. They gain levels, get new outfits and are given kudos by NPCs. We feed them stats on how many people use their translations and look for ways to promote their efforts to the larger community. Each of these rewards is automated and repeatable. In return for these social glories, the system gives highly rated translators more translation tasks. We want the best of the best handling most of the translation. As time passes, many users will try translation and find that it isn’t for them. That’s alright as long as there is a core group of people that latch onto the job and make it into a fundamental part of their online identity. The system is built to support this natural winnowing process in order to build up an elite core. A dozen or so passionate users can translate hundreds, even thousands of pieces of text in relatively short order.
Popular pieces of text with lower scores are resubmitted to elite translators for another pass. As time goes on, the quality of the translations throughout the game continues to improve.
Benefits This is a complex system, but it comes with some intriguing benefits.
Focus on core competency of game design: It is a reasonable amount of work building this localization system, but it leaves your company with a very solid reward system that can be leveraged for other areas of the game. You are investing in game design and player entertainment, both of which are core competencies for any game company.
Serve smaller cultures at low cost: There exist numerous cultures in the world that speak languages other than English, French, German, Spanish, Chinese or Japanese. Dozens of nations like Poland or Brazil can contribute hundreds of thousands of users to your game. By allowing players to translate the game into their own language, you can reach these niche cultures at a very low cost.
Adapt your text to each culture: Many concepts don’t translate well between cultures. By having the users perform the translation, they will often smooth over rough edges. If a particular joke or phrase doesn’t work, users will reword it to something that fits their culture. Often, users will take liberties and incorporate references to their own mythology or culture into the translations. It is an interesting trade off. You give up a small amount of authorial control in return for a translation that seems as if it was written by native speakers.
Highly scalable: Once a community of translators is in place you can release content in one language and watch it quickly and cost effectively be translated into other languages. The cost of localizing an additional piece of content goes to almost zero.
Limitations This system is not without some pretty serious limitations.
Requires a large number of people: To get to those few dozen people who are interested in translating your game, you’ll need a population of thousands, perhaps hundreds of thousands. Only a very small number of people will be interested in playing your translation game.
High startup cost: You need to develop and balance this system. That is expensive and will likely require dozens of iterations on the design.
Questionable translation quality: There is a very good chance that the majority of your early translations are incorrect, confusing or insulting. You won’t be able to tell since you don’t speak the target language. This means that when the system isn’t balanced just right, your users may have bad experiences. Also, as mentioned above, you are giving up a certain amount of authorial control. Your epic bodice ripper about the Monks of Ra may turn into a joke gag about Swedish meatballs. C’est la vie.
The process moves at the pace of the players: If the players don’t find translation quests interesting or there aren’t many multi-lingual people on your service, translation will lag.
Other pieces As stated earlier translating text strings is only a piece of the puzzle. To solve the whole puzzle, we can repurpose some of the systems that we created for the tranlation game.
Pieces to own: These are items that you should try to maintain control over.
Culture specific events: Combining the review system with tools that let users create their own events is one way to go. This moves you down the path of user generated content, which is a giant can of worms, but again has substantial benefits if you can pull it off. This would likely follow the same review pattern we saw with translation, except instead of translating text, you are asked to build something grand.
Culture specific support: Griefing, bugs, currency issues are all best dealt with by a support team that speaks the player’s native language. There has already been some solid work done with volunteer judges and moderators and it makes a lot of sense to invest in this further in the future. Giving player judges the ability to review past grievances, render judgment and then have their judgment reviewed by a jury of randomly selected peers is an obvious profession worth creating. It would likely appeal to a substantial minority of the player population since it involves direct power over others. Again, problem tickets are handled as quests and we slowly give people more power based on the quality of their previous efforts.
Pieces to outsource: Some things like payment systems and local servers, you’ll likely have to outsource to middlemen. Yet out of all the middlemen activities offered by operators, I’m most willing to let them take on these two. Why? Because they both becoming more commoditized by the year. Costs of running servers all around the world are going down, while reliability is going up. As cloud computing and virtualization become more dominant, the last place you want to be investing your valuable cash is in replicating the core business of the likes of Amazon, Microsoft, Google, Sun and a half dozen other future cloud computing behemoths.
There’s a rule of thumb here. Let the middlemen handle the commoditized plumbing, but don’t let them near your customer relationships. Your community and your addicting game design is your unique competitive advantage.
Conclusion Ultimately, building something like a translation game for your service is a business decision. I believe that you should treat the decision to create a utilitarian social game system in a similar fashion to how you would treat the decision to make a capital investment in your company. It resembles a classic business problem: choose the proper mix of the following:
High variable costs with low capital investment: You rely heavily on manual labor to make each widget. You don’t have much in the way of equipment so it costs you an arm and a leg to build each widget.
Lower variable cost with high capital investment: Alternatively, you can invest in capital expenditures like beefy factory equipment. Capital investments cost a lot of money upfront. However, longer term, they can dramatically reduce your variable costs.
Building systems such as our translation game are remarkably similar to capital investments from the ancient age of manufacturing. They are expensive to develop and balance. They have a significant maintenance cost. Yet, they dramatically reduce the costs of servicing another customer in a foreign country. Instead of paying 30 to 60% of a customer’s revenue to a middleman, you instead end up paying a few pennies for bandwidth.
In the case of a game development company, the building of the equipment that reduces your costs also happens to be your core competency. You are good at manipulating players to volunteer their time and energy to complete obscure tasks. You are good at building enjoyable software and task oriented tools that facilitate the creation of these tasks. It is time to put these assets to work.
So what happens when you use game design to improve the way your run your business? The future online game is a complex digital factory filled with powerful social engines that chug and churn throughout the night. The workers funnel in one end, and out the other comes the high quality fruits of their carefully guided labor. This is no dystopia. The workers are volunteers and the factory is a playground. If they become bored, the players leave. But most do not, for the machine knows too well to their subtle human weaknesses. And, you, the builder of the great machines that measure and prod and coddle humanity in endless loop upon loop, sleep soundly as the money rolls on in.
The Randomly Reinforced Lost Garden Prototyping Awards
What a whirlwind of a month it has been. GDC was crazy fun, the latest beta of Expression Design came out at MIX, and I decided to take a leap and start in a new position at work. In the meantime, some great games were created in the last prototyping challenge.
Let's reward awesome developers You know what? I think it is time for an award ceremony. I've been meaning to do this for a while, but never got around to it with the previous prototyping challenges. Here are the awards and how they are handed out:
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.
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. This is a geeky challenge done for lurve of the game.
The Results In my mind, the entire point of the Player with Your Peas exercise was to take a complex design with some potentially messy rat holes (user created levels, physics, path finding, oh my!) and see if you could quickly find the fun. Let's see how folks did:
Bronze Medals
All the prototypes were enjoyable for a couple of core reasons. First, building a world out of little blocks seems to be pleasant at a very simple level. Second, for those who implemented pathfinding, there is something inherently interesting about watching little creatures navigate your world on their own.
Richard Sims' prototype came closest to capturing the fun. He focused on the falling peas portion of the design and managed to add in a solid pass at the combo scoring system. This moved his prototype beyond being merely an intriguing software toy to the point where one could imagine there being a real game. I played with it for more than five minutes.
Some lessons from Richard's prototype that are worth noting:
Focus on prototyping the important gameplay, not the tech: What was nice about Richard's prototype is that he skimped on much of the climbing and jumping portions of the design. Those weren't key to the 'fun' of the design so they could be done later. Knowing what to test first out of your usually exhaustive brainstorming session is a great skill to hone. Just because something is hard (like the pea pathfinding) doesn't mean it is the first thing to tackle.
Answer at least Three Why's: Richard's game links together several game atoms together in a sequence. Simple actions have meaning within the game. Most of the other prototypes only had isolated game atoms. There was very little reason for doing things. Here's a little description of the Three Why's that illustrate how they are used:
Action: First ask"What is your player's core action?" In this case, it is building blocks.
Why? Now ask "Why?" The answer is to give something for the peas to bounce against.
Why? Ask "Why?" again. The answer is because the peas generate combo points if they hits lots of blocks.
Why? Ask "Why should I care?" once more. Because combo points increase your main score and you need to get as big of a score as possible.
Good enough! At this point, the player who is clicking to add blocks probably has lost interest in asking why he should be building blocks. There are enough overlapping reasons that the justification circuitry in his brain is satiated. He'll keep building blocks until all the subsequent game atoms are exhausted.
Gold Medals
No one captured the Gold Medal on this challenge! Doh. This award remains wide open until someone submits an amazing prototype with 15 solid minutes of play. Hmm...I wonder who can make a Gold Medal version of Play with Your Peas... There were several others folks that worked on the game, but I didn't have public links to all the playable versions. If you have some more, send them my way (danc [at] lostgarden [dot] com) and I'll add them to this post. Yes, Harold, I'm looking at you.
Woot! That was fun. Now I feel like Jon Stewart. Except less witty. Or famous. Danc.
I'll be off at GDC in San Francisco all next week. It is always fun to meet up with folks that stop by the blog, so if you want to chat I'll be at the blogger meet up on Wednesday near the IDGA booth. If that doesn't work,send me a note at danc [at] lostgarden [dot] com and we'll figure something out. It should be a great week.
It is easy to forget, in the rush of learning the newest lessons about games, that a lot of wonderful thought has already passed through the hallowed halls of GDC. As an ode to what we've learned so far, I wanted to share with you an excerpt from a talk that Dani Bunten Berry gave over a decade ago. She was one of the early champions of multiplayer digital game design. Her list is still pure gold.
Good Multi-player Design Elements by Dani Bunten Berry, Copyright 1997
"Here comes my annual punch list of things to consider when designing multi-player games updated and expanded from last year based on what we've learned:
Build in the "Norm Effect" if at all possible. This is named for the character from "Cheers" who when he enters the bar is greeted by everyone calling his name in unison. Pitiful old IRC chat-rooms can provide some of this effect so surely we can find some way to welcome people into our game environments.
"Zero sum" is bad. Games where I win and you lose are bad. Worse still is "I win and all the rest of you lose". Notwithstanding the current cultural obsession with endzone strutting by winners, losers do not enjoy themselves and if you can help take the sting out of it, you should. Alliances, cooperative play, ranked "winners" rather than "A winner" with a bunch of losers are all options.
Pacing needs variety. Slow periods should follow intense ones and forced "time-outs" can offer opportunities to socialize, catch your breath and anticipate things to come. Remember, the players no longer have a "pause key" as they did in a solo-game.
Strategies need "wiggle room". People have different personal styles and when playing against each other it's great to let them "do it their own way" rather than a single approach that all must follow. If possible you should balance the game such that a strategic planner for instance might not always beat the joystick jockey or the detailed tactical type. A game that allows for diverse people to play diverse ways is always best.
Legends must grow. Provide ways for players to carry their experiences with them. "Game films" are an excellent (and reasonably cost-effective option) in games where what's sent between the player's computers is a stream of "deltas". Saving that stream and running it back through the game engine provides an opportunity to review what happened during the game. This turns an ephemeral, fast paced experience into a story that can be used to "save face" if the player lost, to learn how to win or just to chronicle their accomplishments. At the very least, try to include ongoing statistics or character attributes outside the environment of a single game execution.
Court your newbies. Nothing will destroy a player's interest in your game quicker than being humiliated a few times when they are just trying to figure out what to do. If possible build in inducements for advanced players to help newbies in order to get something to advance further in the game environment -- like taking an "apprentice" might be the only path to "master rank". At the very least try to make starting as safe on player's egos as you can.
Allow personalization. Let players define their own icons that the others see or somehow personalize their own game space. A big part of the enjoyment of being with others is expressing yourself. A bunch of player avatars all dressed from the same menu gives me the creeps. Encourage graffiti.
Keep the features down. When humans play each other there's this "he thinks that I think that he thinks …" kind of mental gymnastics taking place. This is far more interesting than another unit type or another option to evaluate to almost everyone.
Include audio/visual subtleties. People are remarkably good at recognizing patterns almost subconsciously and they also find it rewarding. A couple of pixels blinking in the corner of the screen and a small sound effect that allude to a possibility allows a player to feel very astute when they can put it together with an outcome. This can also facilitate the personal playing style mentioned above since some folks are better at it than others.
Avoid numbers. Almost no one enjoys calculations. (At least no one "normal"). Humans prefer heuristic (rules of thumb) relationships or continuous equations far more. The heuristics feel good when you figure them out and the continuous equations can only be predicted which also seems to scratch an itch in our brains.
Include spectators. Leave room for "lurkers" to watch games being played and even to effect them in minor ways if possible. A design that includes taking turns, which makes the other players spectators for part of the time, can be interesting if what the player is doing has an effect on them, is interesting to watch and they can tease, taunt and kibitz while watching.
Facilitate relationships. Allow players to form clubs, clans, groups and facilitate scheduled as well impromptu meetings online. Help strangers mix and friends find each other.
Use time limits. Whenever possible design your game so it can be played within a fixed time limit. This will allow people to schedule their involvement. A game you can play a couple of times in an evening would be a good design goal. If you can't end the game at specific times try to at least facilitate a graceful exit opportunity such that a player quits while they are having fun and not after they're so exhausted they'll never come back again.
Include chance. Although most players hate the idea of random events that will destroy their nice safe predictable strategies, nothing keeps a game alive like a wrench in the works. Do not allow players to decide this issue. They don't know it but we're offering them an excuse for when they lose ("It was that damn random event that did me in!") and an opportunity to "beat the odds" when they win.
Keep the balance. Try to keep the distance between the losers and the winners small enough that the outcome is in doubt as long as possible. You can adjust random events, attrition factors or whatever. They'll thank you for keeping the games interesting even though you should probably not tell them what you're doing.
Include cooperation. Even in basically competitive games you can allow for alliances, collusion or at least less cutthroat behavior. In M.U.L.E. I used an interesting trick that would not allow a "Winner" unless a certain threshold of colony success was reached. In order to win players had to sometimes help each other out so the whole colony would thrive thus making the balance closer and play more interesting.
Make 'em stay. Figure out incentives to keep players to stay till the end of a game. It ruins everyone's fun when players bail out prematurely. At the very least you can publish the percent of the time they bailed.
Allow handicapping. Let players handicap themselves if they want. Some players are willing to play with one hand behind their back so let them. (The most common use of this will be parents and kids playing together).
Facilitate special events. "Magical appearances" (scheduled and otherwise) in FRPs are cool. Strategy game tournaments (sanctioned and not) are too.
Leave room for ads. Banners will be around for a while. You might even want to let Nike outfit your monsters with shoes - for a price. Be creative."
Oh la la! It is time for another game prototyping challenge. As has become the tradition around here, you provide the brilliant code and I provide you with a complete set of free graphics that help make you look spiffy.
This game design stems from a peculiar fetish of mine. I don't normally talk about this in public, but...how to say this. I have a thing for casual building games filled with adorable little creatures. Late at night, when the rest of the world is busy sleeping, you'll find me fantasizing about the lurid offspring of Lemmings and SimGolf. For a moment, close your eyes and savor the sweet thought of DMA's DNA all mixed up with Will and Sid's unappreciated love child. Oh yes.
The game idea inspired by these questionable thoughts is called Play With Your Peas. Here are the basics:
Peas: You have a bunch of fun loving sentient peas that like to climb tall objects and jump off of them. They think they are ninjas. You know they are suicidal.
Happy points: If the peas land safely, they generate happy points. The more things that they bounce off of on the way down, the more points you get. Think of a successful pea landing like scoring a combo in Tony Hawk.
What you do: Here's the trick. You can't manipulate the peas. You can only add blocks to the landscape. Add a soft landing spot and your falling peas won't splat. Add a spring in the right spot and they'll fly up into the air. Can you build a brilliant playground that delights your peas?
Score: Your score is the time it takes you to reach 20 million points. If you want to simply play with your peas, go for it. If you want to beat the high scores, you must be Elite and build your landscape with great efficiency so that you maximize your pea combos.
Many thanks to Axcho for dredging up this ancient design from the dusty storage shed of my past.
Game Tokens There are only a few types of elements on the screen
Peas: Little AI characters that run around the environment. You can't interact with them directly.
Plate: All action takes place in a box that bounds the sides and bottoms of the screen. No objects can exist outside of the screen.
Blocks: The user can place blocks on the screen. There are multiple types of blocks such as platforms, springs, jello and more.
Flags: These mark the spots where peas have lept from in the past.
Tools: A sidebar of tools that lets you choose the type of block to place.
Happy Score: A counter that tells you how many happy points you've collected so far.
Time: A counter that tells you how much time has elapsed since the beginning of the level.
Basic Pea AI Peas have three main modes:
Navigating the environment: In its primary mode, the pea navigates the environment in an attempt to reach a jumping spot.
Falling: When a pea is falling, it is treated like a simple bouncy ball interacting with the world.
Being scored: Once a falling pea comes to a rest, it is scored.
Navigating the environment The peas traverse the environment in search of ledges to jump off. This is the hard part of building this particular game design. I'll describe the high level behavior, but I leave the implementation as an exercise for the mad programmers of the world.
Look for a ledge: After a pea is scored, it immediately looks for a nearby ledge to jump from.
Wander: If there is no ledge nearby, the peas wanders in a particular direction, slowly climbing over obstacles and working its way up as high as possible.
Calculate path to ledge: When it finds the ledge, it calculates a rapid path to the ledge.
Moving smoothly across a complex environment can be broken down into a series of movement segments.
Walk on a flat surface:
Climb a block wall: Some blocks can be climbed, others cannot.
Climb up a ramp: Some ramps can be climbed.
Jump a gap: If there is a 1 square gap, a pea can jump over it. Remember they think they are ninjas.
Wall jump: Peas can also jump onto a wall that is 1 square above their head to the left or the right. Think of this like moving how a knight in chess moves.
Jumping spots. A block surrounded by space has two default jumping spots, one on the left side and one on the right side. Once a pea reaches a jumping spot, he will jump. A couple things happen at this point.
A flag is automatically planted at the jumping spot.
The pea jumps and his AI switches from navigating the landscape to being a simple bouncing ball.
The flag tracks several things
How many peas have jumped from the jumping spot. As the number gets closer to 100%, the flag slowly rises to the top of the pole.
If a peas spots multiple jumping spots, they will always head towards the jumping spot that has the highest completion percentage. This ensures that the user is focusing on one or two jumping spots, not a half dozen.
When the flag reaches 100%, the jumping spot becomes inactive and no other peas can jump from this location. The user gets a large bonus for having a completed jumping point.
Peas remember which jumping spots they've jumped from and will not jump from that point again.
The flag also serves an important balancing role. Once a flag is planted, several building limitations come into play.
The user cannot place another block on the square occupied by the flag.
The user cannot remove the block under the flag.
These rules prevent the user from recycling jumping locations and they also slowly eat up the space on the board so that the user needs to work around the detritus of their previous efforts.
Bouncing When your pea falls, it bounces off of blocks that get in its way. Some blocks, such as gelatin, slow you down. Others, like springs, give you an additional boost. However, your pea is not indestructible.
If you land on a standard block after falling a distance more than two blocks, you pea will die. A dead pea means less opportunity to score.
The skill of the game is building environments that yield the maximum number of bounces while still managing to land your peas safely in the end.
It is possible for the player to create cul-de-sacs where the pea will bounce indefinitely. One potential balancing feature is to add in a counter that keeps track of how many times specific blocks have been hit. If the hit count on single block gets too high, the pea yells out 'It's a trap!' Even if a trapped pea is released, you get no points.
Scoring When a peas finally comes to a stop and it survives it's journey, it gets a happy score.
Happy score = Total bounces * (Spring Bounces * Spring Value + Normal Bounces * Normal value + Gel bounces * Gel Value + Successful Landing)
The pea's happy score is added to the player's total score. This is a moment of grand celebration. If you have a particle system, this is a great time to use it. I've provided graphics so that a happy pea can yell out "Ninja!", his career aspirations finally complete. Once the peas is scored, he moves on and starts looking for a new jumping spot to leap from.
Building blocks Okay! Now we have some cute little characters that jump about the screen in some logical manner. Finally, it is time to talk about building your world.
Along the left side of the screen is a toolbox that contains the blocks you can use in the level. To select a block, click on it and it will highlight.
To place the block, click on an empty square. The blocks aren't added immediately since they have a build sequence they must follow.
Initial delay: We want to prevent users from micromanaging the flow of their peas by quickly placing blocks. In order to do this, blocks stay ghosted for a short period of time before they fade into solidity.
Check for peas in the square: While the block is ghosted, any peas that are in the space can move out of the square without colliding with the new block. This helps us avoid accidentally squishing peas.
Block peas moving into the square: New peas that try to move into the square are collided with using the collision rules associated with that block type.
You can place other blocks while a block is in the process of being built.
Deleting blocks You can remove blocks as well.
First click on the delete tool.
Your cursor will turn into the red delete cursor. Feel the power!
Click on the block you wish to delete. As you mouse over the block
The block will become ghosted. There is a short delay before the block is removed.
After the delay is over, the block finally fades away. During the exit animation, peas will pass through the block as if it isn't there.
You can delete other blocks while a block is in the process of being deleted.
Remember, you can't delete a block that has a flag attached.
Standard Blocks
Climbing: Peas can climb the sides of the block.
Walking: Peas move across the surface of the block at full speed.
Collision with top: Falling peas stop when they land on the top of the block. If the fall is greater than 2 blocks in height, the pea dies.
Collision with side: Falling peas bounce off the side
Spring Blocks
Climbing: Peas can't climb the sides of the block.
Walking: Peas move across the surface of the block at full speed.
Collision with top: Falling peas are launched upward with greater velocity if they fall on the top of the block. Angle of incidence equals angle of reflection.
Collision with side: Falling peas bounce off the side
Gelatin Blocks
Climbing: Peas can't climb the sides of the block.
Walking: Peas move across the surface of gelatin at 1/2 speed.
Collision with top: Falling peas stop when they land on the top of the block. Gelatin provides a safe landing spot for high jumpers.
Collision with side: Falling peas bounce off the side
Ramp Blocks
Climbing: Peas can climb the backside of the ramp.
Walking: Peas climb up or down the ramp at full speed.
Collision with top: Falling peas bounce off the sides of the ramp at an angle and lose a little velocity. If they hit the ramp from a height larger than 3 blocks, they die.
Collision with side: Falling peas bounce off the side
Winning In order to win a Play With Your Peas session, you need to complete certain goals on a level, much like Tony Hawk. The simplest is "Reach X number of points". Your final score is the time that it takes you to reach the goal. A new player might take 10 minutes to reach 10,000,000 points. An expert player, skilled in crazy combos, might take 2 minutes.
My hope is that casual players will have fun figuring out the system, setting up interesting combos. They'll generally ignore the clock. Eventually, they'll reach the goal and feel good about 'beating the game'. Their score is then compared against a number of other times in a high score list.
More driven players will feel a natural urge to compete by replaying the level for a better time. To facilitate this, we should have "Try Again" button on the high score screen.
Areas to prototype Even though this design has a relatively small number of moving parts, the emergent behavior should be complex. There are three distinct areas that well are worth prototyping. I've listed them in order of priority.
Pea falling physics: In order to do the pea falling correctly, you need a simple physics engine that deals with balls and planes.
Block and scoring balancing: Balancing the size, properties and scoring of each block is a classic balancing problem. This is an area that will likely take hours to get right.
Pea navigation: If you can get peas traversing a series of blocks in a smooth and believable fashion, you are halfway through the design. This involves some tricky path finding. If you want to stub this behavior out, spawn peas at a jumping flag and remove them once they are scored.
Some design notes One problem that is common to AI-driven systems is that most of the behaviors go on underneath the cover, away from the player's eyes. It is very easy to fall into the trap of creating an intricate AI that 'plays itself' but is completely incomprehensible to the player.
Instead of asking how you might make the most realistic AI system, I prefer to steal a page from Nintendo's playbook. Instead ask "What is the simplest system that drives forward the player experience?"
Peas climb. Peas fall. Peas get scored. All of these activities are very apparent to the user. Instead of complex internal logic, the design focuses on explicit external behaviors. Any internal logic such as the path finding system exists only to the minimum degree necessary to support the external behavior. We won't build SkyNet using these sort of AI techniques, but we can make more enjoyable games.
Conclusion If you create something inspired by this prototyping challenge, send it this way! I'll post it on the website for everyone to check out and comment on. Take shortcuts, mangle the design, find the fun.
Enjoy! Danc.
Assets I've provide the graphics for PlayWithYourPeas in two versions. First, all the graphics have been saved out as PNGs. I also included the Expression Design source file so you can make modifications to the original vectors.
Updated 2-11-2008: I added in the Block-Place-Normal.png to the zip that was previously missing. I also fixed some of the file names.
Updated 2-14-2008: I renamed the Ramp tools so that they follow the same naming convention as the blocks. The pea shadow is now seperated out. The single pixel alignment errors on the tools and the normal block are now fixed.
Gamasutra was kind enough to post the report our group produced this year at Project Horseshoe. If you are interested in a brief glimpse into the thoughts of veteran game designers, it is worth a read. The topic our group chose was roughly related to 'story in games'. However, it became quite clear that the group was more interested in discussing how games are able to support powerful new experiences.
Story, in the traditional sense, was reduced into a rather small and telling role. The best stories, we concluded, are the ones told by each player as they share their amazing gaming experience with friends and family. In this game-centric view of media, "story" is but the afterglow, a processing step in our understanding of past grand events. Games are about causing the birth of the primary event, that glorious moment where the player actually experiences those grand events first hand.
And what is game design? Game design is the process of building devious systems that are fully aware of human foibles, quirks and desires. These systems click and whir with manipulative intent. The best ones encourage human beings to reach out and experience, of their own free will, something new, meaningful and real. Game design as a distinctly unique and powerful tool set I got the glimpse that designers are finally coming to terms with games as their own unique creative medium. I'm not quite sure how to put this into words, so bear with me. :-) The examples we discuss passionately were from games, not movies, theater or books. The language and metaphors were distinctly born from the theories of play and human psychology. Folks were discussing how to build the next world changing work of art in a rich, detailed vocabulary that despite borrowing liberally from other fields, was distinctly unique to games. In fact, there was little talk of cut scenes or protagonists or narrative in general.
The group quickly bypassed such dorm room topics as a waste of our limited time. It would have been as useless as a gathering of early Jazz musicians debating how the aesthetics of Shakespearean plays might advance their new art. Drawing such parallels might certainly be academically intriguing, but it has turned out to be generally orthogonal to the task at hand of making great games.
I've always believed that the real philosophy, language and tools of understanding and building great games will comes from messy development trenches, not the ivory towers or posh hills of Hollywood. Artists, whose lives crumble or soar based off the success of their vision, have far more incentive to push for new techniques that work. The language of games grows like slang in the ghetto, rough, occasionally incoherent to outsiders, but still immensely evocative and effective. When such a language makes the leap to the mainstream, the world changes.
Last week we picked up Super Mario Galaxy. It has always been a private shame of mine that I never truly experienced Mario 64, despite all the accolades that it has garnered. Years ago, I played for the first level, enjoyed running about and marveling at the scenery. But then, as I recall, the game became impossibly difficult. Not for all people. Just for me. Completing precision jumps across lava filled 3D chasms while ominous monstrosities slobber at my heels is my own private form of hell.
The hot hookup But Super Mario Galaxy has received universally great reviews; it maintains an ample 97.3% on Gamerankings.com. It is also supposedly relatively easy to beat and the controls are dead simple, a stance in line with Nintendo's lovely new casual bent. So, what the heck. Targét, the local French emporium of stylish goods, had it on sale for 35 smackers. I figured I'd give it a shot.
So I plopped it in the Wii and sat through the drearily long intro movie. First impressions...the camera still sucks, but it is cool that you can tag the little star bits with the wiimote. Ooh, a spherical world. Wow, this camera really does suck! I'm suddenly navigating upside down and my head is cocked at a 90 degree angle. I barely know where my little dude is heading.
So I gamely struggle with the wonky interface up until the first black hole. I immediately drive my drunken Mario tank directly off the ledge into the hole's waiting maw. Boom, back at the beginning of the level I go. And I lose a life. Confusion sets in. Shouldn't there be like a quicksave or something that lets me try this dastardly trap again? Surely, a mistake made in a fraction of a second surely shouldn't be punished by a minute long replay penalty.
The frustration of not finding your soul mate Oh, but it is. At this point I'm pissed. For me, the first hour of Super Mario Galaxy simply isn't any fun. It is stressful, irritating and it punishes me when I make the slightest mistake. And then it gets worse. I jumped from enjoying WiiSports to playing Super Mario Galaxy. The difference in expected play styles is quite the shock.
Time between failure and retry is too long: If you make a mistake, retrying again should only be less than 15 seconds away. Even a minute is too long. The easy levels of Knytt are just about right...3 to 10 seconds between retries. Something like Braid promises to be even better. Replay just as much as you need to.
Lack of dynamic difficulty: My wife died five times in a row trying to run around behind a giant tromping plant. How hard is it to reduce the difficulty level of an enemy if they end up blocking a player's progress? Make the monster tromp slower. Require fewer hits to kill. We build games in a one size fits all manner when the obvious reality is that there are lots of different types of players. Try to meet up half away instead of asking the player to do all the work.
Blocking linear challenges: Naturally, my wife quit the game after this repeated punishment. Classic burnout. Never block the player with a challenge that presents no option but continued failure. When the player is presented with challenge after challenge in a linear manner, eventually they get to one that they can't pass. Beating your head against such an obstacle is frustrating. Instead, let the player try something else. (Eventually you gain access to multiple galaxies at once, but not soon enough. Also most individual levels remain quite linear)
Too much of a focus on learning through failure and repetition: A good 80% of the levels teach the player new skills by killing them if they screw up. A player new to the 3D platformer genre is expected to rack up hundreds of deaths before they reach the end. Many areas require a half dozen or more attempts, each lasting minutes, before success is achieved. And this is fun?
If you fixed these things, it wouldn't be a Mario game None of these problems are the fault of Super Mario Galaxy. I'm playing the game incorrectly. My suggestions are like trying to improve a lover that isn't quite the right match. Mario is a game about all those things I want to fix. You see, when I play, my most happy moments are exploring and chatting with the little cute mushroom guys. All this jumping crap just gets in my way. But the point of Mario is the jumping crap.
Super Mario Galaxy is all about mastering physical skills. If you map out the skill atoms, everything relies on movement and timing. This is reptile brain stuff that is learned in one very simple manner: repetition. Remember, Karate Kid? Wax on, wax off. The game design is a slave to this biological requirement. If you want to encourage the player to master navigate a narrow path above a black hole, you need to force them to perform variations on that action a thousand times. Each failure improves our muscle memory a fraction more.
This is core of Mario:
Move accurately.
If you fail, you die and try again.
If you succeed, a new challenge appears where you must move with even greater accuracy.
There are of course some lovely exploration elements and cute graphics mixed in with the basic activiities. However, if you removed the core elements of timing and jumping, you wouldn't have a Mario platformer any longer.
It's not you, it's me Sometimes, it is the player, not the design that is at fault. Somewhere along the way, I have diverged from the traditional gamer path. Those simple pleasures of twitching in sequence to bizarre spacial/temporal puzzles are lost on me. Instead of finding them fun, I find them to be obnoxious time wasters.
This goes back to the work of Chris Bateman, Nicole Lazzaro, Nicholas Lee and others exploring different play styles. Not all people enjoy the same sort of games. It's an obvious statement that is still making itself heard throughout the gaming ecosystem.
For example, on Nick Lee's motivation assessment test, I happen to score high on exploration and socializing tendencies, but don't really give a damn about in-game achievement.
I'll put up with fighting enemies or solving puzzles into order to see new vistas or get some coin to help outfitting my character. I'm not in it for the joy of the battle.
For a person like myself, Street Fighter is the single dumbest game of all time.
On the other hand, wandering about in Animal Crossing and planting sweet rows of pretty apple trees is pure crack.
With the advent of casual and indie games as well as the efforts on the DS and the Wii to broaden the market, I'm starting to see more games that I enjoy quite thoroughly. Games are beginning to finally emerge from their geeky, masochist roots and it delights me to no end.
I should have never listened to his advice The rest of the ecoystem hasn't quite caught up. That 98% score for Super Mario Galaxy on gamerankings.com is so horrendously polluted by a self-selection bias that it is laughable. What percentage of the reviewers fit any of the following criteria?
Never played a 3D platformer.
Mostly enjoy casual games like Bejeweled.
Prefer social board games like Pictionary or Scrabble.
That's a random smattering of non-hardcore play styles and skill levels present in the broader population. I suspect you'll find less than 5% of professional game reviewers fit any of those profiles. The quality signals sent by the extraordinarily biased press are completely inappropriate for anyone who hasn't been playing games as their primary hobby for the past five years.
What will it take for the game industry to adapt to the fact that different gamers like different games? I'm not sure that expert game reviewers, describing their personal tale about their unique experience with the game, have a place in telling most people which games they should play. It's like taking dating advice from a Guild Navigator, so loaded to the gills with the spice of genre addiction that they've mutated into an alien being.
For me, the solution is all about trying the game out before I purchase. This is an area where immense improvement is possible.
Customers need to learn to seek out demos. They also need to refuse to buy sight unseen the products that fail to offer a free trial. This is a culture change that will likely take years to complete. It is inevitable. People don't like making $40 mistakes.
Developers need to learn the fine art of making great demos. A great demo is a viral marketing engine that cuts out the middleman. They improve customer satisfaction and can improve the margin that a developer takes home. There is a huge opportunity here to merge the lessons of free-to-play service models with the mechanics found in current downloadable games. Unfortunately, building a demo that provides instant value, an incentive to purchase and makes users want to pass it on to others is a skill that is rarely found at most game development shops. We are seeing some early attempts on Xbox Live, the PS3 and the DS download stations, though at the moment, the demo is often a separate from the full version. As the concepts of 'free to play' and 'demo' begin to merge, developers will need to address this disconnect.
Platforms need to make demos the default method of promoting a game. If a game is released in the store, I should be able to download a demo online. If your platform doesn't encourage this for most games, your customers are being punished. Ideally, customers can purchase the game from within the trial. This is already the case for the casual download market and I expect it to spread quickly into other areas of the game market.
If Super Mario Galaxy had a demo, I would have tried it out and likely given it a pass.
If only I liked you... In a way, all this makes me sad. There is an entire herd of twitchy game developers, trained for decades to worship fare like Mario Galaxy. They are out there, busting their beautiful balls to make more games that push the same exact psychological buttons as the pedestal lounging AAA titles of their childhood. They are building some great games, but those games aren't for me.
It's like meeting a girl who is cute and smart, but really, really likes the whole dressing up their boyfriend in black duct tape and then whipping them until they bleed from unmentionable orifices. You'll eventually back away, but there is always that slightest tinge of regret.
You'll find someone This tale has a happy ending. My wife picked up the controller after I set it down in frustration. The last platformer that she played was Super Mario Bros on the original Famicom, but she figured, what the heck. She came back from being crushed by the first boss, read the walk through sites for tips and finally defeated him. From that point onward, she's been clocking in six to eight hours a day and just picked up her 60th star. She dies over and over again. The addiction and delight on her face when she ends a level is palpable. For her, the game clicks.
Perhaps after she's done, I'll pop into the levels she's already conquered and cherry pick the handful of experiences that fit my style of play. There is a beach level with a cannon and a lagoon. There isn't much there, but it is rather relaxing to hang out with the one scaredy crab (I kill off the hurtful ones) and taking the occasional lazy swim through the pristine waters.
Conclusion Even universal acclaim is not enough to justify a purchase. Each player has their own distinct playing style and many of these preferences are rarely captured by the hardcore journalists who review most games. Instead of complaining about the game post-purchase, it is far better to grab a demo and experience it directly. This goes for even such gems as Super Mario Galaxy.
Happy New Year, Danc.
Updated 10:01AM, January 2nd: Clarified some of the minor bits and added a conclusion so that the main point isn't completely lost in the red haze that comes from hearing a heathen's encounter with the Holy One. :-)
An essay on how to treat customers and employees like owners and reap the benefits.
In any meeting, a negotiator can adopt a variety of strategies. Typically, they horde information, pick apart their opponent's every move in hope of understanding hidden meaning, and ultimately attempt to gain the upper hand through manipulation. Sometimes you outsmart your opponent and win. Many times, you are so busy protecting yourself that a deal never happens.
There is a less common negotiation strategy that relies on going completely naked. Instead of hoarding information, you give it freely. You openly explain both your needs and what you have to offer. If the other person reciprocates with open arms, you can work together to capture amazing opportunities.
It occurs to me that many private companies play the game of business as a negotiation situation where their customers and employees are opponents that must be outsmarted. Many deals are left on the table. What would happen if they instead used the naked negotiation strategy? Imagine a company that says to their customers with conviction and honesty, "Here is what I have, and here is what I need. Let us work together to create mutual value."
The rules of an Open Kimono business The following are simple rules of thumb that guide the behavior of a Naked company.
Rule #1 - We are all in this together: By purchasing a company's product, a customer becomes invested in company's continued success. By working at a company, an employee also becomes invested in company's continued success. In all areas, both the customer and the employee contribute to the business and deserve to share in its success as owners.
Rule #2 - We share information freely: Where possible, aggregate information that is shared freely within a company should be shared freely with the customers of a company. More is gained from sharing than from hoarding. We seek to build trust, empower both customers and employees, and solve problems together with the best tools possible.
Rule #3 - We win through the creation of superior value: In competitive situations, by erring on the side of openness and honesty, we discover mutually beneficial solutions. As a result the company succeeds by being able to offer superior value compared to those companies that attempt to get ahead through trickery or manipulation of perception.
Examples All this is lovely sentiment, but what does it mean? The following practices might vary depending on the exact company, but here is a good start.
All major financial data is posted in an easy-to-comprehend fashion on the company web site
All major company metrics, goals and progress towards those goals are publicly posted and constantly updated.
Periodic customer research is performed and the results are also made available to all customers and employees.
5% of profits are redistributed back to existing customers. Another 5% is given to the employees. If desired, the money can be donated to a charity or reinvested in company stock.
When problem areas are identified, customers are encouraged to contribute suggestion, time or resources to the solving of the problem.
Roots of the Naked business The roots of the Naked business are quite traditional. Successful companies have been using these techniques for years.
Public companies: Public companies are required by law to divulge certain internal information to their stock holders. The result is that dishonest behavior is not allowed to fester for long without being exposed to the light of reality. It is debatable however, if public company's slavish devotion to quarterly stockholder gain is a positive long term strategy. A Naked company that has the transparency of a public company, but is measured on pertinent long term business metrics instead of only short term financial data.
Open Book Management: By sharing pertinent company information with employees, companies run by open book management empower everyone in the company to innovate towards a common goal. A Naked company uses the same technique to leverage not only the distributed power of their employees, but also the distributed networking power of their customers.
Market Orientation: Companies with market orientation listen to both the needs of their customers and the trends in the market when making strategic and tactical decisions. A Naked company's close two-way communication with its customers allows it to respond effectively to the latest market information.
Market as a community: Markets are often looked at as system in which buyers and sellers exchange value, where value is defined in financial and material terms. Yet strong emotional bonds form between buyers and sellers that can bring substantial social value to both parties. People will always seek to find meaning in their actions, yet companies often ignore this fundamental need. A Naked company provides both customers and employees with a self-contained community that encourages, nurtures, and thrives upon the creation of social value.
The case against the Naked business When I bring this concept up to people, the inevitable reaction is "What an idealistic notion. Unfortunately, the world does not work like that." It is utterly self evident that close management of information is essential to any financially successful venture. In no particular order, the following are considered to be fatal flaws in the Naked philosophy.
Severe competitive disadvantage: The moment a company provides open information to the public, competitors will use that information to gain an advantage. Copycat tactics, preemptive product releases and attack ads that further publicize embarrassing information are all likely.
Expensive: By spending time providing reams of information, small companies are using scarce resources ineffectively. Seeking more sales or creating a improved product will yield better results.
Customers lack of business skills:No benefit is gained because customers lack the skills to interpret company information in any meaningful fashion.
Public relations nightmare: Honest publication of information means that the company will be displaying warts and all to the public. There is little opportunity to spin bad news or manage your financial data.
Customer relations nightmare: If you give customers a sense of empowerment, they will complain endlessly and publicly. This in turn leads to bad press and a loss of sales.
No one is doing this: Few profitable companies operate in this fashion. They must have already failed.
The case for a Naked business The following are benefits of an OK company.
Passion: Companies with a strong vision tend to outperform those that focus solely on financial results. By building a culture around a philosophy that people can wholeheartedly believe in, employees and customers will give the extra effort necessary to ensure success.
Strong word of mouth presence: A company with a unique and appealing ideology stands out in the crowd. The fact that customers benefit from this ideology yields a powerful source of word of mouth advertising.
The customer's network is the company's network: A customer that truly believes that they are invested in a company feels comfortable sharing their contacts and resources. At the extreme end, the customer is a believer that happily volunteers for the company. A thousand customers have a larger and potentially more powerful network than a hundred employees.
Faster response to market change: Customers that complain or offer advice provide a highly responsive early warning system to changing needs or competitive threats.
Many eyes catch stupid mistakes: Strategic blunders are easier to catch when you have multiple people offering unbiased commentary.
Increased customer trust and loyalty: This in turn leads to retention and improved profits. Why go elsewhere when a company concretely demonstrates that it is deeply interested in listening to your needs?
Increased employee trust and loyalty: This also leads to retention and improved profits. Employees are the core asset of a knowledge-based company. By keeping them, you build an experience based sustainable competitive advantage.
One reality: The cost, both financial and psychological, of keeping multiple books, one for the public, one for the employees, and one for the investors is greatly reduced. The benefit is that customers and employees can talk the same language and use the same data to create mutually beneficial outcomes.
Key implementation areas Let's suppose for a moment that benefits of an Open Kimono philosophy outweigh the detriments. What are the success factors that must be focused on to gain those benefits?. The follow are key implementation areas that must be addressed in order to achieve success.
Dedicated Leadership: Any culturally driven sustainable advantage needs to have buy-in and support at the leadership level. Words alone are meaningless. Consistent public actions by respected leaders help the cultural change permeate through the entire organization.
Customer and Employee Education: Data is useless unless the intended audience is capable of understanding it. Putting company information in format that is comprehensible to the customers and employees is a partial solution. Actively educating both customers and employees on the meaning and use of the data is equally important. If there is not an obvious connection between the data and the benefits received by the person digesting the data, then the system has failed.
Filtering through the noise: When everyone yells their opinion, it can be hard to capture any useful information. Rigorous data collection and analysis techniques can turn the outpouring of information into actionable solutions.
Conclusion A strongly customer and employee oriented company is more likely to prosper than a profits oriented company. Profits are still important, but it is wise to remember that they are one metric amongst many. By focusing on satisfying a broad range of benefits instead of merely materialistic and financial benefits, a Naked company attracts and retains both superior quantities of customers and superior quality employees.
In the end, running a Naked company is as much a personal choice as it is a business decision. Openness, honesty, community and mutual respect are concepts I can believe in. All else being equal, what type of business would you want to devote your life to?
take care Danc
PS: With some minor changes, this was an essay I wrote many years ago. In the subsequent years, transparency has come en vogue and it now seems everyone is spouting its praises. Which is a great thing. This message needs to be broadcast as loudly as possible lest it be lost in the morass of sub-optimizers twisting the truth in the name of profits.
Ballistic Wars: The good folks over at Easy Only! Games put together a delightful little tactics game using concepts similar to those found in SpaceCute. My hope is to see an entire genre based off this mechanic popping up. As we saw from the prototyping challenge, there are a huge number of different variants that are possible. http://jayisgames.com/archives/2007/12/ballistic_wars.php
Call for Participation for the Experimental Gameplay Sessions 2008: Johnathan Blow is out shaking the bushes to round up a few experimental games. I suspect there are likely a few folks that read this blog working on something intriguing in their spare time. Shine on, you crazy diamond. http://experimental-gameplay.org
March of commodification: Raph chats about how R&D on chat turns into commodity off the shelf software over a period of only a decade. What once needed to be built from scratch is now a simple option that can be toggled on if desired. It made me think that perhaps technology is not a company's long term competitive advantage. Instead, it is the unique (and fragile!) community that a service fosters. http://www.raphkoster.com/2007/12/12/the-march-of-commodification/
Asynchronous games: The ever delightful Ian Bogost has a detailed discussion about the history of asynchronous multiplayer games. I love his use of personalized scores in Asteroids as an example for turning a single player experience into a highly social multiplayer experience. If you are a casual game developer who isn't thinking about asynchronous multiplayer experiences, you are missing out on some amazing opportunities. http://www.bogost.com/downloads/I.%20Bogost%20-%20Asynchronous%20Multiplay.pdf
Flash developers?: Do you know anyone with mad Flash/Flex skills who is interested in innovative casual games and social networking? I've got a good friend who is looking into prototyping some concepts in hopes of creating a startup. It would be ideal if they were in the Seattle/Puget Sound area. Drop me a note at danc [at] lostgarden [dot] com and I'll forward on the info.
A goodly number of indie game developers are lured into Lostgarden.com by the free game graphics. Every few days an email pops into my inbox, "Hey, could you draw the graphics for my cool game design idea?"
I'm honored more than you can imagine when I get such a letter and they mean a lot to me. Unfortunately, I have my fingers in so many projects at the moment that squeezing in an additional graphics job wouldn't be doing anyone any favors. Still, it bothers me that talented people with amazing dreams can't make their games due to a lack of graphics.
Here's a run down of several techniques that help you get your game finished without being blocked by the graphics bottleneck.
Build a game that fits your level of art skills The first path that you should go down is to build a game that fits your level of art skills. If you are a programmer and can only make squares, make a game that uses squares as graphics. It worked for Tetris and it can work for you.
At a functional level, graphics exist to provide feedback to the player, not to wow them with Hollywood-esque delights. Put those dreams of cinematic fantasms to the side and focus on the game mechanics, the interface and the level design. If you can nail all of these and you only have little ASCII art, people will still flock to your game.
Some successful games that designed the project around the developer's lack of traditional graphics skills include:
If they can do it, you can certainly finish your game without relying on an artist for graphics.
Use free graphics The next step up is to use free graphics. There are thousands of game graphics out there on the web. Admittedly, they have problems:
They may not be the most attractive. "Dude, these free graphics are totally sucky compared to StarCraft."
They may not fit your exact mental vision. "No, the Xenli Sorcesses has four silver spikes on her bosom armor, not two. It is completely wrong!"
They may not be complete: "I really need a female knight and and they only supplied a male knight! The end is nigh!"
Other people might be using them in their games. "Argh, now my RPG looks just like the one done by that guy in Australia. *sigh* Now I will never be l33t."
My heartfelt recommendation is that you get over it. None of these is really a blocker. If you can build a game with limited art, you can certainly build a game with a few carefully chosen bits of free art. Here are some answers to common complaints.
You aren't Blizzard. That's okay. You can still make a fun game.
Design is about coming up with great solutions in the face of complex constraints. In order to design a great game, you will need to adapt your vision to reality a thousand times. Practice your problem solving skills by using free game graphics in the best way possible to get as close to your vision as possible.
If the set isn't complete, get creative! If you need two knight graphics, colorize one blue and one red. If you need a dragon boss, colorize one of your knights black and change the villain to be the Dark Knight. Even primitive graphics skills can triple the number of usable graphics if you show a little initiative.
You browse free game graphics archives, but your customers do not. Out of the thousands of people that play your game, only a small handful will recognize that you are using free graphics. The only ones who care are typically merely would-be game developers snobs. Ignore them. That is easy enough.
Here's an example of noted game developer Sean Cooper using my free tile graphics for his Flash game Boxhead. Sean has worked on Powermonger, Dungeon Keeper, Magic Carpet and Syndicate. It is instructive to observe how he uses free graphics to give his game a leg up.
Pay for competent graphics If you absolutely must have quality custom graphics, you are going to need to pay an artist real money to produce them. There seems to be an odd opinion that that artists sit around all day doing nothing and whenever someone asks them for a painting, they scribble for a few moments and then non-nonchalantly hand over a masterpiece. Good art takes time and skill. Drawing a good tile set might take 20 or more hours. Drawing a simple background might take all day. If you aren't willing to pay for their very valuable time and effort, most competent artists will go work for someone who will.
Prices vary dramatically depending on the type of art, the quality of the art and the reputation of the artist. Expect to pay anywhere from $20 to $60 per hour. The best bet is to ask the artist what their standard rates might be. You can always negotiate, but remember if you squeeze the artist too much, you increase the chances that they will put your game on the back burner when a more appealing opportunity comes along. Negotiating for royalties is another option, but since 90% of the reason that games don't get finished is because the programmer flakes out, I would hope that most artists would be rather wary of this path.
There are numerous ways to bootstrap your art budget if you have your heart set on custom artwork.
Create art-free games to fund games with more polish. Release a version using free art. If it sells, reinvest the profits in creating the same exact game with better graphics.
Set aside a certain amount each month to pay for graphics. One fellow I know is setting aside 300 bucks a month to pay for game art. That will buy him about 2 days worth of a cheaper artist's output a month, but if he plans well enough and limits the amount of extravagant graphics in the game, this could be enough.
If you are looking for artist, you can find a reasonable collection of game artists for hire at these links. Just keep in mind that they all expect to be paid.
The one technique that doesn't work The most common strategy I see used by would-be developers is the only one that doesn't work. They pray that they can find an amazing artist who will work for free on their game. If only they hang out on enough forums and email enough artists and beg loudly enough...a godly artist will drop from the sky and gift them with amazing artwork.
It generally doesn't happen this way. Good artists can generally find work that pays in cash. Most likely what will happen is that you'll make a deal with a starving student who immediately leaves you in a lurch as soon as something that lets them eat comes along. They aren't being mean. They are just hungry.
So the would-be game developer mopes about the message boards, complaining about artists leaving their projects and how artists constantly ask for real money. Yet despite the substancial energy that goes into these activities, I've yet to see prayer or complaining ship software.
The big lesson Out of all this discussion about graphics, never lose sight of the big picture. The single most important thing is for you to finish your game. Iterating towards completion is the root of all practical knowledge about game development. Putting a complete game in the hands of player is how you'll learn to make your future games shake the world to its core.
If you are telling yourself "Oh, I can't complete my game because I don't have an artist," be honest with yourself. You are making excuses. Graphics are not an impediment to making a great game. Do what ever it takes to finish your game.
Design a game that doesn't need professional graphics.
Use free graphics when possible.
Set up a rational budget to purchase custom graphics from a professional artist if needed.
Project Horseshoe 2007 slides: Smashing the game design atom
Here are my slides (with talking notes) from Project Horseshoe. I blazed through this in about 30 minutes since dinner was waiting and there is nothing more ornery than a crew of wild haired game designers in complete glucose crash. See if you can spot the source of the infamous '8mm' meme that stalked the conference.
Since it was Halloween yesterday, let's start with a tale of horror. Not so long ago there was an experienced team, working with a known platform, and a known engine. They had just scored a popular girl friendly license valued at roughly $160 million. Their game had the potential to hit as big as Pokemon or Nintendogs.
The designer ignored all this. You see, he had always wanted to make a Zelda clone...one with the critical element that has always been missing from all Zelda games: Hardcore jumping puzzles. The designer thought, "Nintendo is smart, but how could they have missed such an obvious improvement?" Sure the license was targeted at tween girls, but tweens like big swords don't they? This was the game he personally had always wanted to play.
The team were contractually obligated to go along with the design. It had been green lighted. There were milestones tied to the completion of each voluminous chapter of the tome like design script. If the team missed the milestones, the penalties were extreme. So they crunched in happy little silos of artists, level designers and programmers, all in accordance to a strict production schedule. It was the only possible way to get all the specified content done in time for the looming holiday ship date.
Finally, as the end drew near, they sent it off to testing. Early reports come back that the jumps in the first few levels were rather clumsy. The designer relied on his gut and sent forth an email containing a new set of parameters that were intended to polish the jump mechanics.
Eventually, a month later, someone got around to playing the last few levels. Uh oh. They relied heavily on laboriously constructed jumping puzzles tuned to the old jump mechanics. The last few levels of the game were massively broken.
It was too late to fix all the early levels so they entered into a death march to rework the last few levels. Lacking time or resources, they busted their budget hiring extra crew to take up the extra workload. The game was still delayed by several months.
Surprise, surprise, the end result wasn’t a very good game. It received miserable scores, but even worse, the core audience who would have bought it on the license alone was completely alienated by the design decisions. They wanted to befriend and grow cute little animals. They didn't want to die repeatedly while being attacked by spiky monsters while scrambling through military obstacle courses.
When the licensee pulled out of the sequel, the team collapsed. The human cost was immense. Home were lost, families relocated, many were so burnt out on game development they left the industry permanently, their passion crushed.
There were a lot of problems in this tale, but the primary one was a blatant failure of the game design process at almost every level. The game designer really didn’t know what he was doing. He thought he was writing a movie script. He thought he was making a game for himself. He had no idea that the game systems he was dabbling in were deeply interconnected.
Most game design that occurs isn’t much better off. It is a combination of craft (such as cloning Zelda) and intuition (such as when he hoped that tweaking the jumping mechanics would fix all his problems.) There is no science here. No predictability.
We have the ability to do so much better. We can create a science of game design.
If we want to modernize game design and move beyond the land of craft and intuition, we need to face and conquer four great challenges. These challenges will define game design for at least the next twenty years and perhaps longer.
Modeling our players: What do our player really want?
Generating new games systems: How do we create new mechanics that serve those player needs?
Metrics: How and what do we test to make sure we are doing the right thing?
Results: How do we get the results quickly and iterate on them so we can evolve the game quickly?
If we solve these issues and start spreading the resulting practices across the industry, horror stories like the one I just told will become mostly a thing of the past. The ultimate promise of a deep pragmatic science of game design is better game, happier teams and fewer human tragedies.
We are starting to see a smattering of theorists and teams with money to burn tackling these problems. They are creating systems that save their butts from expensive design mistakes. This is damned exciting.
You’ve got the Halo folks tracking heat maps of where players die. Valve has been relying on metrics for years. Nintendo builds early player tests and kleenex tester right into their dev process.
On the game systems side you’ve got Raph’s game grammar.
We are starting to rely on real data to model players moods and reactions with Chris Bateman and Nicole Lazarro’s work.
The work is still at the stage where most pragmatic folks think of these systems as the domain of eccentrics. Yet, each isolated advance reminds me of the turn of the century when physics was being cracked. Brilliant theorists. Great experiments. World changing results.
All these systems are being developed in parallel. You can measure things, but you don’t know what you are supposed to measure. You can write about game grammar, but it never is anything more than a loosely applied system of egghead analysis.
Maybe, just maybe, we can come up with a unified system that tries to answer multiple challenges simultaneously. The connections are all there. We just need to put them together.
In my Seattle laboratory, I'd been working on one attempt. It mixes game grammar, player models and measurement systems into one delightfully unified game design process. I’ve got 10 minutes left to share it with you. Think I can do it?
I started with a player model. Let's assume for a moment that players are naturally inclined to wander about, sucking up tidbits of info in the hope of learning interesting new skills.
From the player model we can construct an atomic feedback loop that describes how they learn all the new skills. This basic atomic loop includes all the fundamental pieces of a game. We are taking the deconstructed analytic elements described in so many books and tying them back together into a functional system.
You’ve got your game system, that black box in the center of the loops.
You’ve got your player input
You've got feedback to the player
You have the the players cognitive model of the game.
We’ve reduced the scope to a single atom in order to making things managable and Press button, character jumps. That’s a skill atom.
Once we have a skill atom we can say interesting things about how the player interacts with it. First, skill atoms have states.
The player can figure out how to jump. They can exercise that skill by jumping on things. That is mastery. We can record this.
The player can fail to figure out how to jump. They never touch the button again. That’s early burnout.
They can get bored with jumping and ever jump again. That is late burnout. We can measure this as well.
Skill atoms are chained together. You can visualize them as a directed graph. Later stage atoms depend heavily on early stage atoms.
Want to kill a Koopa? You need to jump on him. Better hope you mastered the jump skill. We can now represent that classic relationship created by Miyamoto ages ago in a visual model. The theory is slowly catching up with the experimentalists.
You can turn these little chains into big chains that describe the entire game. Here’s a skill chain of Tetris.
Skill chains are remarkably flexible and rather easy to apply to almost any game. You look for the actions the user is performing, the skills they are learning and the positive / negative feedback you’ve built into the game. Any game with explicit rewards can be diagrammed.
There are probably a goodly number of you rolling your eyes at this point. You can create pretty diagrams to analyze anything. Here we've got someone who has created a very lovely and describing diagram of a penguin defecating. This is not a helpful diagram.
We ultimately need pragmatic everyday tools, not egghead analytics. The primary reason we create skill chains is to help solve two of our outstanding challenges:
Get real results quickly
Choose the right metrics so we aren't wading through huge quantities of data.
Skill chains can be used to create a rapid, iterative test driven game design process.
If we really rapid feedback, let’s build the feedback system into the game from the very beginning. Skip the giant paper tome phase. Start with a playable system that gives you meaningful reports.
The nice thing about skill atoms is that they eminently testable. When you write code that is going to be put in front of player, define your skill atoms. Its the same conceptual ideas behind writing unit tests.
You have a test framework.
You write the tests when you write game logic.
You run the test suite when you run the game logic.
You get a clean simple report when someone plays the game.
When you write your game systems, you can instrument each and every atom. It is a relatively inexpensive process.
You labels the rewards
You label the actions
You know when and atom is touched. You know when it is inactive. All those, states, burnout, inactive, etc you can record.
Remember burnout? The next time someone plays the game, we can visualize burnout directly on our skill chain diagram. You see instantly what atoms folks are missing. Here is someone failing to figure out how to complete a single line in Tetris.
You can also look at the data in terms of feedback channels and activity graphs.
Either way you get quick, easy to decipher feedback.
Instead of having a team that creates customized visualizations tailored to your game, you can use a more generalized system.
Instead of sorting through dozens or hundreds of badly organized logs, you can see in a glance where problems are occurring.
This requires a change in your development methodology. You want people to play your game as early as possible and as often as possible. Luckily automated testing of skill atoms reduces the cost substantially compared to traditional manual tests.
Anytime that anyone, anywhere in the world runs you game, you get valuable play balancing information.
Build up a database of a thousand players and release your daily builds to three people a day for every single day of your dev cycle.
In this day of web 2.0 and connected consoles this is now a broadly accessible practice.
Once you have rapid, daily feedback in place, you can use the resulting reports to evolve your design iteratively. All this analytical game grammar silliness becomes a foundational feedback system.
We can regression test game designs now.
We can fix busted skill atoms and see how things improve the next day.
What happen when we refactor our designs to make them more testable? I have no idea, but it excites me.
Imagine if a system like this had been in place when the 'designer' in our horror story made his jumping tweaks. The dashboard would have gone dark almost instantly with burnout spreading across the screen.
The systems I've described today are just the beginning; rough sketch of the future, if you will.
Our player models are primitive.
Our metrics can advance dramatically in their sophistication. We are just starting to tap into biometrics
Our player testing systems are still expensive to run.
There are amazing new games waiting to be designed and evolved into stunning experiences.
The great challenges are still out there. Both the theory and practice of our science is still very being born. Sometimes I wonder, "Who is going to take game design to the next level?"
I love this picture. 1927 5th Solvay conference. Einstein, Bohr, Curie. 17 out of 29 attendees went on to win the Nobel prize.
The first conference was in 1911, almost a hundred years ago. Einstein was the youngest present. Who is the youngest person here? These quirky, brilliant people revolutionized our understanding of physics. Without their work, we wouldn’t have semi-conductors, computers or video games. They were theorists and experimenters not so different than what we have in our industry today. A small group of eggheads changed the world.
I look out at this group and I see the same potential. We’ve got the brains. We’ve got the time.
Let’s make this an amazing weekend."
take care Danc.
PS: There was one more group photo shown immediately after the Solvay photo. It however, has been redacted due to national security concerns.
First, isolate the group I just stumbled back from Project Horseshoe, the amazingly intense game design think tank set in the deep wilderness of Texas. Ah, Texas. Armadillos sporting leprosy and overhanging trees dangling with dozens of wiggling arachnids were amongst the more colorful wildlife lurking on the isolated ranch where we stayed. There is nothing more endearing than having a conversation about virtual gods interrupted by a friendly eight-legged fiend swaying two inches in front of your nose. Did you know that wolf spiders merely cause agonizing pain and swelling? We absentmindedly brushed the curious observers aside and got back to the intense task of solving the world’s biggest game design problems. No time for spiders.
If you’ve ever wandered the halls of GDC and managed to hook up for a few golden moments of great design conversation, you understand the purest essence of Project Horseshoe. It is exactly like that, except the mind melds last for two and a half days and the intensity is magnified by an order of magnitude. Sleep is deferred, scotch consumed, and electric arcs of thought crackle. I always come away with a feeling of inevitability: “We shall change the world.”
The quality of people in a small team matters Key to all this was the quality of the people. With the esoteric topic of game design, you might expect perhaps 1 out of every 100 industry folks and perhaps 1 out of every 100,000 players to be able to have a coherent conversation. Every single chat here went deep. Concepts that typically require a few hours (or days) of build up, were grokked in minutes and then leapfrogged. All told, the various attendees, hailing from a spread of publisher, AAA, casual and academic backgrounds have already created experiences that were integral to the lives of millions of players. I've worked with some good eggs in my life, but never have I been around such concentrated brilliance.
Passion is also critical And it was obvious this crew will inevitably create or influence the creation of a hundred million more experiences in the future. Over and over I heard the passionate sentiment that we are at the very beginning of games as revolutionary and fundamentally positive social force. To have such idealism and talent focused in the same room for a once-in-a-lifetime event was downright intoxicating. It was like witnessing the birth of quantum physics or the computer industry or modern cinema.
Include a few elements from left field I had the honor of giving the talk that kicked off the geeky portion of the event on Thursday. George “The Fatman” Sanger introduced me by saying he told his wife he found me on the internet. Note: Craigs List ads do in fact work. "Slinky SWGD seeks walks in park." I’ll post up my slides shortly. I must admit that I was repeatedly surprised and humbled to find out that so many of my fellow attendees read this little blog. (Hay, everyone!)
Work towards are a clear, pragmatic goal As is the yearly tradition, the working groups at Project Horseshoe will release their reports over the coming months. It would be impossible to capture everything discussed, but at least a few big ideas will surface. Practical, practical. Otherwise, it is just a bunch of egos gusting hot air. And that isn't the point.
What a rush. I’ve got another dozen fresh essays crammed into my bursting noggin. Life is absolutely glorious.
My latest essay on emotion in games is up on Gamasutra. There are pretty pictures about brains. You can read it here.
It asks that simple, innocent question,"What can we do to make games evoke emotions?" The answers are more about applying the lessons of experimental psychology than the 300 hot tricks of screenwriting.
While I was looking into this topic, I read an essay in Scientific American on 'dangerous ideas' and it got me thinking about the sort of 'unthinkable' ideas in game design. This essay contains a smattering of them and I'm curious which ones you find intriguing.
"Games are great at causing emotions."
"You can replicate meaningful religious experiences with a game."
"Most media such as books, movies and poetry are far more about our past experiences than any inherent value of the work. "
"Isolating gamers from the outside world is a highly effective strategy for maintaining service contracts."
"In order to increase the impact of games, we must engage the body as well as the mind." The Wii Fit is just the start, baby. That slack faced hardcore couch potato experience is about to become an experience for dinosaurs (fat, emotionally stunted dinosaurs at that)
Does it hurt to say such things out loud? I have great faith in the ability of science and reality to weed out the ideas that contain no substance. Whether any of these concepts hold water will be directly up to the efforts of talented and innovative game designers. But what if one or two of them held a kernel of truth? My god, what a brilliant future lies ahead.
I am quite looking forward to your thoughts on the essay. Grab a mug of tea, find a comfy chair and dig in.
I happened across a wonderful nugget of design philosophy, while reading an interview with Clinton Keith, the head of High Moon Studios' technical department. It bundles up lessons from Miyamoto, the joy of failing fast and the benefits of using Stage Gate-type processes in one delightfully juicy quote.
"If you want someone to fail, you want them to fail fast, before they spend a lot of money. That's how Nintendo was. When I was working on the Dream Team [at Angel Studios], they wanted us to do this DNA-based driving game called Buggy Boogie. You had these vehicles that would eat other vehicles and adopt their powers and morph. It was really cool. But they would sign three month contracts, and Miyamoto himself would say that he did not want any documents. He would just say, "Find the fun, and I'll be back in three months to take a look at what you have."
We went through about three iterations of that. We busted our hump trying different things, but at the end of it, he kept coming back and saying that it wasn't there, and it wasn't fun. We were a new company that didn't know how to make games. After about six or nine months, he came back and said, "You guys have really worked hard, and we see the progress, but we're not seeing the product. But another opportunity has come up for a fantasy golf game, so why don't you guys work on that? In three months, we'll be back. Show us a golf game."
So rather than getting pissed off at us and canceling the contract after two years and millions of dollars, they spent just a tiny fraction of that with a small team and said, "Well, it was just a bad idea." It maintained the relationship with them, so we could go off and do something else.
The Lessons Here are the tidbits I squeezed out:
Give yourself a short period of time to 'find the fun' in a design. Give a small team for a few months to iterate on a new design idea. Your goal is come up with the enjoyable core game mechanics. Toss the lengthy design docs. That can come later. If you don't have the fun core of your game, all the design docs in the world won't help your title.
If the fun isn't there, move on. Many ideas are bad ideas. You didn't know until you tried. Luckily game designs are a dime a dozen, so perhaps another one will be more fruitful.
If you do fail, it isn't the end of the world. Failure is a reasonable and obvious part of the process of creating games.
Much of how creative people see the world is marred by the success bias. We are constantly surrounded by successful, beautiful creations. It is natural to assume that somewhere out there are people who can just create an amazing game at the snap of their fingers. We look at our lump of an attempt and the comparison can be soul shattering.
What we don't see are the failures, those thousands of experiments that never made the final cut. There is a thread over at TIGsource where they are posting incomplete projects. This is the reality, the secret underbelly of both the marvelous IGD competition entries and many commercial successes. You will fail many times before you creating something amazing.
The multitude of playtests that arise from the plethora of exploratory project will inevitably give you more failures than successes. The smart folks use failures to learn and improve. Failing quickly and cheaply means you'll get to really good ideas faster. The path to success is intentionally strewn with failure. Embracing failure is a fundamental lesson of good design and one that is not taught nearly enough.
So when you look at your feeble, twitching prototype and compare it to the latest vibrant screens of some Miyamoto masterpiece, don't give up hope. He likely went down that path as well. Pick yourself up. Is there are spark of fun in your idea? Can your coax it into a bright flame? If not, you should have no regrets. For there is always the next glorious idea waiting to be explored.
I've been dabbling with quick wireframes to explain the design of Tree Story. There are two common ways you can look at a spec.
One is that of the blueprint, a plan that will be rigorously followed by production workers in order to achieve the end result. In this model, the team members are followers who are expected to implement a list of fixed details, not innovate.
The other is that of a communication tool. As a communication tool, you are trying to seed key concepts in your team so that they can take ownership and run with the idea during implementation. In this model, the team members are ultimate owners of the final design and the 'designer' is more of a facilitator of the process. Any spec exists only to spark conversation so that the team can build up a shared understanding of the feature's goals.
I've found that text is rather horrible as a communication tool, especially with small teams. It takes too long to iterate on and starts bogging down as soon as there is more than one person editing the document. Even worse, text fails horribly when describing anything visual or tactile.
Instead, I'm a big believer in using storyboards augmented by multiple discussions around a whiteboard, especially for early discussions. The story boards / paper prototypes can be quite concrete, but they are still visual and tactile enough for two or three people to stand around and comment on.
The iteration process is straight forward:
Whip up a quick storyboard. Limit yourself to spending 30 minutes to an hour on it. Make it very rough.
Print your latest 'official' wireframe on the biggest paper you can lay your hands on,
Tape it to a whiteboard and nab the first person you spot on your list of influencers.
Brainstorm around the idea. The taped version acts as a starting point for the conversation and an anchor if the conversation gets lost.
Immediately update the wireframe with the new thoughts.
Rehang it on the wall. Ideally look for a spot with a lot of traffic.
Rinse and repeat.
Within a short period of time, you have a design that:
Is easily understood in a glance.
Is understood by multiple team members. The story board acts as quick reference to your indepth conversations.
Is up-to-date.
Is a conversation starter for the rest of the team. I've had the best results when my desk is positioned near where the drawings are hung and I can leap out and chat with people wandering by.
Example wireframes Here's a stab at some wireframes for Tree story. Sorry that we don't have a good white board built into this blog. Someone needs to fix that. :-)
The basics of communication In Tree Story there are NPCs you can chat with. Here is how.
Picking up objects You can also pick up objects and drop them where you desire.
Planting seeds A special type of object is a seed. It lets you grow new platforms in the world.
Each seed creates a different type of tree. Use different sized trees to reach different areas or grow interesting fruit.
These were done in a vector drawing tool because I find wireframes use a lot of objects that are the same. I personally prefer to copy and paste instead of spending time redrawing. However, they could just as easily been done by hand. They are likely a bit more detailed than necessary, but I'm compensating for the rather low bandwidth nature of a blog.
take care Danc.
Weather system PS: Here are some additional wireframes that describe how a sunlight and weather system might work. This could be used with Clint's idea for the weather trees and machines.
The lovely exploration/platformer Knytt Stories by that Swedish genius Nicklas Nygren is available. Download it, play it and spread word of its greatness throughout the land. Knytt is the epitome of accessible indie game design and one of the few titles that I've fallen deeply, passionately and madly in love with.
Raised in the Scandinavian traditions of Linus and kindly gnomes, Nicklas is giving his entire life's work away for free. This blatant socialism shall not stand. Do you believe in human goodness? Do you believe in justice? Do you believe in fair pay for honest labor? If you enjoy the game, the crotchety shareware old timer thinks that you are morally obligated to to donate a solid chunk of cash into the Nifflas paypal account. Quality pickled herring and lingon berries don't come cheap and starvation means a fewer such amazing games in the future.
Alright. Enough promotion. Knytt Stories and its prequel the original Knytt turns my crank because they are a wonderful example of how to create a landmark game in a dying genre.
2D platformers in the niche stage 2D Platform games are past their prime. The numbers, though inevitably incomplete, do not lie.
Other than some handheld holdouts, the publishers have moved on. Much of the audience has as well. It is my belief that if an original game that was identical in competence to Sonic or Super Mario Brothers was released on the market today, it would sink without much of a trace. "Ah, a platform game" gamers would say. "I remember playing those."
I'm in the group that never fell in love in the first place. Most popular platform games just make me irritable. I just don't have the skill. I still haven't completed Super Mario Brothers and my voice turns high and giggly just looking at Contra. The legends of the platform genre are mature stage games that are intended to challenge that rarefied population of gamers who have been double jumping before they started walked.
The vast majority of the level design is usually focused on solving bizarre little timing puzzles. These have evolved over the decades. At first static platforms provided enough challenge. Then came moving platforms. And rotating platforms festooned with enemies. That shot timed patterns of spikes. That were as large your head.
The core platformer audience adores repeatedly bashing themselves against such puzzles until they can fire off symphonic jump sequences with microsecond accuracy. I, on the other hand, feel like I have mittens, the bulky leather-type they wear in harsh Northern climates, permanently welded to my misshapen paw-like appendages. I remember vaguely enjoying some of the earlier platform games. I've certainly jumped over the occasional barrel in my time for mild chuckles. However as a skills of the dedicated platformer genre addicts grew and the developer merrily upped the ante, mitten wielding folks like myself were left far, far behind.
Yet I love Knytt and am very much enjoying Knytt Stories. How do a few guys in Sweden single handedly ignite my love for a genre that I had believed long overrun and corrupted by the elite gamers of the world?
Focus on accessibility I sent Nicklas an email a while back and he was kind enough to answer some of my questions. One response about skill level stood out.
"I wanted everyone (particularly people who usually don't play computer games) to be able to play and enjoy Knytt, that's why I didn't make it very hard. Many gamers who play a lot naturally didn't like that, but to me the game is all about the atmosphere, rather than the gameplay."
With Knytt, Nicklas focused on a broader audience by creating a game that had accessible delights. He risked the wrath of the skilled platform players and intensionally broke many of the essential conventions of the genre.
Exploration, not traditional skill-based rewards The obvious thing that everyone notices playing Knytt is just how wonderful it is to wander from room to room seeing new sights. Many of the creatures in the original game were unique and harmless.
This is a great use of readily accessible red herring skill atoms. You don't need to be a skilled player to gain joy from seeing a wild animal grazing or discovering a cute village for the first time. These are pleasures available to even the most inexperienced of players.
As such, must of the game is structured around seeing the world. Quests for items are often not resolved by hard jumps or boss battles, but instead by wandering and being curious.
Minimize the traditional UI
"I don't really like the health bar (I avoid displaying indicators on the screen, since real life doesn't have them)."
The user interface for games in a genre evolves over time, typically becoming more complex. A user interface is much like a language. It uses symbols to convey meaning in a compact efficient form. Problems arise when users have no experience with those symbols. A health bar is the most obvious thing in the world to an experienced gamer. Yet it is confusing and meaningless to those who have not seen it.
By removing the typical UI trappings, you make the game more accessible. There are fewer things to learn at first and few things to get frustrated by. Instead, Knytt Stories goes the route of incorporating learning into the game itself. Instead of tutorial screens, you have a tutorial level. Difficulty is a switch inside the game itself.
Allow for low cost experimentation Knytt has no lives. Save points are very liberally sprinkled about so that when you do fail a jump, you are seconds away from trying it again. Most jumps aren't fatal. Due to the lovely addition of wall climbing, you can recover from most clumsily timed jumps. Pits become opportunities for exploration, not death traps.
All of this contributes to a warm feeling of safety for the player. The game isn't out to punish them for playing and exploring. Instead, it is balanced so that the player is encouraged to try new things and see what happens. They can climb to the tallest peak and jump off to see where they land. In Mario, this is suicide. In Knytt, it is a joyful act of play that has very few negative consequences and a large potential reward. What if an adorable little village lay at the end of that epic jump?
This is perhaps one of the failings of Knytt's sequel, Knytt Stories. Enemies, ineffective as they might be, litter the landscape with much great frequency. The result is you play with a bit more paranoia and dab less experimentation. By increasing the immediate challenge, the player is less likely to engage in the more unique and accessible pleasures of exploration.
Layer difficulty Perhaps paradoxically, Knytt Stories can be a brutally hard game. You can spend hours searching out the last secrets or grinding through a seemingly infinite set of new levels. Yet even a casual gamer can complete the main scenario in an evening or two without swearing once.
You don't need to sacrifice the hardcore audience in order to make your game accessible. Instead, you can layer the difficulty levels in the game. Here are some of the techniques that Knytt Stories uses to great effect.
Keys: Hidden in very secret places throughout the maps are keys. You can play through the game without noticing them at all. The expert player makes it their mission to find all of them.
Optional jumps: There are multiple paths through a level. The main paths are very low skill. The optional paths require higher skills to reach.
User created levels: By including a level editor, Nicklas encourages folks to make levels to their liking. The result is a slew of 'hard' and 'very hard' levels that skilled players can load at their leisure.
By designing all high difficulty challenges to be optional, Knytt Stories still maintains its accessibility to the new user without alienating the more advanced player. In fact, I'd recommend taking someone off the street that has never played a game in your genre and seeing if they can play through your title and reach the end. If they can't, try turning the difficult portions into optional expert challenges.
Accessibility issues As accessible as Knytt is, it does have some issues that may hold it back from broader adoption. For one, the art style relies on a deep appreciation of old school pixel art aesthetics that may be difficult to grok for many game virgins. As someone from that culture, the game is gorgeous and highly evocative. I'm curious how it might appeal to people outside the gaming culture. I'd like to imagine that retro is cool these days, but I have no data to support such hopeful musings.
Secondly, the game lacks any sort of marketing or awareness. Nintendo and Microsoft can force a new game into the public consciousness with their lavish marketing campaigns. Knytt is a simple little game on an unassuming website. Its fans are a tiny community with few ties to the larger world.
It unfortunately doesn't matter how accessible you make your game play if people don't know about the game and fail to trial it.
Conclusion I could go on and on about Knytt and Knytt Stories since they are rife with some truly great design decisions. This is the game that opened my eyes to the immense design possibilities still present in 2D platformer game mechanics. More generally, the design of Knytt points to one formula for resurrecting a dying genre.
Focus on accessibility: Serve the needs and skills of the broader audience, not the existing genre addicts.
Exploration, not traditional skill-based rewards: Build the game around broadly enjoyable activities like exploration and discovery of evocative places, not those that results from grokking advanced skills.
Minimize the traditional UI: Don't assume the standards are necessary or even desirable.
Allow for low cost experimentation: Build an atmosphere of safety and experimentation
Layer difficulty: Make the hardcore game play optional.
What would happen if you applied this formula to an RTS title? Or an adventure game? Or a FPS? I suspect you'd end up with a fascinating title that quite a few people would want to play.
As an experiment, tell your spouse about this game. Tell her (or him!) it is like reading a great children's story and will make her life better. If she enjoys it, ask her to tell all her friends about the game. Record those things about the game that she dislikes. This is great fodder for your future designs.
If I were Sony, Nintendo or the folks over at Xbox Live, I would be pounding on Nicklas' door with a juicy downloadable contract in hand. Add a spare programmer or two and a dash or marketing, and this game could easily turn into a breakthrough brand. That route may not embody the Nifflas philosophy, but at least he should have the opportunity.
take care Danc.
References
Evolving platform mechanics: It seems that there is a burbling of interest in the platform-esque game mechanics.
Braid: More traditional puzzle focused fare, albeit with quite original time-based mechanics.
Aquaria: Another upcoming 2d scroller that seems to have a bit of an exploration element. Perhaps not a traditional platformer, but I'm flexible.
Tree Story: A design sketch of my own that is a mix between Animal Crossing, Harvest Moon and a platform game. The movement technique need not determine the focus of the game.
Nifflas Games: Home of Knytt and Knytt Stories. Yes, both of them are completely free and provide a more memorable experience than easily 90% of the drek sold at Gamestop.
You can show your appreciation by donating directly to Nifflas using the link below. He runs an Open Kimono business, so you can see exactly how he spends his well earned gains. I think the word is 'frugally'
Yesterday morning I woke up from one of those startlingly lucid dreams where I was playing a completed game design. I tell my wife that odd ideas are like exotic fruit and if you fail to jot them down, they will rot away, never to be tasted again. So here are my quickly captured notes of what is, literally, a dream game of mine. :-)
Imagine, if you will, a space strategy game. You start out with a single planet surrounded by hostile enemy planets. Your goal is to clear the map of enemies and create a galaxy spanning civilization. All pretty standard stuff.
The difference is that you fight and grow using music that you compose by building your empire. This is where it gets trippy.
Planets as sequencers Watch this movie clip of a multi-touch music creation tool. It is wonderfully bizarre.
The basic gist, multi-touch madness aside, is that smart objects positioned on a flat screen can be used to create music. Link them together using a directed graph and you have a pretty competent music sequencer and sound effects generator.
The game design leap is that these objects can also be planets in a strategy game. Each planet has a different effect.
Forest planets are sources for sound effects
Water planets are filters for distorting a sound.
Cities planets are sequencers for taking a sound stream and playing it out over time.
Throughout the design, you’ll see that every element can be seen in two ways. One is as an element of a song. Two is as part of a game.
Linking planets Each planet has a space port. You can drag a space lane from a space port to another nearby planet.
In the process, you connect a sound source to a sound processor. In very short order, just by linking up space lanes, you can create a giant sequenced sound machine. At the same time, you are directing trade and setting up your space empire. Setting properties on planets Each planet is a fanciful user interface that lets you adjust the properties of the filter.
Planets have a sun. You can adjust the time it takes for the sun to go around the planet in order to adjust the timing of how long a sound plays. In the game this is described as planetary engineering
Distance from the other planets effect the volume of the source sound effect.
City planets allow you to adjust the height of the cities, thus allowing you to adjust how you sequence a sound source.
Music = culture = resource Each planet produces a sound. Some generate sounds. Others take in sounds and modify them. The stream of sounds produced by your planets is what most folks would call music. It also represents ‘culture’ in the game. Culture is the resource that makes everything in the game work.
Culture pools in planets that are the final destination of sound streams. They collect it in real time. Culture can be spent on upgrading your planets and creating war ships, defending against attacks.
The enemy does not sleep You are not alone in the universe. There are other planets on the fringes of your empire. They send ships to destroy your civilized worlds and knock them back into desolate husks. They’ll disturb your carefully calculated rhythms, disrupt trade routes and generally cause your empire to devolve into chaos, then silence.
If a planet is attacked enough, it will be turned into a dead world, devoid of music.
Spending culture Luckily, you can use your culture to both defend, fight back and ultimately conquer the enemy planets.
Some planets have industrial complexes. An activated industrial complex sucks in culture and converts it into ones of three main types of ships
Defenses: The planet builds a shield for fending off enemy attacks. It can take X damage per second. Defenses tend to beat equally matched ships.
Attack ships: The planet can send out a stream of attack ships. If the planet is poorly defended, the planet is slowly bombed into the stone age and reduced to a simple forest planet.
Ambassadors: Ambassadors convert dead planets into player planets.
At first you defend against attacks. Then you fight back. Eventually you conquer the enemies and make their worlds yours.
The benefits of conquest Conquest is great. Capturing new worlds allow you to build more complex sequences of sound. This means more interesting songs. It also means that culture accumulates faster and allows you to expand your empire further.
Some planets have tidbits of plot, mysteries, single use powerups, treasures and other rewards. Conquest advances the player in the game.
Culture is multiplied by audience appreciation An empire is a song. As a song it can be shared with your friends outside of the game. At any point, you can send a link to your empire to a friend. They can check it out and simply by the act of listening to your song, your empire gains marvelous bonuses.
If they like, your friends can rate the song. This gives you even more bonus culture. If they like the style of your songs, they can subscribe to your various empires. This gives you even more bonus. By sharing your creations with the outside world, you gain resources that let you advance your single player game.
A game that encourages the creation of great songs The game is balanced to encourage this. During the early stages of creating your empire, there is enough culture in random combinations of planets to conquer a fair portion of the map. Eventually, you start running out of culture. You’ll come across powerful enemies that you cannot defeat unless you start sharing your songs with others.
Good songs, as judged by an audience of your peers, will gain you greater rewards than random garbled messes of sound. Judging music is hard for a computer. However, it is easyier for people. The design harnesses your friends as our AI judgment algorithm to encourage and reward the user to become a great composer.
Some maps can be explored and beaten if the player creates songs that are enjoyed by one or two people. Other maps require that the player create songs that are loved by hundreds.
The enemy as a tutorial The map creation for the game is tricky since it serves two purposes. The first is to provide a challenge to the player. This is pretty straight forward level design and deals with choke points, resources, power ups etc.
The second, more devious goal, is to teach the player compositional structures. The enemy worlds are a nodal graph of a song just like the player’s worlds are a graph of a song. The level designer composes the enemy empire as a song.
All the various tricks of making a song are there for the player to see. The way that you distort a basic sound into something intensely cool. The way that you use a sequencer plus a snare sample to create the beat. All of it is visually laid out as a working model for the player.
When the player conquers the enemy worlds, they are essentially deconstructing the level designer’s song filter node by filter node. The player is then asked to put their newly acquired node to use. The easiest thing would be to replicate what was already done.
What we have is an experiential lesson in music composition masquerading as a game.
The player observes a functional model.
They dissect the model to understand its parts
They are required to reassemble the model and make it work again.
They are rewarded for making something better than the original.
Conclusion I finally got around to reading Rules of Play by Katie Salen and Eric Zimmerman. The tome repeatedly emphasizes that you can analyze a single game through multiple perspectives. Celestial Music is a game that is two things simultaneously. It is a strategy and it is a music creation tool. It is also, by the fact that is both of these things, a system for exploring and learning music in a user friendly manner.
Games lubricate experiential learning about a system. Plunk an inexperienced person down in front of a piano and some sheet music and they will become frustrated. Sit that same person down in front of a game like Celestial Music and they will slowly learn. The result may not be Mozart, but it will certainly be music.
As I awoke groggily from my dream yesterday, I was left with the amazing memory of playing this quirky game. Sound and visuals flowed throughout the screen like some clockwork instrument pulse with life. There was no real distinction between building something beautiful and playing an enthralling game. Delightful.
Take care Danc.
References
Human computation Humans are far better at some activities than computers. Luis von Ahn is a computer scientist at Carnegie Mellon that studies how to tap into the abilities of people to solve hard problems like image recognition or human identification. He uses games as his medium. The fact that people are better than computers at determining what is meaningful music is leveraged in the Celestial Music design. http://video.google.com/videoplay?docid=-8246463980976635143
I've been filling notebooks with extensive sketches of worlds built out of a single homegrown tree. Houses, monuments, clouds, vines and more, drooping, draping and bursting forth in a blossom of growth.
Last night I had a chance to jot down some of the graphics in Painter. My few hours of effort resulted in a basic tree trunk, some foliage and a little girl. Overall, I suspect this would be a pretty easy game concept to get up and running.
Further implementation thoughts Harold stopped by last week and we brainstormed a little on the Tree Story idea.
Collision detection: The foliage uses 1/2 circles as a the collision detection zone instead of the typical rectangles you find in most platform games. This should give the worlds a bit more of an organic feel and results in some simple controls. For folks that have been playing with the Space Cute graphics, you may be able to reuse your existing collision detection systems.
Bundling to create platforms: By overlapping a few simple foliage brushes, you can create interesting and realistic trees.
Blurry parallax layer for depth: You can create a feeling of depth by putting blurred foliage on a parallax layer behind the main action. Scroll this layer at a slower pace than the main layer that the player is on and it will seem like the scene has perspective.
If anyone is interested in playing with some of the graphics, let me know and I can upload a few in a more reasonable form. Before implementing images, I'd recommend first creating two simple prototypes:
Movement prototype with primitive half circles for terrain and a blob for the player to test out movement and the 'fun factor' of the design.
Tree prototype: Use long rectangles and half circles to see if you can auto-generate interesting trees.
Hope you are well on this rainy Seattle sunday afternoon. :-) I think it is time for a bit of tea.
It has been a bit quiet in the garden this summer as I've been busy working on a set of longer essays. The first, The Chemistry of Game Design, is up on Gamasutra this morning. You can read it here.
A blurb from the article:
'“…it was clear to the alchemists that "something" was generally being conserved in chemical processes, even in the most dramatic changes of physical state and appearance; that is, that substances contained some "principles" that could be hidden under many outer forms, and revealed by proper manipulation.”
I recently happened across a description of alchemy, that delightful pseudo-science of the last millennium that evolved into modern chemistry. For a moment I thought that the authors were instead describing the current state of the art in game design.
Every time I sit down with a finely crafted title such as Tetris or Super Mario Brothers, I catch hints of a concise and clearly defined structure behind the gameplay. It is my belief that a highly mechanical and predictable heart, built on the foundation of basic human psychology, beats at the core of every single successful game.
What would happen if we codified those systems and turned them into a practical technique for designing games?'
The article describes a psychological player model and a system for visually mapping out how skills are mastered throughout a game. There is even a diagram of what Tetris might look like. :-) This essay introduces the basic concepts. In the future, I'd love to explore how these ideas might be used as part of an iterative design process.
I find systems skill atoms and skill chains incredibly exciting since they have the potential to ween us off our over reliance on reuse of existing genres. By understanding the rules behind why games work, we can synthesize new, highly effective game play from the base elements.
Feel free to post any reactions (allergic or otherwise) in the this blog post. :-)
I just wanted to share a quick design that occurred to me this morning. This isn't a design challenge since I don't have new graphics for it. We watched My Neighbor Totororecently and my brain has been quite inspired by the scene where Totoro grows a giant tree from a seedling. I imagine that with a sufficient level of polish, this game might inspire some of the same feelings of delight and awe.
So I present to you Tree Story, a platform game where you grow trees in order to collect all the pieces of your broken heart.
The Tale One upon a time, a young girl in love sang a most beautiful melody. A Bird of Fate, called by her song, blew through the window and struck her full upon the chest. Her heart shattered and she could love no more. Full of sorrow, she left her lover behind and began wandering the earth. She sits now alone on a land that borders a distance sea. All around her is emptiness. The only thing she owns is a single seed. If she plants it, it will grow into a tree. Perhaps, if she is strong enough, she can regrow her world and rediscover the pieces of her heart. Only then can she love again.
Movement You control a character that sits in the middle of a scrolling screen. On the screen is a simple scape made of branches and foliage. At the bottom of the screen is the sea. You start on a small island in the middle of the sea.
When you press left and right, you can walk around the circumference of the tree foliage until it becomes completely vertical. Your character is always oriented relative to the normal of the foliage.
You can jump using the jump button (the up arrow)
When you jump, you jump straight out from the normal of the foliage. However, gravity points downward.
You have some slight air control when in the middle of a jump using the left and right arrow keys.
If you hit another bit of foliage, you grab on and reorient yourself to the new foliage.
Objects There are many objects that are strewn about the world. You can interact with them in a variety of ways.
Picking up a seed: If you happen across a seed object, you can pick it up by running into it. You can only have 1 seed at a time, so if you run into another one, you will ignore it.
Using a seed: You can plant a seed by pressing the action button. When the seed is planted it will sprout into a tiny branch with a new bit of foliage. This slowly grows on its own until it reach a small fixed size.
Picking up flowers: If you happen across a flower object, you can pick it up by running into it. You can have as many flowers as you want at a time.
Growing a branch: If you stand at the base of a branch, you can feed it flowers in order to make it grow. By standing at the base of a branch, a HUD appears that instructs you how to perform the basic growing action. Hold down the action key and press up. Your flower count will decrease and the branch will grow. I can imagine turning this into a simple rhythm game, but for initial prototyping it is okay to keep it simple.
Bending a branch: You can also bend a branch. Stand at the base of a branch. Hold down the action button and press left or right. Your flower count will decrease and the branch and its foliage will grow. Branches can only be bent so much.
Chopping off a branch: You can remove a branch. Stand at the base of a branch. Hold down the action button and press down. A meter builds up and you give the base a mighty blow. The branch and any attached branches will be turned back into seeds that fall to the ground.
Picking up a star: Stars hang in the sky. Most of them you cannot reach. However, if you grow a tree, you can climb upon it and reach a star. When you catch a star, it pops and spits out a random prize. The prize could be a branch seed or it could be a dozen flower seeds. The prize falls down and rests upon whatever foliage it hits. Flowers seeds immediately blossom into flowers when they hit foliage.
Picking up a heart: If you happen across a piece of the young girl's heart, you can pick it up. Collect enough pieces and the girl is able to love again.
The basic game play You start with a single seed that grows into a tree. You climb upon the tree and reach new stars. When you collect them they sprout into seeds and flowers. When you collect the seeds and flowers, you can grow new branches off your old tree. This in turn allows you to reach more stars and grow more branches. Eventually, you collect all the hearts and win the game.
Advanced game There are numerous types of seeds, each of which creates a different branch.
Tall branches
Fat branches
Branches that sprout extra flowers all on their own.
Branches that sprout a specific type of seed if you feed them flowers.
Branches that are homes for little creatures. They tell you hints, bits of story and give you goodies. Give them a seed of the desired type and they may give you a rarer seed in return.
Branches that teleport you to another sister branch
Branches that sprout powerups that give you temporary flight or super jumps or double the number of goodies that you get from stars.
When night falls, more stars appear. When day comes, more flowers sprout and trees grow larger. There is a natural rhythm to the game world, despite its simplicity.
Winning the game There is only one level in the game. This is not a puzzle game where you beat carefully designed levels. It is a playground game where you build and build and see how far you can get. The more hearts you get, the closer the girl becomes to achieving true love. Players who win will have built hundreds of branches and their tree will cover the entire map.
The game can be won, but it can't really be lost. If you come back to your saved game later, new flowers will have sprouted and new stars will have appeared. The little creatures on the map will have new trades and they'll let you know that they missed you.
So there you have it. There is a dash of Animal Crossing mixed with a hint of Knytt and a whiff of Little Big World. And of course, the spirit of Totoro. In my head, at least, it all seems like a pleasing way to spend an afternoon. :-)
For some odd reason, I've been chatting more with people that are interested creating web 2.0 applications that borrow substantially from online games. If you see games as a technique for teaching skills and maintaining attention in a pleasurable fashion, I would expect this crossbreeding to only expand in the future.
Why games are interesting to the web Website developers are desperate to have their users enjoy the experience of using the website. If you look at traditional usability and interaction design literature, it says a lot about improving functionality, but almost nothing about making that functionality pleasurable. In the gap there as emerged a faith derived aesthetic where minimalist, highly efficient interfaces are described as the major source of user pleasure. If the only tool in your toolbox measures efficiency, that is what you as a designer value. Regardless of whether or not cold efficiency is what your users value.
Games are interesting to web developers because they demonstrate a rich set of techniques, proven over the course of thousands of projects to keep users heavily engaged. Experience points, in game currencies, mission, player housing, avatar creation, and guilds are some of the meta-game systems that are almost immediately applicable to practically any existing class of application. These keep users around longer, give them an increased sense of community and when used appropriately give them warm fuzzy feelings.
Another area of great interest is that game explicitly deal with the concept of user exploration and the acquisition of new skills. They are experts at giving users the freedom to explore at their own pace while still encouraging the user to master new techniques, tools and skills. At the end of a game of Zelda you've learned hundreds of new techniques and you've enjoyed doing it.
At the end of a few hundred hours of used Digg, you've learned perhaps one or two new techniques. If you are really lucky, you've figured out their commenting system. Modern interaction design has great difficulty with the topic of learning. The current rule of thumb is that users should never be forced to learn any new skills in order to use the application. This greatly limits the scope of potential designs and their ultimate usefulness to expert users. Game techniques, as systems that teach, allow designers to break free from the oppressive assumption that they must only design for the lowest common denominator.
The baggage of games Games also bring with them some interesting baggage. There is an unfortunate tendency to copy wholesale a game design and merely reskin it with a new theme. Math Blasters is
