Lecture 4CS170: Game Design Studio 1

UC Santa CruzSchool of Engineeringwww.soe.ucsc.edu/classes/cmps170/Fall2008michaelm@cs.ucsc.edu10 October 2008

Thanks to Game Design and Tuning Workshop – GDC 2007(http://algorithmancy.8kindsoffun.com/GDC2007/index.html) for some slides

UC SANTA CRUZ

Take a digital game…

UC SANTA CRUZ

…remove the controller…

UC SANTA CRUZ

…remove the controller…

UC SANTA CRUZ

…the sound and music…

UC SANTA CRUZ

…the sound and music…

UC SANTA CRUZ

…and the graphics

UC SANTA CRUZ

…and the graphics

UC SANTA CRUZ

What’s left?

UC SANTA CRUZ

Prototyping The goal of prototyping is to allow you to experiment with

the core mechanics of a game By being able to quickly playtest a mechanic (both with yourself

and a few other people), you can answer many design questions For a large game, you will have prototypes of different parts or

aspects of the game, and different prototypes will test different rule sets

Prototypes abstract away details to focus on a mechanic

Prototypes also serve as documentation of a design – can communicate between team members more effectively than purely written documentation

Two basic classes of prototypes Physical Computational

UC SANTA CRUZ

Abstraction

UC SANTA CRUZ

Physical prototypes

Physical prototypes are particularly useful for exploring core mechanics

As you add more and more rules, and their complex interactions, the complexity begins to exceed what can be reasonably simulated in paper At this point move to computational prototypes

Because object and rules changes can be so fast with a paper prototype (no coding!), you can quickly experiment with modifications to the mechanics and features

UC SANTA CRUZ

FPS Example

We all believe you can paper prototype a board game – a board game is already paper But what about real-time computer games?

What are some design questions you might ask about an FPS? What are the basic actions a player can perform? How big should the level be? What’s the level design (for a particular level)? What objects are in the environment and how do they

help or hurt the player (weapons, powerups, health…)? Where are spawn points?

UC SANTA CRUZ

Simulating real-time with a paper prototype For non-turn-based games, a challenge with paper

prototypes is capturing the real-time aspect You’ll have to invent some procedure, which generally won’t

be part of the real game, for doing this

For the FPS example: Build stack: each player chooses three action cards and places

them face down Reveal: each player turns over his top card. Resolve shoot cards: players with shoot cards fire in the

direction their unit is pointing in a straight line. Simultaneous shots are resolved with dice.

Resolve turn cards: Players with turn cards turn their unit. The order of simultaneous turns is resolved with dice.

Resolve move cards: Players with move cards move their units the number of spaces they selected. Resolve multiple move cards with dice. Cannot occupy the same cell.

Repeat steps 2-5 for the second and third cards in the stack.

UC SANTA CRUZ

Lets think about other features to add You start with the simplest underlying core

mechanic. For all games, the underlying core mechanic is simple.

Other things we might want to add to the FPS prototype: Squad – hierarchical unit strength and importance

Simpler: captain and grunt More complex: RPG-like classes: tank, healer, range,

defender/controller Weapons: weapon tradeoffs Access to weapons tied to stats on player avatar Economic system modeling war production Terrain: effects movement, visibility

UC SANTA CRUZ

Benefits of physical prototyping “People not used to physical prototyping may argue that this

method doesn’t accurately represent the player experience on a computer. They may think a pen and paper prototype might work for a turn-based game, but not for an action-based shooter because gameplay is integrally tied to the 3D environment and the ability of the players to act in real-time. We are not arguing that physical prototyping replaces those things. What we are saying is the overall gaming system can benefit tremendously in its early stages by building a physical prototype.”

“Physically prototyping allows you to build a structure for the game, think through how the various elements interact, and formulate a systemic approach to how the game will function. The sensory experience created by a digital game—e.g., the feeling of moving through a 3D space—is only one component of an engaging game experience. And although it’s a critical component, it can be isolated and left until later in the process. At a minimum, physical prototyping forces you to think through the design elements and define them. You can always change them down the road, but this gives you a framework to build upon, and that in itself can save you from stumbling around blindly when it comes to preparing and launching a production team.”

UC SANTA CRUZ

Steps to building a physical prototype 1 Foundation – a representation of core gameplay. Include only

the most fundamental, basic game objects and key procedures. This is the minimal playable kernel of the game. It may still contain a lot of ambiguity (not specified what to do in the event of ties, etc.). Try playing the raw core mechanic on its own. Won’t be much of a

game yet, but can give you a sense of whether the idea is even worth pursuing.

Structure – adding additional, minimal rules and options to your prototype. You should prioritize your list of features and rules and start adding in ones that are at the top. Focus on rules first rather than features. Add in rules gradually so you can see their effect on the game

(experiment with rules). Features vs. rules: features are attributes that make the game

richer, like different unit types, weapon types, power-ups, etc. Rules describe how the game state changes over time; every new feature introduces (at least) several new rules. At this stage, save features for later.

UC SANTA CRUZ

Steps to building a physical prototype 2 Formal details – adding the necessary rules and

procedures to turn it into a fully functional game. At this point should have clear objectives and challenges. Fullerton suggests isolating each new rule and testing it individually. At this stage your game should feel like a game.

Refinement – the time to start adding those “nice to have” features that will tune the game experience. Rank features and isolate and test each one. If you add a bunch of refinement rules and features too early, you loose sight of what your game is about. At this stage, you should definitely be pulling in external playtesters (start this with the formal details stage).

UC SANTA CRUZ

Brief experiment with physical (chalk) prototype Time permitting

UC SANTA CRUZ

Physical prototypes next week You’ll be doing a game pitch (another powerpoint deck)

Should have everything in it that you had this week You won’t be presenting this, but I’ll be looking at them (provides the

background for your physical prototype) Make sure you highlight which aspects of the game you’re prototyping

Bring your physical prototype to class We’ll play them in groups

Turn in documentation of your physical prototype Objects used in your physical prototype Pictures of all the components of your physical prototype Rules (how to run the physical prototype) The goal is that, from your documentation, someone else should be

able to recreate your physical prototype

Description of playtests you performed (outside of class) and what you learned from the playtests What worked well? What worked poorly? What surprised you about your design?