[size="5"]Principle 1: Understand The Role of the Designer and Producer
It's vital to know what lines of responsibility are drawn within game development organizations. This knowledge gives you an understanding of which people are responsible for which game components, who makes design and production decisions, and so on.
The game designer. The game designer is the visionary, somewhat like a book's author. This person has outlined the scope and description of the product with sufficient detail so that others can understand and develop the product. Just as a book author sees his creation develop differently when made into a film, the game designer needs to accept and solicit modifications from the team members, the publisher and the public during the development process. Often , one of the game designer's tasks is to create the project Bible - the game's lengthy technical specification. This document details the gameplay, describes characters and settings (possibly including diagrams or drawings), includes level descriptions and possibly maps of areas to explore, positions and actions for each character or class of character, and so on.
The producer. The producer is the project's manager, its champion. The producer must keep the entire team productive and the lines of communication open. This person is a diplomat, a politician, a trouble-shooter, a force needed to produce the product. The producer must keep marketing, advertising and public relations teams up to date with the progress of the game, and honest about its features, performance, and other claims that will be made to consumers. These teams must understand the gameplay, its features and story line to generate great ads, media hype, magazine previews, and so on. In return, these non-technical team members, by virtue of their continuous contact with the public, provide the game developers with feedback from the public, magazines and retail channel about what features are currently hot in games.
The producer needs to facilitate communicate between the whole team, and provide timely support for each developer, which includes ensuring that:
- Artists and animators provide artwork, animations, temporary placeholders to the programmers on time, until the final artwork is available.
- Programmers provide the artists with current versions as to see their artwork in a real time gameplay mode. The producer must also make sure that the programmers provide a current version of the game to the sales, public relations and marketing teams, along with various reports about the latest version of the game. These reports describe gameplay, special features, hardware requirements and supported hardware and peripherals, screen shots that best portray the product for ads, promotional sheets, previews and reviews for magazines. The producer also needs to make sure that programmers work with the quality assurance (QA) testers and provide them with the play instructions, special key combinations, hints, undocumented features and actions.
- Audio and sound engineers provide voice, background and atmosphere sounds and music. These engineers also need to view and play the current version to check and validate the timing, usage and clarity of their work.
- The designer (if not a member of the day-to-day team) sees the current version to confirm that the product is in line with the technical specifications and design originally set forth.
- The QA testers report problems to the producer. The problems must be categorized as major (crash, function or action not working), minor (text misspelling, character movement to fast or slow, response time feels wrong), glitches (sound or graphic problem), improvements (add a new feature, improve the character's interaction or behavior, clarify a confusing aspect of the design or gameplay), a videogame standards issue (the triangle button does not perform as the standard function definition), and multi-platform inconsistency (PC version vs. videogame version). Whether one person assumes the role of both producer and designer, or several people handle these tasks, there must only be one producer whose word is final, whose decisions are followed and whose leadership is trusted and motivating.
[size="5"]Principle 2: No Designer or Producer is an island.
Gathering information throughout the product development cycle and knowing what to do with it is the trait of a great designer and producer.
Designers should research their subject matter and evaluate outside suggestions and opinions. The audience demands and expects films and books to seem realistic and accurate. The computer and videogame audience should accept nothing less.
When undertaking the development of a sports game (e.g., Baseball), a designer may feel that he knows the sport from playing it as a child and viewing it on TV. However, much more research must be undertaken to create an immersive experience for consumers. Whether the game genre is sports, RPG, adventure or simulation, the first step is to research similar titles in that game genre. You can do this by surfing the Internet, visiting the local store and purchasing competitive games, reading reviews of similar genre titles, collecting marketing materials and advertisements from other publishers' websites, and so on. This information is invaluable when you are designing a new product.
If you are the producer of an upcoming baseball game, you ought to know the common elements found in other Baseball titles, as well as special features that differentiate each product from its competitors. You should read reviews of similar titles and the competing titles' list of features. From this freely collected information, a designer can understand which features and game play customers expect, special features that the competition offers, and the criteria upon which the reviewers will base their critiques.
As the designer and/or producer, you must ask yourself:
- Does your game suffer the same poor or awkward design flaw as a previously released title or similar genre titles? The design of the game needs to address how to be better than its competitors. The design must be able to handle flaws, difficulties and problems that reviewers and customers have complained about in previous versions of this product or in other similar genre titles. As the decision maker, you must listen to your development team, your marketing and sales team, retailers, and your game playing audience.
- Do the ideas of the game designer and the team outweigh those of the reviewer(s)? The ideas that are made must have a good foundation. All reviewers try to accurately explain and criticize the product to the public. There's a real difference between discarding a reviewer's opinion and listing the problems and how your design addresses each one.
- Does the design consideration include comments from previous or potential customers? Customers enjoy great products. My experience (in producing sports, gambling and trivia/puzzle titles) indicates that customers (fans) will buy any product in the genre they enjoy. Their expectations are that your product will teach the something new about the activity, they will gain experience and be able to brag to their friends and associates, and/or that they'll be able to someday beat the game. I've received a great deal of fan mail in which consumers have cited the aspects of my games that they enjoyed. These letters also tell me what additions to the game that they would like to see in future releases. Magazines publish reader's letters that praise and criticize the products. Market research and beta test groups consisting of potential and previous customers can be worthwhile in the final design stages to tweak the product before its release.
- Are the team's ideas and opinions seriously evaluated in the design of the product? See Principle #3 for more information about this.
- Can the addition of a feature expand the customer base and get more publicity? In Villa Crespo Software's Flicks, a product that reviewed 30,000 films, a field for "close-caption" was added during the development, instantly adding four million hearing-impaired and non-English speaking audiences to the product's customer base. Newsletters reaching that consumer sector gave the product free, positive reviews because the product included information vital to their readership.
The producer should collect information from team members about improvements that can be made to the product, and relay this information to the designer. The producer must be able to recognize a good idea when he hears it, and implement that idea in the game to make it a better product.
Designers should be adaptable and open minded to ideas that can make their games better. Producers need to be managers, leaders, and diplomats who can take information and in getting good suggestions understood by all involved with the final decisions.
[size="5"]Principle 3: Let Professionals do their jobs.
Most projects have a team of talented professionals working on them, made up of designers, programmers, graphic artists, audio technicians, testers, marketing coordinators, and so on. Each of these team members brings their own unique, important talents to bear on the project. A producer and designer must rely on these professionals and their particular points of view to improve and facilitate the development process. Regardless of the product's genre, each member can make a product better.
For instance, the quality assurance (QA) and testing people can suggest gameplay improvements before the product is shipped. No member of the team plays the game for hours at a time like a QA person does, therefore his/her suggestions are similar to that of the potential customer. In fact, members of the QA team have probably played more games in a particular genre than the rest of the team combined.
The producer must not only trust his team members, but also rely on them for input to create the best product.
[size="5"]Principle 4: KISS (Keep It Simple Stupid)
Every aspect of a product should be obvious and easy to understand.
For instance, allowing players to access every option within two button clicks may be simpler than having thirty-seven unique keys to press. Forcing a player to press Alt-Ctrl-Shift A to get his character to kick an opponent would be ridiculous. Likewise, having to press "A," "B," "C" and "D" to control the movements of a plane in a flight simulator would drive the average player crazy. If a player has to repeatedly press four keys to perform a task, the game design should include a super key or a one-key macro to simplify the operation.
Keep design interfaces simple. I once designed games for an arcade manufacturer, and the president of this company taught me a valuable lesson about design. He said if a player doesn't grasp the interface of a computer game or videogame, that player will read the manual since $50 (or so) was invested in the game. With arcade games however, the player has only invested a quarter or two, so if the game isn't understandable, addictive and compelling, the player moves on to the next machine. Who cares about wasting pocket change? While this is especially critical for arcade games, I think it's important to remember when designing games for any platform
[size="5"]Principle 5: Schedules are like laws.
Schedule are like laws; they are created by legislative bodies and meant to be obeyed, but they are also designed to allow exceptions if evidence warrants special circumstances.
Likewise, milestones are created at the beginning of the project may need to be changed based on problems that occur during development. For instance, the decision to change the original game specification (e.g., to support a new computer, a new 3D card, alter pre-planned artwork or audio clips) in order to make a better product is a situation which may warrant "breaking the law" that schedule spells out.
If another month of development time would greatly improve the gameplay, remove non-show-stopping bugs or allow for better visuals or audio effects, then circumstances justify deviating the schedule. To ship a game on a target day, month, or year regardless of the state of the product at that time can spell disaster for that product (not too mention the harm it does to the publisher's reputation). Missing seasonal dates like Christmas is bad, but shipping buggy or a poorly made product is worse.
You should only modify a project schedule if there are valid reasons. The team and publisher must agree that the additional time will substantially benefit the product.
[size="5"]Principle 6: The Yardstick: One Day's Pay for a Week's Worth of Fun.
If a customer pays $50 (plus tax) for a game that I've worked on, that amounts to the average person's one day net pay. (A person earning $21K a year brings home $14K which is $54 a day.) If the player reports enjoying the game that I worked on for at least one week, then I am happy. If the player feels ripped off due to poor game design, numerous bugs, obstacles in playing the game (e.g., multi-CD swaps, memorizing numerous keystrokes, and so on), poor audio, or some other problem, then the game designer and any team members who knew of these problems beforehand are to blame.
Every member of the team should be proud of their product. They should consider the praise from consumers, reviewers and the industry as their reward for they time and work they spent on the game.
[size="5"]Principle 7: I Never met a Genre that I didn't like.
A student who doesn't enjoy math can study hard and still earn an "A" in class. Similarly, a designer or producer does not have to have experience working on a particular genre to create a good game within that genre. In fact, a designer or producer doesn't have to even be an enthusiast of that genre in order to get good results. Putting together a team in which at least one member enjoys the genre (or studying competing products of the genre) is what is critical.
Often just one enthusiastic team member can show similar games that he/she has enjoyed, and thereby turn every team member into a knowledgeable player of the genre. Combining fanatical genre loyalists along with non-genre players on the development team can result in benefits you may not have considered. For instance, a non-genre player can suggest modifications to a game's design by pointing out aspects of the genre he finds unappealing, whereas a fanatic of the genre can lend his expertise and advice to keep a game faithful to the genre.
A knowledgeable developer or producer may ask the entire team to play similar games in that genre and ask each team member to critique the products. This technique can help the development of your product, and it's time well spent.
[size="5"]Principle 8: Be true to your license
Games based on licensed products often cause players to make certain assumptions about those titles. There are preconceptions about the gameplay, content, and target audience. In stores, it's the licensed titles that get noticed first, regardless of their marketing and advertising. Game designers must understand this customer mentality. The designer must understand everything about that license in order to provide the kind of entertainment that the target consumers have anticipated.
For instance, a baseball game that uses a particular baseball team's manager in its title suggests a strategy sports game. Players would probably assume that they would be responsible for making decisions about the players and batting order. On the other hand, a licensed product linked to a professional baseball player would suggest an emphasis on sports action, such as pitching and batting.
There's a reason why licenses cost big bucks. Designers and producers must use the license, its characters, and leverage consumer preconceptions to title's benefit.
[size="5"]Principle 9: Share your Toys!
Throughout the years, many game developers have bounced ideas off me, asked me questions, and so on. I have, and will always, welcome these inquiries because I believe it's for the greater good of the industry. Since I have always been interested in creating and exploring ideas, I feel that when someone wants information, I'll gladly help. Three occasions in particular are worth relating:
- In 1985, an auto mechanic who owned an Atari 520ST called me and to pick my brain about game design and various game projects he was working on. For several months we talked, and often he sent me samples of his artwork as well as demos of the concepts we'd discuss. Sometime around 1987, he had an interview with a major publisher and discussed taking the demos and artwork with him. I encouraged him and wish him success. A few weeks later, he announced that he was hired as "platform level" designer. Within months, he became the top "platform level" game designer for this company, and he worked on the most well-known titles in the industry. He eventually left this publisher to join another equally large publisher as the head of game design. He appeared in several magazines displaying his platform level designs. To this day, I've never met him and have only seen him in the magazine articles that he sent me, but I feel very happy that I was a small influence in his life and in the industry.
- When I was working on All Dogs Go To Heaven, a game for the PC and Amiga based on the Don Bluth film, I met a young man who worked at an arcade. On several occasions, I gave him $10 in tokens to show me the latest video games. As he played, I observed him and asked questions like, "How did you know to do that?". After we got to know each other better, he showed me several comic book sketches that he had drawn, which were great. When I was contracted to produce and develop All Dogs Go To Heaven, I asked him to do all the artwork. Since he was new to computer graphics and animation, I taught him the mechanics of using a Summagraphics Tablet and the functions and features of various graphics packages. He learned quickly and produced some of the finest artwork that CGA and EGA would allow. After the release of this title, he went to work for a Florida publisher as a computer and videogame graphic artist. When the company moved to California, he moved with them. The last I heard, he was moving on into one of the big publishers as a senior graphics person.
- A high school student sent me a concept for a game show. The description read well, but the demo he sent me was terrible. Over several months on the phone, we fixed many of the game's rules and aspects of the gameplay which greatly improve the game show. I programmed the game, and hired an artist to provide the graphics. When I went to Villa Crespo Software outside of Chicago, we published this game show, which we called Combination Lock. The game was fun to play and it was the first product to feature on-screen players of all races. The high school student and I shared in the profits for several years. The reason that I relate these stories is that I want to emphasize the benefit to those who help budding game developers. When the opportunity to help someone comes knocking on the door, offer that person hospitality and kindness. The results will benefit the "seeker of knowledge," will honor you "the master", and will benefit the industry as more creative thinkers join in.
[size="5"]Principle 10: There's no magic formula for success
Keep in mind that no one individual or company of any size has discovered the formula for "what makes a successful product." Like film, art and music, games appeal to a variety of consumer tastes, and of course taste is subjective.
Some developers of past hits have credited their success to the underlying technology that their game used. Other developers claim that their game transported the player into a surreal and immersive universe. Yet others feel that their game's success was due to the way it engrossed the player in a realistic simulation, challenged them with its compelling design , or simply made a great game accidentally. Behind each successful title is a unique list of traits that made it popular with consumers.
The bottom line is simple. A well-designed product based on a team effort with an user-friendly interface developed within a reasonable time frame will be successful.
