For many years, I've been thinking about game design as a form of governance.
Game mechanics, rules and systems are comparable to laws
Players are comparable to citizens
The code and moderators that enforce game mechanics are comparable to executive activities.
The act of game design is the equivalent of drafting new laws, legislative activities.
Issue escalation and customer service are comparable to judicial activities.
Each of these topics provides years of future discussion. However, for the sake of brevity, I'll limit this essay to some thoughts on how a game government differs from a traditional government. Game governments have the following unique attributes:
Games are voluntary
Games allow for rapid iteration
Games excel at targeting individuals
Games are voluntary The current crop of games are voluntary activities. In a traditional government, you are a citizen of the geographic region or nation in which you live. Membership for those who are born there is automatic. Renouncing or acquiring citizenship is a difficult activity with numerous costs. In most games players choose to operate within the magic circle defined by the rules of the game. Playing a game is seen as an explicitly voluntary activity.
There are several prerequisites for the voluntary nature of game to be realized.
Freedom to leave: Player should be able to stop playing the game when they wish. At the very least, they can step outside the magic circle and return to the rules of the real world. However, they might also leave one game and switch to another. The voluntary nature of games is threatened when the player can no longer leave. If you are part of a school program in which Wii Fit is a required activity, it rapidly becomes something other than a game.
Freedom to participate: Equally important, players should feel that their actions within the game are voluntary. Free will, or at least the illusion of free will, is necessary for there to be meaningful choices, deep experiential learning and mastery. Remove the players ability to explore the space defined by the rules of the game and at best you have rote mechanical work. At worst, you've created a crushing regime that teaches and enforces mindless obedience to a machine made of code.
Neither participating in a game nor leaving a game is without cost. All games create a self contained system of value where players are taught that algorithmic constructs are meaningful to their lives. There is always an opportunity cost involved in forming these values. There is also a cost to leaving the whirling blinking, pinging systems behind. The sword you worked for so hard in WoW has little meaning outside the game.
Games enable rapid iteration Most modern networked electronic games involve code executing on servers. The code can be updated and pushed out to millions of players in minutes. Unhappy with the current laws? A few keystrokes later and your populace is now bound by a fresh, crisply defined reality. Traditional governments lack this speed. Laws are deliberated for months and years. They are slowly rolled out piecemeal by people and enforced piecemeal by people. People are fallible and each interpets the laws according to their biases. Some laws don't work. Some laws have inexplicable consequences that play out over many years.
There are several consequences
Metrics: First, metrics concerning large swatches of player behavior are readily available. In many cases, developers can set up tests that let them know if the rules they've created are generated the behavioral result they desire.
Scientific iteration: The player population is easily segmented. We witness this currently with A/B testing or with the rollout of Facebook changes according to geographic regions. It is possible to launch rules in a population subset, measure the results and then either kill the experiment or spread the rules more broadly if they are a success. At one point Valve had a saying that went something like "If this is a design decision that is a matter of opinion, don't waste time arguing about it. Instead play test it." What are the ramifications of using the scientific method on the generation of laws for humans?
Democracy of behavior: This leads to a fascinating reinterpretation of the 2500 year old formulation of democracy. You no longer vote by taking time out of your schedule and filling out a piece of paper. Instead, you vote by doing. The player's actions determine the tale the metrics tell. There is always 100% voter turnout because by choosing to play, you automatically participate in the legislative process.
Game excel at targeting individuals Games are laser focused on the individual's activities. They deal with individual choice and individual rewards. A game knows exactly what a single person has done and adapts accordingly. Traditional governments create broad swathes of rules that affect entities or populations. Their hold on any one individual is powerful, but is very much a blunt instrument. Specifically, traditional governments lack the detailed knowledge of individual behavior, the frequency of feedback and precision of the reward structure. Wherein taxes are a feedback loop that occurs once a year, Pacman adapts to your actions 30 times a second.
Game designs are laws targeted at the mundane activities of free will. With Bejeweled we influence how your spend your free time. With Wii Fit, we reward or punish how you exercise. With Nike Plus we reward and punish how you move your feet. With Facebook games, we mediate how you socialize. In time, each of these will improve. In time games will target more and more activities. Travel, sleep, energy usage, medicine, love, sex, eating. If we can measure it, we can make a game out of it.
Pervasive law: These quotidian activities are the meat of life. As games spread throughout our everyday moments, we are suddenly in the hitherto unheard of situation where law affects 80% of our lives.
If you designed the rules that governed even a small portion of the lives of millions of people, what sort of world would you create? What are your moral obligations as a game designer? Are we still just talking about money? Are we still only talking about fun?
I was about to ask a friend what sort of games she liked to make and I realized that I didn't even know how to frame that question in an intelligent manner. I've noticed that games have distinct styles. These are not visual styles. Nor are they styles associated with prefered process of development. Instead, they are unique styles of game design, how you mix and match mechanics, story, player agency and feedback. What do you emphasize? What aspects of the the player's experience do you highlight with your design choices?
A spectrum of game design styles It is a broad topic, so I'll just jump right in. Here are some styles that I've noticed. You can think of these categories as pieces of a spectrum that cover all major aspects of the final game design that the player experiences. Though they are all present, each style is emphasized to varying degrees in a particular title.
Copycat: make a game like another game that is interesting.
Experience: Make a distinct moment of game play that looks and feels interesting.
Narrative: Make a story that is interesting
World: Make a place or world that is interesting
Systems: Make systems and objects that are interesting.
Player Skills: Make verbs for the player that are interesting.
Let's give a brief description of each of these styles and how I've seen them work.
Copycat A copycat designer takes an existing game genre and builds a new work within it. The term 'copycat' is descriptive and not derisive. I personally steal with great gusto from other games and consider an elegantly pulled off theft to be an essential skill for any practicing designer.
Copycats borrow liberally from the best elements of past works and mix them together with minor design innovations to create the new flavor of the month.
If design problems arise, a good solution is often readily available in a historical product in the same genre. The best copycat designers have encyclopedic knowledge of other games in their genre.
The goal is almost always to make something better or 'more correct' than what has been on the market previously.
Most working designers are copycat designers. On the supply side, there exists a natural urge for a player who deeply loves a particular genre to attempt to do a better job. This provides a constant wellspring of new copycat designers. On the demand side, the market's lust for sequels ensures a wide range of jobs that need good copycat designs. Helping this dynamic is the fact that it is quite easy to learn to be a copycat designer. Find a game you like and copy it. You don't need to know theory or have a strong philosophy of design. Over many years of labor you'll likely get quite good at making polished variations on the initial blueprint.
Competition is intense. Most of the time you are fighting over market share in a crowded genre. You can avoid the competition by building a strong established brand (which costs lots of money) or you can be first to a popular new platform (which requires technical resources and the ability to predict future markets)
Costs are high. All the polish required results in long development cycles with large teams and large marketing budgets.
Risk aversion dominates: Both copycat players and developers are risk averse. Players want their comfortable fix and developers don't want to introduce undue design risk in an already financially risky project. This often leads to bigger titles that are not always better.
An experience designer has a vision in their head of how the game will eventually look, feel and sound. They seek to create an emotional moment for the player that matches their vision.
Experience designers start with a mental image of the game. It could be a still shot. It could be a scene. The scene is laden with strong emotional and evocative detail.
Everything in the game exists to serve and bring to life that vision.
When I think of games that demonstrate the Experience style, I immediately think of Flow and Flower. Graveyard is also a good example. Starting with a target experience has a lot of benefits. You can change your art, mechanics, story and other game elements to match the experience. Experience designs have the added benefit of making the original designer valuable and nearly irreplaceable. The vision resides primarily in their head and they can act as the final arbiter of whether or not the actual product meets their vision.
Designs based on a vision are difficult to communicate. On larger teams, communication mistakes can multiply and bog down the project.
Teams can wander down dozens of different paths and still not reach the ephemeral vision in the designer's noggin.
Occasionally other game play elements are poorly fleshed out. You can easily end up with something that is pretty, but isn't all that fun to play.
A story designer has a tale, usually a linear sequence of evocative events (or graph of such events), that they wish to tell. Games are the stage upon which the story is performed.
The game is conceived as a narrative arc and gameplay is often relegated to mini-game set pieces strung together to support the creation of the arc.
Design efforts focus on the use of symbols and pacing to evoke emotion. When the designer kills or removes a character and there is nothing the player could have done, you know you are dealing with a Story Designer.
The game is a success if players react strongly to the story that has been woven for them over the course of their play.
Story designers are quite common in larger scale games. Many AAA titles sports a very specific 'roller coaster ride' structure that has narrative design at it's heart. Examples of games built by Story Designers are everywhere. Choose your own adventures are the classic case, but I'd be curious if even a game like Passage was ultimately conceived as a tale with fixed endings (albeit one where authorial intent was enforced by a predestined algorithm).
Most story-based games can only be played once or twice before they are no longer interesting. They deliver their tale and then their value is spent.
Every little bit of must-see narrative steals a smidgen of agency away from the player. Instead of letting the player author their own story, the designer steps in and forces their own narrative upon the player. This limits the player's ability to try and learn new things.
Failure is rarely an option, or at least not a serious one. After all, there is a story that must be told. Many times players are shunted from plot point to plot point with minimal gaming fuss.
A world designer begins by envisioning an imaginary space. They picture how it might be if they escaped into it as a player.
Place is a critical organizing concept. Items, people, organizations lives in specific places and their spatial relationships give meaning to the world. It is quite common for world designers to think in terms of maps, architecture, towns, races, guilds, districts etc.
Much of the flavor of the place is created through the use of historical detail. The underlying assumption is that the world existed when the player was gone and it will exist when the player leaves.
World designer will often lean heavily on fresh content in the form of new vistas to create a sensation of being in the world. They will often use the same game mechanics throughout, but delight the player by varying the setting from location to location.
The classic example of a World Designer is found in the paper RPG world. A GM will start with a map of continents and flesh out civilizations, races and alliances. This creates a playground for imaginative adventures. Games like Ultima, Oblivion and World of Warcraft also have a strong World style.
World designs can often result in bloated games. There is so much stuff in the ever evolving world in your head that it is hard to know when to stop adding. New systems and verbs are created to support the exploration of every nook and cranny and few mechanics interconnect in crisp manner.
World designs are usually an immense amount of work. It is far easier to make a single scene or a situation than it is to flesh out an entire world.
Designers can focus so much on building the space that they forget to fill it with interesting things for the player to do. The result is mechanical place that feels lifeless.
Systems designers begin with a curious and intriguing set of rules that interact in unexpected ways.
Designs often begin with a set of objects, properties and interesting ways that the objects interact.
Common sources of inspiration include probability, combinatorics, spacial relationships, physics, timing and economic game theory.
The goal is to create a challenge for the player, be it a short term challenge in the form of a puzzle or a long term challenge in the form of a deep possibility space.
Truly deep systems often lay bare their mechanics in order to provide advanced players with absolutely clarity on their inner workings. The result is less room for details like narrative or world building.
Many of the industry's most original forms of gameplay were conceived by people inspired by systems. With simpler rule sets, you find games like Tetris. Complex systems yield creations like SimCity or Populous.
You'll often end up with a system that is fascinating to the designer, but not that enjoyable to the player.
Many systems oriented designs come across to players as overly abstract. There isn't a clear entry point into the design for new users in the form of a friendly metaphor or setting.
Systems can be quite difficult to balance due to all the various emergent interactions.
Player skills Designers that focus on player skills create a set of actions (or 'verbs' in Chris Crawford lingo) for the player to perform. Then they create systems that help them learn those skills.
You start by writing out the type of verbs that you want the player to perform.
Then you figure out systems to go with those verbs
You figure out what additional skills are discovered when the systems are put in front of players.
Finally you figure out the right feedback systems to teach people those skills in an enjoyable manner.
Miyamoto is a good example of a designer inspired by player actions. When developing games he tends to focus on what the player is doing. Mario was originally named Jumpman after the key action you performed in the game. WiiFit came about by asking what sort of game could be built around the joy of weighing yourself. Mario 64 started as a playtest bed where all you could do is run around a small room and exercise the basic verbs of the game.
Game play occasionally devolves into a series of disconnected mini-games when designers grab the easiest system available to represent a particular action. For example, in FishingGirl, I used a Frogger-style mechanic to represent fishing. As a simulation it was quite limited and was barely connected to the other mini-games associated with of casting and purchasing lures. In something like God of War, they turn the action "Kill boss monster" into the simplistic mini-game "Simon".
After coming up with a set of fun actions, narrative and world are applied as a skin to the results. The result are surreal worlds involving mushrooms, exploding barrel graphics and other videogame-isms.
Rising design styles The following styles are starting to appear within a few pockets of game design community.
Social: Designers that focus on encouraging particular types of interactions between multiple people. They have skills of event coordinators or party planners and focus on atmosphere, breaking the ice, moving people from activity to activity as well as efficient build up and take down of the event. Important organizing concepts include 'Events' and 'Social spaces'. MMOs, Party games, and social networking games tend to attract Social designers. It is my believe that the next generation of great designers will be social designers.
Business: Design that focus on business try to squeeze as much money out of players as possible. I meet designers operating in online games and gambling games with this design slant. Typically, you encounter it in ex-designers who have moved onto publishing roles. It is an extremely powerful perspective that is unfortunately rather rare. As free-to-play becomes more popular, gameplay and business model will become even more interwoven.
Product Utility: Designers that focus on player value first identifies some form of utility that the product bring to the player. Product Utility designers often come from a more traditional product design background and focus on creating innovative solutions to observed problems. Yahoo, Amazon, Iminlikewithyou, and numerous web 2.0 companies a busy using the motivational aspects of games for utilitarian purposes. In short, this is social engineering with a purpose.
Pick your style!
Most designers tend to mix a couple major styles together. For example someone who enjoys working on licenses might start with a world style and do a deep dive to understand the world of the license. Then they augment that with a copycat design. Or someone who works on art games could mix a strong narrative with a systems oriented set of mechanics.
My suspicion is that most designers will have trouble applying all these styles to a game equally. First, each style can easily take years of intense labor to master. Secondly, games need focus in order to clearly convey their intended value. Too many dominant ingredients fighting for the player's time can weaken the end result. It is a bit like cooking. :-)
As an exercise, take a look at various games out on the market and see if you can figure out the handful of styles they've stirred together. Halo is classic Copycat with a heavy coating of Narrative to make it seem like something bigger than your typical game. Desktop Tower Defense a straight Verb and System game, barely seasoned with any other styles. Ian Bogost refers to Jason Rohrer's work at 'Proceduralism'. I see a fascinating mix of Narrative and System styles.
So pick two or three styles for each game you build. Prioritize one as primary and others as secondary (in case there is a conflict at some point later in the design.) Don't ignore the remaining styles since you'll certainly need dashes of them to make the game function. However, be conscious of the dominant style of game you are making and make the hard decisions on what to focus on up front.
Understanding design styles to reduce team conflict Inevitably there will be people on your team or in your audience who are fans of the other styles of game design. I regularly run into good people working in the game industry who passionately want to tell the sort of emotional stories that they see in movies. Story and Experience are paramount to them. However, any sort of Systems conversation inevitably devolves into a muddled Copycat discussion.
You can use the game design styles above much like how personality tests are used to resolve conflicts between people with different work styles.
Identify your personal style. Which of those styles above do you love? Which ones do you find dull or unpleasant?
Identify the style of the game you are working on right now. It is very common for this to be something different than your personal style. Publicly declare the style of game you are making so the entire team can agree upon the game's direction.
See if you can understand the preferred style of other people around you that tend to hold forth passionately on game design.
Realize that having people on the team who are passionate about a variety of different styles is a good thing. Just because you occasionally feel the other person is coming from a bizarre and alien perspective doesn't mean that they don't have something valuable to contribute.
When the opportunity comes to up to add in a dash of 'spice' in an area outside your personal style, see if you can tap into the passion of someone who prefers that style. We can't lead all the time in all areas, nor is it a good idea to try.
My style I almost always approach a new design from a Systems perspective. I find an interesting set of objects that interact with one another in interesting ways and then attempt to build a game around it. My typical process is to try lots and lots of systems, throw them at kleenex testers and see which ones are 'fun'. This is labor intensive, but you can keep the costs down by using small agile teams and simple prototypes. It yields games that are lower on the copycat factor. However, they also have a bit of a surreal aspect to them since experience, story and world tend to be re-imagined on the spot to fit the latest mechanics.
Lately, I've been moving more in the direction of a Verb style. With Systems, I'll often end up creating a game that is fun to design, but not fun to play. By focusing on the verbs and how the systems help the player learn to manipulate the system, my prototypes "find the fun" more often. If games create pleasure through exploratory learning, it makes sense that focusing on verbs and skills are one of the more direct paths towards creating engaging game play.
Narrative is my main weak point and something I should work on.
Conclusion One thing I get out of this exercise is that there is not one True style of game design. For every Miyamoto and Will Wright creation there is a game like Monkey Island or Full Throttle pushing story and experience. People love all these games. Game design style, like style in almost any consumer market is a matter of taste. The good news is that now I can name the various styles and discuss them in a less vague fashion.
I also realize that I've been leaving certain powerful perspectives out of my palette of game design tools. When I was younger (and driven more strongly by raging hormones), experience-driven games mattered immensely. I vividly remember working on a game about sickness and trying to convince my fellow teammates that it was of utmost importance that black cancerous growths fall off the player and scuttle away on their own. As I aged, I've moved onto more intellectual and less emotional designs. It might be fun to bring that side of my design back one day.
Of course, this list of game design styles is a work in progress. So I'll end with some questions.
What style of game designer are you? Do you fit into one of these approaches?
Is there another design style that is missing from this list? Can it be expressed by a combination of the other styles?
Recently I was chatting with some friends about the role of 'theme' in game design. Theme, in this discussion, was the setting of the game, be it fantasy, sci-fi, military, etc. At first blush, the typical game designer's use of theme appears a bit primitive.
Limited range compared to the wide variety of themes in movies or books. Games recycle a half dozen major themes or in some cases invent their own surrealist themes that make little sense outside the context of the game. Books, despite being grouped into narrow genres, have explored many thousands of powerful, evocative settings. You have books about bored European manuscript editors exploring the bizarre world of the pseudo occult and you have books set inside the mind of a quadriplegic. The disparity in variety is intriguing.
Crudely applied. Theme is applied in broad strokes at the beginning of many games, but almost always plays second fiddle to interesting game mechanics. Goombas are mushrooms, but this matters little beyond the fact that they are squat, match the scale of the world and can be squashed. If a novelist lazily integrated a character into their book's theme the way that game developer do on a regular basis they would never be published.
The result is that theme is often seen as an interchangable 'skin' that can be applied after the fact to a set of working game mechanics. The task is typically left to marketers to round up a popular license so that it can be painted onto the latest hot collection of game mechanics. This attitude towards theme affects the very fabric of game development.
And yet, something interesting occurs when we work this way. Very few licensed games turn into major long term franchises. They often feel incomplete and the pieces ill matched. On the other hand, seminal 'grown from scratch' games like Bejeweled, Mario, Quake, GTA or Sims end up doing amazingly well. Despite their surreal and often disjointed themes, they are surprisingly fun. In these titles, the theme of the game mechanics and the theme evolved hand-in-hand, often undergoing major switches half way through before settling into a successful partnership.
The Sims was a game about architecture that morphed into a game about playing dollhouse.
Grand Theft Auto was a cops and robbers chase game where you were the cop. It evolved into a game about being a free roaming criminal.
Quake was an Aztec style world where you tossed about a giant Thor-like hammer. It evolved into a nameless soldier battling against the mutants in a series of brown dungeons.
Bioshock was originally about Nazi's on an island.
If you start to dig into how game generate 'fun', many of these thematic transformations are, if not inveitable, certainly commonplace. It turns out that most game designers are not complete idiots when it comes to integrating theme and setting into their game designs. Designers aren't ignoring theme. They are simply using theme in a manner appropriate to the medium in which they work.
Some logic behind the madness If you look at games as being about exploratory learning, they tend to teach the player a series of skills. First the player learns basic skills (how to press a button) and overtime assemble a scaffold of skills that lets them engage in more complex scenarios like 'save the princess'. Each moment of learning gives a burst of pleasure.
These basic skills are utilized over and over again. If the player fails to learn them, the rest of the game is lost on them. Games reward involvement, yet there is a high cost the player must pay in terms of initial learning necessary to become involved.
"Theme" from this perspective, is shorthand for a collection of preexisting mental tools, skills and mental models. I think of it as a tool chest of chunked behaviors that the designer can rely upon to smooth out the initial learning curve.
The theme you select directly influences how you present your initial skills to the user. By saying "Pirates", I turn on a particular schema in the player's brain and a network of possible behaviors and likely outcomes instantaneously lights up. If they see a pirate with an impressive sword facing a small soldier, the goal of fighting the enemy is self evident. With a small visual cue, I've eliminated minutes of painful initial learning.
There is a fascinating moment in the sequence of exploratory learning where players say to themselves "Oh, I recognize and have mastered this situation already, so let me demonstrate my excellence." Because of the triggering of the theme, the challenge appears possible and attainable. If on the other hand, I had substituted the pirates with gray blob A and orange blob B, the player might be quite confused and not even bother to pick up the controller.
Why so few themes? To a certain degree this perspective on games explains the limited number of themes used in games compared to books or movies. A book uses theme as a hook to get people interested in plot and character dynamics. There are lots of potential hooks and the more unique they are, the more intrigued the reader is to find out more. This encourages a proliferation of fascinating settings.
On the other hand, a good theme in a game is one that triggers a number of clear mental models that are applicable to the game mechanics at hand. If you push too far outside the experience zone of potential players, you make them feel inadequate.
It also suggests that occasionally a literary theme simply is not needed. Sometimes it is better to just tell the player, "Hey, it is a game and like any game you've played, we'll educate you as you go." The same triggering of appropriate schema occurs. If it is enough to grease the wheels of learning, then our mission as a game designer is accomplished.
"Skinning" game designs is a bad practice When you look at game design from the 'games as learning' perspective, the idea of creating an slap-on aesthetic skin for a set of game mechanics starts to break down. In the best games, mechanics and theme evolve in lockstep over the course of the many iterations. If a mechanic isn't working, you have a couple choices. You can adjust the rules or you can adjust the feedback that the player receives. The two act in concert to produce the player's learning experience.
A good portion of the time, it makes sense to adjust the feedback side of the equation. What if people don't understand that the pirate is their character? Maybe it makes sense to make the pirate wear a right red outfit and the enemy a bit more evil looking. When you do so, the theme of the game shifts ever so slightly. Over hundreds (or thousands) of tweaks, a theme for the game might emerge that is quite different than what you originally envisioned. This is often the case for the best game in the history of our industry.
In fact, the final theme may be semi-incoherent if you attempt to analyze it as a literary work. However, that doesn't matter because it provides the moment-by-moment scaffolding of feedback that helps the player learn their way through the game. As long as the game is fun and delivers value to the customer we can often toss the literary definition of theme out the window.
In fact, you start getting into trouble when you make the theme so rigidly defined that you can't adjust the feedback for specific game mechanics. What if you are dealing with a license where the pirate isn't allowed to wear a red outfit? That design option, which may have been the best one available, is taken off the table. The hundreds of little trade offs that occur when theme coherence wins and gameplay loses diminishes the effectiveness of the game.
So you can't just 'skin' a set of game mechanics. When you do makes the attempt, a well executed iterative process of game design will often result in a game that is quite different than its source material. A poorly executed process results in a game that plays poorly.
Conclusion There are a couple lessons here.
The most effective game themes exist primarily to facilitate the learning process for the player. This may be a traditional narrative theme, but it doesn't need to be.
Theme evolves in lock step with the rules of the game over a process of many iterations. You might as well plan for it. Early on develop vertical slices of your game. This will help you converge on working combinations of theme and rules. As you go allow for iteration on production assets.
Locking in your theme too early and too rigidly can stunt the exploration of more effective feedback systems. A bit of flexibility often yields better gameplay.
Oh la la! It is time for another game prototyping challenge. As has become the tradition around here, you provide the brilliant code and I provide you with a complete set of free graphics that help make you look spiffy.
This game design stems from a peculiar fetish of mine. I don't normally talk about this in public, but...how to say this. I have a thing for casual building games filled with adorable little creatures. Late at night, when the rest of the world is busy sleeping, you'll find me fantasizing about the lurid offspring of Lemmings and SimGolf. For a moment, close your eyes and savor the sweet thought of DMA's DNA all mixed up with Will and Sid's unappreciated love child. Oh yes.
The game idea inspired by these questionable thoughts is called Play With Your Peas. Here are the basics:
Peas: You have a bunch of fun loving sentient peas that like to climb tall objects and jump off of them. They think they are ninjas. You know they are suicidal.
Happy points: If the peas land safely, they generate happy points. The more things that they bounce off of on the way down, the more points you get. Think of a successful pea landing like scoring a combo in Tony Hawk.
What you do: Here's the trick. You can't manipulate the peas. You can only add blocks to the landscape. Add a soft landing spot and your falling peas won't splat. Add a spring in the right spot and they'll fly up into the air. Can you build a brilliant playground that delights your peas?
Score: Your score is the time it takes you to reach 20 million points. If you want to simply play with your peas, go for it. If you want to beat the high scores, you must be Elite and build your landscape with great efficiency so that you maximize your pea combos.
Many thanks to Axcho for dredging up this ancient design from the dusty storage shed of my past.
Game Tokens There are only a few types of elements on the screen
Peas: Little AI characters that run around the environment. You can't interact with them directly.
Plate: All action takes place in a box that bounds the sides and bottoms of the screen. No objects can exist outside of the screen.
Blocks: The user can place blocks on the screen. There are multiple types of blocks such as platforms, springs, jello and more.
Flags: These mark the spots where peas have lept from in the past.
Tools: A sidebar of tools that lets you choose the type of block to place.
Happy Score: A counter that tells you how many happy points you've collected so far.
Time: A counter that tells you how much time has elapsed since the beginning of the level.
Basic Pea AI Peas have three main modes:
Navigating the environment: In its primary mode, the pea navigates the environment in an attempt to reach a jumping spot.
Falling: When a pea is falling, it is treated like a simple bouncy ball interacting with the world.
Being scored: Once a falling pea comes to a rest, it is scored.
Navigating the environment The peas traverse the environment in search of ledges to jump off. This is the hard part of building this particular game design. I'll describe the high level behavior, but I leave the implementation as an exercise for the mad programmers of the world.
Look for a ledge: After a pea is scored, it immediately looks for a nearby ledge to jump from.
Wander: If there is no ledge nearby, the peas wanders in a particular direction, slowly climbing over obstacles and working its way up as high as possible.
Calculate path to ledge: When it finds the ledge, it calculates a rapid path to the ledge.
Moving smoothly across a complex environment can be broken down into a series of movement segments.
Walk on a flat surface:
Climb a block wall: Some blocks can be climbed, others cannot.
Climb up a ramp: Some ramps can be climbed.
Jump a gap: If there is a 1 square gap, a pea can jump over it. Remember they think they are ninjas.
Wall jump: Peas can also jump onto a wall that is 1 square above their head to the left or the right. Think of this like moving how a knight in chess moves.
Jumping spots. A block surrounded by space has two default jumping spots, one on the left side and one on the right side. Once a pea reaches a jumping spot, he will jump. A couple things happen at this point.
A flag is automatically planted at the jumping spot.
The pea jumps and his AI switches from navigating the landscape to being a simple bouncing ball.
The flag tracks several things
How many peas have jumped from the jumping spot. As the number gets closer to 100%, the flag slowly rises to the top of the pole.
If a peas spots multiple jumping spots, they will always head towards the jumping spot that has the highest completion percentage. This ensures that the user is focusing on one or two jumping spots, not a half dozen.
When the flag reaches 100%, the jumping spot becomes inactive and no other peas can jump from this location. The user gets a large bonus for having a completed jumping point.
Peas remember which jumping spots they've jumped from and will not jump from that point again.
The flag also serves an important balancing role. Once a flag is planted, several building limitations come into play.
The user cannot place another block on the square occupied by the flag.
The user cannot remove the block under the flag.
These rules prevent the user from recycling jumping locations and they also slowly eat up the space on the board so that the user needs to work around the detritus of their previous efforts.
Bouncing When your pea falls, it bounces off of blocks that get in its way. Some blocks, such as gelatin, slow you down. Others, like springs, give you an additional boost. However, your pea is not indestructible.
If you land on a standard block after falling a distance more than two blocks, you pea will die. A dead pea means less opportunity to score.
The skill of the game is building environments that yield the maximum number of bounces while still managing to land your peas safely in the end.
It is possible for the player to create cul-de-sacs where the pea will bounce indefinitely. One potential balancing feature is to add in a counter that keeps track of how many times specific blocks have been hit. If the hit count on single block gets too high, the pea yells out 'It's a trap!' Even if a trapped pea is released, you get no points.
Scoring When a peas finally comes to a stop and it survives it's journey, it gets a happy score.
Happy score = Total bounces * (Spring Bounces * Spring Value + Normal Bounces * Normal value + Gel bounces * Gel Value + Successful Landing)
The pea's happy score is added to the player's total score. This is a moment of grand celebration. If you have a particle system, this is a great time to use it. I've provided graphics so that a happy pea can yell out "Ninja!", his career aspirations finally complete. Once the peas is scored, he moves on and starts looking for a new jumping spot to leap from.
Building blocks Okay! Now we have some cute little characters that jump about the screen in some logical manner. Finally, it is time to talk about building your world.
Along the left side of the screen is a toolbox that contains the blocks you can use in the level. To select a block, click on it and it will highlight.
To place the block, click on an empty square. The blocks aren't added immediately since they have a build sequence they must follow.
Initial delay: We want to prevent users from micromanaging the flow of their peas by quickly placing blocks. In order to do this, blocks stay ghosted for a short period of time before they fade into solidity.
Check for peas in the square: While the block is ghosted, any peas that are in the space can move out of the square without colliding with the new block. This helps us avoid accidentally squishing peas.
Block peas moving into the square: New peas that try to move into the square are collided with using the collision rules associated with that block type.
You can place other blocks while a block is in the process of being built.
Deleting blocks You can remove blocks as well.
First click on the delete tool.
Your cursor will turn into the red delete cursor. Feel the power!
Click on the block you wish to delete. As you mouse over the block
The block will become ghosted. There is a short delay before the block is removed.
After the delay is over, the block finally fades away. During the exit animation, peas will pass through the block as if it isn't there.
You can delete other blocks while a block is in the process of being deleted.
Remember, you can't delete a block that has a flag attached.
Climbing: Peas can climb the sides of the block.
Walking: Peas move across the surface of the block at full speed.
Collision with top: Falling peas stop when they land on the top of the block. If the fall is greater than 2 blocks in height, the pea dies.
Collision with side: Falling peas bounce off the side
Climbing: Peas can't climb the sides of the block.
Walking: Peas move across the surface of the block at full speed.
Collision with top: Falling peas are launched upward with greater velocity if they fall on the top of the block. Angle of incidence equals angle of reflection.
Collision with side: Falling peas bounce off the side
Climbing: Peas can't climb the sides of the block.
Walking: Peas move across the surface of gelatin at 1/2 speed.
Collision with top: Falling peas stop when they land on the top of the block. Gelatin provides a safe landing spot for high jumpers.
Collision with side: Falling peas bounce off the side
Climbing: Peas can climb the backside of the ramp.
Walking: Peas climb up or down the ramp at full speed.
Collision with top: Falling peas bounce off the sides of the ramp at an angle and lose a little velocity. If they hit the ramp from a height larger than 3 blocks, they die.
Collision with side: Falling peas bounce off the side
Winning In order to win a Play With Your Peas session, you need to complete certain goals on a level, much like Tony Hawk. The simplest is "Reach X number of points". Your final score is the time that it takes you to reach the goal. A new player might take 10 minutes to reach 10,000,000 points. An expert player, skilled in crazy combos, might take 2 minutes.
My hope is that casual players will have fun figuring out the system, setting up interesting combos. They'll generally ignore the clock. Eventually, they'll reach the goal and feel good about 'beating the game'. Their score is then compared against a number of other times in a high score list.
More driven players will feel a natural urge to compete by replaying the level for a better time. To facilitate this, we should have "Try Again" button on the high score screen.
Areas to prototype Even though this design has a relatively small number of moving parts, the emergent behavior should be complex. There are three distinct areas that well are worth prototyping. I've listed them in order of priority.
Pea falling physics: In order to do the pea falling correctly, you need a simple physics engine that deals with balls and planes.
Block and scoring balancing: Balancing the size, properties and scoring of each block is a classic balancing problem. This is an area that will likely take hours to get right.
Pea navigation: If you can get peas traversing a series of blocks in a smooth and believable fashion, you are halfway through the design. This involves some tricky path finding. If you want to stub this behavior out, spawn peas at a jumping flag and remove them once they are scored.
Some design notes One problem that is common to AI-driven systems is that most of the behaviors go on underneath the cover, away from the player's eyes. It is very easy to fall into the trap of creating an intricate AI that 'plays itself' but is completely incomprehensible to the player.
Instead of asking how you might make the most realistic AI system, I prefer to steal a page from Nintendo's playbook. Instead ask "What is the simplest system that drives forward the player experience?"
Peas climb. Peas fall. Peas get scored. All of these activities are very apparent to the user. Instead of complex internal logic, the design focuses on explicit external behaviors. Any internal logic such as the path finding system exists only to the minimum degree necessary to support the external behavior. We won't build SkyNet using these sort of AI techniques, but we can make more enjoyable games.
Conclusion If you create something inspired by this prototyping challenge, send it this way! I'll post it on the website for everyone to check out and comment on. Take shortcuts, mangle the design, find the fun.
Assets I've provide the graphics for PlayWithYourPeas in two versions. First, all the graphics have been saved out as PNGs. I also included the Expression Design source file so you can make modifications to the original vectors.
Updated 2-11-2008: I added in the Block-Place-Normal.png to the zip that was previously missing. I also fixed some of the file names.
Updated 2-14-2008: I renamed the Ramp tools so that they follow the same naming convention as the blocks. The pea shadow is now seperated out. The single pixel alignment errors on the tools and the normal block are now fixed.
A little casual game design of mine called Sprawl finally made it out into the big wide world. I started building the graphics and brainstorming on the concept after playing an elegant board game called Hey, That's My Fish at Project Horseshoe.
Pete, my old compatriot from Anark, was looking for a game design concept to turn into sample game for the Microsoft WPF/E samples they launched this Monday. He actually made it work with AI and everything. WPF/E (aka Silverlight) is a lovely little web platform that Microsoft announced last year. It is in the early stages, but I have high hopes. I've also been working with Harold on a sexy DirectX version, but since he is building his uber engine from scratch, it isn't quite yet ready to share.
The game is a simple turn-based strategy game involving the capture of resources and the containment of enemies. If the response is good enough (and the programmer willing), there are quite a few more features I'd like to add.
Whoever beats every level gets a cookie. It is very possible to win, just incredibly hard.
take care Danc.
PS: Most of the game graphics were created in another product I'm designing called Expression Design. I'll try to post the source files for the artwork at some point on the site. I don't tend to talk about work too much on my blog, but there is a trial available.
Edit: Noted that the player does in fact run nicely on both Firefox and Mac. Tis, true.
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
Here is a conversation I’ve had many times throughout my career.
“Dude, I just thought of the greatest game design” “Really, what is it?” “I can’t tell you that. You could steal it.”
Remarkably quickly, the conversation comes to an abrupt dead end. This happens with professional developers, indie developers and people who happen to have picked up a game controller at some point in their sofa-bound lives and dream of breaking into the game industry. It is a cultural reaction that is pervasive throughout the game industry. The belief driving this response is simple: Game designs are unique and special, like a patentable invention. If you talk about a game design publicly, greedy buggers will implement it before you and take all your glory.
To be blunt, this attitude is completely ludicrous. Your game design is simply a starting point A game starts out with 1% game design and end up 100% production and polish. During the production and polish stages of the title, the game design is likely to change dramatically. For example, there was once a genre busting game design by a famous designer that involved a magic hammer and was described as an epic fantasy action RPG. Something very interesting happened along the way to creating the title. First, they did what every good team does in the early stages. They prototyped the concept and evolved what worked. The grand initial design ended up turning into an intense FPS shooter. What was this fantasy RPG? It was a little title called Quake.
When a team gets a hold of a game design, they change it in ways unique to that team. Give 5 teams the same game design document and I guarantee that you will get 5 distinctly different games. A game design ends up being closer to a movie script than it is to a blue print. The director who executes your design has a major impact on the ultimate results.
Moral #1: The final game is not going to look anything like your initial game design because ultimately it is the game director who makes the most important decisions, not the person who writes the game design document.
Unique mechanics are almost never copied At this point, many people claim that their design possesses a unique ‘hook’ in terms of the game mechanic. Take for example the Sims. This game had a great game design with some very unique and innovative mechanics. Holy crap, if only “I could have thought of it first” I could have made millions. Wouldn’t you love to go back in time, create a copy of the Sims and sell it before the Sims brand was established?
Yet, shortly after the Sims was released, game developers had a very similar opportunity. And they did nothing for upwards of two years. The clone masters had the blueprint for one of the most successful games of all time sitting in front of them and they did nothing. Even worse, the original Sims design was repeatedly rejected internally at Maxis because it was too risky. Ever wonder why Will Wright happily shares information about Spore multiple years before its launch?
Moral #2: Most people like to copy successful ideas. Original ideas are far less likely to be cloned because they are seen as risky.
You can learn more by sharing than hording Occasionally I’ll get someone to bite at this point and tell me their game design. It generally goes something like this: “So it is a fantasy game with a guy name Count Blommar who has red sword! He kills a lot of people and then fights a giant boss in the shape of a marshmallow!”
Months later, when a game comes out staring a hero bearing a red sword, the would-be designer is crestfallen that someone managed to create their idea first. Heaven forbid they actually had the gumption or clout to begin implementing their half-assed design in the meantime.
Often it is much better to talk about your game publicly so that you can gain important critical feedback from other industry experts. By discussing your ideas, you’ll learn a bit about what works and what doesn’t work. Writers do it at writing workshops. Painters do it at art critiques. These forums are harsh, open and extremely helpful. Many popular auteurs credit their current success to the constructive criticism they received from other professionals.
Moral #3: Most people are absolutely horrible game designers. Your game design could probably be dramatically improved by talking to other skilled designers. You have dramatically more to gain by sharing than by hording.
Two copy cats doesn’t mean anyone is stealing We operate in a cut throat industry. I’ve seen plenty of examples of similar games released at similar times and their sales suffer as a result. Two historical RTS games are released within a month of one another. Two FPS, both with triple-barreled shotguns are released nearly simultaneously. There are accusations of spying and the marketing people are lambasted for releasing screenshots too early.
Half the time, both games are merely copying from the generation that came before. If you mass enough game developers together and ask them to limit their imaginations to a narrow range of innovation, you are bound to have the same idea pop up multiple times. Suppose a publisher yells in a crowded room, “Quick, think of a color between red and blue.” How can you curse the fellow next to you who also thought of purple? This is convergent innovation, not theft.
More often than not, the ‘stolen’ idea ends up having a minor effect on the final sales of the game. One game typically has better execution and decimates the other. Perhaps if the failing company had been less focused on secrecy and more focused on building a great title, they would have done better.
Moral #4: If your design ideas are similar to another title, there is a good chance you are both cribbing from the same cheat sheet. Relax. Your super clone isn’t going to win or lose based off the game design anyway. Brand, polish and production values are more important.
How about a little sharing? Game designs are not patents or blue prints. They are an initial artistic sketch that is used as fodder during a very involved production process to create a final game. A great game is not derivable from the design document and an original game design is not likely to be copied. In fact, I would go so far as to say that it is impossible to steal a game design. The best you can do is create an interpretation.
When you refuse to share your game design, you are basing your decision off of indefensible paranoia. That is okay. You grew up in a culture where everyone claimed that game designs were holy. It can be hard to change. It can be hard to share.
If you do share your game design, I offer you this prediction:
No one will steal your game design.
By sharing your game design with other competant designers, you will receive in return invaluable feedback that improve your final game.
You will contribute to the game development community and help others learn about game design.
You’ll find sharing game designs really isn’t such a big deal. Getting someone to listen, that is the hard part. :-) Hopefully websites like this one will be useful in promoting a reasonable discussion once you’ve made the plunge.
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.