250 free handdrawn textures

I was searching through my old archives and came across a set of 250 textures that I thought were long lost. Heck, they aren't doing much good sitting on a slowly decaying CD-R so I figured I'd share them with everyone.

Click here to download CircleTextures.zip (4.49 MB)

Use these however you desire. Mash them up, put them in your games. If you end up releasing a game using these graphics to the public, all I ask is that you put a link to this website someplace the nether depths of your credits.

They are a few years old, so they are all 128 x 128 images using a common fixed 8-bit palette. I also included a text file that explains the naming convention.

If any of you are new to graphics tiles, here's a little illustration that explains all the parts. You have a set of 14 titles that can be used to make any irregular shape and smoothly transition between two titles. For example. Suppose you had a water title and a land title. With the transition titles, you could easily create a pretty shore line.

Tile creation is a dying art since modern 3D terrain engines have all sorts of wonderful blending capabilities for auto generating transition tiles. But if you are working on a game for handhelds or casual games, it is a nice technique to know.

Enjoy!
Danc.

PS: Here's another picture I found! This is the Colossi, a giant floating airwhale that was genetically engineered to serve as the mothership of a parasitic race of super spies known as Puppeteers.

Software Development's Evolution towards Product Design

Occasionally, some poor fellow at a dinner party makes the unfortunate mistake of asking what I do for a living. My initial (and quite subdued) response is that I help design software for artists.

Then comes the inevitable question, “Oh, so you are a programmer?” A gleam appears in my eye and I no longer feel obligated to blather on about the rainy weather. With a great flourish, I whip out my gold nibbed pen and draw a little diagram on a napkin that explains concisely how modern software development works. In the grand finale, I circle one of the little scribbles buried deep in the entire convoluted process and proudly proclaim ‘And that is what I do!”. This admittedly selfish exercise usually keeps everyone involved merrily entertained until dessert arrives.

Download the printable PDF version

After dozens of napkin defiling lectures, I’ve put together an extended PDF of my sketch for download. In short, we have a one page infographic that explains:

• The evolution of software development over four distinct eras.
• The key goals of software development and our saddest failures
• Where software development is moving in the future.

The diagram also contains a surprising amount of poo. But then, that is the bigger lesson lurking within the scrawls. Much of what software developers create fails to serve the full spectrum of their customer’s needs. The funny part is that the usually non-technical folks that I’m talking to laugh heartily at this point…they know exactly what I’m talking about.

You can download the full PDF here. Print it, share it with your friends. Read on to hear how we got to this point.

The Technocrat Era: Programmers serving programmers


At the dawn of software history, programmers wrote software for other programmers. This was a golden era. Life was so simple. The programmers understood their own technical needs quite intimately and were able to produce software that served those needs. The act of software development was a closed circuit. A programmer could sit in a corner and write code that he wanted. By default it also happened to apply to other programmers.

Programmers that grew up in these idyllic days still remember it fondly. There is still the programmer who will claim that all they need is EMACS and the latest version of GCC to make great software. For software intended for a highly technical audience, they may well be right.

The Early Business Era: Programmers attempt to serve others


The end of the Technocrat era was came about due to a startling discovery: the vast majority of the world was composed of non-technical people. Artists, accountants, authors, history majors and other unexpected consumers roamed the prehistoric landscape outside the hallowed engineering halls.

A new class of software entrepreneur called a ‘business man’ came into existence. This new creature realized that the hordes of non-technical people had their own needs that might be served by a well written program running on one of these new fangled “personal computers.” The business man gathered programmers and told them to build software to solve things like balancing budgets or writing letters.

The software products that the programmers created were technical marvels. They provided practical benefits far beyond what was available. VisiCalc revolutionized finance. WordStar and WordPerfect forever changed the act of writing. Even the Quantel Paintbox changed the world of art.

And yet the recently converted users, who couldn’t live without the efficient, powerful and technically amazing new software, were curiously ambivalent. They liked what these new products did from a practical standpoint, but found them to be confusing and often quite irritating.

You see, the programmers treated their customers just like programmers. They made them memorize crazy expert keyboard conventions and loaded the product with dozens of obscure features. This is what the programmers wanted out of a piece of software, so they assumed that the customers must want the same.

Unfortunately, the customer needs were a different beast. Their needs could be roughly divided into two categories:

• Practical needs: They wanted a product that worked. For example, the product obviously needed to save time and money.
• Emotional needs: They also wanted products the possessed less tangible benefits. They wanted applications that treated them with kindness and understanding if they made a mistake. They even wanted to use products that were attractive and conferred status. The customers desired programs that appealed to the softer aspects of their humanity.

When emotional needs were raised, the programmers quickly determined that the customers were indeed “nuts.” The pure technocrats simply did not possess the broad skill set necessary to comprehend, never mind serve, the customer’s unexpectedly important emotional needs.

The Late Business Era: Programmers and artists meet and do battle


The software market had become quite competitive at this point. Business folks, experienced in the Jedi wisdom of more mature markets, reasoned that perhaps serving emotional needs could give their companies an edge. A few companies experimentally hired non-programmers such as artists, marketing and usability dabblers. I use the term artist quite liberally here since it captures that charming, hand-waving vagueness of all classes of “people people”

Oh, the suffering that resulted. The inevitable culture clash was a bit like unleashing wild dogs upon one another and then watching them sulk afterwards.

None of the freshly introduced team members spoke one another’s language. The artists talked about fluff like color and mood. The marketing people made outrageous requests with zero comprehension about technical feasibility. The programmers were suddenly enslaved by bizarre, conflicting feature demands that they did not understand. “Make it friendlier” translates poorly into C++ code.

Let’s take something as simple as making an interface more appealing.

• The artist would whip up a picture sporting rounded corners and more pleasing colors. They’d send it to over to the programmer with a hand scribbled note “Make this.”
• The programmer then would either A) State that an infinite number of programmers could never finish such a technical abomination or B) Recreate the image using rectangles and the preexisting color scheme.
• Everyone would then rage at one another about their general incompetence.

In these battles for dominance, the winners lost horribly. If the programmers got the upper hand, they produced software that, despite great technical accomplishments, was ugly, difficult to use and no better than currently existing products. If the artists got the upper hand, you ended up with lovely products that didn’t do anything worthwhile.

The best products came from those odd teams that managed to compromise. The technology was clumsy and the emotional benefits of the software shaky. But it was better than the crap that customer had to put up with before. The original Mac OS was a great example of this. Later versions of Windows also managed to address a few emotional needs.

The Product Design Era: Can programmers and artists learn to work together?


The clock of progress has moved forward once again. The competition ratcheted up one more notch, and it appeared evident that companies that fail to master the lessons of the last era would be punished by the customers. Our battle scarred software companies were left looking for a better way.

Obviously, designing for emotional needs in addition to technical needs was a winning evolutionary strategy. In the last era however, mixing multiple potent skill sets together left organizational and cultural wounds that often were difficult to heal.

The companies that survived the influx of designers and marketing folks often relegated the survivors to their own separate silos. Marketing people got one org tree, developers got another. Artists and usability folks in most cases were shoved in random back corners to rot in black despair. Many groups were so busy protecting their domain that it was surprising that software got released at all. Release dates slipped by multiple years as the development talent stagnated is a cesspool of misplaced process.

What was needed was the most dramatic of transformations: A change in the cored development process. What made it difficult is that original culture of technocratic software development would need to evolve to support a broadly humanistic approach to product design.

The lead users of the Product Design Era
This change found root, as is the case for most dramatic transitions, from the most unlikely places.

There is a concept in product design known as the ‘lead user’[1]. This is a group of users that solves a difficult program far ahead of the mass market. Often they’ll cobble together their own tools and discover fundamental process and technology issues years in advance of mainstream users.

The old joke about writing Shakespeare with infinite monkeys randomly typing on typewriters got it all wrong. Instead give me a million customers trying to do their job with broken tools and one of them will stumble upon a process that is truly better. By watching the edges of the market place, we gain great insight into the direction that the larger market will take in the future.

The lead users in software development came from several widely divergent areas.

• The first was the game industry. Here, small cross functional teams built products focused entirely on serving emotional needs. Due to intense competition and vicious delivery cycles, many teams were forced to innovate far outside the traditional software development methodologies.
• The second were companies like Apple that followed curious ‘design’ philosophies more similar to that pursued by consumer good companies than software companies. What do shampoo companies and software development have in common? A remarkable amount it turns out.
• The third were web design companies. Due to the low cost of entry and the early emphasis on the web as a marketing medium, the web design market is dominated by tiny, hungry graphic design firms. They brought with them a culture of small teams, close collaboration between artists and programmers, and a nearly slavish devotion to serving their customers.

What the next era looks like
Each of these lead users follows a variant of what is broadly known in more mature industries as “product design.” They see software development not as a pure technical exercise. Instead they look at it as an integrative process of building a new product that solves both their customer’s combined emotional and practical needs. Even when forced to use a “technically inferior” platform, the religious devotion to rapidly and effectively serving customer’s complete spectrum of needs make their product offerings more attractive than the competition.

Robert G. Cooper, a well known researcher on new product development, states that there are several core factors [2] (listed in order of importance) for any successful new product design process:

1. A unique, superior and differentiated product with good value-for-money for the customer.
2. A strong market orientation – voice of the customer is built in
3. Sharp, early, fact-based product definition before product development begins
4. Solid up-front homework – doing front end activities like market analysis well
5. True cross functional teams: empowered, resourced, accountable, dedicated leader
6. Leverage – Where the project builds on business’s technology and marketing competencies
7. Market attractiveness – size, growth, margins
8. Quality of the launch effort: well planned, properly resourced
9. Technological competencies and quality of execution of technology activities.

Many companies in the Late Business era already emphasize a few of these factors. However, there are some differences. Notice how technical competencies are important, but last on the list. Notice also, how that creating a solution to customer needs is first on the list.

Software companies that understand product design tend to pour their efforts into the following activities:

• Focus on a unifying team goal built around customer needs. They ensure that the product is always driven by customer needs, not internal whims.
• Work together in cross functional teams. They build an organization that encourages the sharing of skills to promote problem solving. They discourage the formation of silos of individual ‘experts’.
• Communicate clearly with a process that applies to all team members. They build a commonly followed process includes both fuzzy front end activities like design and production activities like coding. This process forms the language that unifies disparate groups.
• Work efficiently with design friendly tools. The team avoids custom coding and ‘tossing it over the fence’ by adopting tools that work on common data format across all skill sets.

Benefits of a product design philosophy
The benefits of a product design process are well documented. New products that deliver superior, unique benefits to the customer have a commercial success rate of 98% compared to 18.4% for undifferentiated products. These products reach an outstanding 53.5% market share.

Some of the highlights of a strong product design include:

• Create highly competitive products that achieve market dominance.
• Save money by focusing on the right features that bring customer value, not low yield ‘nice-to-have’ features.
• Create passionate customers that accelerate the spread of your marketing message.

To the losers, the success of their rivals appears miraculous. “How is it that a slow web app can take away market share from our superior desktop application?” they ask in surprise.

The answer will be simple. The successful company identified the correct emotional and practical needs of the customer and poured their efforts into serving those needs. The richer companies - flush with silos of ‘wise’ experts - fought with one another and threw random features at the customer. It is rarely about doing more; it is about grokking customers and doing the small set of correct things necessary to succeed.

Dangers of the Product Design Era
As with any process transition, some groups are adopting these techniques slower than others.

• Even within game development there are huge swaths of publishers and development teams that are ignorant of techniques used to incorporate market research, concept testing and new-to-the world innovation into their process.
• Many web developers still create new products by following their ‘gut’ without clearly identifying their ultimate customer.
• Most traditional desktop software developers are just barely escaping the Late Business era of functional silos and warring factions.

Most laggards who hold desperately onto their aging processes will die off in the face of advancing competition. Those with larger war chests merely buy a small period of additional learning time.

Unfortunately, many companies that attempt to adopt a product design philosophy will also fail, despite their best efforts. Cultural change is hard work. To adopt product design you must alter the most basic DNA of the company’s values.

• It involves asking vice presidents to give up their empires that they’ve fought decades to establish. What is the point of an organization of engineers when engineers are all just members of small cross-functional teams?
• It involves asking the men and women in the trenches to give up their own dreams of building their own empires according to the old rules.
• If the ultimate reward of the old system is an isolated corner office with windows, try convincing people to work together in a common war room that has walls covered with whiteboards.

Such traumatic change is absolutely necessary. If you want to make great products for happy customers, you need to make the transition to a broader product design methodology. We may have once been a clique of technocrats. But now we must take our place in the broader society by providing human solutions to the very human customers that we serve.

Dessert
After I’m done drawing all this out on my little napkin, I point to one of the designer fellows in a beret and say, “See that guy? That’s me. I work on a team full of crazy, wildly talented people trying to make the world a better place. We make products that you can love, not just products that you use.”

Folks nod. They get it. They like the idea of software that not only works, but makes them feel good about using it. At one meal I was sitting with an older woman who listened most politely to my wildly gesticulating explanation of modern software development.

At the end she said, “Well, it is about time.”

Take care
Danc.

PS: This cute little illustration was done in a program I'm busy renovating called Expression Graphic Designer. It will be part of a suite of design friendly tools that seeks to ease the bloodshed between programmers and their more artistic team members. You can't build a cross functional production pipeline without the right tools.

References and Random Clippings

• [1] Lead user analysis
  http://www.betterproductdesign.net/tools/user/leaduser.htm http://www.leaduser.com/documents/lu_perform_study_wp_enthusiast.pdf
  
• [2] Success factors in new product development
  Winning at New Products, pg 58-59, Robert G. Cooper
  
• [3] Benefits of a differentiated product
  Winning at New Products, pg 60, Robert G. Cooper
  
• What we can learn from the Stratocaster http://www.cooper.com/newsletters/2001_07/what_we_can_learn_from_the_stratocaster.htm
  
• Inmates running the asylum (a book review)
  http://www.wap.org/journal/inmates.html
  
• The Apple design team work space
  “We have assembled a heavenly design team. By keeping the core team small and investing significantly in tools and process we can work with a level of collaboration that seems particularly rare. Our physical environment reflects and enables that collaborative approach. The large open studio and massive sound system support a number of communal design areas. We have little exclusively personal space. In fact, the memory of how we work will endure beyond the products of our work.” – Jonathan Ives
  http://www.designmuseum.org/design/index.php?id=63
  
• Concept of total customer experience
  http://www.findarticles.com/p/articles/mi_qa4001/is_200201/ai_n9056014
  
• When worlds collide: Integrated development with business and design students
  http://www.findarticles.com/p/articles/mi_qa4001/is_200207/ai_n9103531
  
• When innovators stop innovating
  http://www.findarticles.com/p/articles/mi_qa4001/is_200204/ai_n9024018
  
• Rounded Rects at Apple: Benefits of cross functional discussion
  http://www.folklore.org/StoryView.py?project=Macintosh&story=Round_Rects_Are_Everywhere.txt
  
• A tech writer and a programmer prove the benefits of cross functional teams
  http://www.folklore.org/StoryView.py?project=Macintosh&story=Inside_Macintosh.txt
  
• Development of Mac Paint
  http://www.folklore.org/StoryView.py?project=Macintosh&story=MacPaint_Evolution.txt&sortOrder=Sort%20by%20Rating
  
• Use of cross functional teams to improve game development:
  http://therubrabbits.1up.com/do/blogEntry?bId=6530632&publicUserId=5729773#comments
  

Edit: Added reference numbers to a couple of data points so the connections are more clear.

Valentine's Day 2006

Every year I paint a valentine card and share it with as many folks as possible. Pass it around. I love this holiday, despite the commercial nature, the insane pressure to purchase the perfect set of truffles, and the long lonely night that awaits too many.

It occurred to me that none of this really matters. February 14th is a day that is a simple excuse to do something nice for someone else with no thought for yourself. Everyone has a small talent that is worth sharing...everyone has the chance to bring a smile to another person's day.

Such sentiments may seem cheesy as all heck. And they are. There is honestly nothing worse than living your life without a bit of good natured silliness. So load yourself to the gills on candy hearts and dark Belgian chocolate and unleash the love. Bake someone a cake, Pedro-style. Send flowers to your mailman and compliment him on his shorts. Dance at work. I guarantee that someone will crack a grin. Even if it isn't a strip-o-gram.

Of all the holidays, I humbly submit that Valentine's Day is the holiday that best matches the heart of game design. It turns out, you see...that your job is to create the world's best valentine. Game developers are in the fundamental business of bringing joyous pleasure to others.

The best games, many of which are admittedly not yet written, celebrate relationships, joy and giving. We aren't there quite yet, but if the marriages on WoW and the deliciously lost Mario Kart races with our significant others are any indication, we are on the right path.

You know, I am just dying for one of those diabetically huge sugar cookies smothered in thick, pink frosting. With sprinkles...can't forget the rainbow sprinkles.
Danc, Game Cupid

Pick your game community: Virtual or Real?

I was just over at 4 color rebellion and a comment about Nintendo’s Wi Fi network as ‘discouraging community’ struck me as intriguing. The question must be asked “Which community?”

The basics
We play online to be with other people. They are more challenging, interesting and fun to be around than any AI currently available. Online play is ultimately about forging relationships.

Two philosophies
Are you forging new relationships or strengthening old ones? Xbox Live lets you meet new people and build a new community. Nintendo’s Wi Fi network works primarily off friend codes and assumes that you are playing with people that you already know. I’m simplifying things because there is certainly overlap here, but philosophically these are two different ways of building an online community.

Nintendo is saying “Hey, you already have friends. Play with them.” Implicit in this assumption is that there exists a world outside the virtualized game community. In order to have friends outside gaming, you must have a life outside of gaming.

In the ideal world you would have both options available. Unfortunately, we live in a fear drenched McCarthyistic Americana. Too many cling dearly to a sickening fascination with Fox’s latest “Baby killed by Psychotic Immigrant’ propaganda. Communicating with strangers is obviously one step away from ruined lives.

So pick one. Do you want live on society’s edge and build your own community? Or do you want to game mostly with your existing friends?


Do you have a social network?
I must admit that I fall into the later category when it comes to gaming. I like talking to people in person or on a special interest forum such as this site. I have a network of friends and am not at the point in my life where I’m starting from scratch or starting over. For me, gaming is a wonderful activity that is part of a much broader and highly fulfilling life. I welcome Nintendo’s tact because it lets me build tighter bonds with the people who are most important to me.

Would I personally miss not being able to talk to strangers? Not really. It is a nice-to-have option, but not a deal breaker.

On the other hand, if I didn’t have those social connections outside of gaming, would I miss being able to talk to strangers? Absolutely. I’m not sure if having a stranger yell at me in Halo will result in any long lasting friendships, but it is certainly better than being alone.

I suspect that the ultimate success of the systems will depend on which of these two groups is more prevalent. We can ask which the stronger draw is:

• Strong, safe relationships with existing friends
• Weak, ‘risky’ relationships with new people

But in order to answer this question in any meaningful fashion, you first need to answer a more personal question.

“Are you lonely?”

Take care
Danc.

References
http://www.4colorrebellion.com/archives/2006/02/04/egm-interviews-reggie/#comments

The Blind Men and the Elephant: Thoughts on an integrative framework for understanding games

It was six men of Indostan
To learning much inclined,
Who went to see the Elephant
(Though all of them were blind),
That each by observation
Might satisfy his mind.

John Godfrey Saxe,
“The Blind Men and the Elephant”

To understand game design, it is common to look at games from a wide variety of perspectives. Much like the blind men describing the elephant in the old Indian tale, each perspective brings something new to the picture. However, if we restrict ourselves to studying only one perspective, we end up making ludicrous decisions. “What is this thing we call a game?” someone inevitably asks. The peanut gallery cries “It’s a movie! A set of rules! A very small pebble! No, it’s a duck!”

The result? Weak games, disappointed players and poor team dynamics. There is a better way.


Existing perspectives
There are several predominant perspectives out there. A short list might include:

• Games as entertainment: Games exist as a method of having fun. Is there anything else? (The answer is ‘yes.’ :-)
• Games as craft: Development sees games as a production puzzle full of risks, costs, resources and schedules. Games are a craft with techniques and skills that property applied result in success.
• Games as art: Games are a burgeoning new form of creative expression that will change the world by changing how people think about critical human issues.
• Games as business: Games are a business complete with profit, loss and opportunities for squeezing out more cash with few resources.
• Games as theory: Games are an activity based on well defined (if not yet completely discovered) theoretical foundations.

We could no doubt add games as a community, games as status symbols, games as instruments of Satan and innumerable other perspectives of varying degrees of importance.

It is likely that when you started looking into game design you fell into one of these major categories. At first, I saw games as simple entertainment. Then for a while, I passionately believed in games as art. I’ve dabbled in the other perspectives and always enjoy asking which bucket folks call their own.

There is one right perspective, right?

And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!

In general, someone who lives by a dominant worldview either A) rails against those who do not share his opinion or B) ignores them if he holds enough power. This is really quite understandable. Each perspective is attempting to reach a very different goal. Anything that doesn’t help reach the goal is either an obstacle or noise.

For example:

• From an entertainment perspective, a game is a success if it helps person relax after a hard day.
• From a craft perspective, a game is a success if it ships on time with a well-executed set of features. More is always more impressive.
• From a business perspective, a game is a success if it makes money.
• From an artistic perspective, a game is a success if it evokes emotions and makes the auteur a name. Ideally, it will get young vibrant artists laid. (Let us be honest. :-)
• From a theorist’s perspective, a game is a success if it introduces or clarifies new theoretical constructs that spur a deeper understand of the medium.

We can all think of examples where these goals conflict. Ask two people about the same game and you will get very different opinion about its inherent value.

• To a theorist, Façade is a great game. To a pure business man, it is barely worth the bits on the disk.
• To a business man, Deer Hunter was an amazing success story. To the artist, Deer Hunter evokes all that is wrong with the world.
• To a craftsman, Doom 4 is the peak of excellence. To the player, it doesn’t quite create the same sense of joy as it once did.

On the surface, we would appear to be stuck in the same eternal battle of opinion illustrated in the blind men and the elephant. For folks striving to reach a differing objectives, even mere discussion of other concerns is a simple waste of time and resources.

There is an elephant!
It is easy to lose track of the fact that we are all feeling up the same beast. We are all talking about games.

What we need is an integrative approach to understanding games. When detailed conflicts seem impossible to resolve, it is often worth while to step back and look at the big picture.

Here are three questions we need to answer in order to make any integrative approach useful to real game developers working on real products. (Unfortunately, theory alone won’t pay the bills.)

• What is an integrative framework to use as a starting point for the conversation? If we waste our time reinventing the wheel, we just end up with more arguments.
• What is a common goal that subsumes the existing goals? If people don’t see a reason to work together, they won’t.
• How do the various perspectives work as part of a coherent ecosystem? If there isn’t an obvious way the different perspectives benefit one another then the whole effort is a non-starter.

New Product Development as an integrative framework
There are many possible ways of describing our gaming big picture. We need to start someplace, so let us look at games as a New Product Development (NPD) exercise. This is a common integrative framework that is used across many industries and is easily applicable to the game industry.

NPD is, not surprisingly, the act of bringing a new product to market. It is a process that includes everything from the fuzzy front end of defining a product all the way up to releasing the product onto the market. Apple, 3M, and IBM treat it as a core strategic competency. For auto manufacturers, it is a religion. Even a few software developers are starting to think about their work as more than just writing code.

One of the key benefits of the NPD framework is its comprehensiveness. It details a variety of stages, each of which has important links into on the commonly held perspectives of the game industry. A traditional NPD process looks a bit like this.

1. Idea Generation
2. Idea Screening
3. Concept Development and Testing
4. Business Analysis
5. Beta Testing and Market Analysis
6. Technical Implementation
7. Commercialization

A NPD (or the more loosely applied term ‘Product Design’) perspective allows us to look at any person who makes games and say “Yes, I understand your personal goals and this is how you contribute to the big picture.” When you follow an integrative framework, you no longer have to look at the world in terms of us and them.

A common goal
Next, we need to answer the question “Why should we all work together?”

NPD has a simple goal. Everyone involved wants to create and commercialize a product that benefits an underserved customer need. There are lots of ways to reword the goal of product development in a manner that appeals to a wide variety of people. One of my favorites is “Doing good things for other people (and not starving while doing it)”

Many people coming to product development for first time often mistake it as a capitalist or business system. It borrows from these perspectives, but making new products is about something far more fundamental. It is about basic human decency and using our marvelous intellectual and social skills to better the world. You see someone who has a problem and you help them out. If your solution is good enough, they’ll return the favor.

Admittedly, there is one group -- let’s call them the ‘Self Absorbed’ -- that finds the general goals of new product development repugnant. The major sticking point is the horrendous thought of spending their precious time helping others. Some are young men who just need to grow up and live life. Some have bought into ill-formed notions of how art or innovation actually occurs. I happen to believe that once you cut out the world’s sociopaths, the group that does not willingly contribute to the welfare of others is thankfully quite small.

Working towards a greater good is one of the most energizing and unifying activities that we can do as human beings. It is built in to our wetware. Teams that recognize this fact and structure their efforts around reaching for a meaningful shared goal create the world’s most amazing games.

If ‘Doing good things for other people’ is the general theme, you still need to answer some hard questions in order to bring folks on board.

• Who is the customer? Specifically, who are we doing good things for?
• Does their need really matter to them? If we make something cool, are they going to show us monetary love or are they going to guiltily look the other way and start walking faster?
• Is our solution any good? Can we make something that they think is worth buying?

If you can answer these questions in a clear, highly positive manner, you have a team goal that helps cut across all existing boundaries. You give folks a reason to subsume their personal agendas into a greater goal.

If you give vague answers or switch goals depending on how the wind is blowing, people will call you on your bluff and move back to supporting their own goals. Most people want to believe in a greater good, but they aren’t complete idiots.

A coherent eco-system
Now that we’ve described a common goal for our integrative framework, we need to show folks how they fit into it all together. In essence, you are answering the question “How do we all work together to reach the goal?”

Here are some common ways that each group contributes:

• Business: Business brings tools for measuring and managing sustainability and success of a product development effort. For example, ensuring that the company is profitable just means that the team can eat and continue doing what they love. Money can be seen as a useful measurement of value creation. If people pay you for your product, that’s a pretty good sign you are fulfilling customer needs.
• Art: Art brings tools for identifying and meeting emotional needs that are not easily definable or reproducible by more empirical methods. Products are rarely bundles of only practical benefit. They can include status, comfort, stress relief, companionship and a million other fuzzy human benefits as part of their overall package. Those who promote games as art possesses potent tools for contributing these fuzzy human factors to a complete product.
• Fun: The traditional entertainment perspective provides an established set of standard to benchmark your efforts against. Those who promote games as pure fun know what they like and are happy to tell you.
• Production: The production / craft perspective bring together proven tools for building high quality products on time and under budget. Without production, you’ll never get your product out the door.
• Theory: The theorists provide new empirical tools that can lead to radical innovative leaps. If making games is the craft of inducing fun in players, then theorists and academics provide the basic science that both drives the craft forward. They aren’t the only source, but they are an important input into the ecosystem of new game creation.

Each one of these is an essay onto itself, but I promised myself that I would try to write in more digestible chunks. :-) The important point is that it is easy to find common ground. Once you have an integrative framework and an understanding of shared goals, the benefit of widely divergent tools is quite apparent.

Conclusion
During the writing of this little essay, I ended up starting four other essays. There are lots of areas to explore and I found myself delving into team building, research technology transfer techniques and a half dozen other remarkably intriguing fields. If NPD or Product Design is to be a unifying philosophy, it certainly needs to be fleshed out in much greater detail. There are many practical questions just begging to be answered.

I'm tempted to say "Hey, isn't this exciting!" but it would be perhaps idealistic to expect all the participants in our industry to be focused on the same goal of seeing the big picture. Our charming Godfrey’s poem ends on a pessimistic note.

"So oft in theologic wars,
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!”

I prefer to remain optimistic. We have the start of at least one integrative framework that can help us avoid theological wars. We also have two big carrots that I hope will encourage others to pitch in:

• We can advance game design by leveraging a common viewpoint. The result is tightly focused teams and a lot less arguing.
• We can learn one another’s tools and use knowledge from multiple domains to solve our most difficult issues in innovative ways. The result is better games that satisfy customers more deeply.

Imagine for a moment if our blind men figured out that they were really describing an elephant. Would they train it to carry them about? Would they run away if it was angry (I would!). They certainly would figure out that perhaps they shouldn’t grab certain parts too tightly. At the very least, they could stop arguing and put their efforts into something a bit more practical.

Pause for a moment the next time you hear someone ranting on how their perspective on game development is correct and the other fellow is completely off his rocker. Perhaps it is worth asking “Hey, what is our common ground here?”

Take care
Danc. (aka Mr. Platitude)

References
http://www.noogenesis.com/pineapple/blind_men_elephant.html
http://en.wikipedia.org/wiki/New_product_development
http://en.wikipedia.org/wiki/Product_life_cycle_management