Lost Along The Way: Design Pitfalls on the Road from Concept to Completion

Author: by Rob Irving

The game industry has grown up in recent years -- right alongside many of us who have grown up with it. Once upon a time, the leaders in our field were people who worked in garages for next to nothing and made games because they wanted to build something that entertained them. We were the market, and phrases like "publicly traded" had very little meaning to games, except perhaps when referring to baseball cards. (Even huge cultural phenomena like Pokemon and Magic: The Gathering were unheard of ten years ago.)

This young industry has given birth to a new breed of career professionals -- pioneers who have spent the entirety of their working lives making videogames (or, more broadly, electronic entertainment products). The electronic entertainment industry has risen to compete directly with movies for the public's leisure dollars. Large and highly successful corporations spend and earn billions of dollars each year to make it in the gaming world, and every success comes down to the people who create the games.

The bottom line: making games is a job, and a very serious one. The games that you and I are building today aren't merely games any more: they're products. The distinction between the two words is more than mere semantics: it's a matter of responsibility.

Starting Down the Road

We've all had our ideas for the next great game. That is, after all, why we're working in this industry. At one time, simply taking a great idea for a game and figuring out a way to make it happen was enough. Back then, audiences were far smaller. Selling a million copies of a game wasn't important, and the only people that game builders had to answer to were the people who shared the task of creating the game. The corporate environment in which we now work is no longer quite so flexible. Each product must answer to a number of sectors in order to achieve the financial success that is the goal of any company.

As designers, it is our responsibility to shepherd a game's vision from initial conceptualization to finished product and to maintain that vision's integrity. The overall concept and all of its components must all fit within the constraints of the marketplace, and designers are the first line of defense against straying from the path that is laid out for a product. Designers must be aware at all times of the many responsibilities that a product has -to the company, to the marketplace, and to the player.

The first role of the designer in this process is to build, maintain, and communicate the game's design document. Every game design should have two major documents. The core design document is set out at the beginning and provides the framework for the entire development process. While it is not, by necessity, absolute law, the game design document should clearly communicate all of the essentials of a project's development. Anyone should be able to look at this text and understand what the product is, who it is aimed at, when it will appear, and how it will satisfy all of the responsibilities that the team have as game developers.

The second document is a living document -- the design bible -- and is responsible not only for breaking down the overall design into systems and subsystems, but also for documenting the process that the team goes through while actually creating the game. (This is a subject worthy of some analysis, but I won't go into it in this article.)

The creation of the core design document is the point in product development where the majority of the design responsibilities must be addressed, and it will pay in the long run to consider what might get lost without proper design.

Losing the Audience: Building the Wrong Game

As a concept evolves into the initial design document at the very beginning of the design process, the first step in creating a product out of an idea is to identify an audience for the game that you will build. While it is sometimes tempting to create your own dream game, almost invariably you are not the audience that you're designing for - or at least not the only audience. Like it or not, the pure "gamer" that many of us have always been is just a fraction of the market now. Building a game just for gamers, or even worse, just for ourselves, isn't going to work for our companies or for our paychecks.

In the initial stages of the game's development, you will lay out the basics: the product's genre, setting, mood, and subject matter, but you will also define the target platform, age group, rating, and perhaps even gender. The second set of factors can be as important as the first when you are making the initial design decisions for your game.

The game's target platform will make many decisions for you, and will be the most important to the programmers on the team as they determine how they will develop the engine and tools. When evaluating platforms, you must look at both the experience of your team and the set of tools, art, and library code that may already be available. Starting from scratch on a new platform will certainly extend timelines significantly, and that increases the burden of anticipating the game's audience and its competition. The closer your project's ship date is to its initial design, the better prepared you will be to assess and capture its market. It's also important to remember that timelines will be stretched more for a new platform than for an existing one: the tools that you will be using to build and test a game and the libraries that the engineers use to interact with the system may themselves be undergoing revision while you work for newly-released (or unreleased) platforms. Multiple-platform development presents a number of difficulties, as well. All of these make your target market less clear, and that means that your design itself will be less focused.

Not only does the target platform significantly affect the limitations of your game design and the timelines for its development, but it also has a significant impact on the type of game that you should consider making and the age group and the rating that you aim for with the product. Nintendo's audience, for instance, is typically younger than Sony's. New platforms will be adopted first by an older age group than will eventually constitute their overall market segment. If you think that these trends aren't important, you can look at the disappointing results for games like Conker's Bad Fur Day (Nintendo looking for an older market on the N64) and Portal Runner (3DO releasing a title aimed at younger audiences on the PS2 - a platform that still didn't have many young players) despite a number of good reviews for both games.

Where platforms are concerned, it's also not a bad idea to look at interface. Console players expect simplicity in their interfaces, while PC players are more accepting of more advanced controls. This is one of the reasons that keyboards never seem to establish a foothold as peripherals for console systems.

Jane's AH-64D Longbow, a PC flight simulator that I worked on several years ago, had enough controls to fill an entire keyboard. Did that damage the game? Not at all. The game's design took into account the platform and target market, knowing that PC flight simulator fans expect accuracy and aren't afraid of a lot of controls. While Longbow made an excellent PC game, taking such a complicated game directly to the console market wouldn't have worked out as well. That's not to say that a different version couldn't have succeeded (and there was talk of this), but the sheer complexity of a game like a flight simulator creates difficult design choices when approaching consoles and their controls.

This is exactly the problem that was faced by the teams who ported Wing Commander to consoles: too many controls for simple control systems. To address this, two different approaches were taken by the development teams for the 3DO version of the game and the Playstation version. Wing 3 3DO went for simplicity, cutting features and systems to the bare minimums necessary to play the game and still get essentially the same experience. The team knew that we had a very limited number of buttons to work with, and we decided that we could sacrifice some of the PC's extras (such as power configuration, takeoffs and landings), to keep the controls as simple as possible. As far as 3DO products went, Wing 3 was well received, and garnered some excellent reviews. The Playstation team took a different approach, attempting to stay as close to an exact replica of the PC game as they could build. This approach meant a lot more controls. Granted, they had a few more buttons to work with, but they had to exercise a lot of creativity to push all of that functionality into one little controller. The results pretty much matched the effort: people felt that their game was more true to the original product, but it was considered much more difficult to play. If you are attempting to appeal to the larger audiences that products demand in today's market, you're not going to find nearly enough Wing Commander players to sell to, and that many controls may be intimidating to a large portion of the audience.

Flight simulators and Wing Commander games bring up another important point: niche markets. If you are designing a game for a niche market - strategy games or military flight sims, for instance - then you are already reducing the size of your potential market. The initial question that you must answer as a designer, then, is how you can push your product away from the fringes of the market and back towards the center. The simpler the concept and the broader its appeal, the more you can stretch the market and the game's success.

Your choice of platform obviously plays a big role in your initial design. As I've mentioned, it can also affect the target ESRB rating for your game, and these ratings have become a big consideration for big business - including for Sony and Nintendo when they are evaluating your submissions. While you may be able to slide a bit in either direction as you develop the game, establishing the product's target rating will define your audience much more clearly. While an 'E' (suitable for every age) rating may mean that your product is truly intended for every age, it still may mark your product as a "kids' game" for some consumers. (The notable exceptions to this are sports games, which don't generally contain any objectionable content and can readily earn an 'E' on the box.) On the other hand, you'll have a much harder time selling a game to younger players when there's a 'T' (teen audiences) or an 'M' (mature audiences) on the box. The rating on your box will also affect who will carry your game, as some stores won't carry games for mature audiences, and that's exactly the wrong direction to go when you're talking about expanding your audience. Setting your rating goals early can prevent some serious headaches later. Game features with long development times, such as FMV, are going to be awfully hard to replace if you suddenly decide to change your rating at the end of the development process, so err on the side of caution when designing features that may impact ratings. Of course, your game concept will most likely limit your possible ratings in the first place. (It would be difficult to make a good horror game with an 'E' rating, for instance, and making a game with popular cartoon characters doesn't seem sensible with any of the higher ratings in mind.) Whatever your goal, it's never best to limit your product or market too much with the initial ratings decision. Aim for the middle, and you'll have a lot more options for a bigger audience.

Expanding the audience can take another direction, as well: selling to more markets, rather than to a broader U.S. market. International sales can introduce further demands on your design. Germany - a big market that is still growing - has some stringent guidelines on blood and violence. Asian markets will mean that your game must support non-standard character sets for localized text. If you're going to distribute in multiple countries, pay attention to the expectations of those markets when you're laying the groundwork.

The design of a game and its features should be evaluated against the guidelines of your audience before anything else. Since design is responsible for these decisions much of the time, you should be aware of your audience throughout the development process.

Losing the Franchise: Failing the Fans

Some games have to consider a special kind of audience in their design. Games that extend existing franchises and licensed products both attempt to capture a market that already has some expectations for the product. Because of those preconceived ideas, these types of games will undergo much more scrutiny at both ends of the development cycle. When creating a game design for an existing franchise, you as a designer will have a lot more people to answer to with your design.

The first responsibility to a franchise or licensed product is knowing your product. This means research. If you're working from a novel or series of novels, then you should read them. Pay attention to characters and settings, take some notes, and share your findings with the rest of the team. The more you know about the world that you're building a new representation for, the more your game will be able to reach the target audience. The same goes for movies, television shows, and even other, non-computer games.

For an existing line of games, you should be familiar with the new product's predecessors - especially the most recent ones. Know which ones were most successful and which failed, and look at the reasons why they failed. If those reasons were in the design, rather than in execution, then they are within your power to fix. If you know your franchise or license well, then you will be better able to present a design that fits its audience, and that means getting the green light to move forward with development.

Once you move forward, you face the second responsibility of designing for an existing universe: being responsive to the people in charge of the franchise. When dealing with an established world, you're going to have to know who is responsible for that world, how much involvement they'll want in your initial design, and how often they'll want to look at what you have. Establish these answers early on, and make sure that you keep the right people apprised of any significant changes that come along during the development cycle. The people providing this additional layer of oversight for your product could pull the plug after a lot of time and expense. Don't bet your future on your ability to read their minds.

In some cases, you'll find that it's not how well you stay within an existing universe, but how well you expand it. When designing a game based upon an existing franchise, be aware that you will sometimes need to jump ship, and find out how much leeway you have to do that. While you will probably have to answer to your company, to your publisher, or to the owners of a franchise (or to all of these), you should be able to present a design that stretches the boundaries of a product line where necessary. If you flood the market with look-alike titles from a franchise, the audience may not be loyal enough to keep paying your bills. Keep your pride in check when evaluating this: the most important consideration is not reviews, but sales. You may hear a few of the loudest voices grumbling about your persistence with a line, but if the products continue to succeed, then you must be doing something right. It's good to note here that steady sales over a long period mean only that you are maintaining your audience, even though you're actually losing your percentage of the total market as it continues to grow. If your costs continue to grow over this same period, then your franchise is a losing proposition.

Losing the Market: Hits that Miss

You'll notice that the words "audience" and "market" appear almost interchangeably in the first sections of this article. While they're not exactly the same, it's fair to assume that building a larger audience is equivalent to establishing a larger market. Grabbing your share of the market and continuing to add to it are as important to the business of games as establishing an audience is to their design.

While it's true that finding and capturing the market is primarily the realm of sales and marketing people, it's not only their job. The most important step in for these groups in reaching the market is reaching the people who will be selling the product. Whether they're selling on a web site or to Wal-mart, they'll need to generate some excitement in advance to pave the way for your product. To do this, they're going to need to turn to you. You must be prepared to show off the game you're making so your potential audience knows that it's out there. Developers often grumble that demos and screen capture utilities and the like disrupt timelines and destroy their schedules, this only happens if they haven't planned for them in advance. When you are designing your product, remember that you're going to need to show it off. Pay attention to sections of the game that will showcase everything you have to offer, and be prepared to offer them up as spokesmodels for the product when the time comes. Keep your maps and original work around in case they're needed to enhance a document or ad. If you're asked for a list of bullet points, take it seriously. Just because everyone does it, that doesn't mean it's less important. You're trying to get the product noticed, so take the chance to brag about your design when the opportunity arises.

Of course, there's one other important part of satisfying the market. Everyone says it; you've been told a million times. Hit your schedule. Be responsible to your team when estimating times for tasks, and then be responsible to yourself when completing them. It's so obvious that it shouldn't be in this article, but it's one of the most difficult things that we do in our industry. And when you get there, make sure that you've allowed yourself enough time to give the audience a clean product. While you may be able to sneak a less-than-perfect product out into the marketplace, it might make the audience think twice the next time around.

Losing the Sale: Negative First Impressions

We've looked at the big picture: the audience and the marketplace. But all of that comes down to a whole bunch of individuals - both retailers and actual players - who will purchase your product. Many buyers will make their decisions based on just a short experience with the game - whether playing a demo, renting the product, seeing it at a friend's house, or reading a review (which is often based on a very short play session, as well). Some won't even get that far. The designer's biggest job in creating a viable design is to decide how the game will connect with the people out there, convincing them to buy this product instead of someone else's.

The quickest way to lose a buyer's interest is through the game's look and feel. Particularly in times of transition from one generation of console to the next, the games that look the best will be the most obvious choices for purchasers. If a buyer has a powerful machine at his or her disposal, then he'll want a product that takes advantage of the machine's capabilities so he can show it off. When the only information that a buyer has to go on is a few screen shots on a box or a short demo in the store, it will be fairly obvious what games look great and which ones are duds. The more products that are out there competing for that purchase, the more readily a product with substandard visuals and effects will be discarded for a flashier choice.

The PC market and aging consoles are less likely to be influenced solely by visuals. The PC is less influenced by graphics because there's no universal set of specs for PC's, and the very high-end machine constitutes a small portion of the marketplace at any given time. In fact, pushing the graphical capabilities of a machine may lose more customers than it will gain in a mass market. Even the most awe-inspiring visuals are going to look pretty weak if a player has to turn everything off just to run the game. In this case, the box has more than just pictures to help a user make his decision: it also has machine specifications that can make or break the purchase.

In the case of aging consoles, the buyer is going to be far less concerned with getting the best looking product for home consumption. The so-called "early adopters" have already leapt ahead to a new console (or are looking forward to it, at the very least), and the remainder of the install base is going to be much pickier about how the game plays than how it looks. I'll talk about this more in the last section.

With the issue of visuals still in mind, there are two primary ways to make a shopper into a buyer. The first, of course, is to make a game that pushes the limit with graphics and effects. This may be through splashy special effects, ultra-realistic characters, beautiful scenery, or any combination of these. While this decision is not solely the province of design, it is essential that your design documentation clearly communicate the team's goals for a product's visuals. Many of your decisions later on in development -- from the engine itself to the tools that you will use to create the game to the actual content of the game -- will come back to the artistic direction that the team has decided to take. A game that strives for beauty through complex character models will be more limited in the number of characters that are displayed at any given time (Onimusha), while a game that attempts to capture more action will necessarily have to find different ways of making the characters look realistic without pushing as many polygons -- or even adopt a different style entirely for the art that won't require realistic characters at all (Grim Fandango).

Certain limitations on a project -- platform, engine requirements, tools, and timeline being excellent examples -- will require that a team de-emphasize visuals. Still, the game's design can capture that point-of-purchase sale. The alternative to having the best looking game is to have a "hook" that draws the player in before the comparisons even start. This needs to be a concept that the newcomer can grasp in a few moments of perusing your title. Of course, franchises and licenses have built-in hooks: people gravitate to a familiar character or universe (Star Wars, Pokemon, Spider Man), a familiar personality (John Madden), or even a concept that is common ground outside of the gaming world (World War II, Army Men, or sports games in general). To a lesser degree, this can come from long-running lines in the game market itself. Basically, if the buyer knows you before he meets you, so to speak, then you've got a head start on the competition.

Even with such a head start, you'll have competition, and you may not have these tools at your disposal at all. When laying out your design, make sure that you can explain it quickly and concisely to someone who knows nothing about it at all. If you can't focus your idea down to a few lines of text in your design document, then you're going to have a hard time reaching the people that you want to buy it.

Losing the Player: Obstacles to Enjoying the Title

So now, hopefully, you've caught the eye of the potential purchaser. (Of course, you knew something about that buyer all along, because he's part of an audience that you identified long ago.) That's a step in the right direction, but the look and the hook aren't going to bring everyone into your market, and they aren't going to keep people loyal once they're playing. Most of the buyers out there (retailers and their customers) will look a lot more carefully once they've picked up the box, and many of these will try before buying. These players are going to be concerned not only with the look of the game, but also with the feel of the game. If a game's design loses the player, then it's likely to come right back to the store - or never to leave the shelves in the first place.

Losing the player happens first and foremost through the game's interface. Whatever the title, the purpose of an entertainment product in any industry is to transport the participant to a place either slightly or entirely outside of his realm of experience and to keep him there engagingly throughout the experience. Without a functional set of tools, the player is prevented from ever achieving that suspension of disbelief or - even worse, in my opinion - continually reminded of his interaction with the product, rather than immersed in the game itself.

The problem of interface is usually a matter of too many controls (making a game very difficult to get into) or an interface that is too intrusive (making a game very easy to leave). This is not to say that a game can't have lots of controls. As I mentioned before, Longbow, had functions for almost every key on the keyboard. Not only did the game's design take into account the target market, but it also helped the individual player to learn the game with a clear tutorial, plenty of practice missions, and clear documentation. When they could learn to enjoy the game at the right pace, players could appreciate the realism of the simulation. Mastering the controls just like a pilot became a reward to players, rather than an obstacle.

The faster a player can start up a game and get into the action, the more likely it is that he will want to keep playing it. Diablo is an excellent example of controls that appealed to a wider market. Anyone who was familiar with Windows at the time of the game's release could readily understand the game controls. The point and click interface was intuitive and accessible, and Diablo reached a huge market because of this. Myst is another good example: not only did it satisfy the visual requirements that I spoke of earlier, but it was incredibly easy to play, and anyone - with or without any history of playing games - could quickly start the game and launch into the story. Whether or not it appeals to you as a gamer, its sales certainly speak volumes as to what you can do right as a game designer. Even better for their developers, both of these games translated readily to console play, because there weren't a lot of controls to work with in the first place. (Of course, there are a number of different philosophies on creating an adequate substitute for the mouse on a console.)

In preparing your design, make sure that you address control. Fit your platform, aim for ease of use, and realize that not everyone who will play your product is as familiar with gamesas you are. In the later stages of development, make sure that you have succeeded in allowing players to play the game that you've created. Most importantly, be thorough in teaching the player what you expect. The more controls you're using, the more preparation the player will need, and the more time he will need to learn each different aspect of those controls. Provide tutorials - hopefully within the actual structure of the game - and clear documentation. (While there may have been a time when nobody read the manual, a wider marketplace and a wider variety of players demand that there be a ready reference for those who are just getting started.)

If your design has given the player a chance to really get started, then the next pitfall to avoid is discouraging him with an intrusive interface. There is nothing more distracting than having to press four or five buttons when one would have been sufficient. Recent games have provided both good and bad examples of this. Devil May Cry (for the Playstation 2) doesn't let its interface get in the way of its action. How much would the game have suffered if you had to push extra buttons to draw your guns or reload them? Fortunately, we don't have to know. Silent Hill 2, while being a fun and very disturbing game, has a problem with too many button presses at times. When you walk up to a door and press the action button once to notice a note on the door, again to read the note, again to end the text, yet again to open the door, and still again to actually enter the room, you've worked too hard. Similarly, some of the manipulation puzzles would have benefited greatly from a few interface shortcuts. Metal Gear Solid (the original) is one of the best games ever made. Its major flaw? The fact that you had to button through every single line of a conversation. If you actually made the mistake of dying and restarting that section of the game (for those of us who actually played with restarts), you had to do it all again. And some of those conversations were long. Resident Evil: Code Veronica forces you to enter the inventory screen, select an item, turn it the right direction, and then look closer (another button press) to solve critical puzzles. This could have been simplified to a single action, and the game wouldn't have suffered at all, except for maybe being a few minutes shorter. I've brought Myst up before, and it's relevant here, too, as the Myst designers took interface reduction even one step further: they gave you the zap option to jump from one scene to any visible one that you had already visited. This shortened some oft-repeated trips by a bunch of unnecessary clicks and kept the user focused on the game. [A side note: the 3DO version didn't have this feature. Combined with the agonizingly long load times from the CD ROM, this was a compounded error.]

While I'm on the subject of pressing buttons, menus in general are another aspect of the game with the potential for too much interface. Do you have too many screens that aren't part of the actual game? How long does it take to find a particular item and use it, and will you lose the suspense or energy of the title while the player is out of the action? If a limited inventory is crucial to gameplay, make that fact clear and make it as simple as possible to manipulate that inventory. (Could somebody show me the "drop item" button in Code Veronica?) Stacking is helpful. So is automatic combination of items and reloading of weapons. Of course, there must be balance between the realism you want for your title and the simplicity of playing it, but erring on the side of fewer button presses will never hurt you. Whatever you do, make sure that the player can quit the game if he wants to. A non-intrusive interface is one thing, but frustrating the player when he's already trying to quit is just begging him not to come back.

Particularly with console titles, loading time is as much a danger as control complexity. While developers understand that the game takes time to get all of its data in order, players are generally distracted and frustrated when they are required to sit for long periods of time with nothing happening. Hopefully, you can minimize your loading times by swapping data during the game itself. If this isn't possible, and especially if your loading times are long, then at least give the player something to look at while the game engine is getting ready for the next portion. Attractive visuals and some sort of indicator - a bar, or clock, or anything that actually moves - at least reduce the pain of waiting. The player who gets up to make lunch during the loading screen may never sit back down.

The major lesson here: don't let your interface get in the way of the game experience. Streamlined, simple controls leave people talking about the game, and not about the difficulties they had playing it. A good designer must have the ability to judge what features should be removed from the design and which should make it into the final product in order to make that product accessible to its audience. Trim the excess. Combine pieces that don't work individually into a single, harmonious whole. A key or button press is fairly automatic, but a sequence of them draws attention to the machine, and away from the product, so pay close attention to how many steps outside of the game are required to move it along.

Word of mouth is a very powerful force. How likely would you be to pick up a game that a friend told you they didn't understand or couldn't get into? This includes the friendly guy at the computer store, who has played a lot of games and may make or break your product in a 30-second chat with a prospective customer, and the reviewer, who may not talk to all of your audience but is certainly reaching some of it.

To keep the player from walking away, you have to do more than just let him play the game with as little distraction as possible. Once you've opened the door to this alternate world, what's on the other side of the door should be interesting and give the player something that he can relate to. You certainly don't want your door to lead to a blank wall, and you don't want the player to run screaming from the room after a short amount of playing time. Extending the player's visit to your world means creating an interesting concept, delivering it well, providing ample and immediate rewards, and ramping up your level of difficulty at the proper pace.

Concept isn't really something that can be defined in an article of this nature. Almost anything can make a fun game, and there are many concepts that have yet to be tested. Coming up with something new is the easy part. Delivering it to the player is the hard part. Designers have traditionally been responsible for story delivery and the flow of the game. Most importantly, the idea has to have enough interest for the player to pick up the game, and then it has to make enough sense for him to stay with it. (And it doesn't take long to put down a box in the store when you read the back and think, "Now why would I want to do that?") If there are too many gaps in the plot, or too many steps that are unclear or just plain unacceptable to the audience, then the player will again be lost. Nobody wants to get lost or stuck, and if the solution to a major puzzle is too obscure, requires too many events to occur in an exact fashion, or requires skills that the player has never learned, then the only thing that your user will spend time learning about your game is how to uninstall it. As I mentioned before, word of mouth is a powerful force, and word of a game that just doesn't make sense will surely get around.

If you have made sure that the game has piqued the player's interest, and you haven't stymied him with the interface, then the next thing that you need to do is to reward him for his time. Whatever the reward - a cut scene, a new item, a new area to explore, character advancement, or merely the first victory in a string of conflicts - the game should provide the player with some simple reward in about the first half hour of play. That first play session and the first impressions from that play session will decide whether or not there will be a second one. In that initial time period, the player should understand enough about your game to feel comfortable with it, and your reward is encouragement to move forward.

As the player continues the game, challenges and rewards should become greater and more meaningful, with the final reward being winning the game (or finishing the game, or mastering all of its levels, or whatever is appropriate to the title that you're building). Remember that making a game too easy is just as dangerous as making it too difficult. Achievement only has real value if there is risk attached, and a game that offers no danger and no increasing challenges will quickly become boring. When it is possible, your game should offer multiple levels of difficulty, as this provides a more level playing field for different skill levels (again, the wider audience) at the same time that it offers the player an increased challenge when he can master the easier levels. With each successive challenge, you can ask the player for more time and more skill, and the resulting satisfaction should increase with your game's progression. Overall, you are building to a climax that asks the player to know everything that you can teach him in the game, and the end result of that climax will be the overall victory that is the highest reward.

Once you think that you have the makings of a game that grabs the player and won't let him go, you need to find out if you're right. At the other end of the product cycle is testing, and it is the most valuable tool for making sure that your product won't lose the player. Somewhere along the line, but before the game ever hits the shelves, it must be taken out of the hands of its creators and placed into new ones. Even one completely new pair of eyes near the end of the product can prevent a huge number of simple gameplay hurdles from making it into the box. As professional game builders, we often understand how to circumvent small flaws and difficult areas of a game by using the game against itself. We react as much to structure as to content. Most players are not as familiar with the workings under the hood, and they react in a much more visceral way to a product. What the user sees and feels when he's actually involved in the product is much more strongly influenced by those tiny details that someone familiar with the game is prone to overlook.

Placing the game into the hands of the end user will find the flaws in its construction far more effectively than those who built it looking at the product hundreds of times. Complex motions and solutions that become second nature as you perform them over and over during the development cycle may not reveal themselves to be barriers until somebody is forced to look at them for the first time.

If the resources are available, this sort of feedback can be introduced earlier in the development cycle. Input from marketing, especially focus group testing, can tell you quickly if you're reaching some, all, or none of your intended players. The sooner you find out where you've lost your players, the sooner you can get them back. The value of evaluating a product with members of its intended audience cannot be overestimated.

At the end of the road, most of the potential pitfalls in development come from the creators of a product becoming too attached to the game as theirs - as "art" or "expression," rather than as a job they're doing for a group of consumers. One necessary role of designers is looking at their work with a detached eye and remembering that it has a responsibility to a much larger audience than the people who are working on it day in and day out. Look at the game as a gift to someone else, and not as a gift to yourself, and you have a better idea of what I'm talking about. Even more correctly, keep in mind that the people who will have to give up their hard-earned money for your product will evaluate it not as someone who loves it like a parent or plays it like a gamer, but simply as someone seeking to be entertained. These users will have no initial attachment to your product, and they won't be able to play it like you did after a year or so of developing it. Make sure that you're building it for them.

While concepts and features may come and go and systems may be modified time and time again, the core design should always be a guidepost for a product's development. Careful design in the initial stages of the product cycle and full knowledge of the designer's responsibilities beyond simply building a game will guarantee that nothing - and no one - will get lost along the way.