5 Progressions

[Source: Gamasutra]

Progression #1: Game MEchanics

Keeps the player from getting overwhelmed early into the game, e.g. imagine if a new Zelda player had access to the entire inventory!

Gated Access to mechanics until later in game when they unlock.

Directed Gameplay: zero gating, but missions/levels/quests only require a gradually broadening degree of that possibility space.

Option A

Option B

Progression #2: Mission Duration

Harder enemies, longer distances, or harsher penalties (e.g. deaths/checkpoints) that gradually elongate the experience.

Environment progression (scripted action events, landmarks, and vistas with scaling intensity) as well as trophies/medals.

(i.e. ancillary here = outside the realm of gameplay.)

Progression #4: Practical REwards

Most effective way to retain players: give them rewards pertinent to the gameplay loop.

That said...

• Players need to transparently understand this reward system, i.e. when rewards come (automatically or otherwise) and at what price (if any).
• Players should glimpse future rewards to anticipate and keep [re]playing toward them.

The best rate: appear initially fast with a few nice rewards very soon after starting the game, and then grow slower with time (e.g. XP bar design).

Don't forget to add your notes!

The final type is simply a difficulty/risk curve. However, gameplay progression IS NOT difficulty progression. Instead, it's the structuring (PACING!) of game mechanics, mission duration/deaths, gameplay/audiovisual rewards, and difficulty/risk so as not to overwhelm nor underwhelm players with too much/little for them to continue playing. (cf. "Beat Charts" in Level Up! and Scrapped)

Bottom-Up Design

[Source: Jordan Amaro (Splatoon, MGS5, RE7)]

"As you say, the basic mechanics (movement) need to feel good first. That’s the game by default: a character running in a huge test scene that is essentially an obstacle course. Some call this CCC (Camera, controls, character). No rules yet, no enemies, no interactive objects. Once the character responds well to movement, and you have a few traversal actions, you can increase complexity."

(From Stormbreaker, we likewise learned that it helps to have 2+ traversal actions.)

Step 1: Build Blueboxes

Step 2: Build Interaction Loop
=
"Interesting Situation" PrefabS

=

Encounter design

"not being manipulated or coerced, but self-initiated" (hurt by in-game deadlines, extrinsic rewards, and contrived restrictions).

"wanting to interact with, be connected to, and/or experience caring for others" (e.g. in-game pets).

"having mastered something" (i.e. knowing the outcomes of your actions in advance -- and being correct -- efficacy).

Autonomy

Competence

Relatedness

• Tease with anticipatory play!
• Learn ⇄ Practice ⇄ Master: instantiating an Interaction Loop / Interesting Situation template-prefab may take more than one form of RGD micro-challenge type!
• Use the pacing breathers from Platinum Games #'s talk!

Step 3: Build Progression Loop
=
Levels/Areas Beat Chart

Don't forget to add your notes!

Skill Atoms

1. Look for the Action the player performs.
2. Look for the Skill(s) they are learning, conceptual (e.g. map navigation) or physical (e.g. attacking with a weapon).
3. Look for the +/- Feedback in the game.

"To imagine that you can jot down a design for skill atoms out of your head and that you’ll have created a great game before it is built is foolish. Instead, you accumulate skill atoms through iterative building, testing and watching players interact with a system. With the complex simulations (even Tetris!) at the heart of most games, it is difficult to predict what skills are valuable UNTIL YOU PLAY. The good designer observes what behaviors are interesting and then codifies them with feedback systems so that they are accessible by and interesting to more people." ~ DanC

Don't forget to add your notes!

A slightly looser way to think of this is in terms of a game's "possibility space" -- but with skills.

        Layer 5: Whole Game Recording
        Layer 4: One Level's Recording
        Layer 3: One "Mission Element" Recording
            Razor tool'd per level chunks (or to a cutscene).
            Corresponds to how we plan long-term while playing.
            Reduces to getting through a section of the level.
        Layer 2: One "Input Element" Recording
            Reduces to meeting a specific task in the section.
        Layer 1: One "Primary Element" (Ludeme) Recording
            Each represents a single conscious player input/interaction.
            These are the atoms of gameplay (and to me, the control table).
            - Action-Adventure: move, turn, jump, attack.
            - Mouse-Driven RPG: select item, drag item into inventory, apply XP to an attribute.
            - FPS: reload, fire, open door, duck, melee.

Origins: Ben Cousins' "Primary Elements"

        PEs group into encounters group into levels group into the game.
            And it's more important to nail the layers bottom-to-top.
                The lowermost atomics should be inherently enjoyed!
            On principle that you'll do lower layers the most # times.
            In terms of reward structure (FINISH ARTICLE!),
                The top and bottom get good feedback...
                But the middle layers are curiously neglected.
            Noted well-polished atomics can go unnoticed, being so small.
        Noted how Cousins's Sunshine breakdown mirrors Cook's atom tests.
            - Which primary elements were involved most/least frequently?
                - Helps you nail the most frequently used first.
                - i.e. Helps discern the most important elements.
            - Save Strategy: How many PEs occur b/t [auto-]save points?
            - Death: How many PEs occur b/t deaths?
                - Does it reflect an expected difficulty curve?
            - Camera: How many PEs occur b/t camera adjusts?
                - Is this better/worse than competing titles?
                - Though this could be an issue with failing worse.

Escalating Why vs. Escalating What

Always consider the what [is the player doing] and the why [are they doing it] -- most games escalate the what, but Oxenfree went with escalating the why while keeping the what consistently to conversation--and making dialogue be an ability, not a menu. Makes me think of a TV mystery show (Lost, Gravity Falls) where the cast isn't often changing/scaling their tools or powers, many remaining normal humans -- but the dramatic stakes grow.

Don't forget to add your notes!

Kishotenketsu Level Design

• Ki = The Setup (Introduction)
• Sho = The Everyday (Development)
• Ten = The Confrontation (Turn)
• Ketsu = The Resolution (Conclusion)

Source In Level Design

Source In Level Design - Evolved

Don't forget to add your notes!

Expressive Level Design

Source

Level Design Job #1: "using LD tools expressively" (in the sense of making the world and characters more expressive).

 

Level Design Job #2: "making soup" out of existing art/code ingredients (so, kitbashing). This is NOT building gameplay systems in scripting -- the point is to not get that costly, and to add some flavor outside the core verbs (not upstage them).

What's "expressive" level design?

Step 1: Look at each area and ask "do its interactions feel human? Does it have any human interactions, and if not, how can I add them?"

 

Step 2: Inhabit the character portrayed--and your player--then let them express using...

Soup Recipe

An LD's Utility Belt for Building Expressive, Self-Contained Spaces

0. OnTriggerEntered(AABB) -> IsPlayer? -> PlaySoundAttached

1. Delay: helpful to mimic forms of acting (pausing in thought, timing a joke/score) for narrative designers!

2. The Line of Sight (LoS):

- Param: active % of screen center considered "inside" LoS.

- Param: trigger distance.

- Param: On Begin/End Overlap.

- Toggle Enabled/Disabled (e.g. during cinematics)

3. Build Triggers with "Hysteresis" -- not binary thresholds, but a set of inner-radius (turn on) and outer-radius (turn off). This e.g. keeps a light trigger from constantly being walked on-off-on-off.

4. Expose your state variables to design, e.g. bools for every objective--allows the game to react to the player's actions better!

Don't forget to add your notes!

The Nuance of Juice

Source

There's the common understanding of "juicing" a game, and there's its more general form: improving an "impression" of a feeling perceived by players during your game.

 

Confer the MDA framework's argument that players get to Aesthetics through Mechanics. But noted that for juice, it's not just "emotion" in general--instead, juice focuses on what's conveyed by the Physical/Tactile aspect of a game's mechanics (interactions and feedback).

"Just Add Camera Shake", right?

This applies on a "local" PER-ENTITY level of granularity: every game object and component.

This is why "just add camera shake" is NOT sufficient to know how to juice a game -- that "juicy" level of polish must serve your pillars!

Don't forget to add your notes!

Rational Game Design

(Just the micro-challenges for now!)

Physical Micro-Challenges

• Timing
• Reflexes
• Precision
• Measure

This affords twitchy games, but does not have to if tolerance softens. This is also what the “not interested in the solution’s execution being the challenge, and figuring out the solution being easy” bit of Anti-chamber’s Alexander Bruce’s GDC talk minimizes.

Mental Micro-Challenges

These do all seem generally slower in pace than Physical.

Social Micro-Challenges

•    Synchronization: seems like a social evolution of Timing.
•    Communication
•    Cooperation

This is typically either through multiplayer or with AI.

RGD 101

1. Mechanics defined as player inputs to overcome micro-challenges. RGD showcases mechanics in a skill-input matrix.
2. Ingredients as game elements testing users on mechanics.
3. Rational Game Design = challenge-to-challenge contrasts. 4. Rational Level Design = dial a specific challenge's params, e.g. that a linear ⬆ of a param  => exponential ⬆ of a difficulty.

Don't forget to add your notes!

The 3 Loops of System-Sense

The 3 Loop Types

• Economies = "reinforcing by exchanging resources"
• Ecologies = "balancing by exchanging resources"
• Engines = "reinforcing/balancing with the same resource"

From the Sellers book on systems design, as a preface for SYSTEM-SENSE, i.e. working with gameplay rules the way designers do: "This almost feels like a book that's systems-thinking first and actually game-design second, when it says making games are the best way for people (esp. the designers) to consider their own ways of systems-thinking (i.e. metacognition). //With the higher goal, it almost seems like, of helping designers then recognize similar systems operating in other aspects of life (making me think Miyamoto, and probably cycling back and forth between those and the ones in their games). With the example in CH1 of how selling a real house parallels selling rares in WoW's Auction House."

Don't forget to add your notes!

Primary, SEcondary, & Tertiary Loops

Don't forget to add your notes!

Gameplay as Exploring Possibility

Possibility space is...

"the scope of actions or reactions a player can undertake."

The constraints and ranges available to the player in terms of the mechanics (and metrics!) afforded to to their avatar or other interface with the game.

Games usually start at a well-defined state (the setup in chess, for instance) and end when a specific state is reached (the king is checkmated). Players navigate this possibility space by their choices and actions; every player's path is unique.

Don't forget to add your notes!