Based on Game Design Workshop, Second Edition: A Playcentric Approach to Creating Innovative Games

One of the most difficult tasks that most novice game designers are faced with is patience. The excitement of developing a game, and the eagerness to make a great product sometimes backfires when the creative process is overlooked. This also results in more serious issues down the road, when user research uncovers problems in the game’s core mechanics that are difficult to solve once they have gone deep into production. Many of these issues could have been resolved by creating a prototype of the interaction, and use that as a testing environment to experiment with a game’s fundamental mechanics.

Why is a prototype important?

A written explanation of how a game works, such as a design document, works well in may aspects. However, creating a tangible working model of your idea takes away some of the abstraction in the document. A prototype’s role is to help you iron out your ideas, and test what work and what doesn’t.

Creating prototypes help a designer and their team to avoid getting emotionally attached with anything being tested. All aspects of the prototype should be in a raw form and shouldn’t be considered final by any extent. In the article, “The ideal window of time to start and finish a prototype(including design, implementation, testing, and iteration) is two days to two weeks. Anything longer than that sets off alarm bells.”

The Physical Prototype
Physical prototypes, sometimes called “analog prototypes” or “paper prototypes”, are very crafty in nature. They are created using everyday materials like cardboard, paper, glue, and sometimes reusing pieces for other games. This is a great method of giving the designer the opportunity to focus on the mechanics and not the aesthetics and technology. Many times, once code starts to be written and artwork starts being created, developers start to get attached and making design iteration become challenging right away. By taking the complexity out of the process, user feedback could be responded to in real-time, which allows more iterations. This also allows non-technical peers to work in assist in the design of the game at a greater capacity.

In this article, the author takes us through the the development of a few paper prototypes. The first is Battle Ship, where the designer is able to get a prototype up and running extremely quickly. The second is based on a game called “Up the River”. The author challenges the reader to make their own version of the game. Later, the author takes us through the development of a more complex prototype of a 3D First Person Shooter (FPS), using plastic army men, hexagon graphing paper, and some cardboard. The choice of hexagon is because it allows users to move diagonally, which lends itself well to this type of prototype. Lastly, the author help the ready deconstruct two real-time strategy games, to help up pull out the core features and base our own version from what we find.

Once the paper prototype starts to get created, rules start to be added. In the example of the FPS, the author wanted to keep as much of the typical FPS game mechanics, so rules emerged like:

• bullets can’t pierce through walls
• defined spawning area, where killed units re-materialize
• unit shots in the direction it is pointing

Some of these rules might bring up questions like, “how many spawning points does the game need?” The answer to that question is, “The only way to know is to play it!” No mater what you decide in this early phase, it will probably change later so the author suggest that “your best guess is good enough”.

As you play with your prototype, you should take notes of any questions that come up, and describe any problems that you notice along the way. You will quickly start to compile a list of new features that might help the game be more compelling. Some of the features that came out of the author’s example where:

• Adding a scoring system
• Include a hit percentage
• Provide hit points
• Provide first aid
• Add in ammo
• More weapons

Bellow is an explanation on the steps that you should take to create your own prototype.

Steps to building a prototype

Visualizing Core Game Play

• identify a much of the core game mechanics before you build out
• use a diagram to see which features are not integrate into the mechanics
• Don’t try to build your entire game at once. Plan your focus around the main aspects of the game. Aspects that need to be there in order to make it playable.

An example of core game mechanics might look like:

World of Warcraft: “Players build and move units on a map in real time with the intent of opposing units in combat and destroying them”

Steps for building a prototype

Foundation

• design the basic game object (setting, units, resources) and the repetitive actions that keep the game in motion
• Simplify feature to their most basic level
• Work economically: Don’t do too much at once, and invest wisely. Always keep focus on what the purpose of the prototype is.
• Test the game at this raw state and see what works.

Structure

• build the framework that will support a rich and varied feature set
• prioritize what is most essential
• keep all the distinction between a rule and feature present in all you decisions. Features make the game richer, while rules change how the game functions.
• Focus on structuring rules first, then move onto features

Formal Details

• Add any necessary rules and procedures that help make the game functional.
• Try not to add too much. pair features down to small sets
• Back your decision with both judgment and input from playtesters
• Tip: If you could continue to build your game without a specific rule, then leave it out. You could add it later.

Refinement

• At this point the game will have flow.
• Questions shift from fundamentals of game to small details.
• Add in all those awesome ideas you had in the initial stages! Just not all at once.
• Make sure you isolate individual aspects of the game to get a better sense of how each feature positively or negatively effects game play.
• once you have analyzed the feature rank it by necessity.
• Write an analysis, and make sure to incorporate playtester reactions

Popularity: 14% [?]