Directory of All Essays

Sunday, May 11, 2008

The Scary List


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.

Courage, you see, is also contagious.

take care
Danc.

Labels: ,


Read more!

Sunday, April 13, 2008

The joy of 2D avatars




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!


take care
Danc.

References


Labels: , , ,


Read more!

Wednesday, April 09, 2008

A Services Strategy for Casual Games


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.

take care
Danc.

Labels: , , , ,


Read more!

Sunday, March 30, 2008

The Translation Game

The Rosetta Stone: I18N's early best friend

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 bad
The 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.
  1. Identify: Identify players with base level skills are capable of performing a desired task.
  2. Action: The players perform actions using in-game tools in the hope of receiving a reward.
  3. Review: The game independently verifies the actions using other players for tasks that require human computation.
  4. Reward: The game rewards the person performing the original action based off the verification process.
  5. 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:
  1. 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.
  2. 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.

Take care,
Danc.

References



Labels: , , ,


Read more!

Wednesday, February 13, 2008

GDC: Social lessons of years past


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."
The full talk:
Some more about Dani Bunten Berry:
See you at GDC!
Danc.

Labels: , ,


Read more!

Wednesday, February 06, 2008

Play With Your Peas: A game prototyping challenge


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.
  1. Pea falling physics: In order to do the pea falling correctly, you need a simple physics engine that deals with balls and planes.
  2. 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.
  3. 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.
References
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.


Labels: , , ,


Read more!

Thursday, January 31, 2008

My wife collected 121 stars


Super Mario Galaxy found at least one avid fan in our household. :-) I just had to share.

take care
Danc.

Labels: , ,


Read more!

Wednesday, January 16, 2008

Project Horseshoe Report: The Watery Pachinko Machine of Doom

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.

take care
Danc.


Here is the beginning of my post. And here is the rest of it.

Labels: , ,


Read more!

Wednesday, December 26, 2007

Super Mario Galaxy: A breakup note


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

References

Labels: , ,


Read more!

Tuesday, December 18, 2007

The Naked Business

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 fai