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 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. 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. 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. Principle 8: Be true to your licenseGames 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. 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:
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. Principle 10: There’s no magic formula for successKeep 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. Roger E. Pedersen (REP6@THEGLOBE.COM) has been designing, producing and programming games since the industry’s infancy (1983) for such companies as CBS Software, Gametek, Hi-Tech Expressions, Merit Software, Arcade Giant Merit Industries, Villa Crespo Software, Acclaim Entertainment, Hypnotix and American Alpha. His cumulative title sales have surpassed 10 million copies. He is currently seeking work. Please contact him regarding all opportunities for Project Manager, Producer or Game Designer
|