Screenplay to Game Design Fundamentals

Screenplay to Game Design Fundamentals
By: William H. Anderson

I was one of those people who had been following the hype and building excitement behind James Cameron's movie the Avatar for a very long time! So of course I was naturally excited when I heard about the game in development based on the movie, while at the same time apprehensive about getting it. Mainly due to the long-standing history of movie tie-in games being a bomb!

So naturally when the game came out just prior to the release of the movie I felt compelled, foolishly so, to rush out and buy the game and give it a spin before the release of the movie. I heard like many others that James Cameron's group had been actively involved in helping provide material for the game's development along the way and it was going to give me a glimpse, hopefully into what was coming in the movie.

But like a lot of people found out, Avatar the videogame just like many games that had been anchored to a movie license in the past failed to deliver!

Now personally, I been responsible for working on game design projects that were based on movie scripts and ongoing movie productions in the past. So I really know a lot about the restraints and pressures that game developers are under when having to put one of these products out. That being said, I also know that game publishers often succumb to the pressures of following the coattails of the movie hype to sell their gaming product, and not focusing on the overall quality to carry it. This is a trend that I've seen for decades now and in the videogame development field, and it's not a trend that is likely to change anytime soon. Unless, the movie studios and/or their directors put their foot down and decide that quality video games based on their property is more important than meeting a fixed movie released.

So until this trend changes, which is unlikely for some time, how as a game designer and moreover a game developer approach taking a movie screenplay and break it down into a videogame design that is successful, while working around these tight restraints?

First and foremost it comes down to educating the movie studio and/or director you're working with on the principles behind a Passive Audience Experience and an Interactive Audience Experience. I know these terminologies may be foreign to some of my readers, but they are principles that I've taught to many game designers throughout the years.

A Passive Audience Experience is what I often like to refer to is taking a person on a motion base ride, whereby they are strapped into a seat and taken through an experience by movie studios and its directors. While an Interactive Audience Experience requires game developers and it's designers to not only take a person through that ride, but also encourage them at key moments to participate in this direction and its outcome. This is where the biggest differences lie in working between the game development field and Hollywood. It is also an area where some of the biggest conflicts can occur in a working relationship between Hollywood studios and/or its directors and game development studios who are responsible for creating a gaming product based on their properties.

So first and foremost a game developer must ask themselves, after meeting with a movie studio's representatives, movie's director or the person who will be the game studios principal contact during development of this product and/or the screenplay writer or author, can they work with this contact person on interactive product based on this property, or not?

The question of not is the biggest of all for a lot of game studios, for the draw of the money and working on a Hollywood tie-in product is very attractive for a lot of game developers, but it can also become a major nightmare in so many different ways. Costing a game studio more money than they can make from the product, a huge hit to the morale of their employees who are responsible for developing this product, which in itself can lead to more costly ramifications for a game developer when talented employees decide to leave at the end of such productions. Not to say the reputational harm it often does to a game developer, when they produce such a flop, for the gaming public and the gaming press will rarely ever hear of all the politics that went on behind the scenes back-and-forth between a game developer and a Hollywood studio in just getting the game out the door. The only thing they really care about is that after paying a fairly decent sum of money for what is supposed to be the hottest next generation video game they had a rewarding experience or not! If not, then it is highly unlikely that that buyer will buy another Hollywood tie-in movie product from that game developer again, and it is highly likely that it will cast doubt in that buyer's mind about any other future products coming from this game studio in the near future. This is a fate no game studio wants to face!

Okay, so let's say the answer is yes! You've met with all the representatives who will be involved from the movie side of the product and you feel comfortable that they understand your position and you understand there's in what needs be done to take the screenplay and hopefully some assets from the movie and turn it into a successful selling videogame. Where do you go from here?

Product Identification

Product identification comes into play when we sit down and talk with the movie studio and look at the strengths and weaknesses of the game developer that is responsible for turning this property into a successful selling videogame. It is important to identify the basic characteristics of the screenplay and identify what style of game or genre this screenplay would fit into, and then, importantly, pick the one genre of game style that fits best with the production capabilities of your game development studio. This is an area that can trip-up a lot of developers these days, for they don't always play to their strengths, or worse, believe that they can quickly hire enough new people to fill that void. While this may work with the gaming property that is of their own creation, it is less likely to work with a Hollywood production mainly due to the time restraints that often come with them. When these type of properties come in the door, a game studio needs to be able to hit the ground running, and not gamble on their ability to bring in the talent needed to meet a style and genre of game that they're not accustomed to doing. It's better just to tailor the product towards the strength that your game studio already has. That's not to say you may not have to staff-up in certain areas to improve your productivity in certain areas of your strengths, but try not to move too far out of your own comfort zone in developing this product, for it could come back to bite you!

Screenplay Breakdown

Now that you've gone through the process of Product Identification, and you're fairly comfortable with the type of product or genre for this gaming product and everyone has signed off on it, then comes the time for the Screenplay Breakdown. This is called the pie-in-the-sky phase of game development, where ideas fly wildly. It can also be one of the most enjoyable times to brainstorming in what is going to make this gaming product totally unique. It also gives you the time to outline and define what you are going to call your killer-apps for this product.

Just for a point of reference, for those of you who are not that familiar with videogame design and development. The killer-apps of the game design are those few features that really define some of the most enjoyable and fun features of the videogame product.

While there many game play features that will define your overall gaming product and experience, it's the killer-apps that the magazines and game players in general will be focused on the most in deciding if playing this game was worthwhile for them or not!

Now how do we define killer-apps in relationships to a movie screenplay? This is where close consultation with the movie studios representative on this project can really become extremely valuable. You need to talk with them and find out from their movie production standpoint, what elements in the screenplay are they going to devote the most money and time to in the movie. This can often give you a good starting point for defining your killer-apps. Taking a step back and looking at Avatar the screenplay, which has a whole smorgasbord of different elements that could make for great game play, the only trick is in deciding which ones to focus on the most, to best satisfy the game's target audience for this genre of product.

In this effort you should define a limited number, based on your production capabilities and timeline for release, elements of game play that you will devote a good amount of resources on developing and refining to a high level of polish for this product. In the sake of Avatar, because combat via human weapons, native weapons and air combat was an integral part of the screenplay, along with elements of character building, these would have to have been the areas of greatest focus during the game's development. But also one of the problems that can occur, which did happen with Avatar the videogame, was the split focus between the human race and those of the natives. This is not a good position to find yourself in, from a game design standpoint, for your going to have to split your game play narrative down two different paths, while at the same time doing it successfully. Just so the player feel satisfied that no matter which path he or she takes, the human path or the native path, that each feel very satisfying. This was demonstrated much better in the latest Aliens VS Predator videogame, where the game developer had this problem times three! The design of that product had to take the player down the human route, the alien route and the predator route and yet have them feel satisfying and still have them tie into one global storyline. While it is true, that any time you have to split the narrative of the videogame down more than one paths like this, it's going to be a shorter storyline for each, but in the end not any more so than that of the movie having to do the same thing. But a good rule of thumb, is just to focus more so on those storylines that lend themselves to the strongest elements of game play, while at the same time not deviating too much from the structure of the story behind it. There's no magic formula for this, for each screenplay is different, so it's just going to fall on your best judgment!

Resource Assessment

As we talked about under Product Identification, playing to your strengths as a game developer is key to a successful production, no matter if it's based on a Hollywood screenplay or a totally original game concept of your own creation. It's important to stop, take a breath, and evaluate the resources you currently have at hand, the hiring climate of the industry at the time and your internal human resources, tools and game engine technologies.

Just like a general preparing for war, walks the troops, evaluates his equipment, checks his supplies and determines the best way and fastest way to move his troops and equipment to the areas needed, so the producers and game designers of a product need to do the same.

Understanding your studio's capabilities on all of these fronts will help you better define how to approach putting your final game design together behind this movies screenplay. Doing it any differently would be like planning a trip across country without knowing the state of the car you'll be driving, how much gas is in the tank or even a roadmap of where you intend to go!

There is one book that should be in every game developer's library and mandatory reading for any videogame producer or designer, that is the Art of War by Sun Tzu.

Once you've had a proper and thorough evaluation of your company's resources that will be devoted to the development of this project, and the timeline necessary to meet, you can then sit down to plan out your game design based on the screenplay.

Now, you should know, as most of us who have had to work on these type of projects in the past have learned the hard way, these screenplays are not set in stone! They often change throughout the whole movie production cycle, and if you're lucky not too much so to throw your game production off track. But these type of delays should be totally buffered in to any schedule that is produced for this project. Any game development schedule that has been based totally and completely on just the screenplay, as is, without the assumption that things will change, at least 25%+ throughout the course of the movies production is going to run into trouble! Just like with the videogame production, there a lot of creative people involved in the creation of the movie, and along the way things will change, I've never known and not to! So there needs to be some clear understanding between the movie production company that your studio is working with and buffered into your schedule a contingency for these changes. A game studio needs to have fixed in their contract a certain number of delays that are acceptable and those that are not during the course of the development of one of these type of products. This can be one of the darker shadows of doing a screenplay game, and can often lead to the cancellation of a game production if those delays in the game's development, caused by the screenplay rewrites, jeopardize the videogame coming out at the release date of the movie.

It's not uncommon for a publisher to drop a videogame in production if they feel it is not going to meet the street date for the motion picture. This is often due to the game publishers not wanting to pick up the extra advertising cost that would be incurred if this game does not follow on the press coattails of the release of the movie.

Approaching a Screenplay Game Design

Okay, now that we've covered the basics and you've had the opportunity to do a breakdown of the screenplay, and evaluate what your development capabilities are, we can now dive into breaking the screenplay down into your production game design.

Now assuming that the screenplay is based primarily on an action movie, or at least mostly so, for it's unlikely that you would be doing a videogame based on a movie drama or some type of romantic comedy, we can dive into the elements that make it up.

You should have a list of killer-apps that you have defined from your earlier evaluation of the screenplay and now comes the time to fill in all of the other basic elements that will define your product and how it will play.

One of the nicest things about working with a movie screenplay, as it's adapted to a videogame design, is that you are ready have a structure. Now you just need to go through that screenplay in a more micro sense and start taking out elements that will fill in the rest of the game. This can be anything from the type of characters that are outlined in the screenplay, to their weaponry, to the types of environments that they may be found in. In general there is a lot of information contained in the screenplay that you can gain inspiration from when constructing your final game design document. But one of the most important places to start is with the story flow, for it's key and adapting a movie screenplay into a videogame product.

Now in adapting a screenplay story to a game design story there may be a lot of back and forth between your game development studio, its designers and writers for the motion picture. Most screenplays will have to be abbreviated, sometimes greatly so, to get them to integrate well into a videogame product. This is a step that can't be glossed over at the start of development for will establish the structure for your product, and it's an area of great interest to the movie company. In the end it's their story and they have to be comfortable with the abbreviated interpretation that the videogame will contain.

Because the movie screenplay is taking a person on a ride through a story, there will be many areas contained throughout that are there as linking one story sequence into another, and really are not suitable to force game play into. These are the areas right at the start that you will need to identify, determine if they can be removed, and if they are an integral part of telling the story, can they be done through a cinematic, background dialogue or in some other way to keep the original story intact.

One of the things that I like to do when I get a new screenplay and it needs to be adapted to a videogame, is grab me a red, yellow, and green highlighter and go through the screenplay page by page. I then quickly go through it and highlight and green the areas of the screenplay that lend themselves to the best part of making a great videogame. Those areas of the screenplay that cannot be adapted, for any number of reasons, would be highlighted in red, while those that are questionable and might or might not be able to be used are highlighted in yellow.

Once this is done, you will have to sit down with the screenplay that you just edited with your highlighters and do a quick flowchart of the story elements that you would like to keep in your upcoming game play design, to show how they all link together. This is an important step for you will still have to keep the structure of the original screenplay story together, while at the same time abbreviating it down to something that can be used for your videogame production. This will become the skeleton for which you add the skin of game play around when you finalize your game play design for this product.

At this point you want to get the movie studio's people involved, to evaluate your abbreviation of the screenplay and its adaptation to this upcoming videogame product. It is important for them to understand that, while you have to make these edits to adapt their storyline to this product, you are still following in the spirit of the original screenplay. This will also give them the opportunity to evaluate your changes and talk to the screenplay writers to find out if there's any objections to the edits that you have made. Nine times out of ten they will come back with some suggestions or changes of their own that they feel would make a more proper abbreviation of their storyline, for most of the time they will want to have some back-and-forth over the final direction of the in game story. Just make sure not to get too bogged down in this process, which can often happen, and while I advise game developers to work out these details before even going into production. It is also a good initial step in evaluating a working relationship between a movie studio and a game development studio, just to see if a good creative partnership is going to work out or not, before too much time or money is invested in this development.

Once the movie studio's representatives have signed off on the new story adaptation for this videogame product, you are free to start moving forward with adding your game play around it in the final game design. The actual screenplay that has been provided by the movie studio should outlined a number of sub-elements that your designers can adapt into game play elements, and the list of killer-apps that you have already defined. All of this should fill in the rest of your product design. Just make sure to pace out your game play elements, including your killer apps, in such a way that the player never finds themselves in the position of searching for fun, or what we like to call these type of products, a Find the Fun Game!


Now there is much more I can say about working with a movie screenplay, in adapting it into a videogame product, but this article is just meant to touch on the basics of approaching these type of productions. If you found this article useful and would like me to expand on it further in future blogs than please feel free to email me with your feedback and comments!

Thanks!

Copyright 2010 by William Anderson all rights reserved!

The Making of a Monster

by William Anderson

In one of my last articles we talked about the Making of a Hero, now it's time to turn the table and address The Making of a Monster or Villain.

Have you ever seen a hit movie with a really great and dynamic hero character paired with really weak looking and acting bad guys? Probably not. For a great Hero vs Bad Guy system to work well, you must have a balance between good, evil, and their abilities. In this article, I will take you through some of the design processes involved in creating such characters.

As we go through what makes or breaks the design for bad guys, we'll also sort through the laundry list of classic bad guy classifications. Note: depending on the type of product you are working on, the name classifications may differ. For example, in games like Quake or Unreal you have bad guy characters called Bots while in Action-Adventure you might have Bad Guys, Monsters, Boss, and Sub-Boss characters.

For purposes of this article, I will focus primarily on Action-Adventure characters, mainly because they are more widely known and, in some ways, are more universal to game play design.

Basic Character Classes

NPC - Non-Player Characters
These are any characters that are not controlled in anyway by the player. You see these terms used a lot within RPG game design. They are generic enough to use in just about any type of product design, although you might want to use one of these other descriptions just to make things a little clearer to your readers and team. The design for such characters is identical to Bad Guys and Monsters, below.

Bad Guys and Monsters
These come in 2 different basic categories: Global and Venue or World-Specific. Global characters are what I like to call "filler" characters that can be used to help tie a common theme through a game. This becomes more important in Adventure games where it might be harder to string the game story along with just background art. Remember, that because these characters are global the look, combat and abilities must feel natural in all worlds or they will feel out of place.

Venue or World-Specific characters are dedicated to one specific level or world of the game. The game play design for these characters can vary greatly depending on the type of level or world they are placed in, and their placement in the game.

How do you pace the combat and difficulty for such characters? Simply ramp their abilities based on what the player should know how to do at that point in the game and what weapons and defense he or she has. If you follow this rule it should naturally pace itself out.

Boss/ Sub-Boss Characters
Boss character are usually found at the very end of a game play section, level or world and are used primarily for setting up a milestone event that the play must overcome before continuing on to the next level of the game.

There are many ways to approach the game play design for these types of characters. Here I list some of the most common ones used:

Character Centered Design
These type of characters rely totally on the abilities of the character itself. No outside dangers come into play. Although limited because it is just focused on the character, character centered design can have a wide range of combat abilities limited only by the creative nature of the Boss character and the imagination of the designer. Note that these characters tends to be more common in game designs today mainly because the choreograph is much simpler and, sometimes, the coding time less.

Character and Environment Centered Design
Character and Environment Boss characters are found when the Boss character works in tandem with background or level dangers. This is what I see emerging as the Next Generation Boss design for these newer game systems. With the ever increasing complexity of game systems, and their ability to handle more things moving on the screen we are seeing more designers turning to mixing Boss Character Combat with choreographed background dangers for greater variety of combat systems.

Although this style of Boss character may cost more in development time, it's a great way to balance a weaker, but needed, Boss character in a game. For example, let's say you have a Spy game with a really physically weak Boss character that's needed because it fits a licensed story line. The downside from your standpoint as the designer is that you might need a strong combat situation at this point in the game. How do you resolve this situation? Simply ramp up the level dangers around that Boss character, while making sure the player can't defeat him until you feel that your pacing objectives have been reached.

Environment Centered Design
Environment Bosses are comprised of just background dangers. While the characters do not directly attack the player's characters, the player may or may not attack the Boss character directly to complete this stage of the game.

These type of Boss situations are rare in game design, not because they are not fun, rather, it's just human nature to directly confront what attacks you regardless of whether it is attacking directly or indirectly.

Some key things to focus on while designing Boss Characters…

Ramp the difficulty of Bosses through the game
Ramping Bosses through a game can be done in a number of different ways depending on the product. The key is that these characters should be paced throughout the game based on what experience the player should have at that point in playing. Don't ASS-U-ME that the player has played some other game like yours before and, therefore, will know what you're thinking. You are not just a game designer, you're a game play teacher. Don't be afraid of that.

The second way to pace out Boss characters through a game is to ramp the number of different attacks and moves the boss character can do at each stage of the game. For example, level or world 1 Boss might have only 1 attack, while 2 might have 2 attacks and the 3 Boss might have 3 different attacks.

Show Damage
One of the biggest mistakes still being made in game design today is not showing any sign of damage being inflicted on the Boss Character when attacked by the player. Nothing drives players crazier than to attack and attack and not see any visual sign of damage. There are a number of mechanisms that can help you tell the player the state of the Boss: screen damage gauge; change in the Boss character's art or animations; changes in combat system; Boss sound effect changes; and, finally, the music. Personally, I like a combination of animations to show each successful hit, as well as changing the combat system at different points during the fight just to keep the player thinking.

Watch your Playtime
Make sure that you don't over do it with how long a player is locked into combat with a Boss character. Make sure that it fits within the context of your concept. For example, if it is an RPG, you can spend some more time in combat than you can with an Action Adventure. Tthe player expects to progress quicker then a long prolonged fight; although there are some exception to this rule if the Boss combat changes in unique ways through out the battle.

Sub-Boss Characters
Sub-Boss characters are really just watered down Boss characters that make guest appearances somewhere in the level or world, but not at a point where the player would expect a final Boss combat to take place. The combat system for these characters can be anything you like, but less than what the player would expect from a full Boss character.

One good use of a Sub-Boss character is to make a guest appearance of the Boss to help train the player in some of the attacks or abilities the player will have to deal with in the final battle.

Key things to Avoid in Boss Design
One of the wrong approaches used today in Boss character design is when the designer focuses on making the Boss combat system totally different from anything the player has been All of us can accept failing if we have been given the prior opportunity to learn.

The Payoff

With regard to creating good bad guys for your product, a good rule to keep in mind at all times is "the Payoff to the player must be worth the player's effort to defeat it!"

This can be done in so many ways, such as dramatic death, vast treasure or power-up gain, destruction or creation of something within the combat area. But it must be clearly tied to death of the Boss, and it must be immediate as any delayed rewards will lessen the payoff to the player. Players are on an emotional ride with your game and you want to keep them there!

Clearly, I could expand on many more points covered in this article based on different types of games but these are the most basic concepts. If you would like me to expand on some of these ideas, contact GIGnews or email me directly. Thanks and good hunting!

Copyright 2010 by William Anderson all rights reserved!

The Making of a Hero

By William Anderson

Ever wonder what makes a great hero character for a video game? If so, then sit back for a wild ride into the creative design process behind The Making of a Hero.

Game heroes come in all shapes and sizes. From a medieval knight to a pistol-packing debutante to an earthworm with a robotic suit they all have one thing in common: they are our video game heroes.

Good or bad, short or ugly, the hero design for your product must be right on target if you want to establish a following for your character. A following for a successful game character can pay off in very profitable ways, and not just in the interactive entertainment field.

This is not a task to be taken lightly. If it were easy to establish such a hero every one would be doing it, but there are some basic steps you can take to guide you down the right road.

To start, you should know that there are a number of primary approaches to the development of an interactive entertainment product that guide you in the creation of your hero. These are Character Centered Design and World Centered Design, both are valid approaches to product depending on the target concept.

Here is a simple explanation of each:

Character Centered Design. This is where the designer of the product focuses everything in the game around the lead player character of the game or a combination of characters like those found in 2D/3D platform games and role-playing games.

Character Feature Designs. Found in 3D shooter games, these products use the environment primarily for navigation and protection. Finding the next great weapon or power-up for your character is the main goal. You will rarely find a player becoming personally attached to the Player Characters in these

games as they have a bad habit of getting blown up all the time.

World Centered Design. When the uniqueness of the game play environment is more important than the lead character. Most of these games are primarily puzzle-based concept where you navigate a basic character with simple movements around an ever increasing complex series of levels.

Although some game designers have attempted to mix some of these different approaches, it often leads to disaster. Not because their ideas or games aren't any good, but because there are established markets for games that have been around for many years. This creates a following of game players who expect a certain style of product with established norms in how they work. If you break too far from the basic expectations, you lose your audience and, most likely, a sale.

Unfortunately, some designers who are just starting out in this field get extremely frustrated with marketing people because they have a great idea for a game but can't even get it to first base. This is often because marketing managers are like surfers, always riding the waves of the established norms in the market -- they know if they break from that wave in a totally new direction they could fall and fall hard. This, of course, is not to say you should not try to establish a new wave of your own, just try to take smaller steps which is generally more successful then jumping in with both feet into a totally unknown direction.

Remember that just like in any business, large successes come from building on smaller ones. For purposes of this article we will focus on Character Centered Design, primarily because it is the one most widely used in today's game concepts.

First, the whole idea behind Character Centered Design is that you and I as game players will be focusing most of the time during game play on and around the Player Character and his/her/its abilities and personality. Therefore, all of the gameplay, from level mechanics to monster designs, will focus around the unique design, abilities and non-abilities of your lead player character.

Your design layout for this character must be extremely tight in all areas. Like a keystone in a building, all of the weight above rests on its strengths. Keeping this always in mind, there are a number of key tasks to tackle when laying out the design for your hero character, the following is a list of key tasks in order of importance:

Looks. Looks are important in a number of ways. While not necessarily physically attractive, there should be a uniqueness of the character when placed next to all of the other lead player characters out there. As a good friend once told me, "You're going to be looking at this character for a very long time so it better be a great!"

A good example of this was when I bumped into a designer a few years back at a game show. He told me that when a certain well-known company was working on an upcoming 3D Action Adventure game for the PSX they had a meeting to discus what the lead character might look like. Someone stepped up with the comment, "I don't know about you but if I have to look at the back side of a character all the time it better be an beautiful lady!" By this one simple comment video game history was made and millions where made in the process.

And they were right on the money with the character design, if you just think about the concept they were working on: a two-fisted shooter game that would automatically fall right into the male 14+ category. But could they have failed with this approach? Yes, if the character design was weak or if some of the other items below were not balanced correctly. (As we have seen with many copycat product that tried and failed).

Movement Abilities. The movement and basic abilities of the hero character are two of the most critical features of any game product. The entire idea behind playing a video game is to give the player the ability to control a character in a unique world. The easier it is to use, the more satisfying the playing experience. I can't count how many games I've seen that had every thing going for them but the basic movement controls were just so bad that players just walked away, without looking back.

This aspect is sometimes hard for a lead designer or product manager to deal with -- if the programming

or animation staff just don't have the knack for putting smooth movements into their work you are in trouble. Not to be underestimated, this is a very special skill for both programmers and the artists to pull off

seamlessly and in such a way to avoid bogging down the game with unneeded code delays or animation frames.

Action Abilities. The action abilities are all of the special things the hero character can do in the game. From combat, climbing a rope, to pulling a lever on a wall these must follow the same rules as the Movement Abilities, while also adding depth to the global gameplay.

By depth, I mean adding a basic toolbox of things the hero can do throughout the game and adding to them as needed, while also pacing these gained abilities throughout the product to give the player time to adapt and learn. This will ultimately add a lot of uniqueness to your concept and make the player want more.

With this you should also keep in mind that players -- especially action game players -- get bored very

quickly if things aren't changing fast enough. This is why pacing out rewards such as added action abilities, power-ups, treasures and secrets throughout the game are vital to keeping players involved with the play.

Don't Over Simplify. Designers and Project Managers are under a great deal of pressure these days to make every feature in the game so simple that everyone on the production team and in marketing can play it easily. Just say no! Game players are not created equally and neither is gameplay. Remember the old expression "If you design a product to please everyone, you've made a product that pleases no one!"

There should be a learning curve to gained abilities, while keep the basic movements and abilities down to established norms in design. In this way a player can dive into the game quickly but must advance his or her knowledge to move to higher levels and greater depths of play. This will automatically build Satisfaction into your product and that will bring them back for more!

Weaknesses. Weaknesses are simply what can and can't hurt or restrain the play during the game. This must be consistent with the norms in design for this concept and consistent with your concept.

There are 2 basic norms you will need to follow when designing your product:

1: The established gameplay norms of the similar successful games.

2: The norms you will establish and train the player in for your game.

As you may know, while designing a game, you will have to layout a number of rules for your hero and the product that, once established you should never break. If you do, the player will not be able to establish for himself the dos and don'ts in your product and that will lead to frustration.

Also, never establish a rule in one level or world and break it in another. I know this is just common sense, but I've seen a number of designers play this Joker Card and it has lead to their game CD becoming a coaster for a soda can.

Enhancements. Player character enhancements and rewards are totally expected in every game concept. From gaining a new weapon, finding treasures and armor, to items that give the player the ability to gain access to other locked off areas of the game like keys, these items build life or what I like to call Draw into a product.

Why is Draw important? With some type of draw mechanism you as a designer will have an extremely hard time enticing the player into taking chances, and this is what gameplay is all about. Think of it this way, the two most basic human emotions that we as designers must work with and master in product development are simply Pleasure and Pain. And in this there are also rules.

The first of which are the expected rules that were established by all the successful games that have come before yours, and the others are very simple:

1: The interface and controls should not interfere with game play.

2: I will not be punished arbitrarily.

3: I will be rewarded in an equal way for learning and overcoming obstacles.

4: There should be an intuitive or logical solution to any challenge or situation.

5: Basic instinctual human dangers should be valid! For example fire and sharp object will always be avoided by natural human instinct unless there is a clear understanding why not.

There are other branches of rules that you will discover as you go but these are the most basic five. Remember that we all want pleasure and will do anything to avoid pain, and by balancing these out in a fair way we create a challenging world to which we escape.

If you follow the right steps it's not hard to make a unique and compelling Hero for your game, but it's critical that you take your time and work out as many details as possible before designing your world around him, her or it.

If you need more help defining the Hero for your concept then I would grab some paper, sit down with a number of good games and simply document all that you can about how they work. List the number of different moves, command controls, and as many of the thing above we talked about.

Remember that your continued design education, outside of GIGNEWS, is on the screen of every game you play, including the bad ones. All you have to do is reduce what you see down to all of the key elements and think about why the designer might have done things that way.

Copyright 2010 by William Anderson all rights reserved!

How to Get Your Design Ideas into Production

By William Anderson

Have you ever asked yourself, "How do I get one of my idea or concepts into development?" In answer to that question, the following are some of the things I've learned over the years.

Before you start any new concept or design project, you should first analyze your current situation, as well as the needs or wants of your target publisher or developer. Without a clear understanding of these variables you are doomed to fail!

So lets get started…

Reviewing your Current Situation

Before you start, ask your self, "What do I need to pull together to create this concept and design?" If you can do it all by yourself -- great, but more often than not you will need the help of some friends or colleagues. Generally speaking, people who can fill the gaps in your skills who are also on board with your leadership and vision.

Next, identify what style of products you would like to create, as there is really no point in pitching a game concept you have no heart for.

Make a list of the types of games you would really enjoy creating a concept or design for. Hopefully, you will have more than one, as the more you have, the greater chance you will have to find something in that group you really want to do.

Also, do some research to see what might be coming out in the next year. If the market is destined to be saturated with shooting games or golf games then Publishers are most likely not looking for those types of concepts or designs anytime soon! Even if you think you might have the killer idea that will push your game to the top, it will still be a hard sell to the publisher.

Lastly identify all of the possible publishers and or developers that are doing the types of games on your list. This may take some research time, but the clearer you are on this, the easier it will be to make important contacts down the road. I've never met a publisher or developer yet who was not flattered by someone really knowing about them and their work.

Now with this done, it's time to really get into the thick of it…

Initial Review of the Publishers Needs or Wants…

Before you sit down to draft your concept, it is best to identify your target publishers' or developers' needs or wants -- this is critical to your chances for success. By simply matching up what you can provide with what the publishers or developers are currently looking (or have a history of publishing) will make your job much easier down the road.

Next, you should always understand that there are two types of publishers and developers out there, the "Needs" type and the "Wants" type. Each approaches from a different direction when it comes to selecting a project for development and each must be approached in their own way.

The Needs Publisher or Developer

This is by far the best type of publisher or developer to work with as they are usually more savvy about market trends and money making opportunities. The are also, however, the hardest nut to crack with a totally radical new game concept idea.

These companies have established a rhythm for selling products, and are extremely fearful of breaking out of that direction when it comes to selling or pitching an idea out of their comfort zone. My advice with this type of company is to write a short description of your game idea with some simple drawings of game play and then pitch it in an informal way, just to test the waters. If you find the waters warm, then more than likely this company has reached a level of success that allows them to take more risks, or they are dying and desperately looking for a life raft.

Obviously, try to avoid the desperate and dying companies. If they die in the middle of your project they could easily tie your concept and company up in years of legal and copyright headaches. But if the company appears stable, then work at evolving your concept while keeping them in the information loop. This will help you to avoid costly time delays due to reworking the concept back in their direction.

And, don't get so married to your concept that you become inflexible to a publisher or developer's ideas or suggestions. You will be surprised how far a little compromising will take you!

Now for the Wants Publisher or Developer

The Wants type of company is normally looking for a killer concept that will set the tone for their company. Be it Sega® looking for their Sonic™, Namco® looking for Pac-Man™ or Capcom® looking for their next Mega-Man™ concept, they all want something that stands out, and are willing to put some major bucks behind it!

To establish a mascot character and product for a publish or developer is the Holy Grail of game design and should never be taken lightly by any designer.

Because this type of company may be risking a lot of money and company reputation to establish such a property, they may become more than a little nervous on occasion. If this proves the case, there are a number of key things you need to keep in mind when dealing with such a of company:

1: Never showoff any idea, concept or design that is only half complete, this will only serve to freak them out. Remember that during this early stage most companies in this position consider themselves on the Titanic, and at the first sign of a leak they will head for the first life raft!

Concept art and storyboards should be clean and, if at all possible, in full color. All designs and level layouts should contain as many notes as possible, including arrows showing player direction.

Lastly, and possibly one of the hardest pills to swallow, if the main brain or visionary behind the concept is not very articulate with other people, then team him or her up with someone who is! I can't tell you how many great concepts and designs I've seen go down it total flames just because the designer or producer presenting the product could not communicate well with others. Even if you have to hire someone just for this task alone it is money well spent!

2: Put as much concept art as possible out there to ensure your publisher and team that you are on the right track and really putting great thought behind what you're doing.

I'm a very big believer in having lots of conceptual art behind a product. It serves a vital roll in video game products. For one thing, it keeps the entire team's eye on the end goal of the product. The more concrete the vision, the harder it will be for distractions to throw things off. It also gives great confidence to your publisher and the press that you are in total control of your concept and leaving nothing to chance. And in the field of video game production, keeping your publisher confident can make your life really wonderful!

Remember the Golden Rule of Design: "Keep your Team Confident and Focused on the Goal, and Keep your Publisher and or Developer Confident in your Leadership of that Team"

If you lose on either of these maxims, you will have a hard time producing a great game.

3: Always keep every aspect of your concept and design communication tight with your team, publisher and/or developer. This is not meant to imply you should communicate everything to them -- that would be impossible and impractical. But make sure, as much as possible, that the information passed on is correct and is not lacking anything they might need to know to perform their jobs.

4: Don't be a "yes man" (or woman) when working with others! Some people believe that you have to totally be agreeable with your team, publisher or developer, or that you must have have a quick sure answer to a question to get things done.

Well the fact is you are just kidding yourself!

If something is coming down that you really believe will negatively effect your team, product or schedule then speak up! And I'll pass on one of the best pieces of advice I ever got while working as a Product Manager and Designer for Namco: "Don't feel like you have to give an answer now!" Hold, wait, and think about it! Try to keep your self from making quick and off the cuff answers -- in the end it will save you a lot of grief.

5: And, lastly, keep all appointments, schedules and milestone dates with them. Always inflate your time projections with this type of company as any delays will only serve to diminish their trust in your team, production and/or company.

Diving Into the Documentation Stage

Before we dive into the last part of this article, I would like to explain the phases that lead into a full production, just so you have a clear idea of the process.

First, with the ever-increasing cost of producing a full-length video game product you would have to be completely mad to go into a large publisher asking for a full commitment of cash without, what we like to call P.O.C. or Proof of Concept.

P.O.C. is typically one stage of your game that contains enough to judge the following:

1: Global Features of Playability.

2: Any Killer or Signature Game Play Features of the Product.

3: Sample Textures and Art Style.

In short, enough to judge if the game is going to be any good!

So, based on this your Concept phase is funded by you or your company, not the developer or publisher and the POC stage would be funded. In this way, your developer or publisher does not have hanging over their head the full weight of the cost of a full length production without proof it is going to be great.

POC development can take from 3-12 months depending on the target system, experience and equipment of the studio, staffing needs and many other time related issues. And targeting your concept at a pre-existing engine you own or can buy can really speed things up and lower POC cost. In turn, making you more appealing to Developers or Publishers.

Wrap Up

There are a number of key documents that you or your company will need to produce in order to get things rolling and to keep things on track during production. Here is the one key to your Concept Proposal stage: The Concept Proposal document&183;

This document should contain the following information and anything else you believe is important to pitch your concept. Note that these items are some of the ones I've run across during my years of design, but your concept may require some other key descriptions. Just use your best judgment.

1: Title of your concept.

2: Mission Statement that covers target system, ESRB rating and other key target points.

3: Concept overview or summary of what you are proposing. (Keep it to 1-page if possible).

4: What makes this product stand out! (Please don't say graphics!)

5: What competitive products are out there like this or somewhat like this?

6: Concept art for your lead character, if any! (Color always gets a stronger reaction!)

7: Some conceptual drawings of your lead character in action. (Also color if possible!)

8: Flowchart of the scope of your concept, including Interface, worlds and levels.

9: Storyboards of some of the levels, worlds and some unique mechanics of the game.

10: What is your or your studio's readiness to go into the POC stage of development?

11: What will you need after the POC stage to move to final product mode?

12: POC Schedule and Final Production Schedule.

13: Staffing needs for POC stage and staffing needs for final product.

14: Equipment needs, outside of current equipment on-hand.

15: Who is to main contacts at your company for this concept proposal, such as CEO, Creative Director, Producer, Lead Designer, Lead Artist.

16: Final summary of what you need from this publisher or developer to take your concept into the POC stage.

Remember that you may be asked by them to add some more details to your concept proposal before final approval, so a little back and forth is to be expected. Also, try to remember that if failure comes, use it to your advantage. For example, if a publisher or developer turns your concept down then ask them a few follow-up questions, like:

1: Was there anything lacking from this concept in your opinion?

2: Do you have any suggestions on how to enhance our concept or presentation?

3: If we make all of the changes you are looking for would you be interested in another review?

Basically, just keep your eyes and ears open during the entire experience, and don't get too caught up in any one event, good or bad. You have a lot of work ahead of you and you will need to stay just as focused on the goal as your team.

Copyright 2010 by William Anderson all rights reserved!

The Fundamentals of Proof of Concept

By William Anderson/ President of Awaken Games

In my last article, How to Get Your Design Ideas into Production, I touched briefly on the subject of POC or Proof of Concept, as an important stage of getting your project accepted by a developer or publisher. Now, at the request of some of GIG readers, I will attempt to expand on this subject in much greater depth.

First, for those of you who my not be familiar with the term POC or Proof of Concept, it is simply an abbreviated version of your game, or product concept, designed to better sell your production or design to a company. In short, it is a condensed version of the game that a developer or publisher can put their hands on and really see what you are proposing.

Think of it this way, when you go in to buy a new home what is the salesperson going to highlight? The leaky pipes? The neighbor next door with the large barking dog and 1am jam session? No, they are going to show you all of the nice amenities that product has to offer.

This is exactly what your POC is designed to do for your game concept and/or proposed production -- sell it to a developer or publisher by highlighting the best game play features and art this concept or product has to offer!

But, before we dive into the subject of POC development fundamentals, I must dispel a myth: Your POC does not have to be a full-length level or game, it can be as simple as a few screens of game play.

Mainly, the best rule is to add as much as you believe is needed to show off the best qualities of your concept proposal. If you can stand back objectively and look at it and say, "I can really see the full direction of playability for this product based on the hands-on experience!" Then you are on the right track.

Remember that when your concept or proposal hits a developer or publisher's door, it will be judged on a number of key factors. It's best to try to keep these factors in mind as much as possible during your POC development process. Here are just some of the factors to keep in mind...

1: Acceptability…Does the developer or publisher accept outside concepts or proposals? Your early research into developers or publishers, prior to submission, should weed out this possible impasse situation.

2: Applicability… Is this the style of product they have marketed in the past or can market?

If this company has never taken on a product like yours in the past then you will more than likely have an uphill battle to get your concept accepted, unless you are a great salesperson.

From experience, the larger a publisher or developer becomes the harder it is to get them to open up to new or totally different concepts. They have established a rhythm for selling into set markets, and fear rules them changing from that path (especially if they don't have the money to risk).

I've seen mature sales people break-out into a cold sweet during meetings where CEOs start to propose taking on a project that takes them into unknown markets. It's best to play in their backyard when picking your concept proposal. Selling your concept to the sales and marketing staff can make or break your chances at acceptance. A good CEO will rarely go against his marketing staff unless he or she wants them to break out of their rut and branch off into new markets. (There are ways to make a "Don't Want" company a "Want", but that's another article).

3: Marketability… Are the market conditions right for such a concept, at the projected time of publishing?

This is truly key to understand when proposing a concept to a company. If there is a projection of a glut of 3D Shooters at the time of publication, then there is little likelihood that a publisher is going to be too hot about your 3D Shooter concept. Be very mindful about the upcoming markets. If a publisher is not totally aware about an upcoming glut of games like yours, then they may -- and more than likely will -- cancel your product during production once they see the wave coming. Or worse, perhaps, they can have you dancing your game design around fears of new features of upcoming games like yours. This can lead to long delays in production, loss of original focus of the design, and a totally frustrated team, who are also becoming unclear on what the final game is going to be.

4: Playability…Does this game play well enough to compete or dominate in the target market?

This is a very important factor. If your game concept does not offer anything new or unique, you might as well pack your bags and go home. And PLEASE don't say, "We've got better Art!" With the advances in art technologies, plenty of games have great or acceptable art, but play poorly. In short, a purity picture does not sell games anymore.

My own personal rule is that a typical game player will only be drawn in by nice art for about 30-45 seconds when they first see it, after that it's all game play. For your concept proposal to really stand out it will need some "Killer Apps", or features that set your product apart from all other concepts -- something that you can really focus on in your presentation pitch to a developer or publisher.

5: Graphics and Effects…Do the graphics proposed in this product fit the concept and are they of market quality?

Although game play in my book is always king, you need the balance it with a look that fits well with the concept and is competitive with other products coming out. This means that the quality of background art, textures, special effects, lighting, and shadow-maps must all compete with the art standard being set in today's games.

That's the basic questions that might come up, but only by truly understanding these types of questions will you be able to better position your concept or product for acceptance by a good developer or publisher.

And, as a side note, you might have noticed that Music and Sound effects are not included in the above list. This is because I've never seen a publisher expect this to be included in a POC product proposal. This is not to downplay its importance in the total balance of the product, it's just something that comes into play later during production.

Now for Proof of Concepts development fundamentals in greater depth…

By now you should have some idea of what a POC is, but if it's still not clear in your mind then, simply put, a POC, in most company minds, is "First Playable" for your concept. This would be, typically, one or more stages of play that really demonstrates the core of the game play and any killer features that set your product apart.

A production cycle for a Proof of Concept would typically looks something like this…

1: Sit down with your project staff and just get totally wacky! Let ideas flow from all directions with no rules about what will work or not from a technical or game play stand point. Campout for about a week and have some fun during this stage. Write down all the thoughts that flow from these talks. And don't be afraid to spend a little money on research material like magazines and games that are like the product you are trying to create, or that have elements that really inspire your thoughts.

2: Next, hand all of these notes over to your staff in charge of assembling this into the final design for the game. Don't worry yet about how clean this information is, just make sure it contains the heart of your product ideas.

3: Sit down with your team and talk about what ideas in this concept are the Killer-Applications for the game. This is what will make people go all tingly inside when they see it or play it.

4: Now, hand all of this research and brainstorming information over to your lead or senior designer to be compiled into a concept design document for final approval. This must be a person you trust with your vision for the game. Believe it or not, someone must be the final judge of what will make it in the final product and what will not. PLEASE don't set up a full development team committee for this process! A final review team of Producer, Designer, Lead Artist and Project Programmer is the most you will ever want in this process. These are the people you must ultimately give total trust to in making the POC and final product, and that trust must be seen and understood by all development staff members.

5: With final approved concept design in-hand, it's time to assemble your conceptual material, such as character designs and A.I. designs, game play level layouts and mechanics. Here is where a great conceptual art designer comes in really handy. If you have never worked with such a person, you are really missing out on a great experience. For clarity, a conceptual artist is not a production artist. He or she is an artist totally dedicated to providing you and your team with all of the visual inspiration needed to make their jobs easier,

6: Once all of this material has been reviewed and approved by your senior project staff, it's time to assemble your design documents, such as…

Design Document that outlines the total scope of the production in as much detail as possible. (There are some good articles here on GIG to review on the subject)

Art Requirements Document that list out all of the screens, character animations, effect items and interface items needed for the game.

7: Now, review all of the documents you have just prepared and refine it down until you and your senior staff are happy and committed to the final vision and scope of the proposed production.

8: Next, you need to have a meeting to review what within this design you really want to focus on for our POC stage or stages? Remember that you want whoever plays the POC to really get a great idea of what the final product is going to be. Once this meeting is done write down all of the best features, level elements and so on that will make up the heart of your POC.

9: Schedule out all of the tasks needed to finish and fine tune your POC product. Remember to always give yourself some buffer time to fix bugs and smooth over the rough edges.

Simple Guidelines…

> Must be simple to understand and play.

> Must look great.

> Must Not Crash.

> And if at all possible, must be on target platform.

10: Assemble a POC staffing and requirements document that outlines all of the people, equipment and resources you will need to finish your POC.

11: With your schedule and POC requirements documents in hand, it's time to prepare your cost projections for the POC stage of development. This is vitally important, as this is what you will be asking a developer or publisher for initial funding for. Again, build in some buffer funds for unknown cost that will pop up.

12: Now, assemble all of the information, designs, concept art, schedules, etc into a nice neat presentation package. This is your Concept Resume for success so make doubly sure you are happy with it before your take it on the road.

13: Lastly, take it on the road. At this point you will send it out or take it on the road to be reviewed by your target developers and or publishers. The only thing to remember during this stage is that you are only seeking funding for the POC stage of development, first. Then, after they are happy with the proof of your playability, then additional funding will be required for completion.

Don't expect a home run on your first trip to see a developer or publisher. I've worked with some large publishers who only wanted one thing out of their first encounter with a new developer -- to see who these people are and get to know them personally. Then, if they believe these people are smart, trustworthy and have the personal skills needed, a second meeting is called for. Sometimes they do not even tell the person about calling for a second meeting until days later. This is normally because they want the time to evaluate feedback from all of their own staff members who met with you or know of you or your studio.

Also -- very important -- don't get all twitchy if there are people invited along by the publisher that seem out of place. The publisher knows the skills and knowledge of their staff better than you do, and if others are asked into a meeting it's because someone trusts their feedback -- don't discount their importance. As a final note, you should understand that a POC proposal is best laid out in the same way as you would assemble your resume, with the most interesting, fun and dynamic aspects of your concept up front.

A common mistake I've seen in a POC product is where the player must dredge through endless areas of little to no interest just to find something great about the concept. Your POC product is NOT a good time or place to show off your game play pacing skills, as you slowly take the player up to something truly fun in your concept. Do what every it takes to get your audience into what game play makes your product great right away as people tend to pass judgment quickly, and if you've not drawn them in at the get-go you've lost your first impression advantage.

Copyright 2010 by William Anderson all rights reserved!

The Designer's Production Guide

By William Anderson

There are many "do and don't" rules in game design, and most successful designers abide by many, if not all, of the same ones. Although they may vary from designer to designer, depending on products and experience, for the most part, these "rules" fall along the same lines. In this article I will address the most important rules I have used when starting a new project for a company, as well as outline those questions you should ask as you head into a production.

Designing for the situation and your team!

This is a very simple rule but one frequently overlooked by Designers, Producers, and Managers. They get so caught up in the desire to realize their vision that they don't stop to ask the important questions: "Is this concept beyond my teams ability to make?" or "Do we, as a company, have the know-how to bring in the right staff and technology quickly enough to do the game on time and in a cost effective manner?" Failure to address these simple issues has needlessly killed many projects, teams, and companies.

Making a great game is easy, the truly tough part is managing creative people and their different creative personalities. This is made even more difficult today as an increasing number of game companies are, at their core, run by accountants and marketing people. These are professionals who are trained to be extremely organized and who avoid eccentricities (or about 85% of a game development team!) If you think Men are from Mars and Women are from Venus, then Game Developers must be from Pluto! Of course, this sort of organized leadership is not a bad thing as long as there are some simple and well understood rules laid down by the company and project managers who are skilled at heading off creative conflicts within a team, and who can interface with higher non-production managers.

The first rule, or what I like to call the First Law of Design, is to simply review what is possible before you make a commitment to a full production. This goes for Designers, Producers and Managers alike -- you only have one shot at this!

The following are basic questions I like to ask myself before starting a project. Please keep in mind that upper managers may be so in love with a concept that their optimism will veto your position. Unfortunately, that's the nature of the interactive entertainment field. Outside of reminding them that if the game never gets out then no one will enjoy their vision, there is not much you can do about it.

Questions to Ask:

Does a concept exist for this new project, such as from a license?

This is a very tricky situation. Anyone who has ever worked with a Licensor will tell you that licenses often come with a legion of legal people, agents, and producers who know little to nothing about the interactive entertainment field, but who will not hold back on their demands for changes. There is a comment very often used by Hollywood agents when addressing game companies and it goes something like this:

"Now we will show you how real entertainment is done!"

Maybe it's just me, but I've not seen a movie with a game controller attached, or one that let the audience wander into every corner of the set. There is a big difference between non-interactive and interactive, and as long as your company is willing to stand their ground you should do fine.

Here are some of the basic questions to ask when dealing with a licensed concept:

1. Is the Licensor offering enough flexibility to actually make a game?

For example, many years ago I was approached by the president of a game company who was talking to a advertiser about doing a game based on one of their character commercials. It was an extremely well known character and I was very excited about the game prospects, until I went through the proposed contract. In short, they did not want the character to do anything that was not in the TV commercial and that was about 3 basic movements. Not exactly what players would expect. After seeing that the advertiser was not flexible on this issue, the company dropped the proposal.

Even If there is enough flexibility, make sure you have all the dos and don'ts in the contract to avoid any misunderstandings during production.

2. How much oversight will the Licensor have on the project?

If they do give your company flexibility, just make sure they don't bog you down in a long corporate review process for each milestone. Some companies are large, and getting information through to the right people for sign-off could take days.

3. Who will be your review and sign-off contacts with the Licensor?

You must have clear and direct contact with the key people responsible from the Licensor side. This is most critical during the concept design phase and during final production. However, avoid involving them in staffing issues and small studio or resource problems, it will only undermine their confidence in your production.

4. What is the understanding for the target age group?

This is critical to clarify before the design phase can begin. The licensing company must have a clear understanding of the target market and the level of return in that market. And don't be shy about educating the Licensor on what the state of that market might be at the time of product release. If you're making a racing product and 5+ other racing games will be coming out at that time, then you might want to hold on the concept until the market cools down.

I know plenty of developers might say that if they want a racing game then make a racing game! But, in the long run, this will only hurt your studio and more than likely end your business partnership with that Licensor.

Note: If you are a Producer or Project Manager you would add questions about joint properties, royalties and other legal issues not focused on for this article.

What if there is no preexisting concept?

As a designer, this is a much simpler situation to deal with, but it comes with its own set of important questions. Companies that make products without a license and a known character are much more skeptical about "sell-ability." In most cases, the designer of the proposal must work doubly hard to make clear his or her vision and enthusiasm for the product.

Some of the questions you might ask in this situation:

1. What are the studio's procedures for presenting concepts?

Each company you work with may have totally different procedures for presenting ideas for consideration. One company I worked for wanted 3 concepts based on their own characters, and 3 totally original concepts before any new project proposal meeting could be scheduled. On the other hand, other companies may have a rough idea in their mind that they want you to flesh out into a full design.

Before you start to brainstorm, it's good to spend some time getting to know the likes and dislikes some of the managers might have about different styles of games. It might also help to understand their concerns about marketing different types of games. This is also a good way for you to show respect for the job they have to do, and it helps you design a product they will feel more comfortable selling.

Also use this time to find out if there is a concept floating around that the company managers are considering that would make them more comfortable. By taking this on as your project, you could avoid a lot of political headaches down the road and show the company what you can do. Then, when the next project comes, they will be more open to trusting your concept proposal directions.

2. What is the timeline for producing, pitching the concept, and starting production?

Knowing a company's schedule idea up front is critical to your design efforts. It will help you effectively communicate back to them what is possible. For example, if the company wants 5 concept proposals done in 30 days, then you need to ask them what level of depth they require for concept approval. If it's significant, then you might need more design and conceptual resources to accomplish the task.

3. Will the game be published in different markets, such as Japan or the UK?

This is where a designer must do his or her homework. There are many different styles of game concepts and just because one sells well in the States does not guarantee sales overseas.

4. What are your current resources for producing a new concept?

If the company is looking for a really professional presentation then you will probably need help, from conceptual artists to assistant designers. Personally, I like to have a conceptual artist help with all concept proposals just because, quite simply, a picture is truly worth a thousand words. Marketing managers don't have the time to go though a long technical breakdown of how the game is going to play and look. Show them a picture.

What is the target platform?

Game systems are not alike and you must know what you're getting into. For example, when developers recently jumped onto the Sony Playstation 2 bandwagon, they made the wrong assumption that they could get up and running just as fast as they did on the Playstation. Wrong! Game systems have become extremely complicated pieces of hardware and the PS2 is no exception. Unless you work out the capabilities of your target platform, you are just producing a wish concept.

Here are some key things to find out:

1. Has the company worked on this platform before?

If a publisher or developer has never worked on a system before there can be plenty of hidden problems like delays in getting contracts done and getting needed equipment, software, and support.

One of the biggest pitfalls I've seen in this field is when a company makes assumptions about producing a game on an unknown system. The main one being that if a game could be done in 12 months on one system, then it should take the same amount of time on the next. Sure, that would be the case if all game systems used the same operating system, but that's just not reality. The truth is that in a rush to get a new system to market, the manufacturer takes many shortcuts in design and documentation on the system, and developers pay the learning curve price. This is why 2nd and 3rd generation games on a system tend to be better. At that point developers know much more about the hardware and all its tricks.

2. What type of development equipment do they currently have?

If the company has development equipment then you need to find out if it is owned or on loan from some other source, and what agreements there might be for that loan. You will also need to find out if the development equipment is up to date on the most current software library and documentation.

If the company does not have any equipment then you will need to know if the company has agreements to obtain systems, or if that's your responsibility.

Sometimes a company like Sega or Nintendo may request an overview of your project before granting your company a license to develop. During this process be extremely cautious when disclosing too much information about your upcoming project. Now that these companies also develop software themselves it puts them in the strange situation of evaluating a concept that might be better than one of their own. In the past, I have asked that any producers or designers who are currently working on games for the system manufacturer not be allowed to attend these meetings, and I leave the technical details out of the conversation.

3. What is the availability of programmers for this system if required?

This is extremely critical for you to know before starting any new project. High end programmers are paid top dollar by the big developers, creating a shortage for smaller developers.

If the surplus of programmers is really low and the price range is really high then you might want to target your product at a less costly platform. After your company has built up a better financial base, then go for the higher platforms. This is where I see many start up companies fail. They just don't understand the vast cost of trying to target a cutting edge system.

Do you have a Project Staff in place?

Once you get past these other questions, then it's time to evaluate the other staff required for the project. Just because there is a current staff in place does not mean that they can do the job. For example, when I was asked to start a new project for a small game development studio they told me they had a full staff of artists and programmers in place. What they did not know is that most of the artists did not liked to work on video games, and that some of the programmers did not fit the minimum professional requirement for the position. It showed in their work and dedication to the company.

This is why it is extremely important that you review the backgrounds of your staff before you propose a production to a company. If the staffing is not right, your schedule will not hold, and money will be lost.

Here are just some of the things you should know about:

1. What are their backgrounds and strengths in development?

2. Do their skills fit what is needed for the upcoming project? If their skills are not up to par, can they be quickly brought up to the project's required level? If not, then can you bring in staff quickly enough to fill the project needs?

3. If staffing is required does your company have the capability to bring in the right staff? Some companies are so new that they just can't move that quickly and if a tight schedule is a concern then you might want to propose a smaller initial project.

What is the technology base of the studio?

If you're extremely lucky then you will land in a company with game engines and tools already in place. Unfortunately, that is not always the case.

Things to evaluate:

1. Is the game concept being targeted to a pre-existing engine?

2. Is the engine solid or does it need upgrading and, if so, to what extent?

3. Is the engine code well documented or remarked?

4. Was the publisher happy with the performance of the engine?

5. Are the programmers of the engine still with the company?

6. Are tools in place for working with the engine?

After you answer these questions you will have a good understanding of what can be done technically for your concept design.

Do you have any tools for this project?

The right production tools can save a company almost immeasurable time and money. So it might surprise you to find out that most game companies shy away from investing in such tools. It's been the mindset for many years that if it's not going in the game then why spend money on it? Well, the wakeup call is that the most successful projects that have ever come out of this field owe their existence to these types of tools. Not only did they make productions faster, but they took away much of the team stress during production.

If you are lucky enough to find a company or studio that understands this point, then the next step is to have a clear understanding of what you are trying to make before buying or creating your tools.

Please keep in mind the word "flexibility" in designing and making tools. Any tool that can be used for only one type of game is a poor investment for the company or studio.

What are the current art tools?

This can get very tricky for a designer or manager to evaluate as it changes from studio to studio. Some may use SGI where others use PCs and so on. You will have to weed through all of this to decide if the current art tools will fit the needs of your project.

Here are some basic questions:

1. If the game is 3D or 2D do you have the equipment and training needed?

2. Is your art staff up to speed for the task at hand or is more training required?

3. Do you have enough artists and equipment to do the concept?

If you can not staff up or get more equipment to meet the needs of the design concept, then think about scaling back on the idea to fit your available resources. Don't think that you can just push your staff extra hard to get what you need. A good economy plus low unemployment rates equal an empty studio and a dead project to show for it. In short, it is best to work with what you have and that what this article is all about.

Clearly there are plenty of other questions that will pop up as you work through this article, but these should give you some idea of how to ask the right questions as you move into a production. Asking these questions breaks you out of the rush and enthusiasm of the vision long enough to find out if you are heading for a crash, and how to head off potential pitfalls.

After asking the right questions, you will have a better chance of designing a game that matches the situation and your team while removing much of the risk of creating a monster concept that would, ultimately, eat your company, money, and team.

Finally, before jumping into production, a project designer, manager, or producer must look out for a studio's ability to enforce professional boundaries. This is extremely critical. If production staff members start to assume overlapping job responsibilities it will destroy the morale of your team and rob you of the ability to really judge individual contributions and performance. Unfortunately, this is a problem that runs rampant in the gaming industry, so don't be surprised when it pops up. To head it off, and to avoid any confusion, it's best to make changes in project duties official and clear to all staff members. Game productions can be stressful enough without adding an unclear management system.

Copyright 2010 by William Anderson all rights reserved!