Category Archives: Game Production
Nobody Knows Anything: Why Skipping Playtesting Is Inconceivable
Last week plagued us with at least three deaths of figures in the entertainment industry. The death of beloved Marvel Comics editor and Marvel film cameo star Stan Lee made front page news around the world. A less publicized death was that of actor Douglas Rain, who provided the voice of the murderous computer HAL 9000 in my favorite film 2001: A Space Odyssey. But another death that was significant to me and many others was that of screenwriter, novelist, and playwright William Goldman. If you are not familiar with his name, you certainly are with his work: Butch Cassidy and the Sundance Kid, Marathon Man, and The Princess Bride, to name but a few.
In addition to his works of fiction, he is also famous in the film industry for his memoir about his career in Hollywood, Adventures In The Screen Trade, and particularly for this quote:
“Nobody knows anything…… Not one person in the entire motion picture field knows for a certainty what’s going to work. Every time out it’s a guess and, if you’re lucky, an educated one.”
That observation is as true in the game industry as it is in Hollywood. I’ve experienced first-hand from both sides of the fence how game publishers will push developers in certain directions or to make other concessions in the belief that the publisher knows what will sell to the game-buying public. In many cases, I’m sure it is a sincere belief, but in others, I’m certain its merely the publisher representative trying to demonstrate and justify their value to the project. But sincere or not, what is going to work in a game is just an educated guess at best.
However, I’m not going to point my finger only at the publisher. Remember, nobody knows anything. That includes game developers. Even a developer with years of success may discover that when his or her game is first played by gamers, that what the developer was sure was easy is actually difficult, what was understandable was confusing, or what was fun was boring. As developers are working on a game, it is essential that they get it out in front of potential players to verify their assumptions about the game. To not do so is, as The Princess Brides’ Vizinni would say, inconceivable!
Not game developer gets it right the first time they show their game to players. It may take dozens, hundreds, even thousands of adjustments to games before they deliver the right play experience. This is the called iterative process of game design, a design methodology based on a cyclic process of designing your game, making a prototype, testing the prototype with users, and then learning what changes need to be made to the design. The cycle continues until the game is good enough to launch (or you run out of time and money for more iterations).
Usually developers will find it to be a very humbling experience, because everything they thought they knew about how people would react to their game will prove to be wrong. But they shouldn’t be too hard on themselves. After all, nobody knows anything.
A Template For Game Pitch Powerpoints
Prior to doing their final Game Production projects, students at the Los Angeles Film School take a course called Concepting and Preprodution. The first half of this course involves each student creating a PowerPoint presentation for pitching a game concept of his or her choice. The students then all pitch their concepts to a Greenlight Committee consisting of faculty and other members of the school staff, who afterwards deliberate in private and select one or more projects for the students to develop as their Final Project.
Once informed of the Greenlight Committee’s decision, the students then break into development teams and spend the last half of the course creating a game design document, technical design document, asset document, and schedule for the development work to be done in their following courses, Game Production 1 & 2.
After serving on several Greenlight Committees, I found that many students did not provide the members with the information necessary to truly understand the game being propose, while others spent far too much time on story or other details that really did not impact the Committee’s decision. So I decided to create the following template for the students to use, and it seems to have worked out well.
Title
The first slide presents the game’s title and key art, as well as the student’s name. While this slide is displayed, students introduce themselves and the game they are pitching. This gives the students an opportunity to grab the Committe’s attention before launching into the details of their game.
Overview
Students say their elevator pitches while displaying an overview of the game’s essential aspects: it’s genre, theme (setting), play value (what makes it fun to play), a well-known game that’s similar, what features will make the student’s game different from the competition, and what game engine will be used to develop the game. This overview provides the Committee with a high-level understanding of the game, providing context for when the student begins discussing the details.
Gameplay
Students describe the game’s goals, core mechanics the player uses to achieve those goals, and the obstacles that determine the difficulty of performing the mechanics’ actions successfully. Students are also encouraged to include a diagram that illustrates how the mechanics work in relation to the game objects.
Gameplay, continued
Students describe the resources used to “fuel” the mechanics, along with any other ways those resources are produced and consumed. Finally, the students explain the different ways the game concludes through a win, loss and/or a draw so that the Greenlight Committee understands the player’s goals.
User Interface
Students explain the control scheme for the player’s use of keyboard, controller, mouse or other input device; the camera perspective used; and where game state information is displayed on the screen. Their PowerPoint should include a wireframe or other mock-up of the game screen and highlight the elements being discussed.
Narrative
If the game has any semblance of a story, students give a short synopsis of its narrative in terms of its protagonist, antagonists, backstory, complication, and resolution, as well as the number of levels in the game. Because some students create overly-elaborate stories for their games, we limit the overall presentation to 8 minutes and begin to give warnings about going over the time limit at about this time in the presentation.
Audio
Students have the option to play samples of their choice of music for the game, including its main theme, low-key music (such as for an exploration mode), and intense music (such as during a combat mode). The music is embedded into the slide and played by clicking on a Speaker icon.
Staff
Students name who they would like to have on their team and the roles to which each would be assigned. Our rules are is that the Project Manager, Lead Audio, and Marketing person must have at least one other role, and that the Lead Programmer cannot have any other role. This prevents students from being assigned too much responsibility or too little.
Risks
Finally, students are required to explain at least three risks that might cause their project to be unsuccessful and what steps they can take to mitigate those risks. The one risk they are not permitted to list is “No enough time”, since they are required to pitch concepts of an appropriate scope to be done in the two months they have to produce the game.
Thank You
This final slide informs the Committee that the presentation is done and invites them to ask the students follow-up questions.
As I wrote above, this template seems to have worked well for our student’s Greenlight Presentations, and perhaps it would work well for you when you need to pitch a small-scale game project.
David Mullich 