It has been a bit quiet in the garden this summer as I've been busy working on a set of longer essays. The first, The Chemistry of Game Design, is up on Gamasutra this morning. You can read it here.
A blurb from the article:
'“…it was clear to the alchemists that "something" was generally being conserved in chemical processes, even in the most dramatic changes of physical state and appearance; that is, that substances contained some "principles" that could be hidden under many outer forms, and revealed by proper manipulation.”
I recently happened across a description of alchemy, that delightful pseudo-science of the last millennium that evolved into modern chemistry. For a moment I thought that the authors were instead describing the current state of the art in game design.
Every time I sit down with a finely crafted title such as Tetris or Super Mario Brothers, I catch hints of a concise and clearly defined structure behind the gameplay. It is my belief that a highly mechanical and predictable heart, built on the foundation of basic human psychology, beats at the core of every single successful game.
What would happen if we codified those systems and turned them into a practical technique for designing games?'
The article describes a psychological player model and a system for visually mapping out how skills are mastered throughout a game. There is even a diagram of what Tetris might look like. :-) This essay introduces the basic concepts. In the future, I'd love to explore how these ideas might be used as part of an iterative design process.
I find systems skill atoms and skill chains incredibly exciting since they have the potential to ween us off our over reliance on reuse of existing genres. By understanding the rules behind why games work, we can synthesize new, highly effective game play from the base elements.
Feel free to post any reactions (allergic or otherwise) in the this blog post. :-)
Rockets, Cars and Gardens: Visualizing waterfall, agile and stage gate
The further I dig into new product development practices the more I crave a simple way of helping folks new to the concepts visualize them quickly. In that spirit, I've assembled a little pictorial journey through the intriguing landscapes of waterfall, agile, portfolio management and stage gate. For fun, there is also a description of how you can apply portfolio management techniques to individual agile project as a technique for additionally reducing the design risk.
The concepts illustrated here are readily applicable to most software projects including games, websites and of course full desktop applications.
Software development as a learning exercise All the diagrams start with two premises:
Knowledge is critical to success: A large number of software projects fail because we build software that has little real world value. If you dig into the reasons, even teams with great production skills claim they focused on the wrong issue or they really didn’t understand what the customer actually wanted. When you build the wrong software, you end up with useless code, loss of political support and eternal development cycles. If only the team had reliable knowledge of what to build, they could deliver value early.
Most product teams start with very little practical knowledge: Knowledge is great, but we start projects with hardly any. We don’t know exactly what our customers want. We don’t know how our design will work when it runs smack into the complexities of the real world. We don’t know what new opportunities and constraints will emerge in the future. Even when we are experts from a related domain, the best we typically have are theorems, guesses and opinions.
Product development is about rapidly producing targeted solutions that generate maximum customer value. In order to do this efficiently, our teams need to be learning teams that are constantly gathering concrete domain knowledge about customer needs. A team that learns the quirks of its customers, code, and business rapidly will often out perform teams operating without this knowledge. With this concept as a filter, let’s take a look at some typical development scenarios and how they are affect by team learning.
Typical product development of a single product In most traditional waterfall models, teams gather requirements, develop the product and then test it in order to see if they implemented the spec correctly. Only after they release do they gain any insight into what the customer actually desired. The metaphor that is often used is that of launching rocket towards a destination. You get to aim it once and then you fire it off and pray that you hit the target. All well and good, except A) this is a rocket that burns money for fuel and B) when it misses its target, entire teams (and sometimes entire companies) get the ax.
Now, not all is lost. If your company has enough money to burn, they can try again. There is a good chance the team learned quite a bit about what their customers actually desired by failing in the marketplace, so the next moonshot has a better chance of landing closer to some actual customer needs.
The old joke is “If you want to build a good piece of software, rewrite it four or five times.” Eventually, if you keep trying long enough, you’ll hit a target market that wants your product. Some very big companies have made a staggering amount of money following this dogged pursuit of success. They fail again and again and again, but their few successes fund the further pursuit of new growth businesses. The learning is quite expensive but very valuable.
Room for improvement This pattern of eventual success through multiple failures has been well established in all sorts of new industries. A few smart companies have identified two basic strategies for speeding up the time it takes to identify a new successful market.
Standard portfolio model: Fail in parallel. By trying lots of different options all at once, a few will succeed.
Iterative model: Fail sooner. Try something simple, test it to see it works and repeat.
Standard Portfolio Model If the waterfall process is like firing a rocket at a target, the portfolio model is like firing a swarm of rockets and hoping one hits. The company greenlights a large number of projects, funds them fully and hopes that one of them will blossom into a success. In return for spending more money, you rarely have to wait until version 3.0 to observe success.
This model tends to be highly useful when the target market is poorly understood or ephemeral in nature. For example, in the music industry, when user tastes change every month, it doesn’t make sense to spend three years attempting to evolve an individual album to fit the market. It also tends to be useful when the cost of development is low and potential payoff is high. The incremental cost of green lighting one more project can be easily offset by the incredible amount of money a successful record produces.
The big benefit of the portfolio model is that it allows you to try completely different options simultaneously. Companies are often put in situations where more than one idea has potential and they lack the information to choose which ones to fund. If they were forced to choose only one, they would often miss out on creating multiple product lines. Instead of putting all your eggs in one basket, a portfolio model spreads the risk and increased the chance of multiple innovative breakthroughs.
The Achilles heel of the traditional portfolio model is cost. Smaller companies have difficulty funding one project, never mind ten or twenty.
The iterative model Smaller teams have learned to maximize their learning opportunities by building lots of opportunity for rapid feedback into their process. The agile software development movement is the poster child here, but many of the same lessons are found throughout lean manufacturing, kaizen and other successful practices used by product development companies across a broad spectrum of industries.
The common metaphor is that of driving a car as opposed to launching a rocket. At every possible opportunity, you are looking ahead and adjusting the team’s trajectory in order to steer towards. Each change may seem subtle, but due to all the rapid cumulative adjustments, the team hone in on their targets quite efficiently.
It ends up being okay that the team makes little mistakes. If they veer off a little bit to the left, that's fine. They rapidly learn it was a bad idea and correct their efforts. The short feedback cycles ensures the big mistakes happen far less often.
Instead of taking 12 to 18 months to create and evaluate a new concept, they build and put new version in front of users every 2 to 4 weeks. They also work in high bandwidth environments where all the team members are close together and close to the customer. Team members converge on and build concensus around good ideas over a period of hours, not months. Teams become experts through intense hands-on problem solving and testing. This ends up building products much more likely to serve real needs than those imagined in Platonic specs by ivory tower experts.
Agile development is favored by small start up teams because the techniques greatly reduce the risk of an individual team failing. If you only have room for one shot at the target, you might as well steer your way to success using lots of rich information instead of launching blindly into the unknown. Long term, agile processes delivering more value sooner, with lower overall risk.
An agile project is intensely focused. In the rush of completing only high priority features, many alternative concepts never get the chance to be explored. Customers, a rather vague and argumentative bunch at best, are required to speak with one voice in the name of reducing noise and thrash for the team. For many teams struggling just to get software out the door, these traits are a godsend. The downside is that there is little concept of strategic portfolio management.
Agile projects can be a bit like a hill climbing algorithm. They will steer towards the closest customer success story, but may ignore a bigger opportunity further away.
Stage Gate: Cross breeding portolio models and iterative development We can do better than either pure agile or pure portfolio development. The stage gate process borrows a little bit from both iterative and portfolio techniques. You are still launching multiple products, but then you use iterative development techniques to guide each project towards success. You kill projects that fail to meet your goals.
Imagine that we are gardeners. We seed a diverse portfolio of projects, some high risk, so low. As we add team members and customer feedback, the projects begin to flourish, winding their way up towards the sunlight of launch. The core team development practices can be agile since we want to encourage short cycles of rapid feedback. The best ones start to blossom and ripen with obvious customer value. However, some projects are sickly and seem unlikely to produce much of anything.
As gardeners, it is also our job to groom the garden. The weak projects are trimmed back and turned into mulch that helps nourish the most successful projects as well as create a bed for seeding even more promising ideas. The best projects are harvested and sent off to customers, rich with ripe features, bursting with value. We are constantly seeding new projects to keep our portfolio balanced.
We’ve added three items to the traditional agile model.
Diverse seed teams: The first is the concept of multiple teams heading in different directions with different goals. There isn’t a single customer, but multiple customers driving multiple potential success strategies.
Kill Gates: The second item is the concept of gates every few iterations that kill poorly performing projects. It is better to return those resources back to existing projects than to continue investing. You can think of the success criteria that drives the gates as a set of reasonable constraints. The team is allowed to do whatever it desires as long as it meets the outlined constraints that are measured at each gate.
Concept banks: The third is the concept bank where old ideas are stored for possible recycling. You never know when the remnants of an old idea will nourish a strong new project.
You may start out with dozens of projects, but in the end you’ll only launch a few into the market. The combination of trying lots of directions with very small low cost agile teams dramatically increases your opportunities to learn compared to either pure iterative or pure portfolio techniques.
You spend dramatically less than you would in a pure portfolio model since you don’t have the heavy cost of finishing and deploying the bulk of unsuccessful market explorations. All that waste can go back into either exploring new options or building out projects that show success.
You have a higher success rate than a purely iterative model since you are exploring multiple hills instead of climbing a single hill and hoping that it is the highest one around. This recognizes that not all successes are created equal and it can be easy to get stuck in rut serving a niche. By keeping your options open, you can always shift resources around if a truly great opportunity emerges.
One downside is that cost is a little higher than a pure iterative model. You need to devote a portion of your overall efforts to generating and exploring new opportunities. This is typically more than offset by the earlier access to successful products. Another downside is that some long term projects (such as say…a fusion reactor) are culled before they show their promise. This can be handled through careful tailoring of gates so that break through innovations are properly weighted.
The Harvest Process: Applying a stage-gate model to a single product A single product can benefit greatly from the ideas in the stage gate model. A single product is composed of a variety of separate features, scenarios and audiences. We can treat each chunk of customer value as a separate project and bundle of high value projects as a product. The basic model is the same as the stage gate process outlined above. However instead of spinning off multiple products, your individual teams tend to be focused on critical workflows or user scenarios for a single product.
Returning to the garden metaphor, as you nurture these areas of value, you should always have projects that are ripe for release. Publishing can be as simple as creating a public release that turns off all the experimental projects, leaving only your best features to show the public. I think of this as harvesting a ripe crop for your favorite customers.
As time passes, the little ideas that you seeded earlier will mature and produce a new crop of high value features. The process just keeps repeating, season after season, release after release.
The cliché in our business is that ‘ideas are cheap’. The shame of the matter is that some of the best ideas are left to rot because they don’t come from the right people and the production schedule has no room for creative thinking. The Harvest process builds innovation in at the lowest level possible. Everyone is encourage to come up with ideas and there is a clear and official process by which those ideas can become reality. Making it work In order to pull this off you need some basics in place. There is a substantial expense to running multiple projects and constantly integrating their efforts. With the right people, the right process and the right values in place, it is a very achievable goal.
Multiple, small agile teams: A single monolithic team has difficulty guiding a multitude of projects. Smaller teams can champion their area more easily.
Highly refactored and regression tested modular code: You need to be able to change one element without breaking the rest of the projects.
Innovation at the edges: Teams need to be able to innovate in interesting directions without constantly referring back to the ‘master planning committee’
Kill gates: If you don’t understand success and kill projects that don’t meet the bar, you’ll end up with a cancerous mass of bizarre, unhealthy features that have grown in random directions. Quality kill gates that actually kill projects are critical to success.
Shared design: You still need to present a unified face to the customer. Each team is under additional constraints to share visual styling and minimize conceptual complexity for the product as a whole. These constraints are built into the kill gates.
Customer feedback: At every stage, you need to be testing your products with real customers. You should be able to quickly deploy a working product to your customers every day. None of these ideas can succeed without people using working versions of your software and the team being wiling and able to learn from the customers’ reactions.
Conclusion In the end, any of the techniques outlined above have a chance of working. You need a driven group of people with the right circumstances in place. With the right amount of random luck and persistence, even a waterfall project can change the world. For some fat cats working in bloated large companies, this is enough. However, if failure has a personal cost, you’ll want to look into the alternative techniques such as agile, stage gate, or harvest. Over the long term you’ll notice less overall portfolio risk and your customers will start enjoying your superior, well informed product designs.
If you take away one thought today, it should be that learning is fundamental to software development. We do not live in a Newtonian world where huge mechanical brains can predict the future. Instead, we operate in a constantly shifting organic universe of cultural trends, customer urges, fluctuating cash flow and skeptical sponsors. In order to deliver great products on time, we need to learn from our environment and build a response rapidly and precisely. Portfolio technique increase learning by trying more options. Agile techniques increase learning by shortening the feedback cycle. Build both of these key concepts into your teams and you’ll find that they make smarter decisions and deliver more value to your customers.
Small initial teams? Try 20% of one person. With Harvest and Stage Gate, initial teams can be very small. For example, you could devote 20% of one person’s time for the initial concept stage. That doesn’t sound like much, but if you have every single person in the company devoting 20% of their time to new ideas, you’ll be seeding the equivalent of hundreds of new projects every year for no additional headcount. Google is the golden child of this concept right now, but 3M has been doing it successfully for decades.
Put those hundreds of ideas through a simple checklist that looks for potential customer value. Spin off the best ideas into tiny teams of a couple people and give them an iteration or two to come up with something cool (and testable.) Repeat the process several times and you rapidly gain some surprisingly innovative products .
The phrase “game mechanics” sends a pleasant shiver down my spine. At the heart of every game are these mysterious whirring clicking mechanisms that deliver to the player pleasure and thrills.
We use them, we build them, but I’ve never seen a good unified definition of game mechanics that gives us a practical base upon which to build great games. Here is one. It is clobbered together from a variety of influences though many of you will recognize some central tenets from ‘A Theory of Fun’ by Raph Koster.
Game mechanics are rule based systems / simulations that facilitate and encourage a user to explore and learn the properties of their possibility space through the use of feedback mechanisms.
It is a simple definition, but it offers a good amount of insight into why games work and how we can make them better.
Feedback loops Central to the model is the concept of feedback loops that encourage learning. Here is a diagram that should explain the concept in a more visual format:
(click to expand the diagram)
Player performs an action.
The action causes an effect within the simulated game world. The simulation contains public and private tokens and the causal rules that affect the states of the tokens. The player rarely knows all the rules and is highly unlikely to be able to instantly describe the complete possibility space described by the rules. The unknown portion of the simulation is a “black box” that the player must attempt to decipher.
The player receives feedback.
With new tools and information in hand, the player performs another action. Using what we’ve learned, we pursue additional pleasure.
Linking game mechanics to create a system of systems Interconnected networks of game mechanics make up the game as a whole. You can think of the game as a set of interlinked of puzzles where solutions to one puzzle lead to clues that help on additional puzzles.
The info treats that a game provides to the user need not be used to solve the immediate black box at hand. Humans horde potentially useful information like squirrels horde nuts for the winter time. We’ll store hints in our copious long term memory in the hope that there will be another black box down the line that will yield to our improved tool chest of knowledge.
The traditional metagame that sits on top of a game’s core mechanics is a good example of how one black box feeds into another. In this situation, the game mechanics are arrange in a temporal hierarchy where rapid feedback loops (often part of the basic control scheme) provide tools that enable the mastery of longer term feedback loops. The potential patterns of linking game mechanics together are nearly endless. This is a wonderful area of future study.
Humans are infovores Humans are wired to solve black boxes. It is a fundamental aspect of our neurological learning wetware. We get real chemical rewards when we grok a problem or gain information that we suspect will help in grokking a black box. Evolution has selected for this behavior over thousands of generations since it is the biological reward system that encourages tool use and technological adoption. Without this built in addiction to problem solving, we would lack agriculture, medicine, architecture and other fundamental survival techniques that make the human species such a remarkably successful animal.
A key aspect of our model is that games actively encourage learning. I can put a black box on the table with a hidden button. Unbeknownst to a potential user, pressing the button enough times and the black box will spew out a thousand shiny silver coins. This is not a game. This is a bizarre gizmo.
To turn it into a game, a game designer would need to do several things.
Encourage Discovery: First, make it obvious that the button in meant to be pushed. Humans are naturally curious creatures, but as game designers, we need to explicitly direct them to take certain actions.
Encourage Exploration: Second, the designer would put a counter on the front of the machines that lets the user know that their actions are having some impact on the system. The counter provides delightful drips of feedback and it is up to the user to interpret that feedback
Provide Tool Mastery: Third, the designer would post a note “Payout: 1,000, coins!” Not all games need explicit winning conditions, but hinting at future utility is a highly useful technique for encourage the player to begin interacting with a particular game mechanic.
We’ve turned a gizmo into a simple game of chance. The difference between the two is that our primitive 1-armed bandit is explicitly designed to encourage player learning.
Existing games are richly laden with techniques that encourage learning. A few that come immediately to mind:
Levels take complex systems and encourage players to explore and master one aspect of the possibility space at a time
The use of scores, coin collecting and experience points are all simple feedback mechanisms that let the user know they are making progress towards some future state.
The classic “See the treasure chest you can’t reach” in Zelda acts as a promise of future utility.
A system alone is not a game. A dump of information is not a game. A system that encourages learning through strong feedback mechanisms is a game.
Secondary effects I’ve just described the foundation of a game mechanic. Now lets dig into several of the secondary effects that immediate appear when you attempt to put this system into practice:
Burnout: A definition After merrily harvesting tidbits of information by plunking coins into the virtual pachinko machine, the player will eventually grok the system. The game mechanisms may still serve up information, but the tidbits are not longer as tempting. The info we receive has no resonance with problems that we are solving or problems we have solved. It activates no curious networks in the brain. We begin subconsciously filtering out the feedback from these mechanisms. Burnout is a state of completed learning where the player finally figures out that a particular action no longer yields meaningful results.
In Monkeyball, researchers were astounded to find the the biggest jolt of pleasured occurred when you fell off a cliff and died. People loved it! If you look at falling off the cliff as a huge learning experience, this makes perfect sense. However, when they replayed the animation, people hated it. Same stimulus, radically different response. The animation of falling off cliff lost its ability to teach the second time around. Ultimately, users are subconsciously constantly asking the question “Is this activity worth my time? Does it gain me anything useful?”
Premature burnout There are multiple paths that learning can take and not all are ones that game designers desire. We would like to imagine that groking a system results in complete and utter mastery of that system. In reality, ‘grokking’ means that that the user has stabilized on a mental model of the system they no longer feel like improving further. This model can be simple or complex, depending on the inclinations of the user.
A complex model of Black Jack might take into account probabilities of cards appearing based off what has already been played.
A simple model of Black Jack might conclude that cards appear pretty much randomly. There is more depth for the user to explore, but if they are a casual player, saying it is random is ‘good enough’ to judge the game.
A big frustration to game designers is that many users settle on a very simplistic model of how a particular game mechanic works. Players will claim that a game is unfair or too difficult and immediately toss it in a rubbish bin because the designer misjudged their reaction to a game mechanic.
Some mechanisms have highly predictable burnout rates. Most players immediately figure out that watching a cutscene again isn’t going to provide much additional information. Other mechanisms demonstrate a large variation in burnout rates depending on the person who is playing the game and their personal preferences and disposition towards addiction. Some players try a slot machine once and then never again. Others will ruin their lives in pursuit of the next reward, never grokking the simple truth that such machines exist to take money, not give.
The factors that influence burnout are numerous.
Practical importance of imagined future rewards that stem from mastery.
The ability for the mechanism to signal that there is additional depth of mastery possible.
The first two factors are not possible to derive by simply exercising your superior intellect. A deep understanding of your target audience’s psychology is most helpful here. The second two factors are very much under the designer’s control and can be refined through heavy prototyping and player observation.
Milking: The transition from learning to tool use The flip side of burnout is grinding. If burnout is when a player discards a game mechanism because it is no longer useful, milking is when a player continues to exercise a game mechanic long after they’ve reached the state of mastery because the game mechanics continues to provide value.
When a player has learned one system, they will often keep interacting with it. On first blush, this seems mildly demented. The activity no longer provides burst of juicy learning. It is a bit like jawing on a piece of gum that long ago lost its flavor.
However, remember that games are networks of linked game mechanics. Player will continue to interact with a mastered game system in order to create a useful game state for exploring another black box. Mastery gives the player predictable pragmatic tools that helps them advance in other aspects of the game. The learning and mastery that occurs in other portions of the game provide the necessary reward that goads the player into revisiting old game mechanics.
You can extend the time that a player spends with a set of a game mechanics by ensuring that a mastered system still provides utility to the player. Designs techniques that build tools result in more gameplay for less development work.
Red Herrings: Black boxes external the game The network of blackboxes that the player considers valid can extend far beyond the systems in the game itself. Often, the player will collect strange bits of info that have no real impact on the game mechanics that the game designer built into the game. These pieces rattle around in our heads like a collection of oddball keys for a set of locks that we may never find.
Game designers can tease the player with hints to systems that do not exist in order to suggest depth to their games. A sly arched eyebrow in a cutscene triggers as massive cascade of meaning alerts. Our brains love people and faces and relationships and the breeding opportunities and politics! Surely, that eyebrow is important? The player greedily stores the memory away.
What impact will the collected information have on their gameplay? None. What impact will it have on their lives? Very little. This virtual person in a cut scene is no one they will ever meet. But our brains were not evolved to deal with such things. As apes, the tale of an arched eyebrow by a potential mate from our little tribe always meant something very, very important. So our brain rewards us with a little jolt of pleasure for noticing such an “obviously” beneficial tidbit.
The designer managed to suggest a system and get some of the benefits of that system without actually building it. It is not going too far to suggest that paintings, sculpture, movies and television all thrive on this simple quirk of our brain’s learning systems.
The downside is that such red herrings burnout quickly. Our brains becomes quite good at recognizing false, useless information. Almost no one watches a cut scene more than once. What would be the point?
My personal bias is to use red herring game mechanics sparingly. As game designers, we have deeper skills at our disposal. We can tailor potent electronic cascades of feedback loops that spin out a complex duet between computer and the player. Such system are highly effective at causing visceral pleasure and encouraging deep long term learning. As game designers, we conduct a majestic symphony of explicit learning and entrancing interactivity, something no static media will ever manage.
Sometimes though, it is worthwhile to suggest great mysteries with broad brush strokes. Setting, character design and plot can be crucial hooks that help make a game meaningful to players before they even press a single button.
Human factors: Emphasizing the humanity of games Some folks read about models and immediately see them as reductionist mechanisms that strip the humanity out of the soul out of creating artistic games. The game mechanics I’ve described in this article attempts to avoid this trap. They explicitly include social, narrative and emotional elements in addition to purely analytical problems. All aspects of the human experience, that have an impact on our ability to process and learn from stimuli, fall within the domain of potential game play.
This definition of game design is much broader than the current range of games available on the market. Though it works quite well with hit points, button mashing and high scores, the breadth of the definition is intended to encourage exploration of a much wider range of human learning. Some open questions that I find immediately suggested by the model include:
What are the feedback mechanisms that impact learning about relationships, love, hate or spirituality?
How do we build games around such topics that leverage these feedback mechanisms?
Existing games give us the foundation of practical knowledge that lets us make the same thing in a reliable fashion. A good theoretical framework helps game designers create future titles that are inclusive of a wider range of human experience.
Conclusion The goal of any model of game design worth its salt is that it both explains existing behavior and predicts future behavior of medium. In my experience so far, this model seem rather robust at explaining almost any existing game on the market ranging from board games to slot machines to social games. There is certainly room for improvement, but it is a good enough for my main goal.
I want a practical model that lets the good folks in this grand industry describe game designs in more exacting terms. The model should give insight into why their prototypes suck. It should allow them to discuss potential issues and solutions with shorthand language that cuts to the meat of the matter. A good predictive model allows for more intelligent design decisions with less waste and unnecessary rework.
So some of aspects of the model that I find useful:
It treats game mechanics as well defined, comprehensive atomic units. These units can be discussed individually and they can also be linked together in interesting ways.
Explicit identification of user value. Fun is not a nigh spiritual activity that spontaneously bursts forth from the ether. It has a testable neurological basis.
There exist clearly inputs and outputs that easily identified. You can easily tell when a specific game mechanic has all component elements such as actions, rules, tokens and feedback systems. Through observation, you can identify the player’s reaction to each mechanism and then adjust its impact.
All and all, the hope is that this model of game mechanics is a good foundation for future discussion. It is one that I’ll be leaning on heavily as I continue to meander through this lovely little series of essays on game design.
A theory of fun for game design: Raph Koster Many of the basic concepts in this essay build upon the ideas in this book. I find it helps my thinking to rework what I’ve read in essay form. Call it a form of active listening if you must. ( http://www.amazon.com/Theory-Fun-Game-Design/dp/1932111972
Other loose ends This essay became too long and started budding little essays. Some have been planted in new documents that may one day emerge in full blossom. The rest are here for your reading pleasure.
Is a book a game? With this big emphasis on learning, there is bound to be a wiseass who asks “Is a text book a game? It too encourages learning.” The problem here is that there are few strong feedback mechanisms evident. The user reads the book and without a doubt they get a burst of pleasure from ingesting the info. However, the act of turning the pages, and interpreting language are skills mastered through other activities ages early. At best, reading the book is an example of milking, where a player uses a mastered technique to advance the grokking of some larger blackbox.
The primary role of content. In this model of game mechanics, content in the game is meaningful only through it’s association with a feedback mechanism. Plot points become reward and hints, Damage becomes a punishment that clues that player into the fact they shouldn’t be doing something. There is no such thing as an inherently pretty picture that exists ‘just because.’ The image is pretty because it activates the brain’s learning systems which in turn feed back into actions.
In order to answer the question “what content does my game need?” you need to first answer the question “What feedback should my game mechanics provide to the user based on their actions?”
We are entering the mythical land of game consoles as convergence devices. The Xbox 360 can play music, movies and games. So can the PS3. So can the PSP and it even has a web browser. Nintendo might toss in a bit of DVD playback into the Revolution for a chuckle or two. The dream of big media conglomerates and technologists seems to finally be coming to fruition. Just imagine: a single box that does everything. What could be better?
Yet most attempts at forcing convergence of disparate devices fails. A few geeks buy into the hype, but consumers tend to ignore mutants like PSX and other technological monstrosities.
What drives the big console manufacturers to create convergence devices if they have such poor historical track records? Technological hubris is of course always a player, but there are certainly deeper issues worth exploring.
Mind you, convergence is a messy marketing term that is going to need a bit of structure in order to discuss in a meaningful fashion. Let’s look at the two key strategies that are often described as ‘convergence’ and pick them apart to see why they are attractive to those shiny boys in sharp suits.
Convergence as a product design strategy
Convergence as a platform strategy.
Why convergence as a product design strategy sucks I’m not a fan of convergence devices that promise to do everything. They tend to under perform in the market due to a variety of factors. There a several great articles wandering about the net covering this topic in more detail, but here are the four basic reason the sink these brilliant technological marvels.
Issue #1: Confusing benefit statement Instead of a single clear benefit statement, consumers are bombarded with a dozen half-baked benefit statements. You need to be able to sum up your entire value proposition in a short sentence.
Look at the PSP’s promise to the customer “Experience entertainment without boundaries.” That, my fine lady friends, is vague and meaningless marketing speak that fails to describe any sort of concrete benefit. Check out the value statements of some successful non-convergence products:
iPod: 5000 songs in your pocket.
Google: Find anything on the web easily and quickly.
Nintendogs: Own a cute dog (even if you can’t own a real one)
Gmail: Friendly webmail that never forces you to delete your messages.
Tivo: TV without the crap. (Admittedly, Tivo’s biggest problem is that they aren’t allowed to promote this as a value proposition without irritating the advertisers)
Issue #2: Compromised solution that competes poorly against single purpose solutions: Look at the classic VCR TV. You end up with a crappy TV and a crappy VCR glued together by a weakened user interface. Many consumers would rather buy a quality TV that gives them those warm post-purchase fuzzies. The quality of the individual buying experience matters.
The complexity that attends convergence is typically the kiss of death. A poll the Consumer Electronics Association found 87% said ease of use is the most important feature for users when they are purchasing new technologies.
Issue #3: Higher cost of entry A multi-function device forces you to buy a bundle. What if a VCR TV costs $300 and you only have $200? By increasing the entry point, you limit your audience. Often consumers will buy the cheaper single component and then save up to get the secondary or tertiary elements of the bundle.
Issue #4: Single point of failure When one piece fails, the whole thing fails. The perceived risk of system failure is much higher for multi-function devices. This is quoted as a typical issue, but it sounds a bit academic relative to how consumers typically purchase.
The failed logic of convergence focused product design The traditional product design logic of a company focused on convergence is deeply flawed.
Both product A and Product B are valuable to consumers.
If we combine product A and Product B into a combined Product C, we will end up with a product that is twice as valuable to consumers.
Other companies aren’t selling converged devices so our super product will have a unique competitive advantage that will help us dominate the market.
Customer value however is not an additive property in consumer products. For all the reasons listed above, a converged product will often have dramatically less value than its individual parts.
A company strategy based on convergence is often that of the lazy corporate strategist who attempts to avoid the radical cultural shifts required by real innovation by playing a childish game of mixing and matching existing product lines.
Product successes are not based on convergence I can only assume the myth of convergence as a product strategy came about when someone saw the occasional success of a convergence device and mistakenly assumed that the chimeric nature of the device was indeed the source of the product’s sales mojo. Let’s look at a couple convergence devices and dissect the real reason why they were successful.
The classic one is the “clock radio” combo. Though this is certainly a ‘convergence device’, the ultimate driver of adoption was a simple, easily articulated use case: “Wake up to music.” Customer benefit drives adoption.
I find camera phones to be another interesting example of customer benefit being the real driver of adoption, not convergence. At first glance the combination of cameras and phones seems to validate the logic of convergence. Cameras are successful and cell phones are successful. And what do you know; camera phones are successful as well!
Yet something curious occurs here. The marketing people at phone companies are running around frantically trying to come up with ‘convergence’ products and services that take advantage of this obvious ‘camera-cell phone synergy’. This task ends up being really quite difficult. Why? Because the benefit of having a camera phone has very little to do with synergy.
The reality is that the benefit of a camera phone is really quite simple: “Always having a camera with you helps you take better pictures.” Any professional photographer will tell you that the real trick to taking great photos is having a camera with you when the right moment occurs. By stashing a camera in an item that is on your body 99% of the time, you increase the value of the camera.
By this argument, if the technologists had managed to figure out how to pack a camera into a standard keychain (and people were constantly encouraged to upgrade their keychains), the “camera keychain” would have been nearly as successful. The customer value is what matters. The fact that the value takes place in a convergence device is mostly random happenstance.
What I’m harping on here is that most ‘convergence devices’ are in reality just a combination of technologies that happen to tap into a concisely defined customer need. Rarely does someone use a radio-alarm clock as a main clock. Nor do they use it as their main method of listening to music. Instead, they use it for a narrow, highly specialized purpose that has a very strong value proposition.
So focusing on “convergence” in consumer products is a silly, meaningless product innovation strategy. What you should be focusing on is serving a customer need. Sometimes that involves slapping two mature technologies together, but more often it involves traditional product design techniques that attempt to solve unrealized customer requirements.
As a game designer, the obvious lesson is that you shouldn’t expect to create a RTS-FPS-RPG that is an overwhelming success in the market place. But we have bigger fish to fry today. If convergence is a poor product design strategy why do console manufacturers insist on designing consoles that promote convergence?
The other face of convergence: Platform creation The other face of convergence is when a company attempts to create a technology platform that serves as the foundation of a wide array of successful products.
The logic here is straight forward.
Create a technology base that allows product companies to make innovative products.
Product companies will focus on filling the needs of real customers with great, easy to use products.
Customers will buy the well design products and in the process the platform will come along for the ride.
Ultimately, network effects will start to make their effects felt and it becomes silly for anyone to develop products without the help of the underlying platform.
You provide technology so that someone can create a Grand Theft Auto and then when everyone wants GTA, you happen to sell them a large number of PS/2s in the process.
Platforms are about potential, not about results Platform creation is often mislabeled as convergence by the ignorant press and the marketing lackeys that goad them onward.
It is in the platform provider’s interest to claim that they do everything under the sun. They have no idea what the killer application will be for the platform, but the last thing they wish to do is define the platform too rigorously and turn off potential developers.
We are entering into a turbulent time in media. The traditional console game industry is stumbling and future growth is coming from poorly defined markets like cell phones, online games and casual games. Pundits are describing an all digital future where media is downloaded on demand. Digital music and movies are driving the creation of radical peer to peer distribution system outside of the control of traditional channel owners.
In short, if you are a large company such as Sony or Microsoft, you can’t afford a narrow focus. If you focus on a few carefully chosen product benefits and fail to pick correctly, you’ve put the entire platform at risk. What happens if you don’t include great movie playback features and in the next few years someone comes out with an amazingly popular movie distribution system that doesn’t run on your platform? Billions of dollars of potential revenue are lost.
When platform strategy meets product design reality This thinking puts Sony and Microsoft in an interesting position. They release products that hedge their bets and promise to do everything. All the standard convergence flaws apply.
The new consoles have confusing benefit statements. Is the PS3 a game playing device? Sony isn’t saying.
Convoluted UI’s. The classic consumer devices of the world have two or three buttons that a grandmother could use. To really tap into a PSPs capabilities, you need to be an uber geek. Downloading a special program to download movies onto your PSP using you PC is not a strong value proposition. Where is my ‘download music’ button?
The new consoles are overly expensive. Do you really need Blue-ray or HD capabilities? Most people don’t, but you end up paying for those technologies now because they need to be part of the bundled ubiquitous platform capabilities.
From a product design stand point, all this is very silly. From a platform design standpoint it is essential. When some of those extra features are used by a killer product that plays on the platform, the platform can explode into the market. Your risk is greatly reduced because by building a platform, you have hundreds of smart companies trying to create a killer product for you. You don’t need to rely on your own (often questionable) product design capabilities.
Sony makes a bet that a GTA will come along and use the streaming capabilities of their DVD player to create a must have game experience. Microsoft makes the bet that a Halo will come along and use the Xbox Live capabilities to create a must have experiance. They don’t know what the ultimate hit product will be, but they pack enough attractive goodies into their offering that someone, somewhere will build a success using their platform.
Do platform companies innovate? There is a big difference between the culture of a product company and a platform company. At the most basic level, the DNA of how they think, react and value products and innovation diverge.
Innovation is almost always about creating a small set of easy to use functionality that serves an underserved customer need. The initial results are unpolished and compare badly to established products. However, because they have little competition in their niche, they thrive and grow at a rate far better than the main industry.
Platform companies are horrible at creating new products that target customer needs. They are always looking for someone else to make the hard customer-centric decisions for them. Trimming features is agonizingly difficult since there is always the little voice in the back of their head saying “But this could be useful in the future.” The result is bloated product offerings that do everything for everybody.
The closest a platform company comes to innovating is when they spot a product category that is critical to the adoption of their platform. Superior resources will be spent in order to own that product category and ensure that its predominant home is the company’s platform.
For Microsoft’s original Xbox this product category was the FPS genre. They invested heavily in making Halo the predominant FPS title on any platform. Halo was certainly a good game, but the combined marketing and hype that Microsoft lavished up on it was critical to its ultimate success and recognition as a major brand. They spent this money because they realized that owning the product category would strongly drive the adoption of the overall Xbox platform.
Since they own the dominant brand in this product category, it is doubtful that they’ll lose it to another platform. Nintendo made this mistake with Final Fantasy. Instead of creating their own RPG offering that dominated the RPG genre, they relied on Square. Ultimately the relationship faltered and Square took Final Fantasy over to the Playstation. The N64 platform suffered a major blow. A product category leader moved to a different platform and took their customer base with them. The lesson for a platform company is the importance of owning your product category leaders.
As we’ll see, this mistake was not an isolated incident, but instead was a classic result of Nintendo’s product focused philosophy.
Why do product companies remain small? Product companies are great at innovating, but often poor at building up platform-style network effects.
Nintendo is quite happy to make hard choices and try to understand customer needs. Last generation, they made the choice that online services didn’t bring enough value to their customers. This generation they are rolling out a service that has only a few features (what, no match making?!), but serves the true needs of their customer base far better than any current solution. The claim of twice the percentage of gamers playing Mario Kart compared to Xbox Live is a strong one.
Again, we see the philosophy of choosing simple products that serve clear needs and leap into the market with impressive success.
The downside is that product design is a heavily centralized activity. If you look at three very different product innovation companies, Nintendo, Apple and 3M, the vast bulk of their innovative products are designed internally. The culture and processes required to make great customer-focused product decision are highly refined and quite delicate. The fundamental activity of cutting the junk and keeping the good stuff can be easily sidelined by ever a few doubter or hedgers. You literally need to build your entire company around the product design process.
This product design process is not easily transferable to external firms. You can’t easily imbue a 3rd party developer with the design processes that Miyamoto and crew have built up over the past decades. You can’t easily replicate Steve Jobs’ eye for design. In fact, there is limited strategy focus in most companies. The more you are a product company, the less energy is put into being a platform company and vice versa.
Instead of hundreds of developers innovating on your platform, you have one. That one company is generally a highly profitable powerhouse, but its output often will rarely compare to the shear bulk of people putting out content for a broader platform. The result is that massive platform momentum is hard to generate
A tricky balancing problem All of this creates a complex set of difficult-to-balance requirements.
A new console must be marketed to consumers with a clear value proposition at time when there is very little value and lots of potential.
If you increase the potential of your device, you make it more expensive by bloating it with extra features.
If you increase the out of the box value of the device, you limit the breadth of the platform’s capabilities and tend to focus on first party innovation at the expense of 3rd party development.
A snapshot of the console manufacturers Using some of these thoughts we can come up with a snapshot of each of the console manufacturers.
Microsoft is a pure platform company that dabbles in product design only as a method of ensuring the dominance of their platform. Innovation is secondary to creating a rich and full featured platform. This ties heavily into the culture and history of the company.
Sony historically has been a strong consumer product design company. In the past 10 years, they’ve caught the platform bug and are still figuring out how to deal with it. The success of Playstation literally saved a company that was hemorrhaging money from a stalled electronics business. The shock to Sony’s DNA is that it succeeded as a platform offering, not a product offering. With the Playstation 3, they are embracing the platform strategy fully. The question is whether or not they have the skills and the internal culture to pull it off. They certainly have the brand.
Nintendo is a strong product company that dabbles in platform development to the degree necessary to make their products succeed in the marketplace. It is quite likely that their individual products will be surprisingly successful in the next round, yet overall market penetration will still be dragged down by a basic lack of platform momentum.
Conclusion And so end my meandering thoughts on the topic of convergence. The important takeaways:
A product design strategy relies on a focused product targeted at a strong user need.
A platform strategy relies on creating a broad and flexible foundation that accelerates the development of successful products. Where products are about fulfillment of needs, platforms are always about potential.
The cultural DNA required to pursue each strategy is very different. Product design involves making hard choices for the customer. Platform design involves throwing in the kitchen sink for the developer.
Product design requires a strong centralized system of decision making. This creates amazing successes, but limits the scalability of the platform.
A platform focus creates a business model that scales impressively based off the contribution of numerous 3rd party developers. The real trick is getting it off the ground in the first place since the initial value proposition is mere fluff without products to back it up.
So when you heard Microsoft and Sony marketoids blathering on about super technology and cool things you can do with the convergence of all media, you are right to dismiss it as hot air. They are simply filling time until a developer creates a great product that uses their platform.
At that point, their tune will change. Suddenly the message will be all about the newly minted product successes. It is the same pattern that occurred with GTA, Halo and Final Fantasy. They will then use the success of the golden child to drive further adoption of their platform. In turn, their platform success will encourage more developers to take risks and build great new products. Over time, if enough killer products come out, the platform will snowball and gain momentum.
Nintendo, on the other hand, will come out of the gate with a concisely defined product offering that a target audience will love. The most successful teams will be internal Nintendo development teams and closely held 2nd parties who are well indoctrinated in the process of creating unique solutions around specialized hardware and software.
There are certainly many unknowns. Nintendo could realize their product design bias and beef up their 3rd party support structure to counter the weakness inherent in their cultural predisposition. Sony could rediscover its product design background and launch with strong games tailored to the strengths of their target platform, thus avoiding the early lull that hits most platform focused products.
We can’t predict the future, but at least we’ll have a reasonable vocabulary to discussing what happens.
A Game Business Model: Learning from Touring Bands
Most metropolitan areas sport a wide array of bands that eke out a reasonable living by touring about the nearby countryside. At every stop, they get a bit of cash from the till, sell a handful of t-shirts and maybe even an album or two. If they are good, they build up a sizable population of groupies that worships the ground they walk on and follows them from show to show.
Very few people outside of the circle of fans know who these bands are. Yet the moderately successful bands make enough to get by and a few even manage to prosper. These bands do not sell a product like their mass market Brittany Spears brethren. Instead, they survive by providing a service to their devoted fan base.
Over the past several months I’ve been tracking several successful online game developers who operate in a similar fashion. Each operates profitably, employs a small staff and appears to be growing. Their names include Jagex, Iron Realms, Three Rings and Iron Will games. Chances are that you’ve never heard of them.
This essay is about illuminating a successful, alternative, business model that has the following key characteristics:
Supports large numbers of independent game titles in a low competition environment.
Is amendable to bootstrapping and thus avoids the need for large publishers, money men or other controlling interests.
Encourages unique pockets of innovation.
Offer an opportunity for sustainable, lower risk profits for a small group of developers.
A business lesson learned from touring bands A touring band cannot rely on selling millions of copies at $17.95 a pop to anonymous music fans across the nation. Instead, they make their money by selling a wider range of goods and services to a narrow group of fans. There are really only two ways of creating a reasonable revenue stream. You can get a little bit of money from a large number of people. Or you can get a lot of money from a relatively small number of people.
Touring bands aim for the later. They build a brand based off a powerful social experience and establish a strong relationship with their customers. They then leverage this brand to encourage the sale of merchandise, event tickets and more. The result is a strong lasting brand and high per customer revenue.
There is a classic business case taught in most MBA entrepreneur classes that examines the 30-year reign of Grateful Dead. Even though they allowed free taping of their concerts and capped their ticket prices, they remain to this day one of the top grossing bands of all time. They bucked the trend of selling records through the corporate food chain and instead provided music directly to their fans.
There is a simple lesson here. A dedicated fan base combined with a service-based business model can be a great foundation for an owner run business.
Modern games are the equivalent of a Backstreet Boys album Games have typically relied on the opposite strategy. In order to participate, you first need to get a giant publisher to fund your game development. Then the finished retail game is marketed to a broad audience and if everything aligns, a title can sell the million plus copies necessary to break even.
The result of the standard mass market business model is quite predictable:
Emphasis on big mega hits in order to break even.
Requires the upfront investment of large amounts of money. If you were a garage band, expect to lose your intellectual property.
Products tend towards bland ‘pop’ experiences in order to maximize the market opportunity. More than likely, you are a studio band assembled for the sole purpose of being the next Monkees.
High risks of failure due to intense competition in the broader market
What do touring bands have to do with games? Games are by no means rock bands (despite the existence of lovely men like CliffyB.) However, we can apply the basic business techniques practiced by touring bands to the newly minted field of online games with good success.
Let’s look at what the companies I mentioned earlier are doing.
Three Rings produces an online game called Puzzle Pirates that focuses on casual puzzle games in a persistent online community.
Iron Realms makes a series of text-based MUDS.
Iron Will makes a 2D Ultima Online-style MMO.
Jagex makes a web-based 3D MMO.
Sofnyx makes a multiplayer Scorch Earth game called Gunbound.
There are others, but they all operate far below the radar of the mainstream gaming press.
The similarities are worth noting. Each started with a small community numbering in the thousands. Many customers have been with the games for years. Each operates either a micropayment or a subscription model that doesn't cap the amount of money the customer wishes to spend. Though none of these companies publish their numbers, rumor has it that they are almost all profitable.
Development costs were low and initial investment came from the team members, friends and the occasional angel investor. Publishers or venture capital was almost never involved.
The differences are also important. Core gameplay ranges from puzzling to shooting to turn-based combat. There is a bit of a focus on fantasy worlds, but from what I’ve gathered there is little overlap in the core user bases. Currently this means little competition from similar games and rumor has it that the impact of larger MMO’s is relatively insignificant.
These games are the equivalent of small successful touring bands. They provide a service, not a packaged good. They sell to a dedicated fan base that despite being small provides enough additional revenue per user to make the venture profitable. The result is a self-contained community served by small team of dedicated independent developers.
Village Games (Aka the Small Multiplayer Online Game) I call these small online multiple games ‘village games.’ They are quirky, isolated communities much like a traditional village or small town. The communities tend to be a bit more friendly and insular then their larger city-sized brethren such as Everquest or World of Warcraft. The game play tends to be a bit more unique and able to take risks.
Here are some defining factors for a village game.
Focus on creating a small community numbering typically in the thousands.
Either subscription or micro-payment based revenue model. Often there is no cap on the amount that a single player can spend inside the game.
A small development team, usually numbering anywhere from 3 to 10 people.
The game experience is addictive for a year or longer.
The game focuses on a niche experience that is not provided by larger retail titles.
A village games is a distinct service-based offering that is separate from other forms of games. It certainly isn’t a retail title. It isn’t an ‘indie game’ or a ‘casual game’. Those are packaged goods titles that are merely trying to sell the same old shite through a different channel. It isn’t a mainstream MMO because the funding model and number of people served is radically different.
So why in the world would a designer be interested? If it weren’t for a few critical factors, we could write these titles off as a peculiar niche sub-genre.
Business factors In order to paint a practical picture of how village games operate, I compared the genre to retail titles in eight major categories:
Core Business Drivers: How do you make money?
Upfront investment: How much does it cost to start the business?
Break even and Payback periods: When do I get my money back?
Sources of Equity: Who funds my game?
Ownership: Who owns the fruits of my labor?
Risk of Failure: What are my chances of success?
Potential Upside: What do I get if I succeed?
Competitive Insulation: Who is going to stop me from winning?
The results are fascinating and suggest that the village game market is a great opportunity for entrepreneurially minded game developers.
Core business drivers One of the most tricky aspects of understanding village games is the fact that they are driven by completely different business metrics than games sold as packaged goods. Switching your brain over to thinking about quality of customers, not quantity, is the first step.
A retail title gains a developer roughly 70 cents per copy sold. The publisher gains about $18 per copy sold. The price of each copy is fixed and has mere weeks before substantial price erosion takes place. Making money is a matter of selling as many copies as quickly as possible. The viewpoint is always short term and focuses on shipping and placing physical goods.
A village game, on the other hand, is instead about keeping and maintaining customer loyalty. A typical customer will spend an average of $60 a year and stays on for an average of 18 months, with some players staying for years. The developer generally keeps all $60 in revenue. Making money is a matter of maintaining your current customer base and incrementally increasing that base over time. The viewpoint is almost always long term and focuses on maintaining and extending customer relationships.
To put these numbers in perspective a village game customer is roughly 130 times as profitable as a retail customer for the game developer. This means that a game developer can sell less and make more profit.
Upfront investment However, a highly profitable venture is of now use to your typical game developer if the cost of starting up the venture is too high. Upfront investment is the amount of money that you need to put into a project until it begins to pay for itself. It is here that village games truly shine.
A typical retail game will run anywhere from $2 to $10 million over an 18-month development period these days. In my model I choose a mid-level next generation title that costs about $3 million to develop, plus another million in marketing. Someone needs to sink $4 million in cold, hard cash into a project before they see even the glimmer of profitability. A next generation mid-level retail title must sell roughly 800,000 to 1 million copies to reach profitability.
A village game requires total investment of roughly $250,000 over an 18-month period. In essence, you are paying for the salary of the development team plus miscellaneous marketing and server expenses. At 18 months, your game starts making enough money to pay for your monthly expenses without having to go begging. A village game with 3 to 4 employees needs to maintain a customer base of roughly 6000 to 9000 users.
At this point, you've reached what is known as 'Break Even'. That is when your monthly expense are equal to your monthly revenues. You'll notice that in my model both the retail game and the village game reach break even at the same time. The nice thing is that the village game consumer 12 times less cash in the process.
Payback If you were an investor, there's another metric you'd be interested in called Payback. After you've sunk so much money into a project, at a certain point you'd like to get it back. If you took out a loan, you'll have to pay it back. If you remorgaged your house, you'd like to unmorgage it as some point. Payback is the point in time at which the vast profits from your venture accumulate to the point where you can payback your initial investment.
For a retail game, the sales come in a giant spike upon release. Payback occur almost immediately, typically 18 to 20 months after the start of development.
Here village games show their first sign of weakness. Payback occurs after about 30 months. If your goal is making large amounts of profit (or 'greedy pig profits' as a profession in economics termed it years ago) village games are a long haul.
From a developer's perspective, this means two things. If you are in the business for making games, the path to profitability is roughly the same for retail and village games. If you want to simply make a big profit, retail games will get you there more quickly. However, you need to take into account both risk and your ultimate goals.
For the moment, I'm assuming that you are in it for the love of making great games and that the slow road is just as good. In that case, you need to consider how to fund your village game.
Sources of equity Funding is the boogie man of game development. We have nothing like the 'producer' structure that exists in movie industry where rich folks toss good money at creative entrepreneurs. Instead, we have the publisher system, aka 'selling your soul'.
When you are dealing with millions of dollars in start up costs, the requirements of an advanced distribution channel, and low success rates, a portfolio model of funding retail games is inevitable. Publishers rule the roost for good reason. They are the only ones who have the critical industry knowledge to fund and maintain a quality portfolio of retail game titles. In general, a company must fund 20 to 50 titles a year in order to maintain a positive return on their investment. Your game can not simply be ‘good’. It has to be the correct puzzle piece that fits in the middle of a highly nuanced portfolio mix. Due to all these factors, getting funding for a retail title is nearly impossible.
A village game operates in a completely different world. Due to the relatively low burn rates, it can be funded with ‘sweat equity’, the main developers working for a pittance. It is also amendable to both friends and family investment as well as angel investment. As a village game grows its customer base, the revenue and profitability numbers became much more exciting to smaller VC companies. You'll need to find folks who are comfortable with the longer payback period associated with village games, but that is not an insurmountable hurdle.
The upside of all this is that unlike a retail title, a village game has readily available sources of start up funds and means of supporting growth at later stages if desired. This ready access to seed money is perhaps the strongest benefit of all that village games have going for them. There is no excuse to not make a village game.
Ownership A major side effect of the funding model is that retail games and village games have radically different ownership models.
Retail games give over ownership to the publishers. They typically own the rights to original license and have full managerial control over the development and execution of the title. All of the risk and all of the potential upside is owned by the publisher. The game developers are studio musicians that do their job for a meal and a place to sleep. The result is often craftsmanship, not entrepreneurial breakthroughs.
A village game tends to be owned by the developers themselves. They take on all the risk, but they also get a bit of the upside if they succeed. Personally, I’m a huge believer in the entrepreneurial spirit. Overall, a company with an ownership culture will be more agile, more profitable and more innovative than one that treats their workers like hired guns.
Village games lend themselves well to lifestyle businesses. They are exhausting initially due to their reliance on sweat equity. However, as a steady subscriber based is built up, that company has more freedom to combine work and play.
Risk of failure There is a more pratic reason to consider starting up a village game. Most games fail and there is nothing more crushing than working on a title for multiple years and seeing it crash and burn. Village games offer smart teams the opportunity to steer their way out of danger.
Retail games have an impressively high risk of failure. Only 116 games out of roughly 5000 released in the US since 1995 have broken 1 million in total unit sales. A mid-level title needs to sell almost a million copies to break even. For next generation console titles, a 5 to 10% break even rate will be impressive.
Releasing a retail title is like firing a solid gold cannonball at a moving target while wearing a blind fold. Retail games get one shot at success during a short 4 to 8 week release window. If all factors are not perfect, the title’s sales will suffer. This risk of failure is also almost entirely due to market factors that are outside the control of the development team. Items like the funding of other teams, the marketing spend, the release schedules of other major titles and the whims of the player all are big factors.
Village games, on the other hand, typically experience a soft launch. An initial version of the title is released into the wild and it attracts a few customers. The developer has the opportunity to adjust their title in order to fix the most egregious errors. Often a title will evolve over a period of years, until it matches the demands of the target audience nearly perfectly.
Village games succeed or fail based on the skill of the developer and their ability to successfully target a niche market with compelling game design. If you are an experienced game developer, you have a much greater chance of creating a successful village game, than creating a financially successful retail title.
Upside At this point, some of you may be intrigued by the thought of making a village game. There will be some of you that are wondering how much money such a enterprise could gain you. It turns out that regardless of your business model, you still need to make games for love, not money.
Retail games can make over a billion dollars with a single title. That is rather exciting. However, as a developer, you are going to see approximately none of it. Royalties, for all intents, are a myth propagated by those good folks who wish to hire fresh labor at inexpensive rates. If you are a developer on a retail game, the upside of successful title is that you get to keep your job until the title is released. If you do a really good job, your team is signed on for a new title and you have job security until it is released or canceled.
A successful village game will produce a steady profit, but the money never becomes astronomical. Instead, you'll be able to provide above average salaries and many years of job security. This is far better than most games can promise.
Competitive Insulation The long life of a village game occurs because it is highly insulated from direct competition.
Such a thing is unheard of in the retail market. Since a successful game must capture such a substantial portion of the market in order to achieve profitability, games are almost always in direct competition with one another. The result is a massive arms race that is quite difficult to win.
Village games exist in a far less competitive environment.
First, they are able to target themselves at a niche game mechanics. The hardcore Scorched Earth-style gameplay of Gunbound is unlikely to be replicated by World of Warcraft anytime soon.
Second, they build strong communities that resist the siren call of external delights. Sure, World of Warcraft has some great content, but is it enough to make you leave your friends behind?
Third, they are very low profile. Since these games are often built through low levels of marketing and word of mouth, it is uncommon for their players to even realize that alternatives exist. For a retail game this would be fatal. Since a village game can survive on such a small number of subscribers, it is actually a competitive advantage. In that same population of 3 million WoW subscribers, you could have 300 completely viable village games.
All of this has a surprising impact on innovation. When you only have to worry about satisfying your little niche, it becomes more worth your while to explore local maxima in your game design. Irons Realms sports some of the most intricate political systems ever found in a commercial game. Puzzle Pirates has created a PvP combat system that appeals to 30 to 40 year old women. With innovation comes additional competitive insulation. Go ahead, EA. Just try to clone Gunbound. I would pay good money to see the results.
Wrapping it up By this point, you should have a good overview of some of the business dynamics behind successful village games. In short, here is a unique business model that provide low entry barriers, low competition, easy access to seed capital and copious amounts of creative freedom. The money is good, but not great. However, the chance to build your very own profitable game company is nearly priceless. That is a dream that was crushed out of most developers long ago. The basic business drivers of small numbers of highly profitable customers make it all possible.
I’ve been looking at game business models for some time. Very few offer an entrepreneur any reasonable chance of success. I understand the retail business and keep my hand in it, but it is often too volatile for anyone except the bright-eyed youngsters and the sharks that feed upon their efforts.
As I slowly grow older and more conservative, I’ve started looking for a way to mixing game development with a stable family life. There are two paths. The first is to become a manager in the upper echelon of the current industry. If you can get to the portfolio management level of the retail industry, a lot of the turbulence lessens. But you lose the daily interaction with the development teams, and for a lot of us, that is what this is all about.
The second path is to go outside the industry and find a new niche for game development where the profit margins are still fat and the role of being an owner / developer is still a viable option. I’ve talked a bit about Serious Games as one option on this path, but to be honest I can’t stomach the steady diet of military and government projects it typically entails. Village games, on the other hand, excite me.
Here is a market niche where a passionate team with a bit of money put aside can carve out a viable, vibrant community that is insulated from outside competition. They can perfect a game over years of face-to-face interaction with their biggest fans. Most importantly, they can own their own destiny, be it success or failure. And to be honest, the odds aren’t bad.
Have band, will travel Hundreds of bands have tried to make a living touring their local cities, playing gigs and selling t-shirts. Most fail, but a few succeed because it is a real business model that provides a solid service to fans of live music. It is a hard life, but you are your own person and you get to do something that you love. These scrappy little groups are hidden from the mainstream media until one miraculously breaks out to the surface. Maybe they are a Nirvana, or a Beatles, or a Grateful Dead. But when one emerges, the industry is changed forever. And the people in the suits who diddle with the numbers on their portfolio spreadsheets ask, “Where the heck did they come from?”
Village game developers are the true touring bands of the game industry. They are at a sweet spot with low competition, moderate returns and the chance to own your own game development company. You’ll need a game designer with a bit of a business head. He’s the songwriter. You’ll need a programmer who isn’t an asshole. He’s the lead singer. You’ll need an artist. He’s wailing on the lead guitar. You’ll need the web / infrastructure guy. He’s in the back laying down the drum line.
Given enough passion, enough skill, and enough years tuning your sound out on the road, and maybe, just maybe, you will give birth to the next great game that shakes the foundations of the entire industry. The simple truth is that the tour is an end all by itself.
So what are you waiting for?
Take care Danc.
Escapist article on Boutique MMORPGs This was a nice trackback on my article that describes quite a few more games that fit the criteria and also gives some solid numbers. http://www.escapistmagazine.com/issue/75/15
I've been a game designer, pixel artist, painter, tools designer, product manager and marketing guy. I got my first job while in college working on a shooter called Tyrian at a little company called Epic Megagames. These days, I'm designing games deep in the forests of the North West.
I remain, to this day, not a chickadee plucker. Despite the rumors.