Sunday, April 30, 2006

Who knew Pikachu was so big?

We were looking through photos from last summer and I came across this lovely image. It was one of those photo opportunities I couldn't resist. I'm rather curious what percentage of revenue comes from the games and what percentage come from the merchandizing offshoots.

For a good overview of the Pokemon brand management and product introduction issues, I highly recommend this case study:

take care

Wednesday, April 12, 2006

The joyful life of the lapsed game developer

Once upon a time I was a passionate game developer. Though I still love games and game design, I no longer work in the game industry. I have forsaken the church of game development for the easy and highly rewarding life of mainstream software development.

This is my happy story.

What brought me down this path?
It began with a common enough tale in the game industry. The project I had worked on for the previous two years was canceled. After all those 80 hour weeks, fueled by a feverish passion to build something marvelous, I was cut loose. I never went back.

There are lots of people like me. In fact there are more lapsed game developers in the world than there are current game developers. Let’s look at some back of the napkin numbers. The average career in the game industry is 5 years. With 800 mainstream games a year and an average team size of 40 developers, we have a rough population of 32,000. If 20% leave a year, that’s roughly 6,000 new lapsed game developers every year. Over the past decade, that rapidly adds up to 50,000 or more lapsed game developers.

This doesn’t include the smaller shops that generally have a higher turnover rate. Feel free to refine the numbers, but the basics still stand. The population of lapsed game developers dwarves that of current game developers. If you could put together a LGDC (Lapsed Game Developers Conference), it would be at least twice as large as that little show in San Jose. And when Chris Crawford gave his keynote we would cheer maniacally.

Because he is our god.

Oh, those little reasons
I joined a company that ended up making middleware for the game industry. I still was able to maintain many of my old contacts, but the work environment was quite different. I learned about new ways of doing things that were quite shocking and delightful. As the years have passed, I’ve always contemplated going back, if only to recapture that raw emotion of pushing my creativity to the edge. Yet I never have. Most of our happy 50,000 strong brethren never do.

There are lots of reasons of course, some of which are the fault of the industry at large. Many however are due to the fact that I’m having a blast doing what I’m doing.

The short list of things that kept me away
These are some of the issues that you’ve heard before. They bear repeating.

  • The stunning and widespread ignorance of project management: Fresh game developers are like conscripts in the Red Army, tossed untrained into the teeth of the advancing Germans. They get the job done, but the unnecessary psychological bloodshed is appalling. The 95% chance that I’d end up on a team run by bullheaded milestone sluts that worship the rush of the crunch is worrisome. Everyone has bad practices, but the general inability or unwillingness to learn and adapt is a deal breaker.
  • A general lack of exciting projects: The chance of working on a truly meaningful game project that changes the world is slim. I’m an oddball in that I enjoy making games with interesting new game mechanics. Churning out sequels with mildly upgraded graphics does not seem like a worthwhile way to spend my life. This isn’t insurmountable, but it does reduce the number of viable opportunities.
  • Pay: Taking a roughly 20% pay cut is hard to justify. Pay has nothing to do with money and everything to do with respect. It is hard to swallow my pride and admit to the world that I am worth less because I happen to work in the game industry.
  • Family: We’ve been talking about kids lately. 80-hour work weeks don’t leave much time to change the diapers or watch your favorite little woobie-boo take her first tottering steps. You can’t get those moments back. The thought of giving that up just so I could make a button on a car configuration screen glow a little more brightly makes my heart break.
The things that kept me doing what I’m doing
Here is a little secret. Staying away isn't all about the game industry's faults. It turns out that the world outside of game development is quite wonderful. It is full of fresh honey, flowers, and lithe and luscious servants feeding you goblets of purest nectar. It is a fundamentally better life.

Over the past twenty years, while game companies have been churning and burning their way through the disposable lives of their enthusiastic employees, other industries have been learning and improving. Software development is no longer a mysterious black box…there are better ways of doing things that improve the lifestyle of the workers while improving the bottom line of the company.

Sure, there are still quite a few miserable groups out there, but tides of knowledge have lifted all the boats.

  • Agile development: Once you have run a successful agile software development project, you can never go back. It is the difference between being happy and tired each day after honest labor, and feeling like you’ve spent the day slogging through a wasteland of mud up to your neck. The team is in control and they tend to make products with lower overall design risk and lower execution risk. Agile development works and it has opened my eyes to the possibility of software development without suffering.
  • Reasonable work hours: I have done more than my share of all-nighters, but it pragmatically is not worth it. Here is a little tidbit from the High Moon talk at GDC. By the 4th week of working overtime, your productivity drops below your 40 hour a week average. By working normal hours, I’m happier and I get more work done. People outside the game industry are not lazy when they go home at 5pm. They are smart.
  • Making the world a better place: The applications I build now help people in a very concrete way. I like that warm fuzzy feeling. I was talking to a fellow lapsed game developer who now works in 3d imaging in the medical field. He told me “The work I do now saves people’s lives. You can’t beat that.” There is a moral core that is missing from the game development community that exists in other industries, even in other entertainment sectors. In movies, you can still make documentaries that right past wrongs. In books, you can seek to help and enlighten. In games? I wonder.
Lapsed game developers won’t be coming back
Is the game industry better off without those 50,000 lapsed game developers? Surely, most were slackers that would have just slowed the rest down?

I was a reasonable game developer. I single handedly drew 95% of the graphics for Tyrian in a 4-month period of time, roughly 1/2 to 1/3 the time that art for comparable games had taken. You’ve read my essays on business practices and game design. Could I have contributed? What is more important is that there are likely hundreds, if not thousands of lapsed game developers out there who are far better than I will ever be. Surely, they could have helped the industry in some meaningful way.

It is too late now.

Instead, those talented folks have gone out into the bigger world and seen amazing new wonders beyond even the wildest imaginings of their kept game developer brothers. They stay away, not because they are weak or ignorant. Lapsed game developers stay away because they’ve seen the light of quality pay, reasonable work hour, jobs with meaning, and competent management.

In the process, they’ve incorporated new knowledge of business and successful development practices. Instead of simply doing more, they do the right things first. They have evolved into something wiser and more capable than those who stayed behind.

To all those who are lapsed
This essay is a joyful call to all those wonderful people who are leaving the game industry. Welcome to the bright side of life. You are blessed.

To all those who are tempted
If you happen to be between projects and are questioning your allegiance to the brotherhood of game development, here is a suggestion. Find an Agile development shop that is doing something you could believe in. Try it out for a year or two. If everything I’ve said is a lie, you can always go back. If it isn’t a lie, the experience will be well worth the time, for you, your bank account and your family

To all those who are lost
For all those mournful souls still strapped to the burning cross of waterfall milestone hell, I really wonder if it is possible to improve your lot. I suppose you could learn some modern project management skills. Or you could question why you do things the way that you do and see if there were any alternate methods that might be better. You could even learn from successes outside of the game industry.

In the end, it is probably far too much work. Better to continue what you are doing and to continue to fail. It is certainly far better to continue to damage your mental health and starve your family of both money and your love. The way things are right now is just easier for everyone.

I have faith however. Because, eventually, you too will join us.


It worked, didn’t it?

This is why you should join the LGD coalition:

These people are crazy.

Ah, Chris.

Sweet Jesus. Artwork!!.htm

Sunday, April 9, 2006

Jesse Schell, over at Carnegie Mellon, dropped me a note on a fun project documenting game design innovations. I normally do not post the editorialized links that you find on many sites. For this, I’ll make an exception. Here’s the blurb:

"The Game Innovation team is launching The Game Innovation Database (GIDb) today. The goal of the GIDb is to:
  1. Document every innovation in the entire history of computer and videogames.
  2. Provide a comprehensive taxonomy for classifying videogame innovations.
  3. Make its data available through an online wiki.
  4. Serve as a forum to discuss the importance, influence, and possible future applications of various innovations.
Anyone can edit and contribute entries. The GIDb is designed for a variety of users. Instructors can use it for teaching videogame history and design classes. Game developers can use it as a tool for research and brainstorming. Game players, enthusiasts, and researchers can find information about specific games and can easily share their own knowledge. Those with a strong interest in videogame innovation may apply to join the GIDb Editorial Board.

Please feel free to make contributions and pass this along to friends and colleagues. We need your contributions and input!

The GIDb can be found at"

So what?
Here’s why I think this is important. Language is one of the biggest barriers to discussing game designs in an intelligent fashion amongst educated game designers. Currently, each designer is an island, isolated by and limited to their own design experiences. When they attempt to discuss even basic concepts with other designers, the terminology just doesn’t exist. Conversations devolve into exercises in semantic nitpicking as both parties desperately attempt to invent a common terminology on the spot.

I overheard a conversation at GDC where two developers were talking about how games must be challenging in order to be fun. I butted in and said, “What about Animal Crossing? Surely, this is a game that is not about challenge?” It turns out they were discussing Animal Crossing as a prime example, and they looked at me like I was an idiot. Quite understandable. After a few more fumbling attempt, it turned out they were using the word “challenge” were I was using the word “inconvenience” I happened to have a very particular definition of the term “challenge” and the misunderstanding sunk the entire conversation before it even started.

Multiply this one situation by the thousands that have occurred throughout the history of modern game development and it is no wonder that game design is considered to be mostly black magic practiced by a few mysterious talents.

Academic language definition is not the answer
Language is rarely defined through academic rambling. It instead tends to evolve and standardize through everyday usage. I would love to sit down and write a game design dictionary filled with exacting academically defined definitions. However, that would be next to useless. Many have tried and almost universally their work is ignored, except perhaps by a few brilliant eggheads. Academic definitions of game design contain too many words and not enough obvious practical applications where people can actually use the proposed terminology.

I like the approach taken over at because it consists primarily of practical examples. The site consists of dozens of types of game mechanics listed in a format that tells you why they are different, why they matter, and how they relate to others game mechanics. I can easily imagine a game developer browsing through the topics in search of inspiration on their next game.

Game design documents are rhetoric, and the same goes for text-based descriptions of game mechanics found in most writing on game design. In this wiki, however, most of the items listed are real games, many of which are available through emulators or in someone’s video game collection. You can play them and grok the described mechanics on an instinctual level. This is useful data that can be absorbed experientially.

The terminology listed in the taxonomy may seem secondary, but it always exists, lurking in the background. It helps guide your understanding of the information you are consuming and helps integrate your mental models of how games work. When you talk about the concepts that mechanics that you’ve learned with others, how do you communicate them? I am a lazy fellow, so I tend to forward the link from an existing web page onto my friends. I’ll reuse the same terminology so that I don’t confuse folks. The result is a common reference point, anchored in shared experiences.

In the end you have a pragmatic set of useful examples that drive language unification, not some academic dissertation on the definition of the word ‘fun’. It is a classic example where ‘show me’ may well work better than ‘tell me.’

Take care

PS: Blogger has informed that this is officially my 100th post on That is a lot of pseudo-academic blathering, if you ask me. :-) Hope folks are enjoying it.

Thursday, April 6, 2006

Team culture matters

I just thought I would repost this lovely Slashdot comment that I came across recently. For some reason, it caught my eye.
"Having lived through the Microsoft buyout of a game studio, perhaps I provide some insight into why acquired studios seem to lose their mojo. Disclaimer: This are my opinions only, and come from the individual contributior perspective, not that of the studio management.

First off, Microsoft corporate culture does not map well to a typical successful game studio, and no matter what assurances are given that the studio's culture and operations are going to be left intact, within a couple years the studio becomes fully integrated into the 'Microsoft Way'.

Probably most destructive are the Microsoft one-size fits all HR policies such as stack ranking. Game development is truly a team effort, and successful studios have managed to create teams where most of the performers are above average. Instead of being able to reward people fairly, a pre-determined number of people each year have to be given a "poor" review which includes no compensation increases of any sort, and the warning that if they fail to improve by next year, they will be on the list of people to be 'managed out'. On the other end, a smaller pre-determined number of people will be rewarded handsomly no matter if they have not produced anything to merit such. So a culture of teamwork, focus on the product,and pride in the company will quickly morph into a culture of individual self-promotion, politics and backstabbing, and a disdain for the company.

Additionally, as part of Microsoft, the studio no longer has the urgency to make the next game great and complete it in a timely manner. With Microsoft's billions insuring financial stability if a game is cancelled, and no direct financial upside to
producing a hit game, the pressure of living close to the edge that was present
in the old culture that helped the team focus is supplanted by a devil may care
attitude that creeps into the 'rank and file'.

As a result, many of the developers transform from passionate, competitive people who strive for excellence into someone who just 'does their job' and goes home at 6pm sharp. Others just leave for greener pastures. Management gets their large bonuses in any event.

There are other issues of course, such as loss of control over future projects, headcount restrictions that prevent a studio from hiring desperately needed people, and so on."
-Anonymous Coward
Developing most modern games requires a team oriented culture. That means team focused management, team goals, team rewards, team dashboards, team seating, and team vision. Unless you are talking about very small indie games, one person cannot do it all.

If game development is a communal activity, do we structure it as such? How team members communicate with others, the alliances they form, the expectations they share...these deeply social interactions matter. It turns out that software development is an exercise in social problem solving. Many minds working together produce amazing solutions that no one individual could create on their own. It is a fundamentally human activity performed by people for people.

When managers, analysts, and the man in the trenches forsake their culture in the pursuit of the bottom line, the bottom line suffers. A gelled team of programmers will experience a roughly 10x improvement in productivity compared to a collection of individuals. This isn't about technology. It isn't about process. It is about the subtle psychology of people working together. When you encourage a strong team culture, amazing things are possible. When you discourage it through micromanagement, asinine review processes, and lack of a clear vision, you will always wonder why you failed.

take care

PS: If you believe in the benefits of teams even in the slightest, stack ranking is an abomination.

Wednesday, April 5, 2006

Managing game design risk: Part II - Data Driven Development

Read part Managing game design risk: Part I here. It provides an overview of different classes of production processes and their relationship to various forms of risk. The next two essays will talk about common techniques for reducing risk.

The first technique, data driven development, involves lowering execution risk by investing in lower risk product features and processes. This low execution risk strategy is the predominant technique used by game developers to reduce risk and is currently considered state of the art by most development houses. Compared to naïve product development there are considerable advantages. However, there are also some unexpected side effects worth taking into account.

If we think about data driven development in terms of our process complexity spectrum, we want to drive processes out of the complex and chaotic zones down into the simple zone. Simpler development processes are easy to manage, easier to scale to larger teams, and far less likely to fail catastrophically.

Conceptually, data driven development relies on two techniques
  • Investing in existing low risk activities
  • Converting moderate risk activities into low risk activities.

Investing in existing low risk activities
The first step is to identify low execution risk items and invest in them. If we were to rank some common game elements according to risk, they would look something like this:
  1. New core game mechanics: High risk
  2. New to the world technologies such as better AI: Moderate-high risk.
  3. New Setting / IP / Brands: Moderate risk
  4. Level design: Moderate risk
  5. More of the same technologies such as improved rendering: Moderate-low risk
  6. Graphics / Cut scenes: Low risk
If you look at the resources spent on modern games, you’ll find that game funding priorities are roughly the inverse of their execution risk. Core game mechanics have the fewest number of people working on it during the length of the project, graphics of various types have the most, level design tends to sit someplace in between and so forth. It is a rough rule of thumb, but it works reasonably well.

Converting moderate risk activities into low risk activities
The next step is to simplify complex or complicated tasks in the hope of turning them into simple production processes. Game development in the past was saddled with some truly unpleasant risks.
  • Crazy custom code written under tight deadlines for hardware platforms that are still in flux.
  • Artist fumbling their way around new technology often introduced unacceptable schedule risk.
  • Assembling the game elements at the end of the production cycle often meant that level design and minute-by-minute game play wasn’t testable until very late in the development cycle.
Wouldn’t it be nice to simplify these areas dramatically?

Historically, the simplification of complex processes has occurred during the early stages of any new mass media life cycle. Let’s consider animation as an example of the typical evolution. Once upon a time, each artist drew in a unique style. If you wanted a Norman Rockwell illustration, you pretty much had to go to Norman Rockwell. In the case of early animation, you typically required one animator to create most of the frames of the animation. Animations were short, labor intensive affairs

Walt Disney (and others) came along with production techniques for the highly repetitive task of animation. They reduced the risk of producing a series images with the same visual characteristics. Suddenly, instead of having one artist working in a particular style, you could have hundreds, all laboriously following style sheet, all drawing Mickey Mouse. By defining specialized roles and standardizing the production process, early animation houses reduced risk and enabled the task to scale in a linear fashion.

The same process of risk reduction is occurring in game development.
  • Artist fumbling? This issue is solved by using standardized tools like Maya and Max and Photoshop. When they are tightly integrated in a unified tool chain, they increase the speed of creating complex graphics while reducing schedule risk.
  • Crazy custom code? Replaced by 3rd party rendering technologies like Unreal or Renderware which reduce the risk of rolling your own technologies.
  • Assembling game elements at the end of the production cycle? I sat through a lovely talk on God of War in which 7 programmers created a highly tuned tool chain that allowed designers to act as highly reproducible, lower skill production cogs. The entire issue of game mechanics was reduced to a ‘push button and play animation’ sort of affair. You could also play test levels early and often.
Data driven development
The result of these process simplification efforts is a production model known broadly as ‘data driven’ development. By focusing on low risk development elements, tasks like creating graphics, models and other static content becomes the primary cost center for the title. The following practices are common.
  • The company invests in a centralized engine maintained by a relatively small number of programmers. Tool development takes on a hitherto unprecedented role.
  • Game mechanics are usually borrowed from an existing genre.
  • The team streamlines the flow of data into the game engine using a well defined content pipeline. This allows people without programming skills to build much of the using artist friendly tools. The data is rapidly translated into the game engine where it can be viewed running in the actual game.
  • The team then ramps up the number of artist / designers to fill the game with content.
  • The focus of the title is on providing the most exciting, highly polished static content to wrap the core game mechanics.
Data driven development optimizes many but not all aspects of game development. Some gameplay elements such as new game mechanics have not yet been reduced to simple production processes. These remain stubbornly in the land of complex or even chaotic process. Companies try to reduce these risks as much as possible by selecting well explored game mechanics.

God of War is a great example of this development process. They gained impressive production efficiencies by building a strong content pipeline around the proven gameplay. The core game play differed only mildly from beat ‘em ups from ages past. However, they make the experience feel fresh by skinning the mechanics with flashy content. Every time you pressed a button to open a door, you saw a new animation. Every time you killed a monster, you saw another new animation. It looks great and it doesn’t play all that badly either.

Benefits of data driven development
Data driven development is clearly superior to naïve game development processes of the past. It results in dramatic reductions in all forms of execution risk:
  • Technical risk: Because most of the game rewards come from content instead of complex systems, the need for taking on technically risk work decreases. There is no need to put in a complex physics engine when an animator can produce the same results with less risk to the overall project. The overall code size is much smaller and you need fewer programmers. The God of War executable was only 1.5 MB in size and this was produced by a mere 7 programmers.
  • Quality risk: By create a tight content pipeline that is regularly exercised early in the development process, errors are found early and fixed early. Because you are dealing with data instead of code, code errors decrease dramatically.
  • Schedule risk: Because game content is produced in a manner that scales linearly at low risk, you can easily throw more people at the problem or cut back scope if there is a threat of schedule risk.
  • People risk: By having content readily playable and instituting style guides, Disney-style directorial control can be imposed on areas like level design. This lets companies use relatively low skill designers as ‘production cogs’. They are replaceable, easily trained, and scalable to large work teams.
This is an impressive feat. If you’ve ever lived through a poorly run game development process, the God of War presentation at GDC sounded like heaven. We all want to create a high quality game that lets us spend the last day of development on the beach. If you don’t understand the techniques and processes involved, your skills are behind the curve and your games will suffer.

Opportunities for deploying data driven development
There are two classes of game that benefit strongly from implementing a data driven development process
  • Genre king brands competing in mature genres
  • ‘Story games’ that rely primarily on quality static content
The obvious win are products that are at the end of the genre life cycle. Such teams are serving a well-defined market populated primarily by late and laggard adopters. Since the hardcore ‘genre addict’ customers they server are highly risk adverse, it is okay for the product to sport low risk features. Does anyone who buys Halo 2 really want a radical shift in game mechanics like you find in Animal Crossing? Not likely.

There are also very specific genres of game that benefit greatly from data driven development. Japanese RPG titles, graphic adventure games, and other games whose primary value comes from giving the player a strong linear narrative can use a robust content pipeline to cut their execution risk.

These ‘story games’ compete head-to-head with the tales in other linear narrative formats such as movies or books. The gap between the experience of a movie like Advent Children and a ‘game’ like FFXII diminishes with each new sequel. Such titles have forsaken interactivity as the primary method of providing players with value. The more high quality static content, the better.

Problems with data driven development
Data driven development is the future for a large portion of the industry. It is simply so much more effective at managing risk than older methods. However, there are issues that the smart development team should take into account.

  • Market issues: Low product differentiation
  • Cost issues: High production costs
  • Game play issues: High player burnout
Market issues
How do new games compete? This is a big question. I humbly submit that the unique value propositions in games typically are centered on innovation in interactivity, not the static fluff wrapping the interactivity. For example, in Nintendogs, the value comes from interacting with a dog, not from the resolution of the wallpaper in the room. Even in God of War, the core value comes from the combat, not the pretty animations.

The low risk activities that data driven development relies upon also happen to be low value activities. You can easily add considerable graphics, level design and animation to a product and only add incremental value to the customer. When companies compete using fluff elements such as graphics and level design, you end up with a slew of undifferentiated products.

In the early days of middleware, Epic started licensing their Unreal engine. Licensees replaced the graphic and the levels, but failed to innovate in terms of new game mechanics. The licensees believed they were offering new and exciting content. Players on the other hand, saw this flood of titles as inferior FPS with tire game mechanics. They ran smack into markets dominated by genre kings Quake and Unreal. These titles failed. Ah, the irony. Differentiated content is not enough to compete.

Cost issues
The other issue is that the strategy of risk reduction is not a cost reduction technique. By ensuring that production activities scale in a linear fashion at low risk, all that happens is that development teams are encouraged to do more of the same in order to compete. Most companies blindly invest in the most obvious and lowest risk competitive option.

This is creates a vicious cycle:
  • The competition releases a title with ‘The best graphics ever’
  • Your team chooses to compete by putting money into the lowest risk production element. By simply spending more money, they can keep their risk of execution failure low and still mount a competitive product.
  • When another competitor comes out with ‘Even better graphics’, then your producer doesn’t mind at all hiring a baker’s dozen of new art cogs to up the ante. It won’t delay the product and could give the game an edge. This is an easy management decision.
  • The product releases and sells a very reasonable amount. Unfortunately, due to the extra production costs, it posts a loss.
  • Even though your title is a financial failure, it provokes other competing companies to spend more on the quality of their titles.
The cycle slowly drives profitability out of the marketplace. The results are low profitability games that launch in intensely competitive markets. A small percentage remain profitable by capturing the genre king crown, but most lose money.

Gameplay issues
If we look at data driven games from our action / reward game play model, we can also predict some key characteristics of data driven games.

Data driven games encourage player addiction by relying on two classic game design elements:
  • Visceral rewards: Visceral rewards are ones that attempt to trick the brain into reacting as if it were put into a real world, high intensity situation. You see a strong focus on emotional content and realism. Final Fantasy does this quite well by providing highly emotional drama in almost every cut scene.
  • Unique rewards: Unique rewards are rewards that are different each time the player successfully completes an action. The classic quote from David Jaffe is his desire for "Lots and lots of special cases. I don't want any two doors to open the same way” You are still pressing the same button, but the results appear unique.

Visceral rewards create very intense rewards. This can be very delightful to jaded players. Unique rewards, in the form of new animations, ensure that the rewards give the player a solid buzz each time they are encountered.

Visceral rewards have a high burnout rate, especially if they are reused. When you kill the Minotaur for the first time, it is quite exciting. After dealing with several of the beasties, the thrill of the kill wanes.

Unique rewards might seem like a good game idea, but they too have a dark side. With repetition, players will eventually grok the deeper patterns behind the ‘unique’ rewards. Ultimately, they see the impressively tumbling statue in God of War as yet another animation that opens a door. When the gameplay patterns become visible, players can prematurely burn on the title far sooner than the designer predicted.

This can lead to situations like Quake IV. Here the franchise was damaged because players focused on how the mechanics are ‘more of the same.’ They dismissed the new expensive graphics engine and the plethora of content that was intended to differentiate the product in the market place.

From a game design perspective, data driven games are a quick jolt of brain candy to be consumed and forgotten. They are low touch, consumable entertainment product that fails to build a deep and loyal customer relationship. When your ability to connect with your customer at a meaningful level is threatened, you have surprisingly high franchise churn. Crash Bandicoot? Sonic the Hedghog? Lara Croft? These titles’ relationship with the customer was much less secure than they imagined.

Contrast this to Mario, a franchise that relies much more heavily on constantly updated game mechanics. By offering players a series of unique high value game play experiences, Nintendo creates a strong customer bond with the character that primes the channel for future titles. Nintendo generally avoids player burnout and accidental damage to their highly valuable franchise by focusing on gameplay, not merely lobbing undifferentiated content at their customers.

Closing thoughts on Data Driven game development
Data driven development represents one vision of the current state of the art in game development. It eases a large number of issues that have plagued game development for many years.

If you care at all about why you do the things you do, you need to understand the practice and repercussions of data driven development. It is the current future of the console industry and its driving philosophies will shape the work environment of most professional game developers. Many of us have been doing flavors of data driven development for years, but expect extremely polished pipelines like the ones found in God of War to become the default for the upcoming generation.

It is a potent technique if used correctly. Pure data driven development is a solid strategy for titles in mature genres that have a brand capable of capturing the first or second place in the market. Such genre king titles are the bread and butter of any publisher and reducing execution risk is of paramount importance. However, companies should be careful of producing more than two or three titles that use the same game mechanics or they risk devaluing the franchise.

For all others, data driven game development tends to be a very expensive way fail in the marketplace. The execution risk may be low, but design risk and financial risk are actually higher than if you did naïve game development. If you can’t capture the genre crown, exciting static content is rarely enough to carve out your own niche within the marketplace. You’ve invested a lot up front and you won’t get the sales on the backend.

Even a title like God of War is a huge risk for Sony. They’ve supported it with a large marketing budget and a decent sized development budget. It certainly has gotten them rave reviews, but sales have been disappointing for AAA title. First month US sales are reported at only 200k for the month of April and by June of 2005, they had reached 500k world wide. The mythical typical AAA title needs to sell anywhere from 900k to 1.2 million depending on how the books are kept.

With continued promotion, I’m hoping they’ll at least break even or turn a small profit. Admittedly, Sony is attempting to create a new next generation IP. They are willing to take a moderate loss on the first title. It is a simple strategy. Create an expensive splash, get the new brand in the public consciousness and then scoop up the preorders for GOW2.

I have to wonder though. If we’ve already gotten to the point where one of the world’s top five publisher has to release a very expensive title as a loss leader in order turn a future profit, where does this leave the smaller companies? Screwed and tattooed. At the very least, it suggests that launching original content-based IP that relies on older game mechanics is an expensive and risky strategy.

Data driven game development is one risk reduction strategy. If everyone invests in this ‘safe path’, then there will be some remarkable market failures. This is just another tool and should be used with care and wisdom.

What’s next?
In the last part of this series, I’ll talk about another take on the risk reduction game, a little technique called prototype driven development. This focuses on reducing design risk, instead of execution risk. It should provide a fun counterpoint to many of the issues found in data driven development.

Take care

God of war sales figures “disappointing”

The spin on God of War sales figures: “Grand Turismo + God of War sell over 2.5 million.” Right…now how many did just God of War sell?

Ub Iwerks leaves Disney in the dust

GDC: God of War: How the Left and Right Brain Learned to Love One Another

Sunday, April 2, 2006

Managing game design risk: Part I

GDC was wonderful. Unfortunately, I’m the sort of person who is absolutely miserable at copying notes in any literal way. As soon as I started writing, I became distracted by a thread connecting several intriguing talks on prototyping, tools and production risk. The result was a very long essay. This is the first part.

Managing Risk
Much of game production is about managing risk. We partake in a highly complex process that juggles people, technology, new forms of interactivity and rapidly changing market dynamics. Developing a single game is a high stakes effort in which the likelihood of failure is dramatically greater than that of success. One false move and the development team can face financial ruin or heavy restructuring at the request of their publisher.

It is a fascinating optimization problem that drives many of the practices in modern game development. Here are some rough notes describing different forms of risk as well as my initial thoughts on techniques for mitigating certain types of risk.

  • Financial Risk
  • Requirements Risk
  • Execution Risk

Financial Risk: The big daddy
All product development consists of the act of producing and delivering something of value to customers. In return, the customers give you money. If this process produces profit, then you can develop more products. If it produces a loss, you are heavily encouraged to stop making such products and do something more profitable with your limited resources. Economics abhors waste.

The likelihood that you will lose money is financial risk. It is the invisible hand that makes all other forms of risk meaningful. However, simply looking at ‘making money’ does not tell us enough to optimize our processes. We also need to look at what we make and how we make it.

Requirements Risk: What the heck are we making?
Requirements Risk is all about making the right product for our customer. It is split into three interrelated categories. Naturally, any one of these risks can increase the project’s overall financial risk.

  • Design risk: Risk of not including the right features that create a potent value proposition for your target audience.
  • Scope risk: Risk of not doing enough or doing too much. If you don’t do enough, you increase Design Risk. If you do too much, you increase execution and financial risks.
  • Market Risk: Risk that there will be changes in the market place that invalidate your value proposition. Market risk is external to your project.
Of these three, design risk is the most fundamental with the other two acting as constraints. In order to mitigate requirements risk, you must choose the minimal right features for your product. This correct set of features changes over time as external events influence your target market.

Execution Risks: How do we make this?
Once you understand ‘what’ you need to do, you need to execute on your plan. At this point, four additional risks raise their ugly heads.

  • People Risk: Risk that you do not have the right people with the right motivation and methods of work to execute. A subset of this is creative risk, in which you fail to create a product that you, as a creator, takes pride in. Often creative risk can be in conflict with the constraints of financial risk.
  • Technical Risk: Risk that major technology that you rely upon will fail. The obvious aspects of technical risk are things like rendering engines, path finding, etc. In games, technical risk also fluctuates wildly with the addition of new game mechanics. Since we are dealing with psychological interactions with real customers, minor game mechanic changes have surprising results. Even the act of adusting a character's jumping distance may not ‘work’ since it can destroy the fun factor for the rest of the game.
  • Schedule Risk: Risk of delaying the product and missing a competitive window in the market place. Games are products with a shelf life and strong market cycles. When you miss your dates, you dramatically increase Market Risk for certain types of established genres.
  • Quality risk: Risk of errors. A product that solves all other factors, but includes bugs and other malfunctions.

Mitigating risk: A difficult problem to solve
You end up with a web of constraints with no easy solutions. There is a wonderful section of Douglas Adams book “Dirk Gently’s Holistic Detective Agency” in which the lead character manages to get his sofa stuck in the stairway going up to his flat. He creates a 3D computer model of the situation to figure out how to get it unstuck, but can’t manage it. Dirk Gently, the world’s lateral thinking poster boy, solves the problem in seconds. All he has to do is remove one of the walls. Unfortunately, the solution to moving the couch would destroy the entire house. Woops.

Modern game development often finds itself in a similar situation. Let’s take the fundamental problem of choosing the right features for our product. An obvious engineering path is to add more features. Bridge builders might call this over engineering, a time tested technique. That way, you’ll ensure that you make a product that solves everyone’s needs since it contain more than enough features.

In game development, the secondary effects kick in. By increasing your scope, you increase the need for people, technology, time and quality. None of these scale linearly.

  • When you add more people to a team the communication processes within a team change dramatically. A 2 person team can sit in a room together and talk through problems. A 20 person team needs defined managers and process. A 200 person team often spends the majority of each individual’s time simply maintaining group cohesion and intergroup communication. Each stage is distinct and requires major cultural shifts to succeed.
  • As features increase in number and diversity, the need for new technology development increases. As game mechanics are added, the very nature of the system and its effect on the customer fluctuates radically. Each new feature has a very real chance of destroying the value of the entire product.
  • More features require more planning time and uncertainties can result in large schedule fluctuations. These are compounded by technology and people risks.
When you optimize for a single risk factor, you’ll often have unpleasant secondary risks that bring down the whole system.

The spectrum of process complexity
These high risk, heavily interconnected systems finally are getting their due. Building games is not like engineering bridges. In fact, folks have started to notice that many traditional project management are counter productive. When someone attempts to scale the project by turning one of the dials, the non-linear risk increases in unpredictable ways and the product fails.

The first step is to realize that there are different types of production processes and each one requires radically different management techniques. Here’s a diagram from the Scrum methodology that describes how uncertainty in both requirements and execution creates multiple classes of processes.

  • Simple Processes: When both requirements and execution are quite certain, then the projects can be managed with relatively simple processes. Often a simple checklist does the trick. The repetative steps that a single worker performs on an assembly line is a good example of a simple task.
  • Complicated: When the requirements and execution get out of hand slightly, you end up with a project that can still be completed with your typical check list. However, you need to increase the number of rule and steps necessary to accomplish the task. Bridge building is a good example of a complicated task.
  • Complex: Many projects fall into the dangerous middle ground where requirements and execution is somewhat defined, but rife with multiple layers of uncertainty. In these situations, high feedback, agile processes let team steer their way towards ago despite high risk and uncertainty. Software development is a good example of a complex task.
  • Chaotic Processes: When both requirements and execution uncertainty is very high, projects tend to devolve into unmanageable chaos. Success arises as often from luck as it does from any real process.
Game development is intriguing because it contains elements spread across all areas of the process complexity spectrum.
  • Simple: Creating 2D art
  • Complicated: Creating 3D character models:
  • Complex: Writing Code
  • Chaotic: Creating new game mechanics
If you end up focusing on a shoehorning all elements of gameplay into a single process, you are bound to leave gaps in your competitive strategy. With that thought in mind, I’ll be posting a couple more essays shortly that use this conceptual framework to examine two common risk mitigation strategies.
  • Data driven development: Reducing risk by simplifying the process of game development. This technique focuses on reducing overall execution risk.
  • Prototype driven development: Reducing risk by embracing change and finding the fun earlier. This technique focuses on reducing overall design risk.

Take care

PS: Part 2: Data driven development is posted. Read it now.

Descriptions of Scrum