Steven Bachelder, Gotland University

Our Mission: To explore the benefits of prototyping across development roles

Our working group explored the process and benefits of using a prototyping process throughout development, as it relates to everyone who has a stake in the game's success. While we felt there was some good information on why and how to prototype a game from the designers point of view (see the literature list in the end of the report), there was very little information on how to manage the process from a studio manager or publishers point of view.

We believe that defining the best practices for prototyping touches upon far-reaching questions regarding game development processes, such as documentation and funding. According to our experiences, publishers are more willing to buy into a 350-page design document, than a process of prototyping. For us, this seems absurd and dangerous, as the validity of a design document as a detailed specification of an end product nearly always falters. This can lead to serious disputes between developers and publishers, when discrepancies in the documentation and its realization are found. Prototyping can help in solving these kinds of challenges.

Our approach during this session was to justify why each of our target groups should care about the prototyping process, and what each group should do to support it and use it to the best effect. Our target groups included designers, developers not involved in the prototyping process, QA, studio managers, and publishers. 

Global benefits

As we explored this process, we realized that there were some common benefits to prototyping across all of these groups. For instance, a prototype acts as a wonderful communication tool, allowing people to experience the fun and buy into the same solution. It allows feedback to be gathered and iterated on earlier in the process. It helps align the team behind an idea, while generating enthusiasm for a given solution. It helps solidify the design intent and resolve arguments about the design. And finally, it's a wonderful form of risk mitigation as all of this happens before major resources are committed to a given solution. 

Prototype as experiential design document

The core idea of prototyping is to prove that a given feature design is successful with the smallest amount of work possible. In essence, we can think about a prototype as a concept sketch for a game mechanic. By game mechanics, we refer to a central element of gameplay, such as an interaction that the player is asked to perform in the game, repeatedly, or in a particular situation. Developed into an appropriate form and scope, a sketch for a game mechanic can be characterized as ‘an enjoyable mini-game that shows great promise’, to borrow Daniel Cook’s view on early prototypes.

Most publishers and studio's require that concept sketches be created and approved for the major pieces of art in a game, yet many do not require this from game mechanics. And for some reason, most prototypes are viewed as throwaway work, yet a concept sketch is viewed as vitally important. We believe these views to be both wrong and the source of extremely expensive mistakes in the development process.

Before we begin it is important to discuss what we mean by a prototype. A prototype is a design doc you can experience; a quickly created version of a game design element that can be played and tested. A prototype is not a vertical slice, a pitch for an entire game, or a small scale production, but rather a working version of one small element within it. A prototype is not something that is only done at the beginning of production, but rather done before any design element is incorporated into the game. Prototypes should be quick to create, require few resources, and provide testable results to a development question.

Why and How to Prototype: Game Designers

Although the focus of our workgroup was to convince other roles along the game development pipeline to buy in to prototyping, we still started with the designer.

Prototyping best practices for game designers have been combed and covered fairly deeply (see, e.g. Game Design Workshop by Fullerton et al.), so we'll cover some of the most basics.

First, know what question your prototype will be trying to answer.  In order for your prototype to be as efficient as possible, the designer should have a clear, testable goal before creating the prototype.

Remember that a prototype is not a mini-production.  Your timeline for creation should be extremely short, and the smaller the team working on the prototype, the better.

When building your prototype, choose the most appropriate medium or prototyping tool for quick iteration.  This could be related to your skillset - if you have a strong programming background, then creating a digital prototype may be the fastest and easiest process.  However, perhaps a paper prototype may be more appropriate for you to build, or perhaps rigging up a crazy mechanic mock-up in PowerPoint, if you happen to know all the tricks. 

One of the biggest fears related to the support of prototyping is that it is often "throwaway" work.  But any experiment, failed or not, can be valuable if it is properly documented.  Creating mini post-mortems for your prototypes to archive why something did or didn't work can be valuable when addressing gameplay mechanics down the line.  It is not necessary to create an elaborate document for each prototype you do, but a brief write-up on the successes and failures of the test are certainly worth the time.

Make sure you are putting your prototype in front of the correct audience: not fellow game developers who might be expert players, but first time players who challenge your design intentions.

Why and How to Prototype: Development team

So, this is all fine and well, but designers have long known the value of prototyping.  What about the rest of the team that it takes to actually create a game?  Let's start with the Development Team, that is, the group of programmers, artists, etc. who come onto a greenlit project to actually create it.  What value does the prototyping process have for these people?

In spite of all the talk of prototypes as throwaway work, the process actually prevents work waste on the end of the development team.  Having a way to experience the game mechanic early on gives a more valuable basis of direction to work from than does a design document. This also gives artists and sound designers better grounds to ‘gather concept art and music to create an emotional target’, a guideline that the World of Goo developers concluded from their prototyping endeavors. Experiencing the game mechanic also allows developers to give early feedback to the designer, especially in regards to system plausibility.  The sooner the programmers realize that the designer's mechanic is, in fact, impossible on their engine, the quicker the problem can be addressed and the design re-worked.

Prototypes can also help the development team identify future tuning needs very early in the development process, so everyone involved can have better foresight to what is to come along the pipeline.

One of the best ways the development team can support the prototyping process is to use the prototypes as tools.  This means actually playing the prototypes, reading the designer's write-ups, and using them as a means of giving feedback.  If a red flag goes up while playing a prototype, this should be communicated back to the designer as soon as possible so it can be addressed.

Even though prototypes can be great tools for foresight for the dev team, their fragile nature should be recognized and accepted.  Programmers should go in with the knowledge that the code in a digital prototype will most certainly need to be re-written.  The designer just made it that way to work, period, not to work well, and prototype code should not be iterated upon.  Rather, the prototype should be used as a template or a design document for the mechanic that the designer is trying to convey.

Why and How to Prototype: QA team

Prototyping is not only an asset to those building the game, but those tasked with the responsibility of tireless testing it.  A prototype helps a QA team understand the design intent in a more tangible way than a design doc, so that it can be tested more appropriately.  It's also a fast an easy way to integrate new members onto a team.  QA can use prototypes to develop their testing plans for the game itself once it hits development, but there are some expectations that should be maintained by this team.

First, QA must expect prototypes to be delicate, fragile creatures.  They can't be handled in the same rigorous, bug-gouging way as a development build, because they will be buggy and half-broken by default.  Prototypes are a sketch for understanding the gameplay and the design intent, and their future potential - nothing more, nothing less.

Why and How to Prototype: Project and Studio Management

Traditionally, the further up the chain we move away from the single developer, the more skeptical the attitude about the values of prototyping.  Why should a lead or project manager, amidst their responsibilities of efficiently budgeting time, support prototyping in a development cycle?

On the process side of management, prototyping allows the project manager to identify more accurately the scope of the project, as the prototype is meant to give sense of the direction into which the game is going. If and when new members are attached to the project, prototypes can be used in communicating the concept and development tasks to the newcomer, thus speeding their integration to the project.

Concerning business management, at its best prototyping helps to identify potential risks of a project earlier, thus eliminating surprises further ahead in the development process. As tangible evidence of gameplay, managers can use prototypes in selling the concept to constituencies within the publisher.

Successful prototypes produce evidence that the concept works and it is fun. Prototypes like this are excellent motivation tools for the studio personnel to build development momentum - they are a way to remind everyone that they are working on something cool and worthwhile.

In order for prototyping tasks to bear fruit, there has to be an environment where prototyping is legitimized as serious and important work. It cannot be seen as something to be done on free time, but as an integral part of the business. Legitimizing prototyping openly promotes the birth of a creative atmosphere, where analyzing half-finished sketches of colleagues can breed a number of new, polished ideas. 

Image: This report is a result of editing tens and tens of observations together into an accessible whole. We have included a couple of images to illustrate our process of filtering out the most significant aspects for each role.

This kind of creative dialogue has to be supported formally as well: besides rewarding the team for finished products and milestones, companies need to organize their reward systems in a way that encourages people to prototype. This ties into integrating the prototyping process in the front end of the development process: prototyping has to have schedules and goals, there needs to be resources and tools available, and finally, these processes and costs have to managed. Still, prototyping is experimental in nature, and therefore it should have qualitative goals - related to the quality of design and development solutions - rather than quantitative ones.

Integrating prototyping into the process also means that the sketches have to have owners. This requires a step into managing the prototypes through ownership and archiving. Managing prototypes this way helps the company to build a library of IP that is accessible as a R&D repository, which can be helpful in solving problems in a particular project, or even responding to a publisher request about a new concept.

As a manager, it becomes crucial to know when to stop prototyping and when to start production, especially in genres such as MMOs and RPGs, which are ‘content heavy’ and thus difficult to prototype in many aspects, as Daniel Cook has observed. This relates also to publisher relations, and negotiations with them about the role of prototyping in a project.

Why and How to Prototype: Publishers

As we mentioned in the beginning, getting publishers into buying the practices described above might be the most difficult part. However, there are many reasons prototypes can be of value to publishers. From their standpoint, prototypes should be seen as crucial factors in risk mitigation: through sketches of game mechanics, feature sets and the fun factor of games can be assessed earlier. In addition, when a concept is proven by prototyping, its potential feature set can be increased with reduced costs when compared to creating a huge feature set into a design document and then freezing it for good. These steps should help in creating more focused expectations, and consequently lead to a better success rate overall. 

The above whys to prototype require certain measures if they are to work for the publisher's benefit. First, as underlined earlier, the difference between a vertical slice and a prototype has to be understood. Knowing the goals of each prototype, i.e. the question it tries to answer, is something the publisher needs to pay attention to as much as the developer. 

Second, if the developer legitimizes prototyping by managing the prototyping process properly, the publisher should work in parallel with this. It means stage-gating the prototypes by including them on the milestone lists. This gives publishers the chance to open a window to the development process more often, which consequently helps in identifying their sacred cows and priorities by pinpointing aspects of the design they do -- or do not -- want to be changed.

Finally, publishers can also build value in a library of prototypes. The library can be organized through a lens of best and worst experiences and designs, so that examples can be introduced to other projects and developers. Even if a project gets cancelled, its prototypes can salvage value from the failure. 

Conclusion: Prototyping for the win

Our starting point was to argue that prototypes should be regarded as design documents that you can experience. We have explored the different 'yous' here as the different development roles, with their particular responsibilities and needs in the game development process. Through the whys and hows we have suggested what each group should do to support prototyping and use it to the best effect. The result has been an attempt to justify and define what would be a road towards the best practices in prototyping within the games industry.

As a summary, we synthesize the whys and hows for each role into a set of guidelines, which might be regarded as a manifesto of sorts:

• Designers: Solidify your design intent to the project members through prototyping. It establishes credibility for your ideas, and kills your darlings. Always define what you are trying to answer with the prototype, and embrace failures by rapid iterations. Make the prototypes with the smallest team possible to save time and resources. Learn to identify genre-related prototyping pitfalls and possibilities.
• Development team: Play the prototypes and try to understand the design intent in order to establish a common framework with the game designer. Treat the prototype as a design document, and raise red flags about impossible features. Don't focus on the code, expect to re-write it - yet, think of it as a template.
• QA: Play the prototype but expect it to be fragile. See the prototype as a tool for identifying test cases, and writing test plans based on them. Question the game designer about the design intent - it helps him iterate the design.
• Managers: Prototypes should help you in planning and identifying risks. Legitimize prototyping in-house, and to the publisher, in order to promote creativity, but manage and schedule it rigorously to save the publisher's money. Learn to analyze what and when to prototype, and how this differs from genre to genre. Embrace prototypes as communication tool: Integrate new team members by getting them accustomed with the project's prototypes, showcase prototypes in-house to other teams, and use them to sell to constituencies within the publisher. Be aware of over-prototyping.
• Publishers: Do not mistake a prototype with a vertical slice of a game, but see it as possible evidence of the fun factor. Evaluate it on qualitative instead of quantitative basis. Make sure you understand its scope and the questions it tries to answer: If the developer fails to answer your question ‘Why am I seeing this?’, you should be able to guide their prototyping to the direction that serves your goals. Include prototypes into, or as, milestones, and give the development team a chance to prove you are wrong about a given design matter through a task of rapid prototyping. Managing prototyping in such a way can build your trust to the development team, and vice versa. Build and manage a library of IP from prototypes across projects, as this enables you to salvage value from failed projects.

Literature on game prototyping

Cook, Daniel (2005): 'Common Game Prototyping Pitfalls'. Lost Garden, online: http://lostgarden.com/2005/08/common-game-prototyping-pitfalls.html

Fullerton, Tracy & Christopher Swain & Steven Hoffman (2004) Game Design Workshop: Designing, Prototyping, and Playtesting Games. San Francisco, New York & Lawrence: CMP Books.

Gabler, Gray, Kucic & Shodhan (2005): 'How to Prototype a Game in Under 7 Days: Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester'. Gamasutra, online: http://www.gamasutra.com/features/20051026/gabler_01.shtml

Kosak, Dave (2006) 'Game Prototyping: How the Skunkworks Work' Gamespy, online:http://pc.gamespy.com/pc/spore/698263p1.html

Saffer, Doug (2007): Designing for Interaction: Creating Smart Applications and Clever Devices. New Riders.

Waugh, Eric-Jon (2006):'GDC: Spore: Pre-Production Through Prototyping' Gamasutra, online: http://www.gamasutra.com/features/20060329/waugh_01.shtml

Zimmerman, Eric (2005): ‘Play as Research: The Iterative Design Process’, in Brenda Laurel (ed.): Design Research. MIT Press. 

section 4

next section

select a section:
1. Introduction  2. Speakers  3. Executive Summary  
4. Concept Sketches for Game Design: Best Practices for Prototyping within the Game Industry
5. Multiplayer Game Atoms
6. Game Designer as Artist
7. Please, Let Me Play the Game I Bought
8. The Gaming Date
9. Dramatic Choices
10. Game Designer's Bookshelf
11. Project Unity
12. Schedule & Sponsors