Directory of All Essays

Sunday, July 05, 2009

Flash Love Letter (2009) Part 1

Flash Love Letter (2009) Part 1
Chapter 1: Introduction
Hello Flash game developer,
Over the past couple months, I've spent a bit of time looking at Flash gaming on web portals like Kongregate and Newgrounds.  There are over 14,000 games spread across 30,000 portals with hundreds of new games coming out every month.  The output alone is amazing. 
Let me cut to the chase.  I think that you, Flash game developers, are some of the most talented and inspirational people working today in game development. Your passion for building games burns so incredibly brightly. Your ability to quickly make and distribute games is second to none. You hold immense potential to transform the future of games. 
Let me tally your blessings: 
  • Cheap and effective distribution: Your platform reaches over 350 million players, more than all home consoles combined.  A poor college student can release a half decent game and within a month, a million people will play it.  Such reach is unheard of on almost any other platform. 
  • Robust technology: Graphics, animation, sound, video, physics and networking technology is freely available and works surprisingly well. You are building on one of the most accessible and robust multimedia platforms that has ever existed in the history of the world.  Where other teams waste man months just getting a black triangle showing on the screen, you can have a working game up and running in hours. 
  • World class creative tools: Flash is fed by an art pipeline familiar to millions of artists that has been polished and tested over the past decade.  
  • Thousands of developers making stuff just for you: With a few simple API calls, you have the entire power of the web at your finger tips.  Want to send emails, suck in friend lists from Facebook, access payment systems, or let people buy underpants emblazoned with your logo? It is all there waiting for you to piggyback atop. 
  • Immense creative opportunities: Flash is uniquely positioned to create social games, mobile games, location-based games, games that suck in databases, games that use video, games that use real-time audio, games that connect millions.  The number of radical new game genres is primed to explode like no other time since the 80's. And you have all the tools necessary to  drive the wave of game play innovation forward. 
  • Freedom: You can make whatever you want. Unlike developers of other platforms, there is minimal interference from traditional gate keepers such as big company politics, retailers or publishers.  The Man doesn't own you, at least not yet.  
Such riches! Your platform of choice contains almost everything you need to radically transform gaming as we know it. 

The mystery
So...where are the great world changing Flash games?  They appear to be missing.

What we'll cover
Flash games are currently the ghetto of the game development industry.  Compared to the number of players it serves, the Flash game ecosystem makes little money, launches few careers, and sustains few developer owned businesses.   Despite the vast potential of the ecosystem, Flash games contribute surprisingly little to the advancement of game design as an art or a craft.  
In order to understand why this promising game platform is such a surprising dissapointment, we'll look at Flash games from three perspectives: 
  • Chapter 2 - Making money:  How do Flash developers currently make money.
  • Chapter 3 - Generating value: How Flash developers currently create 'valuable' game for their players?
  • Chapter 4 - Reaching customers: How developers currently reach their players. 
  • Chapter 5 - Premium Flash games as a service:  A mental model for understanding the new world of web gaming. 
For each step, I'll cover alternative techniques that give you, the game developer, make even better games. 

Chapter 2 - Making Money
Money makes the world go round.  It pays salaries and gives developers the time and space to create creative products.  Yet, Flash game developers don't seem to be making much cash. 

Flash gaming's Achilles heel
I took a look at the Flash ecosystem to see if I could spot the fatal flaw. 

The red flows are where people pay out money and the green items are places where people earn money.  Here are the common money sources for the developer: 
  • Direct: The game developer sells ads from a generic ad service on their personal website or portal. 
  • Game specific ad service: An ad service such as Mochi collects Flash ads that are typically placed in front of a game during loading. 
  • Site licenses: A portal pays a developer a fixed fee for a customized site locked version they hope will increase player retention. 
  • Sponsorship: A company pays a developer a fixed fee in order to direct customers from other portal to their portal in the hopes of capture those customer's lifetime ad revenue. 
There is one obvious fact: the entire flash ecosystem is driven by low quality advertising.  Piddling amounts of ad money flows into the developer's pocket through a variety of obfuscated middlemen.

Ads are a really crappy revenue source
For a recent game my friend Andre released, 2 million unique users yields around $650 from MochiAds.  This yields an Average Revenue Per User (ARPU) of only $0.000325 per user. Even when you back in the money that sponsors will pay, I still only get an ARPU of $0.0028 per user. In comparison, a MMO like Puzzle Pirates makes about $0.21 per user that reaches the landing page (and $4.20 per user that registers)    
What this tells me is that other business models involving selling games on the Internet are several orders of magnitude more effective at making money from an equivalent number of customers. When your means of making money is 1/100th as efficient as money making techniques used by other developers, maybe you've found one big reason why developers starve when they make Flash games.  

The effect of 1/100th as much money
Due to the low quality revenue streams, even great games make beer money, not rent money. A good game will make $1000 and a great game might earn $5000-7000.  A rule of thumb is that you need to release 10 good Flash games a year to convince your girlfriend's father you are not a bum. 
    10 games a year may not seems like such a big deal to some, but there is a hidden one-two punch that knocks most developers into bankruptcy 
    • Most Flash game developers have little financial cushion and live paycheck to paycheck. 
    • Flash game revenue is highly bursty due to a reliance on landing sponsorships upon release of their latest game. 
    It is common for a developer to release several games in a row and get sponsorships or licenses for each one. But the inevitable randomness of game development results a month or two delay on your next project.  It only takes missing one or two of those 10 games to force a professional Flash developer into ever waiting arms of endless soul sucking contract jobs.  It is surprisingly hard to change the world when you are stuck re-skinning the latest Mountain Dew advergame. 

    Only cockroaches survive without money. 
    It doesn't matter much raw talent you possess. With the right support, you could be the next Miyamoto.  Sorry, not important.  All that really matters is that you possess what I call the 'cockroach gene'. Can you churn out 'good enough games' and survive if your games repeatedly fail to make money?
    The following are survival strategies employed by successful Flash developers: 
    • Be a full time student:  This is the dominant category of Flash developers. 
    • Live in a socialist country: I'm looking at you, Scandinavians.    
    • Have (rich) family that will support you: I've met folks that do this but it is uncommon. 
    • Starve for your art: The Jason Rohrers of the world are also rather rare. 
    If any of these fit, congratulations.  You are in the small percentage of developers that have the financial support necessary to be a Flash game developer. Everyone else, thousands upon thousands of talented developers, fall in a category called 'churn'.  They can't even survive on ramen and passion.  So they move on to richer markets or leave game development behind forever.  
    Such a loss. Such an incredible waste.  I'd guess we are losing 95% of our best Flash games because the people with the talent to make great games find the Flash market financially untenable.  

    Solution: Players as a revenue source
    Ads are a good secondary source of revenue, but surely there are richer sources of revenue?  There is an obvious one, used for decades by all other game industries...why not ask the players for money?

    Here's the theory behind asking for money for a game. 
    1. Players have access to lots of games.  Most of which are free.  This is the reality of the market. 
    2. However, at a certain point, they start playing your game. 
    3. If you've created a great game, some players will fall in love.  They will be in the thrall of your reward system and your in game value structures.  At this point, they don't care that there are other games.  They don't care that they are playing on a portal. All they care about is your game.  Games create value through play. 
    4. When a player is in love, money is no object. If you ask the player for cash in exchange for more value, they will often agree. It is a good exchange in their eyes: They give you a small bit of change and in return, they get proven, addictive experience that they love. 

    Ask for the money  
    When game developers ask for money, they are usually pleasantly surprised.  Their customers give them money; in some cases, substantial amounts. I witnessed this early in my career making shareware games at Epic in the 90s and I'm seeing the same basic principles are in play with high end Flash games. Fantastic Contraption, for example, pulled in low 6 figures after only a few months on the market. That's about 100x better than a typical flash game and in-line with many shareware or downloadable titles.  
    Here are the four steps you need to follow in order to successfully ask for money from your players: 
    1. Offer: Offer premium content
    2. Tell:  Tell players about what they get if they pay you. 
    3. Repeat: Repeat the first two steps until it clicks with the player. 
    4. Accept payment: Get the money in your bank account.

    Step 1 - Offer
    Offer the player something valuable. Take a careful look at what players find valuable about your game and try dividing it up into two buckets: Introductory content and Premium content.  Give away gameplay in the Introductory bucket, but sell the content in the Premium bucket.  Many Flash developers insist on giving away everything for free.  Stop devaluing your work and start creating a premium offer.  Below are some ways of creating premium buckets. 

    Time gates
    Players can play for some period of time and then they are locked out until until they pay.  For example, players could play for 45 minutes - 1 hour (effective free trial times in the casual space) and then pay to play longer. 
    Content gatePlayers play an initial teaser portion of the game for free and then pay to unlock access to additional content. For example, players could pay to unlock all the levels in a game.  This is how many shareware titles worked. 
    Aesthetic items
    Players purchase non-gameplay additions that increase their identity or status.  For example, players could pay to give their character a cool outfit that they can show off to their friends. 
    Sell unique abilities that let players experience the game in a new way.  For example, players could purchase new jumping boots that let them fly through levels in a way that let's them re-experience the game all over again.  
    Virtual items can be bundled together to create additional value.  For example, if people love buying food for their virtual pet, let them buy a 10 pack of food for a 30% discount. 
    Some abilities can expire after a period of time or after a number of uses.  For example, you could buy a potion that increases your strength, but you can drink from it 3 times.  Also known as "item rentals."
    If certain abilities or bonus are a valuable long term, consider charging a reoccurring fee.   For example, you could offer extra storage for advanced players, but charge a monthly fee. 
    Stackable subscriptions
    If certain abilities are additive(such as an experience or currencies multiplier), let players buy multiples of the same thing. 
    Rare items
     Limit the number of items available so that players feel special when they purchase it. 
    Time limited items
    Offer some items for short periods of time so that players feels that they lucked out finding the product in time. 
    Sale items
    Set a standard pricing system for items and then offer some items for sale.  This works great with time limited offers. Again, players love to get deals. 
    GiftsPlayers seek to maintain social bonds by gifting other players with items or abilities. 
    Accelerators Many games have a 'grind' that artificially lengthens the game. Players with little time are willing to purchase items that let them reduce or eliminate the time consuming activities in the game. 
    Physical goodsT-shirts and other branded items
    Examples of premium content bucketing techniques
    There is no need to limit yourself to any single one revenue stream.  There are lots of different types of players and each player values something differently.  Some players may be willing to buy a t-shirt.  Others may want 5 stackable subscriptions.  Others may just want a pretty new character with a panda head.  When you restrict your game to a single revenue source, you miss out on gaining money from all the different types of customers that would have paid you if you had just given them the right offer.        
    When you design your game, pick three or four revenue streams and build them into your game.  Here are some categories of users that you may want keep covered. 
    • People who don't want to pay:  Advertising is a good option to keep around. A few hundred bucks is still money in the bank. 
    • People who are interested in more of the same: Once you've established the value of your game, some players want more.  Give them more levels, more puzzles, more enemies in exchange for cash. 
    • People who are interested in status or identity improvements:  Some people see games as means of expression and identity.  Give them items that let them express themselves or customize their experience.  
    • People who have limited time: Some people live busy lives and want to consume your game when they desire and how they desire.  Cheat codes, experience multipliers and other systems that bypass the typical progression all help satisfying this customer need.

    Step 2 - Ask
    Tell the player what they are going to receive in return for their money.  If people don't understand the promise of what they are buying, they won't pay.  
    • Ensure the user sees the offer: Screenshots, feature lists, and evocative language should be placed clearly in front of the user.  You want convey to the player the value, both practical and emotional that they will experience if they were to gain access to the premium content. 
    • Tie your offer of premium value to an explicit request for money.  We live in a capitalist society so people understand the concept of buying something.  Don't ask for a donation.  Don't ask players to "give you what they feel like giving."  People will think you are a charity case and in my experience your revenues will drop by 90% or more.  Give the offer a specific price, be it $10 or 200 gold in your favorite virtual currency.  
    • Time the appearance of the offer.  You can ask for money when players are caught up in the emotional moment of play.  Which is more valuable to the player? A Pirates of the Caribbean T-shirt at the mall or a Pirates of the Caribbean T-shirt right after you walk off the Disney ride and are flush with excitement?  Both your odds of buy the shirt and your pleasure in owning the shirt are greater when you buy it after the ride.  Use game design to make players fall in love and in their moment of game playing passion, they will be willing to spend money. 

    Step 3 - Repeat
    Repeat telling and asking several times until the value of your offer sinks in. Players need to see the offer multiple times before they'll commit to making a purchase. One technique that works well is to put the offer in the natural flow of playing the game. 
    • Prominently place the offer in high traffic areas of the game such as entry, save, in game store and exit screens.   
    • Email the user periodically to let them know about specials or sales.  By asking them to read an email, you are costing them time, so make sure that what you offer is valuable and delightful or else you'll end up with angry customers. 
    You can risk annoying the user if you do this too much, but in my experience coaching indie and Flash game developers, they err on the side of being hiding their offers. I've seen offer screen buried in option menus, guaranteeing that less than 1% of users will ever see them.  I've seen offers that appear only if you click a tiny button.  Users see it once and then never see it again.  Don't be embarrassed. As long as your offer is clear, professional and doesn't attempt to trick or overwhelm the user, most players will see your purchase button as just another useful, functional part of the UI. 

    Step 4 - Get the money into your bank account
    Use a payment service to process their order.  The good news is that there are dozens of 3rd party payment systems on the market.  The bad news is that they all have subtle differences that have a huge effect on both your short term and long term revenue. 

    The many layers of payment middlemen, each taking their cut.  
    (Margins are approximate and will vary depending on the service)
    Some things to consider: 
    • Margin: How much does the payment service take?  The payment company is providing you with a service and deserves to be paid.  However, you'll find that some companies take 10% and others take upwards of 75%.  Companies pitch various bundled services such as storage or fraud protection as justification for their increased fees. Some companies will also share some of the margin with portals in return for them carrying the games. Shop around and be honest with the trade off you are making.  Remember you'd need to get 5 times as much traffic to makes the same amount of money if you pick a service with a 50% margin vs a 10% margin. 
    • Processing fees: Most Flash payment systems are simply a repackaging of non-Flash payment services with a pretty UI and a bigger margin tacked on top.  The existing payment services already takes a chunk of the user's money in the form of 'processing fees'  Ask if the advertised payment company margin is inclusive or additional to the existing 'processing fees'.  A 30% margin seems reasonable, until you realize that it is on top of an existing 50% margin for a mobile provider.  I like to ask "If the customer pays $10 on their credit card or phone, how much cash ends up in my bank account?" 
    • White box or branded?: Some services like Super Rewards can be reskinned so that they are transparent to the end user.  Until the player enters into the actual payment portion of the process, they feel like the stores and such are part of the game.  Services like Noboba and MochiCoins are heavily branded with the payment company's logo.  Their goal is to get the customer to invest their trust in them, the payment provider.  The downside is that customers don't invest as much trust in you, the game developer. 
    • Customer registration?: In order to track customers and their purchases, you'll want a secure login system.  Some payment services let you build your own.  Others require you to use theirs so that they can control the primary relationship with the customer.  Often these services will not release customer lists to the developer.  This becomes a problem long term if you release multiple games and want to run cross promotions. 
    • Storage support: Once players purchase an item or feature, they'll want to have access to their stuff when they sign back in.  This means your game will need online storage and a server back end.  Some payment services offer this as part of the package, which is great for the common situation where the developer doesn't know much about back end programming. 
    • Lock-in: Do you have the ability to easily switch to another payment service?  In general, the more comprehensive solutions with customer make it more difficult to switch.  With some comprehensive services, capturing customers is more valuable than your money.  You only provide cash for a single game, but a customer can be sold and resold dozens of times to dozens of games.  Run far, far away from such companies since their best business interests are not aligned with your best interests. 
    We are in the early stages of the Flash payment market.  Often new game developers will unthinkingly jump on the first service that they happen across.  In this low information environment, payment services can charge unreasonably high margins and very few developers will complain. Many will be excited to give away 50% of their money because they weren't earning any money previously. 
    A payment provider should be a reliable commodity service, not a major business partner. Over time, I predict we'll see more transparency and competition which should drive down prices.  The ideal payment service is one with low margins, low switching costs, no branding and APIs that let you cheaply and easily tie into generic, developer controlled login and storage services.  This will come about as a competitive market works its magic, but until then the opportunists are out in full force and Flash developers will pay a premium for their ignorance.  By asking, comparing, and publicly publishing information about margins, developers can encourage payment providers to compete openly and honestly. 
    The good new is that some generic payment systems are cheap to hook up to your Flash game and allow for experimentation.  On one project, we used SuperRewards and reskinned their front end to it fit nicely into our game.  They charge 20% margin on all purchases, but we can now transparently swap in primary payment provider for credit cards, mobile etc.  By mixing and matching we can build a payment front end that makes us more money.  We own our own virtual currency and we own our customer data.  
    This was accomplished with one programmer in 2 weeks of work and can be reused across multiple games.  Such a path isn't for everyone, especially if you lack web programming skills.  However, with a little elbow grease, you can tap existing, proven, generic payment services to roll your own with very little downside. 

    Execution matters
    Most Flash game developers are ignoring all of these steps.  A few are doing a couple steps poorly, failing and then running about screaming that you can't make money off charging for premium content.  Instead of jumping to ill formed conclusions, try executing with vigor some of the basic business lessons learned in the past 2000 years of capitalism.  Just going through the motions isn't enough. 
    Here's an example of a good idea poorly executed. Dan Hoelck is the very talented developer behind the polished Flash game Drunken Masters, a game that attempts to charge for premium content.  He created a content gate, displayed his offer to the player and integrated a payment service.  Unfortunately, the resulting sales process is torpedoed by multiple fatal flaws.  As a result his conversion rates are miserable: 0.01% of users purchase his offer.  You'd hope to see numbers closer to 0.1 - 1%. 
    • The call to action isn't clear.  The offer is labled 'cheats' (not a positive connotation) and then crams lots of little detail in a tiny font at the bottom of the screen. I'm looking for a big 'buy now' button and some pretty pictures telling me all the lovely things I'll get. This is nowhere to be seen.  
    • The value of the offer is questionable.  He gives 90+% of the game away for free, and lets you purchase a few miscellaneous features that most people don't need. A good rule of thumb when using a content gate is that your premium content should be seen as twice as valuable as the demo experience.  
    • Making purchasing difficult: In order to purchase, you need to manually type in a URL, find the right link to click on and then purchase. Is this necessary? Every step of the pipeline, you are going to lose large numbers of users. As much of the purchase flow should be within the game as possible. 
    • Charging too little.  Dan charges $1.50 for his game and this is likely too little. Beware your natural tendency to undercharge.  People who love your game are surprisingly price insensitive. For example, in the microtransaction-based MMO Domain of Heroes, prices range from "$0.99 to $349.99 and about 80% of the revenue comes from purchases at the $19.99 pricepoint." With a little price experimentation I suspect Dan could have increased his price to $5 or $10 and increased his overall revenues substancially.
    It is okay to fail.  The basic system Dan made took him ~40 hours to implement and it is obvious he has learned a lot of lessons from the experiment.  Building an effective sales pipeline is just as much a craft as making a great game.  As a game developer you need to approach the task as a new skill to master that you likely aren't going to get right the first time.  Put in the basics, measure your results and apply what you've learned to your next project.  

    But people will hate me if I charge money! 
    Some developers I've talked with worry that they'll alienate others by charging directly for their game.  Here are some common concerns: 
    • Bad reputation: Many Flash game developers are not in it for the money, but to be part of the indie community. The threat of a poor reputation can be frightening. The truth is that modest, self effacing developers that find financial success are worshiped like heroes. Just ask Colin of Fantastic Contraption how he was received at GDC.  If you are worried about your reputation, stop starving yourself into hipness.  Instead create great games and be generous to others. A good reputation follows naturally. 
    • Players complaining: So what if you end up being hated by a few kids that feel entitled to free stuff?  It isn't the end of the world. Usually the money and thanks from delighted customers more than make up for a few sour grapes tossed about on dark and skanky corners of the Internet. 
    • Bad rankings: It is true that players will occasionally mark down paid games out of ignorance and spite. Luckily there is a solution.  If you offer real value to customers in love with your game, your fan's rapturous applause will drown out whiners.  Players, in aggregate, tend to forgive great games, even if they need to pay for them. 
    • Sponsors: Sponsors don't want the game they serve competing directly with their primary source of revenue, ads. If you can promote that your premium game results in better player engagement and repeat plays, most portals will happily take their cuts of the resulting ad revenue and leave you to monetize your customers.  A smaller number will worry that your premium content will pollute their 'free' label.  An even smaller number will be greedy and ask for a cut of your hard earned customer revenue.  In the short term, you can ignore demanding portals.  The market is highly fragmented (30,000 portals!) and no portal owns more than 5% of the players.  At this point in the market, developers have the ability to walk away from the greedy minority.  Suggest reasonable terms where portal keep their existing ad revenue and you keep all in game revenue.  If they balk, leave the bastards to rot. 
    If you make a great game played for hours on end by millions of people, you deserve to be paid.  Stop worrying about how people 'might' react.  Ask a fair price for the value that you provide. 

    Quick monetization check list
    • Are you asking users for money? 
    • Are you telling users what they'll get if they pay you?
    • Have you hooked up a payment system before you launch your game?
    • Are you tapping multiple revenue streams that appeal to different types of users?
    • Are you basing your design decisions on the behavior of people who make you money? 
    • Are you appropriately filtering the feedback of people who do not make you money?
    Take care
    PS: Time for a short break!  I'll follow up with the next few chapters in a couple of days. 


    Labels: , , , ,

    Read more!

    Wednesday, April 09, 2008

    A Services Strategy for Casual Games

    Gamasutra posted up an article that has been bouncing around in my documents folder for a little while. The original title was "A Services Strategy for Casual Games", but the new one is a bit more punchy.

    One response that I've heard quite a bit is that portals will never allow user data to be released back to developers. This is quite true for most established portals that have traditionally focused on selling packaged goods online. However, middlemen adapt and markets flow around stupidity. More sophisticated variations on sites like are bound to emerge. If a dozen portals don't want your business, find the one that does. Given time and a exclusive supply of successful games, they'll grow into a bigger fish that can help feed your team.

    The portals are engaging in a kneejerk reaction to changing business models. In the long run, do they really think they can keep customer data away from developers when the games that players want are online services? Such companies just end up being a roadbump in the way of progress. A portal that gets irritable about giving up customer data guarantees that their cut of the pie is zero. This is their loss, not yours.

    take care

    Labels: , , , , ,

    Read more!

    Tuesday, December 18, 2007

    The Naked Business

    An essay on how to treat customers and employees like owners and reap the benefits.

    In any meeting, a negotiator can adopt a variety of strategies. Typically, they horde information, pick apart their opponent's every move in hope of understanding hidden meaning, and ultimately attempt to gain the upper hand through manipulation. Sometimes you outsmart your opponent and win. Many times, you are so busy protecting yourself that a deal never happens.

    There is a less common negotiation strategy that relies on going completely naked. Instead of hoarding information, you give it freely. You openly explain both your needs and what you have to offer. If the other person reciprocates with open arms, you can work together to capture amazing opportunities.

    It occurs to me that many private companies play the game of business as a negotiation situation where their customers and employees are opponents that must be outsmarted. Many deals are left on the table. What would happen if they instead used the naked negotiation strategy? Imagine a company that says to their customers with conviction and honesty, "Here is what I have, and here is what I need. Let us work together to create mutual value."

    The rules of an Open Kimono business
    The following are simple rules of thumb that guide the behavior of a Naked company.
    • Rule #1 - We are all in this together: By purchasing a company's product, a customer becomes invested in company's continued success. By working at a company, an employee also becomes invested in company's continued success. In all areas, both the customer and the employee contribute to the business and deserve to share in its success as owners.

    • Rule #2 - We share information freely: Where possible, aggregate information that is shared freely within a company should be shared freely with the customers of a company. More is gained from sharing than from hoarding. We seek to build trust, empower both customers and employees, and solve problems together with the best tools possible.

    • Rule #3 - We win through the creation of superior value: In competitive situations, by erring on the side of openness and honesty, we discover mutually beneficial solutions. As a result the company succeeds by being able to offer superior value compared to those companies that attempt to get ahead through trickery or manipulation of perception.
    All this is lovely sentiment, but what does it mean? The following practices might vary depending on the exact company, but here is a good start.
    • All major financial data is posted in an easy-to-comprehend fashion on the company web site
    • All major company metrics, goals and progress towards those goals are publicly posted and constantly updated.
    • Periodic customer research is performed and the results are also made available to all customers and employees.
    • 5% of profits are redistributed back to existing customers. Another 5% is given to the employees. If desired, the money can be donated to a charity or reinvested in company stock.
    • When problem areas are identified, customers are encouraged to contribute suggestion, time or resources to the solving of the problem.
    Roots of the Naked business
    The roots of the Naked business are quite traditional. Successful companies have been using these techniques for years.
    • Public companies: Public companies are required by law to divulge certain internal information to their stock holders. The result is that dishonest behavior is not allowed to fester for long without being exposed to the light of reality. It is debatable however, if public company's slavish devotion to quarterly stockholder gain is a positive long term strategy. A Naked company that has the transparency of a public company, but is measured on pertinent long term business metrics instead of only short term financial data.
    • Open Book Management: By sharing pertinent company information with employees, companies run by open book management empower everyone in the company to innovate towards a common goal. A Naked company uses the same technique to leverage not only the distributed power of their employees, but also the distributed networking power of their customers.
    • Market Orientation: Companies with market orientation listen to both the needs of their customers and the trends in the market when making strategic and tactical decisions. A Naked company's close two-way communication with its customers allows it to respond effectively to the latest market information.
    • Market as a community: Markets are often looked at as system in which buyers and sellers exchange value, where value is defined in financial and material terms. Yet strong emotional bonds form between buyers and sellers that can bring substantial social value to both parties. People will always seek to find meaning in their actions, yet companies often ignore this fundamental need. A Naked company provides both customers and employees with a self-contained community that encourages, nurtures, and thrives upon the creation of social value.
    The case against the Naked business
    When I bring this concept up to people, the inevitable reaction is "What an idealistic notion. Unfortunately, the world does not work like that." It is utterly self evident that close management of information is essential to any financially successful venture. In no particular order, the following are considered to be fatal flaws in the Naked philosophy.
    • Severe competitive disadvantage: The moment a company provides open information to the public, competitors will use that information to gain an advantage. Copycat tactics, preemptive product releases and attack ads that further publicize embarrassing information are all likely.
    • Expensive: By spending time providing reams of information, small companies are using scarce resources ineffectively. Seeking more sales or creating a improved product will yield better results.
    • Customers lack of business skills:No benefit is gained because customers lack the skills to interpret company information in any meaningful fashion.
    • Public relations nightmare: Honest publication of information means that the company will be displaying warts and all to the public. There is little opportunity to spin bad news or manage your financial data.
    • Customer relations nightmare: If you give customers a sense of empowerment, they will complain endlessly and publicly. This in turn leads to bad press and a loss of sales.
    • No one is doing this: Few profitable companies operate in this fashion. They must have already failed.
    The case for a Naked business
    The following are benefits of an OK company.
    • Passion: Companies with a strong vision tend to outperform those that focus solely on financial results. By building a culture around a philosophy that people can wholeheartedly believe in, employees and customers will give the extra effort necessary to ensure success.
    • Strong word of mouth presence: A company with a unique and appealing ideology stands out in the crowd. The fact that customers benefit from this ideology yields a powerful source of word of mouth advertising.
    • The customer's network is the company's network: A customer that truly believes that they are invested in a company feels comfortable sharing their contacts and resources. At the extreme end, the customer is a believer that happily volunteers for the company. A thousand customers have a larger and potentially more powerful network than a hundred employees.
    • Faster response to market change: Customers that complain or offer advice provide a highly responsive early warning system to changing needs or competitive threats.
    • Many eyes catch stupid mistakes: Strategic blunders are easier to catch when you have multiple people offering unbiased commentary.
    • Increased customer trust and loyalty: This in turn leads to retention and improved profits. Why go elsewhere when a company concretely demonstrates that it is deeply interested in listening to your needs?
    • Increased employee trust and loyalty: This also leads to retention and improved profits. Employees are the core asset of a knowledge-based company. By keeping them, you build an experience based sustainable competitive advantage.
    • One reality: The cost, both financial and psychological, of keeping multiple books, one for the public, one for the employees, and one for the investors is greatly reduced. The benefit is that customers and employees can talk the same language and use the same data to create mutually beneficial outcomes.
    Key implementation areas
    Let's suppose for a moment that benefits of an Open Kimono philosophy outweigh the detriments. What are the success factors that must be focused on to gain those benefits?. The follow are key implementation areas that must be addressed in order to achieve success.

    • Dedicated Leadership: Any culturally driven sustainable advantage needs to have buy-in and support at the leadership level. Words alone are meaningless. Consistent public actions by respected leaders help the cultural change permeate through the entire organization.
    • Customer and Employee Education: Data is useless unless the intended audience is capable of understanding it. Putting company information in format that is comprehensible to the customers and employees is a partial solution. Actively educating both customers and employees on the meaning and use of the data is equally important. If there is not an obvious connection between the data and the benefits received by the person digesting the data, then the system has failed.
    • Filtering through the noise: When everyone yells their opinion, it can be hard to capture any useful information. Rigorous data collection and analysis techniques can turn the outpouring of information into actionable solutions.
    A strongly customer and employee oriented company is more likely to prosper than a profits oriented company. Profits are still important, but it is wise to remember that they are one metric amongst many. By focusing on satisfying a broad range of benefits instead of merely materialistic and financial benefits, a Naked company attracts and retains both superior quantities of customers and superior quality employees.

    In the end, running a Naked company is as much a personal choice as it is a business decision. Openness, honesty, community and mutual respect are concepts I can believe in. All else being equal, what type of business would you want to devote your life to?

    take care

    PS: With some minor changes, this was an essay I wrote many years ago. In the subsequent years, transparency has come en vogue and it now seems everyone is spouting its praises. Which is a great thing. This message needs to be broadcast as loudly as possible lest it be lost in the morass of sub-optimizers twisting the truth in the name of profits.


    Labels: ,

    Read more!

    Tuesday, May 15, 2007

    The Circle of Life: An Analysis of the Game Product Lifecycle

    My article introducing folks to the genre life cycle is up on Woot. Gamasutra is a site that I respect quite highly, so I'm honored to see them taking an interest in these esoteric writings of mine. :-)

    Let me know what you think:

    take care

    Labels: , , ,

    Read more!

    Sunday, February 18, 2007

    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.

    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.

    Take care

    References and resources

    Original pretty pictures
    I was inspired by these image of agile development when I began making diagrams.

    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 .

    Iterative techniques
    Agile Overview:

    Stage gate
    Winning at New Products: Accelerating the process from idea to launch, 3rd edition Robert G. Cooper, copyright 2001

    Project Horseshoe Report on building games that sell
    Many of the ideas in this essay were heavily influenced by discussion inside the Play Dough group at Project Horseshoe 2006.

    Labels: , , , , ,

    Read more!

    Saturday, February 10, 2007

    "Content is Bad"

    I just came across an article by the good folks at Introversion discussing procedural animation and its benefits versus hand crafted content. Some of my favorite games of all time are riddled with procedural content. The universes of Elite, the dungeons of NetHack, the random maps of Age of Wonders...all these are littered with procedural content. And how could I forget Dice Wars. Or Tetris. Or Poker.

    The more handcrafted content you build, the more it costs. There are few economies of scale. Want a new level? Add a couple more monkey designers and artists to the team. Want a higher level of detail? Add some more team members. Procedural content has the benefit that despite an initial start up costs, you get immense amounts of content for little to no incremental cost. Procedural content also is inherently more agile friendly than handcrafted content. It can be refactored, unit tested and evolved in an iterative process that lets you try out new ideas quickly.

    The problem with hand crafted throwaway content
    If we look at content from a rewards perspective, you can classify content in games into two main buckets:
    • Throwaway: This is content that the player sees once or twice and then proceeds to ignore every time they see it again. It has a very high burnout rate since the player immediately sucks any value from it, groks it and then filters it out as noise. In order to keep throwaway content exciting, teams produce large amounts of it and direct a steady stream of empty calories at the player. RPG's, Adventure games and many single player FPS have mastered this technique. Most plot points, level designs, conversations with towns folk, etc fall into the throwaway content category.
    • Reusable: This is content that the player keeps coming back to again and again because it tends to be useful. A new character with abilities, a new weapon that has a unique effect on the environment, a store that lets you trade in resources are all examples of reusable content.
    Handcrafted content is expensive in bulk, but it has another issue: it is incredibly difficult modify quickly. If you build a clown and then decide that a rapid zombie dog works later, you are forced to rework the models and animations completely from the ground up. You can lose month when you decide to alter your static content. Great game play comes about through rapid cycles of prototyping and playtesting. Visuals, settings and level design are feedback mechanisms like any other and need to be adjusted and iterated upon just as much as the algorithmic simulation underneath.

    The more handcrafted, throwaway content that you have, the less agile your development process will be. This dramatically increases the chance that you will fail to converge upon enjoyable gameplay. It also dramatically increases the chance that you'll fall back on conservative game mechanics because the act of trying something new is too bloody expensive.

    If you are on a budget, you should start identifying throwaway content and figuring out ways to remove it from your design. It may seem like a great idea to have a clown appear in a scripted scene where he describes his life story. However the incremental value to the customer is rarely worth the cost of production or the loss of project agility.

    Using procedural content to replace throwaway content

    There are two faces to procedural content. The first is as a hack for throwaway content. It allows you to cheaply replace large amounts handcrafted seemingly meaningful, but actually useless game content with algorithmically generated seemingly meaningful, but actually useless game content.

    Ask yourself:
    • Is this content critical to a working game mechanic? Identify the feedback that it gives the user and think about how it might provide them with utility. Sometimes you can cut content immediately from the game.
    • After the user has seen this once, will they ever care about it again? This helps you understand if you are dealing with throwaway content or something meaningful to the player.
    • If not, is there an inexpensive stylistic tweak that allows me to use a cheaper means of producing the content? If so, there are numerous possibilities here ranging from a less expensive art style, to procedural content, to player generated content. Pick the one that provides the player with the most utility, costs the least and leaves you in a position of greatest agility.
    You'll find a lot of procedural content generation techniques that fit the bill. These are rarely up to par with the best hand crafted assets, but they will work in a pinch often at a much lower cost.
    • Sound generation
    • Texture generation
    • Particle systems
    • Procedural character animation
    • Ambient animations
    Using procedural content to augment reusable content
    The second face of procedural content is where it is integral to a reusable game mechanic. In NetHack, the act of exploring the dungeons and coming across different configurations of monsters and items is crucial to the player's slow but steady unraveling of the immensely complex system underlying the game. Each level was somewhat disposable, but the map generation system was actually an intricately balanced algorithmic method of putting the player in unique initial conditions that helped maximize their learning of new skills.

    In a card game, the randomness of shuffling the deck and dealing the players an interesting distribution of cards has a big impact on the gameplay that follows. You simply could not play the game without this element of algorithmic level design. Players would figure out the predictable set of hands and all challenge would be removed.

    When dealing with reusable game mechanics, procedural content can replace handcrafted content in the following ways:
    • Setting up interesting initial conditions, especially with configurations of existing game tokens.
    • Introducing risk and uncertainty into game mechanics
    Where procedural content fails
    Procedural content is by no means a panacea.
    • Procedural content is bad at setting goals: Dynamically generated quests were all the rage at one point. It turns out that people just zip through the text. Players quick discern the pattern and you are left with another high burnout game mechanic lying on the trash heap. Good goals are interesting because they are unique; they promise a brand new opportunity learn, advance or help out. They tend to play upon complex concepts of duty, heroism or desire. If you break down why 'Rescue Princess Peach' is meaningful, you'll have a tome on basic human psychology. These are areas where our algorithms are childishly primitive.
    • Procedural content is bad at most social factors: In fact, you can generalize the concept to say that procedural concept is miserable at replacing most human aspects of content. Conversations, voice acting, descriptions of long lost cultures, plot, all these are difficult to replace. You can either cut them from your game, turn them into easily refactorable modules (like the descriptions in NetHack) or as a very last resort, use traditional, expensive handcrafted production techniques.
    • Density: Developers sometimes react to the ability to generate infinite levels by building games that sport infinite levels. This is a very bad idea. When you are using a random map generator to put the player in interesting situations, the key operative word here is 'interesting'. All the standard rules of pacing, flow and burnout still apply. If your procedural content only amuses players for 15 minutes, make a 15 minute game. Otherwise start increasing the density of interesting interactions. No one wants to wander for hours through an infinite maze that has no purpose.
    • Procedural content requires a programmer-designer or programmer-artist: This shouldn't be surprising, but you really need someone who is both a good programmer and a good game designer to make procedural content work. Someone who only programs or only draws seem to be a dime a dozen, but good programmers with design skills or art skills are rather rare. If you aren't such a magic person, so you need to form a team that has all the skills you need. Sit your designer and programmer next to one another and iterate like mad.
    Ze sum uppery
    The phrase "Content is Bad" is of course hyperbolic. To rephrase it, too much handcrafted throw away content is expensive and decreases the teams agility. Procedural content is one solution, but if there is anything I'd take away from this essay, it is the broader concept of creating agile, refactorable content.

    If you are smart, your design will change dramatically over the course of development. You'll discover a hundred little tweaks that end up making your final game far better than the initial design. Always be on the lookout for content that you can refactor in some way so that you can change it more cheaply.
    • Procedural content, when properly used, can turn the bulk of hand crafted content into code with all the added benefits of flexibility and cost reduction. You'll still have a bit left over in the form of variables and other compact data, but this will be much easier to manage.
    • User created content (which is at least another essay or two) offloads handcrafted content to your users.
    • If all else fails, at least modularize your content into tiny bite sized pieces that can be added or removed without derailing the ability to do frequent, completely playable builds.
    Always maintain the ability to make a change to game play and test it with users within the next hour. If content becomes a barrier to this goal, you need to refactor your content-based systems. Be brutal in enforcing this rule, no matter how much you like that cutscene with the clown. It could save your team and your game.

    The plague of handcrafted content is only going to get worse in the future. A friend mentioned that a level in his previous game took 2 days to assemble. Now, with the advance in customer expectations, it takes their team two months to build a level. If it costs that much to build a level from scratch, think of the pain involved in propagating a substantial late game design change throughout a series of levels. I can't help but wonder what their production schedule might have looked like if instead they had adopted the philosophy that "Content is bad."

    take care


    "Procedural technique is another name for tool."
    Jason Booth has a wonderful essay that talk about how much of what we call procedural content is really just another name for tools. They leverage a small bit of creative content to create a lot of gameplay, but they still need to be used in a creative fashion. There is no magic 'make me a world button' and the folks that take this attitude tend to give the whole concept a bad name.

    A more comprehensive definition

    Introversion discusses procedural generation
    The originators of the phase "Content. Is. Bad." They should make a t-shirt with that phase on the back and my favorite character design of all time on the front: "@"

    One of the grand daddies of procedural content done well.

    Desert Bus
    A game by Penn and Teller that illustrates the problem of gameplay density quite succinctly.'s_Smoke_and_Mirrors

    Thought experiment: Tiles as an early form of procedural content
    "But most games that use procedural content suck" I recommend folks look at games like Zelda or Mario Brothers. Tiles were a huge innovation that allowed the developer to convey complex concepts (like walls, doors, tapestries, rocks, etc) without drawing ever single scene by hand. Instead you create a few modular pieces and then arrange the initial conditions of those pieces in an interesting way. You only use a small core of handcrafted seed data to build some truly enormous worlds.

    This may seem like 'not true procedural generation', but compare it to the other popular alternative of the day: Drawing out every screen by hand. The genre that relied upon this technique, graphic adventures, was pushed into niche status. It simply could not compete economically with the richly interactive environments and economic efficiency of procedural techniques like tile-based environments. Food for thought.

    Labels: , , ,

    Read more!