Download
1 / 20
200 likes | 326 Views
Lecture 4 CS170: Game Design Studio 1. Thanks to Game Design and Tuning Workshop – GDC 2007 (http://algorithmancy.8kindsoffun.com/GDC2007/index.html) for some slides. UC Santa Cruz School of Engineering www.soe.ucsc.edu/classes/cmps170/Fall2008 michaelm@cs.ucsc.edu 10 October 2008.
E N D
Lecture 4CS170: Game Design Studio 1 Thanks to Game Design and Tuning Workshop – GDC 2007 (http://algorithmancy.8kindsoffun.com/GDC2007/index.html) for some slides UC Santa Cruz School of Engineering www.soe.ucsc.edu/classes/cmps170/Fall2008 michaelm@cs.ucsc.edu 10 October 2008
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
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
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?
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.
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
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.”
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.
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).
Brief experiment with physical (chalk) prototype • Time permitting
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?
