Chapter 5 Exercises: Game Mechanics

Exercise 1: Verb Decomposition

Type: Analytical
Time: 25-30 minutes
Deliverable: Verb tables for three games

Choose three games you have played for at least ten hours each. For each game, create a table with four columns: Verb | Primary/Secondary/Progression | Category (Avatar/Object/System) | How Often Used.

List every verb the player can perform. Be specific. Do not write "fight" --- write "light attack, heavy attack, dodge, block, parry, use ability." Do not write "explore" --- write "walk, run, jump, climb, swim, open map, fast travel."

After completing all three tables:

1. Count the total verbs for each game. Which game has the most? Which has the fewest? Is there a correlation between verb count and your enjoyment of the game?
2. For each game, identify the single primary mechanic. Write the One Mechanic Test sentence (one sentence describing what the player does most).
3. Identify one verb in each game that could be removed without significantly changing the experience. Why does it survive? Is it there for variety, for a specific moment, or because no one thought to cut it?
4. Identify one pair of verbs in each game that interact with each other in a way that produces depth. Describe the interaction and why it creates more interesting gameplay than either verb alone.

What this teaches you: Verb decomposition is the most fundamental analytical tool in game design. Once you can see games as collections of verbs, you can evaluate, compare, and design mechanics with precision.

Exercise 2: Implement the Attack Mechanic

Type: Implementation
Time: 45-60 minutes
Deliverable: Working Player.gd with attack state

If you have not already completed the progressive project from Section 5.14, do so now. Implement the full Player.gd from Section 5.12 with:

• Eight-directional movement using get_axis()
• State machine with IDLE, RUN, and ATTACK states
• Sprite flipping based on horizontal movement direction
• Attack action with commitment window (0.3 seconds default)
• AttackArea using Area2D for hit detection

Once the basic implementation is working, experiment with the following tuning parameters and document how each change affects the feel:

1. Speed: Try 100, 200, 300, and 400 pixels per second. At what speed does the character feel sluggish? At what speed do you lose control? What is the sweet spot for your game's intended feel?
2. Attack duration: Try 0.15, 0.3, 0.5, and 0.8 seconds. How does lengthening the commitment window change the risk-reward calculation of attacking? At what point does the attack feel punishing rather than weighty?
3. AttackArea size: Try a small hitbox (32x32 pixels), a medium hitbox (64x32), and a large hitbox (96x48). How does the hitbox size affect difficulty? How does it change whether the player needs to aim precisely or can attack loosely?

Write a half-page reflection on what you learned about tuning. Which parameter had the biggest impact on feel? How would you describe the difference between "responsive" and "spammable"?

Additional experimentation (optional but recommended):

4. Diagonal speed normalization: Temporarily remove the .normalized() call from get_input(). Move diagonally. Notice that diagonal movement is approximately 41% faster than cardinal movement (because the diagonal of a unit square is ~1.414). Put the normalization back. This is why every professional game normalizes diagonal input --- without it, players who discover the speed advantage will move diagonally whenever possible, which looks ridiculous and breaks encounter balance.

5. Attack cooldown: Add a cooldown timer that prevents attacking again for 0.5 seconds after the attack ends. How does the cooldown change the rhythm of play? Does it feel protective (preventing spam) or restrictive (preventing expression)?

What this teaches you: Game feel is not determined by code architecture or clever algorithms. It is determined by numbers --- speed values, duration values, collision sizes, cooldown timers. The difference between a mechanic that feels "perfect" and a mechanic that feels "off" is often a single parameter adjusted by 20%. Tuning is the least glamorous and most important skill in mechanic design.

Exercise 3: The One Mechanic Paper Prototype

Type: Design / Prototyping
Time: 30-40 minutes
Deliverable: Paper prototype and playtest notes

Design and build a paper prototype of a game with exactly one mechanic. Not one type of mechanic --- one verb. The player can do one thing, and the entire game is about doing that one thing in different contexts.

Materials: index cards, paper, dice (optional), a pen, and one other person to playtest with.

Constraints: - Exactly one verb. If the player can do two things, you have too many mechanics. - At least three "levels" or scenarios that use the single mechanic in different ways. - A win condition and a lose condition. - Playable in under five minutes per session.

Examples to inspire (but do not copy): - A game where the only verb is "flip" (flip cards, flip tiles, flip switches --- one verb, many applications) - A game where the only verb is "choose" (binary choices with cascading consequences) - A game where the only verb is "place" (place tokens on a grid to create patterns, block opponents, or claim territory)

After building the prototype: 1. Playtest it with another person. Watch them play. Do not explain rules that are not written down. 2. Note: Did they understand the one mechanic immediately? Did they find variety in the single verb, or did it feel repetitive? At what point (if ever) did they get bored? 3. Write a half-page reflection: What makes a single mechanic sustain interest? What did you learn about the relationship between simplicity and depth?

What this teaches you: The constraint of one mechanic forces you to find depth within a single interaction. This is the purest form of mechanic design --- no secondary systems to compensate for a weak core.

Exercise 4: Mechanic Taxonomy Classification

Type: Analytical
Time: 20-25 minutes
Deliverable: Classification table with analysis

Choose a complex game --- one with at least fifteen distinct mechanics. RPGs, open-world action games, survival games, and strategy games work well.

Create a table with columns: Mechanic | Category (Avatar/Object/System) | Subcategory (Movement/Combat/Item/Resource/Physics/Economy/Progression/Social/Information).

Classify every mechanic you can identify. Then answer:

1. What is the dominant category? Is the game avatar-heavy, object-heavy, or system-heavy?
2. Which subcategories are absent or underrepresented? What does that tell you about the game's design priorities?
3. Are there mechanics that do not fit cleanly into one category? What makes them ambiguous? (Ambiguous mechanics are often the most interesting --- they sit at the intersection of multiple systems.)
4. If you had to cut one mechanic from each category, which would you cut and why? What would the game lose? What might it gain in focus?

What this teaches you: Classifying mechanics forces you to see the structure of a game's design, not just its surface. Two games can feel completely different while having similar mechanical profiles, or feel similar while having radically different profiles. The taxonomy is a diagnostic tool --- it tells you where the game's design weight is concentrated and where there might be opportunities or redundancies.

Exercise 5: Mechanic Clarity Audit

Type: Analytical / Experiential
Time: 30-40 minutes
Deliverable: Clarity audit report

Choose a game you have at least moderate experience with. Evaluate its primary mechanic across the three dimensions of mechanic clarity:

Discoverability: How does the game teach the player that this mechanic exists? Is it introduced through a tutorial, through environmental design, through a tooltip, or through trial-and-error? Play the first fifteen minutes and note every moment where a mechanic is introduced. Rate each introduction: Clear (player immediately understands), Adequate (player figures it out within a minute), Confusing (player needs multiple attempts or external help).

Legibility: Choose five instances of the primary mechanic being performed. For each, list every piece of feedback the game provides: visual effects, sound effects, screen movement, UI changes, animation changes, haptic feedback (if applicable). How many feedback channels are active simultaneously? Is the feedback sufficient to understand what happened, or is information missing?

Predictability: Before performing the primary mechanic five times in different situations, predict the outcome. After performing it, evaluate: were you correct? If not, was the unpredictability the result of a learnable system (you will predict correctly with more experience) or an opaque system (the outcome seems arbitrary regardless of experience)?

Write a one-page audit report with a clarity score for each dimension (Strong / Adequate / Weak) and one specific, implementable improvement for the weakest dimension.

Stretch: Repeat this audit for your own progressive project. Score the attack mechanic you implemented in this chapter across all three dimensions. Be ruthlessly honest. If your attack lacks visual feedback (legibility), add it before moving to Chapter 6. If the attack area is unclear (predictability), adjust the hitbox visualization. If the player would not know they could attack without reading the controls (discoverability), consider how to communicate the mechanic through design.

What this teaches you: Mechanic clarity is the invisible infrastructure of good design. A brilliant mechanic that the player cannot find, cannot read, or cannot predict is functionally identical to a bad mechanic --- the player will never appreciate it.

Exercise 6: Meaning Through Mechanics

Type: Analytical / Reflective
Time: 25-30 minutes
Deliverable: Comparative analysis (1 page)

Choose a single mechanic verb --- "shoot," "build," "collect," "jump," or "trade" --- and find three games that use that verb. For each game, analyze:

1. What does this verb mean in this game? What feeling, fantasy, or message does it communicate?
2. What surrounding systems (narrative, economy, progression, aesthetics) give the verb its meaning?
3. If you transplanted this mechanic from one game into another (e.g., Minecraft's block placement into Tetris's context), how would the meaning change?

Write a one-page analysis arguing: "The same mechanic can carry completely different meanings depending on the system it operates within." Use your three examples as evidence.

What this teaches you: Mechanics are not meaning-neutral. The verb does not carry inherent significance --- the system gives it significance. This insight is critical for narrative design (Chapter 20) and ethical design (Chapter 33).

Exercise 7: Mechanic Interaction Map

Type: Design thinking
Time: 30-35 minutes
Deliverable: Interaction diagram with analysis

Choose a game with five to ten mechanics that interact with each other. Draw an interaction map:

• Write each mechanic in a circle.
• Draw a line between every pair of mechanics that interact (i.e., performing one affects or is affected by the other).
• Label each line with a brief description of the interaction.

After completing the map:

1. Which mechanic has the most connections? This is likely the game's most important mechanic, even if it is not the most dramatic. Why does high connectivity matter?
2. Are there any mechanics with zero or one connection? These are siloed mechanics --- they exist independently from the rest of the system. Are they justified (they serve a unique purpose) or unnecessary (they could be removed without loss)?
3. Identify the single most interesting interaction (the line that creates the most emergent gameplay). What makes it interesting? Could the game exist without it?
4. If you could add one new mechanic to this system, what would it be and what connections would it create? Draw it into the map. Does it increase depth proportionally to the complexity it adds?

What this teaches you: Interaction maps make invisible relationships visible. Most designers know intuitively that their mechanics interact, but they cannot articulate which interactions matter and which mechanics are isolated. The map turns intuition into evidence. You will use this technique again in Chapter 9 (Emergence) and Chapter 24 (Game Economy Design), where mechanic interactions become the primary design challenge.

Exercise 8: The Mechanic Removal Test

Type: Design thinking
Time: 20-25 minutes
Deliverable: Removal analysis (1 page)

Choose a game you know well. List its five most prominent mechanics. Now, for each mechanic, imagine removing it entirely. The game ships without it. Everything else stays the same.

For each removal, answer:

1. What would the game lose? What specific moments, challenges, or experiences would disappear?
2. What would the game gain? (Be honest --- removal almost always reduces complexity, which has value. Fewer mechanics means a tighter learning curve, clearer identity, and easier balancing.)
3. Would the game still be recognizably itself? If not, this mechanic is likely core to the game's identity.
4. Would the game be worse? (This is a different question. A game can lose part of its identity and still be good --- possibly even better.)

After completing all five removals, rank the mechanics from "most essential" (the game collapses without it) to "most removable" (the game barely changes). What does this ranking tell you about the game's true core?

What this teaches you: The removal test reveals which mechanics are load-bearing and which are decorative. It is a tool you should apply to your own projects regularly. If a mechanic survives removal without significant loss, it might not deserve the development time, testing effort, and cognitive load it imposes.

Exercise 9: Mechanic Feel Vocabulary

Type: Experiential / Reflective
Time: 25-30 minutes
Deliverable: Vocabulary list with examples

Play five different games for five minutes each, focusing exclusively on how the primary mechanic feels. Not whether you enjoy the game. Not whether it is well-designed. How does the act of performing the mechanic feel in your hands?

For each game, write three adjectives that describe the feel of the primary mechanic. Do not use "good," "bad," "fun," or "boring" --- these are evaluation words, not feel words. Use sensory and tactile vocabulary:

• Weighty, floaty, snappy, sluggish, crisp, loose, tight, slippery
• Punchy, soft, crunchy, smooth, sharp, blunt, heavy, light
• Responsive, laggy, committed, cancellable, rhythmic, chaotic
• Precise, forgiving, generous, demanding, satisfying, hollow

After completing all five, compare your adjective lists. Are there patterns? Do you gravitate toward games that feel "snappy and precise" or "weighty and committed"? How does your preference relate to the games you naturally enjoy?

Now take one game from your list and try to identify what creates the feel. If a mechanic feels "weighty," is that because there is a slow wind-up animation? A screen shake on impact? A long commitment window? A delay between input and action? Try to map each adjective to a specific design decision --- an animation length, a particle effect, a sound design choice, a timing parameter. The goal is to move from describing feel to engineering feel.

Write one paragraph about what you learned: What is the difference between a mechanic that feels "good" and a mechanic that feels "bad"? Can you describe that difference without using the words "good" and "bad"?

What this teaches you: Developing a precise vocabulary for game feel is one of the most valuable skills a designer can have. "The jump feels floaty and imprecise" is actionable feedback. "The jump feels bad" is not. Professional designers communicate in feel vocabulary constantly --- in meetings, in playtest reports, in design documents. The sooner you develop this vocabulary, the sooner you can participate in those conversations as an equal.

Exercise 10: Design a Mechanic From a Fantasy

Type: Design challenge
Time: 35-40 minutes
Deliverable: Mechanic specification document (1 page)

Start with a player fantasy, not a mechanic. Choose one from the list below:

• The fantasy of being a master thief
• The fantasy of commanding an army
• The fantasy of surviving alone in the wilderness
• The fantasy of growing a garden from nothing to paradise
• The fantasy of being the fastest thing alive

Design a single primary mechanic that delivers this fantasy. Your specification must include:

1. The verb: One word that describes the core action
2. Input: What does the player press, click, or gesture?
3. Rule: What determines the outcome? What variables affect success or failure?
4. Output: What changes in the game state? What feedback does the player receive?
5. Variable expression: How can two players performing the same mechanic produce different results? What dimension of skill, timing, or choice creates expression within the mechanic?
6. Why it delivers the fantasy: Explain, in two or three sentences, why performing this specific action would make the player feel the specified fantasy

Do not design the game around the mechanic. Do not add secondary mechanics, progression systems, or levels. Design one verb that, in isolation, captures the essence of the fantasy.

The constraint is critical. You are not designing a game. You are designing a single interaction that, when performed, makes the player feel something specific. If you cannot achieve the fantasy with one verb, the fantasy might be too broad (narrow it), or you might be confusing the fantasy with the context (the fantasy is what the player feels, not what the game looks like).

Stretch: Implement a bare-bones prototype of your mechanic in Godot. Empty room, placeholder art, one verb. Does it feel like the fantasy? If not, what is missing --- and is the missing element a tuning problem (the mechanic needs adjustment) or a context problem (the mechanic needs surrounding systems to deliver the fantasy)?

What this teaches you: Starting from fantasy rather than mechanic reverses the typical design process. Most beginners start with "what if the player could..." and then try to make it fun. Starting with "what should the player feel?" and then designing the mechanic to deliver that feeling produces more focused, more emotionally resonant mechanics.

Exercise 11: Primary Mechanic Swap

Type: Design thinking
Time: 20-25 minutes
Deliverable: Redesign document (1 page)

Choose a game you know well. Replace its primary mechanic with the primary mechanic of a completely different game. Everything else stays the same: the setting, the narrative, the visual style, the progression system, the secondary mechanics.

Examples: - Dark Souls with Tetris's primary mechanic (rotate and place blocks instead of attack and dodge) - Minecraft with Guitar Hero's primary mechanic (hit notes in rhythm instead of place and break blocks) - Stardew Valley with Slay the Spire's primary mechanic (play cards instead of plant crops)

For the transplant you chose:

1. What changes about the game's identity? What is preserved?
2. What secondary mechanics become irrelevant (they only existed to support the original primary mechanic)?
3. What new secondary mechanics would you need to add to support the new primary mechanic?
4. Is the resulting game interesting? Could you imagine someone wanting to play it? If so, you may have accidentally designed something genuinely novel.

What this teaches you: The primary mechanic is not just a part of the game --- it is the anchor around which everything else is organized. Changing it cascades through every other system, revealing hidden dependencies and assumptions.

Exercise 12: Comparative Mechanic Analysis

Type: Analytical
Time: 30-40 minutes
Deliverable: Comparison table and analysis (1.5 pages)

Choose two games in the same genre that implement the same primary mechanic differently. Strong pairs include:

• Dark Souls vs. Devil May Cry (melee combat)
• Super Mario Bros. vs. Celeste (platforming/jumping)
• Civilization vs. Age of Empires (strategy/building)
• Minecraft vs. Terraria (block placement/world manipulation)
• Slay the Spire vs. Hearthstone (card play)

Create a comparison table with rows for:

After completing the table, write a one-page analysis:

1. Both games use the same primary verb. What makes the feel different?
2. Which game gives the player more expression within the primary mechanic? How?
3. Which game has higher commitment (more consequence for each use of the mechanic)? How does that affect the pacing and decision-making?
4. What is the single most important design decision that differentiates how these two games implement the same mechanic? If you could change one parameter in Game A to make it feel more like Game B, which parameter would you change?

What this teaches you: Two games can use the same verb and produce completely different experiences through differences in timing, commitment, feedback, and expression. This exercise trains you to see mechanics not as verbs (jump, attack, build) but as implementations of verbs --- specific configurations of parameters that produce specific feelings. Understanding this distinction is the difference between "my game has combat" and "my game has combat that feels like this."