LESSON #11: Level Design 1: Rational Game Design

Fix your game with Rational Game Design TODAY: 1. Digital Prototype Testing/Sharing. 2. Level Design Topic #1: Fix your game with Rational Game Design

PART 1: DIGITAL PLAYTESTING SET UP (10 minutes): Teams Choose Tables Set up game digital prototype on 3 laptops. Decide initial Observers (1-2) and Players. Discuss: 1-3 points/instructions to share with visiting players? Write them down!

PART 1: DIGITAL PLAYTESTING PLAYTEST ROUND #1 (20 minutes): Observers stay to manage playtest, Players find other games to play. If team chose 1-3 instructions, give them. Players attempt to play prototype (5-10 min). Observers take notes! Players fill out questionnaire (5 minutes). Time permitting, discuss answers.

PART 1: DIGITAL PLAYTESTING TEAM MEETING (10 minutes): Convene at your team table to discuss observations and questionnaire answers. Discuss Production goals for the next week (next top priority Backlog items, potentially influenced by tester experience/ observations) and divide work equitably.

PART 2: RATIONAL GAME DESIGN An interactive, 1-hour presentation & exercise based on the April 2016 2-day (10 hour/day) workshop at NU by Alexis Jolis Desautels, based on Ubisoft’s 9-day (72 hour) intensive and secret RGD training program, leaked in the Gamasutra article “Rational Design: The Core of Rayman Origins” by Chris McEntee… …so we can talk about it.

PART 2: Rational Game Design The Problem: Many games, particularly large scale projects with many designers, have broken difficulty curves. Players are thrown into scenarios which are far beyond the skills they can be reasonably expected to have developed so far, get frustrated, and quit. Or they encounter many levels that are too easy, given the skills they have so far developed. Low Player Attachment: Instead of long engagement and positive reports, players stop playing and do not recommend the game to their friends, hurting sales.

Rational Game Design Given a graph of game difficulty over multiple levels…

Rational Game Design (in this case, six levels)

Rational Game Design This is a BAD difficulty curve, suddenly increasing.

Rational Game Design This is also BAD, going flat.

Rational Game Design This is closer to what we want– a gradual increase.

Rational Game Design Actually, we really want this– a sequence of greater challenges for the player, with opportunities to regroup after each peak.

Rational Game Design Each peak has four parts, where the player (1) Plans, (2) Executes, (3) has to improvise, and then gets to (4) loot the bodies.

Rational Game Design But for the purposes of this discussion, let’s stick with the straight line.

Rational Game Design Ubisoft’s system for managing difficulty curves in level design SUMMARY: RGD is a way to solve the problem of inconsistent / broken difficulty curves in games. RGD sees games in the most stripped-down way: as a series of mechanics, achieved through specific player input, to build skills. The analysis of mechanics and inputs provides a list of specific "Atomic" Parameters which can be tested in different combinations. These varied combinations are the "Patterns" on which levels are then built.

Rational Game Design TAKEAWAYS: The participant in this workshop should be able to: Identify Core Mechanics of gameplay (concept) and break a mechanic down to its Atomic Parameters based on Skills and Inputs (physical actions). Build a Difficulty Matrix (table) for a Mechanic’s Atomic Parameters, and design Level Scenarios based on their variation. Be able to design Patterns (level scenarios) based on variations on Ingredient (enemy or obstacle) parameters.

Rational Game Design Design levels by SUBTRACTING your Mechanics: A big failure of designers is to try and create variety by constantly ADDING new and more stuff. This spreads the player thin learning many new mechanics without ever delving deeply. Deep game and level design is achieved when the player can explore a few mechanics in great variation, by SUBTRACTING features. If you have a mechanic with 5 features, what happens when you turn off 4 at the start, and progress to all 5? Occasionally, turn off some, given the scenario, to focus on a deeper understanding of the others!

Rational Game Design: Failure Failure Case: “Avatar The Game,” Early level: alien dogs (big/powerful, running, jumping, biting your face) attack before player learns to target & shoot. Dogs jump in from all directions, moving everywhere. Player is lost!

Rational Game Design: Failure Failure Case: “Avatar The Game,” Early level: alien dogs (big, running, jumping, biting your face) attack before player learns to target & shoot. Dogs jump in from all directions, moving everywhere. Player is lost! QUESTION: Given the same enemy dog, how can the space of this intro level be re-designed for an easier encounter? CONSIDER: What about the design of the space in this scenario makes it too hard? In other words, what player skills are being tested to hard?

Rational Game Design: Failure Make the player safe on a raised/caged platform This reduces test for the timing skill– player has less urgency, can focus on aiming skill. The Avatar Game team did this, putting the player on a turret to defend their fellow human soldiers, but the chaos of the dogs coming from all directions, when the payer had not yet learned to aim or shoot well, made the level impossible for many players. When they show up later, make the same enemy harder to beat by removing the safety!

Rational Game Design: Failure Limit the space where the dogs can enter This reduces the test for the precision skill– reduces potential range dramatically. The dogs are just as big, powerful, and face-bity, but are easier to shoot because the range of space needed to cover is limited– shoot them as the get through the fence. Similarly, offer limited paths they can run through (boulders/ buildings). When the dogs show up later, make the same enemy harder to beat by offering more directions for their movement.

Rational Game Design: Learning Playing Requires Skills to Solve the Game Mechanics Gaming = Gaining Mastery of a set of Skills How do players learn and master these skills? Consider this Progression of Learning for skills: Tease (introduce the concept) Learn (in a safe environment) Practice (with increasing challenge, in varied scenarios) Master (final test, higher pressure scenario) This is the access cycle for each mechanic, which progresses difficulty by considering player growth. Once the player learns a skill, they can combine it with others.

Rational Game Design: Skills PLAYER SKILLS CATEGORIES: PHYSICAL: Precision, Timing, Reflexes, Measurement, Endurance, etc. ( we’ll see Mental and Social a bit later) ATOMIC PARAMETERS EXAMPLES (FROM DEVICE INPUT): Precision: Angle of Tolerance, Size on Screen Timing: Anticipation Time, Window of Opportunity (WoO), Obstacle Predictability, Input Change Frequency Measurement: Analogue Zone Size (physical joystick zone of tolerance), Analogue Zone Placement (Where joystick goes). RGD: What are easy, med, hard tests for each parameter?

Rational Game Design Quick example of parameter variation: FPS Enemy Motion You are introducing shooting of Ingredients (enemies) to your player. These enemy fighters can run side-to-side or directly at the player to stab you in the face. How is each case easier or harder for the player to “hit”? Why? What player skill is being challenged in these two scenarios? A level designer builds these different difficulty experiences into the spatial design of a sequence of ever-more challenging levels!

Rational Game Design Parameter example: Pokemon Go Hit Circle In addition to Monsters that jump, fly, and stand further or closer away, The Target Circle is the primary way the designers distinguish between enemy experiences. How do the target circle experiences differ to create easier and harder catches?

Rational Game Design Consider a mechanic: Aim-and-Shoot: Example of final game (Form): 1st person shooter, high-intensity alien bloodfest. Bare INPUTS for an FPS (Function): the skill of matching the position of two points (aiming) and validating (pulling the trigger and seeing the target react). Adjust Parameters on enemy access for different difficulty: Size of the target shape on Screen Movement Speed Predictability Window of Opportunity (WoO) etc.

Rational Game Design NOTE: For Size-On-Screen, ACTUAL enemy size is irrelevant! It could be a 12-inch scuttling monster running near your feet or a full 6-foot tall human sniper standing on a distant building. If both are 10% of the screen they are effectively the same thing in terms of Size on Screen!

Rational Game Design PLAYER SKILLS CATEGORIES: PHYSICAL: Timing, reflexes, measurement, precision, endurance, etc. MENTAL: Concentration, choice, observation, management, strategy, tactical, cleverness, etc. SOCIAL: Persuasion, leadership, etc. RGD Mental is harder to quantify than Physical (in terms of concrete progression of difficulty). WHY? What happens when the cost/benefit of a choice is too hard for players to decide? RGD Social challenges are enormously hard to manage. WHY? What happens when we provide social difficulty restrictions in games?

Remember to always distinguish between Form and Function: Rational Game Design Remember to always distinguish between Form and Function: Form = aesthetics/story Function = player skills, inputs, atomic parameters. For example what are the forms (Story) & functions (SKILLS) in G-d of War? In Assassins Creed?  

Rational Game Design The Deliverables for this process: IDENTIFY, IN ORDER: [1] Goal of Gameplay [2] Mechanic [3] Needed Skills [4] Inputs (informs a LOT of design decisions) [5] Atomic Parameters (list them, provide easy, medium, hard, and "no case" examples) [6] Level Design (LD) Patterns (overall easy, medium, and hard patterns based on parameter combinations, ideally with drawn diagrams, which can then be creatively interpreted as story-rich level scenarios)

Rational Game Design Level Design (LD) Patterns: Concrete LD situation extracted from Atomic Parameters Allows us to create difficulty with a limited amount of well-conceived ingredients (enemies or obstacles). Create LD patterns (variations) for each mechanic separately-- their combination is the level! ATOMIC PARAMETERS MUST be quantifiable (no case, easy, medium, hard) and validated through playtesting! THE VALUE OF THIS PROCESS: If you know your atomic parameters, you know what your changes will do to your game, and, especially, you can keep all elements within your desired boundary of difficulty!

Rational Game Design TIPS FOR ATOMIC PARAMETER SELECTION: Set Atomic Parameters to FOCUS your game. Remove those you don't want to challenge, and set as constant those you don’t want to evolve. Isolate Atomic Parameters for each Mechanic. Think Skills and Inputs. Eliminate minor Atomic Parameters.

Rational Game Design EXAMPLE #1: Gameplay = Driving What is the mechanic? What are the Ingredients (enemies or obstacles)? What are the Skills (how does the mechanic work)? What device inputs are needed to achieve each skill? For each skill, what is/are the Atomic Parameters (what are the physical inputs, especially to manage encounters with the Ingredients)?

Rational Game Design EXAMPLE #1: Gameplay = Driving 1. Mechanic = Steering 2. Ingredients = Objects in the Road, Other Cars, Turns 4. Inputs = assume Joystick 3. SKILLS        5. ATOMIC PARAMETERS Precision     Angle of Tolerance Timing         Anticipation Time                     Window of Opportunity (WoO)                     Obstacle Predictability

Rational Game Design EXAMPLE #1: Gameplay = Driving 3. SKILLS        5. ATOMIC PARAMETERS Precision     Angle of Tolerance Timing         Anticipation Time                     Window of Opportunity (WoO)                     Obstacle Predictability Next: Input test cases for each parameter: the easy, medium, hard, and no-test case. What are the tests for Anticipation time? 6. FINALLY, pull out combinations of parameters and design levels!

Rational Game Design EXAMPLE #1: Gameplay = Driving THE CHART: [5] Atomic Parameters:            | No Case | Easy | Medium | Hard | PRECISION:  Angle of Tolerance (joy): | | loose | medium | exact | TIMING: WoO:                 | always open | long | medium | short | Predictability (pattern):  | no change | slow/repeating | intricate | no pattern| Anticipation Time     | | far away | medium | close/sudden | [6] LD Patterns: Variations of the above! A non-WoO with easy Predictability could be two cars in front of the player, moving in tandem slowly back and forth across the screen, so there is always an opportunity to pass them, but the player has to predict where the opening will move. To get a good difficulty curve, start with a level that only tests one parameters, set easy, while limiting the others. For a racing game example, start alone on the road and just test for player precision with shallow turns. Then make harder turns, then introduce a super-predictable car. Then introduce a harder-to-predict car. Then two cars. Then a car that jumps in front of the player for harder anticipation time, etc. The chart lets us see exactly what we are testing for!

Rational Game Design EXAMPLE #2: Nintendo Archery: Gameplay = shooting Core Mechanic = aim + shoot The Ingredients = wind, Swinging objects, etc 4. Skills: Players progress their skills through varied Ingredient Patterns: Hit Unimpeded Goal = PRECISION skill Wind/Swinging Objects = TIMING skill Then make harder tests of these skills with varied swinging times, size, etc

Rational Game Design EXAMPLE #3: 3rd person shooter, like Gears of War: Gameplay = Combat Core Mechanic = Point and shoot The Ingredients = enemy NPCs, explosive objects Skills = PRECISION to coincide Xs and TIMING to match at the right time

Rational Game Design EXAMPLE #4: Stealth mechanic (like in Splinter Cell): [1] Goal of Gameplay: [2] Mechanic: [3] Skills: [4] Inputs: [5] Atomic Parameters:               | No Case | Easy | Medium | Hard | [6] LD Patterns: Variations of the above!

Rational Game Design EXAMPLE #4: Stealth mechanic (like in Splinter Cell): [1] Goal of Gameplay: Reach destination without being detected [2] Mechanic: Move character and/or camera [3] Skills: Timing, Precision, Measurement (not Observation-- mental!) [4] Inputs: Move the joysticks with your thumbs [5] Atomic Parameters:               | No Case | Easy | Medium | Hard | PRECISION:  TIMING: MEASUREMENT: [6] LD Patterns: Variations of the above!

Rational Game Design EXAMPLE #4: Stealth mechanic (like in Splinter Cell): [1] Goal of Gameplay: Reach destination without being detected [2] Mechanic: Move character and/or camera [3] Skills: Timing, Precision, Measurement (not Observation-- mental!) [4] Inputs: Move the joysticks with your thumbs [5] Atomic Parameters:               | No Case | Easy | Medium | Hard | PRECISION:  Analogue (Joystick) Angle of Tolerance (direction): | loose angles | medium | exact | TIMING: WoO:                 | | long | medium | short | Predictability:   | camera | guard, repeating pattern | long/intricate or no pattern | Anticipation Time     | far away | medium | very close/sudden | Input Change Frequency  | no change | 1 input/sec | 3 input/sec| 5 in/sec | MEASUREMENT (stick massaging): Analogue Zone Size (physical zone of tolerance) |80% |40% |10% | Analogue Zone Placement (where joystick goes)  |0/100% (ends)|50% (mid)|25 or 75%| [6] LD Patterns: Variations of the above!

Rational Game Design NOTES: INPUTS AND PARAMETERS Measurement on a keyboard = timing A hard WoO (window of opportunity) means only occasionally available to hit: using cover or moving/rotating shielding elements. Anticipation Time in a rhythm game starts Physical, but as the game gets harder and the player more skilled, they learn the song and offload the work to the Mental Button mashing: frequency of input and duration of input (G-d of War)

Rational Game Design : Group Design And Now The Fun: We can examine an Ingredient (enemy/ obstacle) as a set of characteristics, and then consider the Atomic Parameters that would allow us to get varied Patterns (gameplay scenarios): INGREDIENT-TO-LEVEL EXAMPLE: Consider this Enemy Character, all Atomic Parameters easy by default: ENEMY [Ingredient characteristics]: Size = big (easy) Speed = slow (easy) Predictability = very (easy) WoO = always (easy) Hit Points = low (easy) DISCUSS: WHAT IS THIS ENEMY? (lots of possibilities!)

Rational Game Design : Group Design ENEMY [Ingredient characteristics]: Size = big (easy) Speed = slow (easy) Predictability = very (easy) WoO = always (easy) Hit Points = low (easy) A Couple Possibilities That Fit These Characteristics:

Rational Game Design : Group Design INGREDIENT-TO-LEVEL EXAMPLE: NOW, create level scenarios for these Parameter Variation scenarios Don’t change the ingredient– change the encounter scenario!: [Ingredient characteristics]   [Atomic Parameters] ENEMY [TEAM A] [TEAM B] Size = big Size on Screen: medium hard Delta Position on Screen: easy (centered) hard (edges) Speed = slow Speed on Screen: easy hard Predictability = very Predictability: easy hard WoO = always WoO: hard easy Hit Points = low An enemy with the characteristics on the left can be used in multiple levels with various combinations from the right!

Rational Game Design SUMMARY: Don’t create lots of new monsters -- create variations of access by changing the space where we encounter those monsters!  The big idea here is to avoid constantly adding new mechanics to make the game “more interesting,” but instead to allow a player to learn a few core mechanics more deeply through spatial variation that limits what the few ingredients can do. In other words, when doing level designs, instead of constantly adding new Monsters, design level spaces and scenarios that allow the same monsters to be presented where they function differently, by limiting what the monster can do. Change the level to change the way the same monsters work, making them ever more challenging as these spatial restrictions are lifted in progressive levels!

Rational Game Design FIXING A GAME WITH RGD: In addition to designing a game’s level sequence using this system, you can also FIX an existing design with RGD! For example, if you have to cancel level #6, levels 5 and 7 are screwed (in terms of difficulty curve) unless you go back to the matrix of mechanic parameters and tweak them together to fill the gap! (see following images)

Rational Game Design Here again is our graph of game difficulty over levels 3-8

Rational Game Design TRAGEDY! Your team has been told to cut level 6!

Rational Game Design And now there is a huge challenge jump from levels 5 to 7.

Rational Game Design THE SOLUTION: Go back to your RGD chart to make the test of some parameters in level 5 a bit harder, and the test for some parameters in level 7 a bit easer, to smooth out your difficulty curve.

Try this system and make better Difficulty Curves! Rational Game Design Try this system and make better Difficulty Curves!

Production Scheduling: Course Milestones Due Week 8: Paper Prototypes: “Fun” Due Week 9: Digital Prototypes: “Quantity.” Due Week 11: Full Playable Prototypes: “User Clarity.” Due Week 12: Revised prototypes: “Fun.” Due Week 14: Prototype Complete: Multiple levels populated, bugs fixed, full Art and Audio. Final Presentations: Playable Game and Marketing materials: Trailer, Website, Press Release, Icon.

PART 3: Mid-Project Peer Evaluation (Due by email next class) Download file for your team-size from the website (based on BU Executive MBA project peer evaluation system). Fill out text evaluation for ALL team member before assigning any final score points to anyone. NOTE 1: Any score distribution out of your available points total is acceptable EXCEPT awarding equal amounts to any team members: All scores must be different. WHY? NOTE 2: Evals will not be shared by teacher with team members, but you should use this document as an opportunity to reach out to each other and discuss issues! NOTE 3: This is a chance to consider how you are doing as a teammate on this project, and how you might want to do better in the last remaining weeks!

Due Next Week: HOMEWORK #11: A FUN Game: 4th Digital Prototype with revised play, more levels, some more art, & audio TEAMS: Divide Unity/Art/Audio production equitably, and submit your content in time to get into the weekly build. Meet with your team at least once outside of class to discuss progress, solve problems, and consolidate build. Test clarity with at least two NEW players. Submit fourth digital build to class next week. Individually: Progress Report #4: Submit typed pargraph: What you agreed to produce, what you accomplished, self-evaluation and related screenshots.

Have an Phenomenal Week! And don’t forget to email us with questions: Instructor: JASON WISER JasonWiserArt@gmail.com Available an hour after class and daily email.