Chapter 7 Exercises: Rules, Constraints, and Freedom
Exercise 1: Rule Layer Decomposition
Type: Analytical
Time: 40-50 minutes
Deliverable: Three-layer rule analysis for three games
Choose three games you know well. For each game, identify and write out the three layers of rules:
-
Constitutive rules (3-5 examples). These are the abstract, mathematical rules that run under the hood. What does the code calculate? What are the hidden formulas? Examples: "Damage = base_attack * weapon_multiplier - enemy_defense." "The board is a 19x19 grid where stones are placed on intersections." You may need to research or infer these --- that is part of the exercise.
-
Operational rules (3-5 examples). These are the rules as the player understands them. How would you explain the game to a new player in plain language? Examples: "Click on an enemy to attack it." "You can only place a tile next to an existing tile." "Crouch behind cover to avoid bullets."
-
Implicit rules (3-5 examples). These are the unwritten agreements and expectations. What does the player assume without being told? Examples: "If a chest is visible, it can be opened." "The game will not present an unsolvable puzzle." "Other players will not deliberately lose in ranked mode."
After completing all three games, answer these questions:
- Which layer is most consistent across all three games? Why do you think that is?
- Which layer varies the most? What does that tell you about where each game's unique identity lives?
- For each game, identify one moment where the layers misalign --- where the constitutive rules, operational rules, or implicit rules produce a result that contradicts one of the other layers. What is the player's experience at that moment?
What this teaches you: Most designers think about operational rules intuitively but never examine the constitutive or implicit layers. This exercise forces you to see all three layers simultaneously, which is essential for diagnosing rule design problems that feel wrong but are hard to articulate.
Exercise 2: The Three-Rule Game
Type: Creative / Design
Time: 45-60 minutes
Deliverable: Paper prototype of a game with exactly three rules, plus written analysis
Design a complete game using exactly three rules. Not three types of rules. Three rules, total. The game must be playable as a paper prototype (cards, dice, drawn boards, tokens --- no digital tools).
Constraints: - Exactly three rules. Write them out. Each rule must be one sentence. - The game must have a win condition (derivable from the rules, but does not count as a fourth rule if it is a natural consequence of the three rules). - The game must be playable in under 10 minutes. - The game must involve at least one meaningful choice per turn.
Process: 1. Write your three rules. 2. Build a paper prototype (index cards, coins, drawn grid --- whatever the game needs). 3. Play the game at least three times (solo or with a partner). 4. After playing, write a one-page analysis: - What choices did the game produce? Were they meaningful (multiple viable options with different trade-offs)? - What was the possibility space? How many meaningfully different states could the game be in? - Did any emergent behaviors appear --- strategies or interactions you did not anticipate from the three rules? - If you could add one more rule, what would it be and why? What depth would it add? What interactions would it create? - If you had to remove one rule, which would you remove? What happens to the game? Does it still work?
What this teaches you: The three-rule constraint forces you to confront the relationship between rule count and depth. Most students discover that three well-chosen rules can produce a surprisingly deep game, while also discovering where the design feels thin and what a fourth rule would solve. This is the fundamental skill of rule design: knowing when to add, when to stop, and what each rule costs.
Exercise 3: Meaningful Choice Audit
Type: Analytical
Time: 30-40 minutes
Deliverable: Choice inventory and quality assessment for one game
Choose a game you have played recently. Play for 20 minutes (or recall a recent session) and catalog every choice the game asked you to make. For each choice, classify it using the four criteria from Section 7.4:
| Choice | Multiple Viable Options? | Differentiated Outcomes? | Information to Reason With? | Irreversible / Costly? | Verdict |
|---|---|---|---|---|---|
| (describe the choice) | Yes / No | Yes / No | Yes / No | Yes / No | Meaningful / False |
After completing the inventory:
-
Count the meaningful choices vs. false choices. What is the ratio? A well-designed game should have meaningful choices making up at least 70% of all choices presented. Where does your game fall?
-
Identify the best choice. Which single choice in your inventory is the most engaging? Why? Which of the four criteria is strongest for that choice?
-
Identify the worst choice. Which choice is the most clearly false? What type of false choice is it (no-brainer, uninformed gamble, delayed revelation, cosmetic fork)? How would you redesign it to make it meaningful?
-
Pattern analysis. Are false choices concentrated in a specific part of the game (early game, menus, dialogue, combat)? What does this tell you about where the designers focused their attention?
What this teaches you: Players feel engagement when they are making meaningful choices and boredom when they are executing procedures or making false choices. This exercise gives you a diagnostic tool for identifying where a game's choice design succeeds and where it fails. Apply it to your own project ruthlessly.
Exercise 4: Implement the Door-Lock System
Type: Implementation
Time: 60-90 minutes
Deliverable: Playable Godot scene with at least one locked door and one key
Build the key-and-lock system described in Section 7.12. Requirements:
-
Create a locked door. Use the
DoorLock.gdscript (or your own variation) to create a door that blocks the player's path. The door should have a visible sprite that changes color when unlocked. -
Create a collectible key. Create an
Area2Dnode with a sprite that represents the key. When the player walks over the key, it should be added to theGameManager's inventory (you may need to add aninventorydictionary or array to yourGameManager.gdfrom Chapter 6 --- addhas_item()andadd_item()methods). -
Place the door and key in your level. The key should be in a different room or area from the door. The player should be able to see the locked door before finding the key (this creates the goal before providing the solution --- a fundamental design principle).
-
Test the flow. Play through the sequence: discover locked door, explore, find key, return to door, unlock. Does the sequence feel satisfying? Is the key findable without being trivially obvious? Does the unlocking feedback feel clear?
-
Add a second locked door with a different key. Use a different
required_keyvalue (e.g., "red_key" and "blue_key"). Color-code the keys and doors to match. The player should now have two gated paths and two keys to find.
Stretch goals:
- Add a Label or particle effect when the player tries a locked door without the key
- Make the door animate (slide open, swing open, or fade out) instead of just changing color
- Add a boss key that only appears after defeating an enemy
What this teaches you: The key-and-lock pattern is a rule expressed as spatial design. Building it forces you to think about sequence --- the order in which the player encounters elements of your world. This is the seed of level design (Part IV) and gating design (Part VI). A locked door is the simplest possible way to control the player's journey, and understanding it deeply will inform every gating system you design for the rest of your career.
Exercise 5: Constraint-Driven Design Challenge
Type: Creative / Design
Time: 30-40 minutes
Deliverable: Three game concepts, each designed under a specific constraint
For each of the following constraints, design a one-paragraph game concept. The concept must include: the core mechanic, the core constraint, one interesting choice the player faces, and one sentence about what makes the game compelling.
Constraint 1: One Button. The player can only press one button. No directional input, no mouse movement, no other inputs. Just one button. Design a game around this single input.
Constraint 2: No Visuals. The player receives no visual information. The game communicates entirely through audio (music, sound effects, spatial audio). What kind of game works without sight?
Constraint 3: Five-Minute Session. The complete game experience must fit in five minutes. Not one level --- the entire game. The player should feel they had a complete, satisfying experience in 300 seconds. Design for maximum density.
After writing all three concepts, write a paragraph reflecting on the experience:
- Which constraint was hardest to design around? Why?
- Which concept is the most interesting? Is it the one from the hardest constraint?
- How did the constraints change your design thinking compared to designing with no restrictions? Be specific: what ideas did the constraint prevent, and what ideas did the constraint generate that you would not have had otherwise?
What this teaches you: Constraint-first design is a powerful creative tool. Starting with "what CAN'T the player do?" instead of "what CAN the player do?" produces ideas that are more focused, more original, and more feasible than open-ended brainstorming. Many professional game jam designers start with the constraints before they start with the ideas.
Exercise 6: The Possibility Space Map
Type: Analytical / Visual
Time: 35-45 minutes
Deliverable: Visual map of one game's possibility space with written analysis
Choose a game with clearly defined rules and a bounded game state (board games, puzzle games, and simple action games work best --- avoid open-world RPGs for this exercise).
-
Define the game state. What variables describe the current state of the game at any moment? (Board position, player health, score, inventory, enemy positions, timer, etc.) List all state variables.
-
Draw a possibility space diagram. Choose two of the most important state variables and create a 2D graph with each variable on one axis. Plot several representative game states as points on the graph. Connect states that the player can transition between in a single action.
Example for Pac-Man: X-axis = Pac-Man's position (1-245 tiles). Y-axis = number of pellets remaining (0-244). A single action (moving one tile) changes X and potentially decreases Y. The win state is Y=0. The lose state is any position where a ghost occupies the same tile as Pac-Man.
-
Identify the boundaries. What are the edges of the possibility space? Which states are impossible? Which states are reachable but unlikely? Which states are reachable and common?
-
Mark the interesting region. Where in the possibility space do the most interesting choices occur? Is it near the edges (high risk, low resources), in the middle (balanced tension), or everywhere equally? This tells you where the game's depth lives.
-
Write a one-paragraph analysis. How does the game's rule set shape the possibility space? If you removed one rule, how would the space change? Would it expand, contract, or restructure?
What this teaches you: The possibility space is an abstract concept. Drawing it makes it concrete. Once you can see the space, you can see where the interesting play lives, where the dead zones are, and how rule changes reshape the entire landscape. This is a tool you will use for the rest of your design career.
Exercise 7: Rule Cascade Analysis
Type: Analytical / Prescriptive
Time: 25-35 minutes
Deliverable: Cascade impact analysis for one proposed rule change
Choose a game you know deeply (100+ hours of experience is ideal). Propose one new rule --- something simple. Examples: "The player can now double-jump." "Enemies now respawn after 5 minutes." "The player starts with a map of the entire world."
Now trace the cascade. For each of the following categories, describe at least one specific impact of your new rule:
- Movement and traversal. How does the new rule change how the player moves through the world?
- Combat and challenge. How does the new rule affect difficulty, enemy encounters, or combat strategy?
- Economy and resources. How does the new rule affect the value of items, currency, or consumables?
- Pacing and progression. How does the new rule affect the rate at which the player advances?
- Level and world design. How does the new rule affect which areas are accessible and in what order?
- Player emotion and fantasy. How does the new rule affect how the game feels?
After completing the cascade, answer:
- How many of the six categories were affected by your single rule? (The answer should be most or all of them.)
- Are the cascade effects positive, negative, or mixed?
- Would you implement this rule change? Why or why not?
- If you would implement it, what other rules would you need to change to compensate for the cascading effects?
What this teaches you: Rule changes are never isolated. This exercise builds the habit of thinking systemically --- tracing the ripple effects of every design decision before you implement it. Experienced designers do this instinctively. Building the instinct starts with doing it deliberately.
Exercise 8: Fairness Audit
Type: Analytical / Critical
Time: 30-40 minutes
Deliverable: Fairness assessment of one game's rules
Choose a game you have found frustrating --- one where you felt the game was "unfair" or "cheap" at some point. Now apply the fairness framework from Section 7.7 to diagnose exactly why it felt unfair.
For each frustrating moment you can recall, answer:
- Was the rule consistent? Did the game follow the same rule it established earlier, or did it make an exception?
- Was the outcome transparent? Could you tell why you failed? Was the cause visible, or did it feel arbitrary?
- Was the implicit contract respected? Did the game violate an expectation it had established through earlier gameplay?
- Was the failure the player's fault? Could you have avoided the outcome with better play, or was it unavoidable regardless of skill?
After analyzing 3-5 frustrating moments, write a diagnosis:
- How many of the frustrating moments were caused by genuine unfairness (inconsistent rules, opaque outcomes, violated contracts, unavoidable failure)?
- How many were caused by difficulty that felt unfair but was actually consistent and transparent? (Be honest --- sometimes "unfair" really means "hard and I don't want to admit I made a mistake.")
- For each genuinely unfair moment, propose a specific fix that would preserve the difficulty but improve the fairness.
What this teaches you: The ability to distinguish between "hard" and "unfair" is one of the most important critical skills a designer can develop. Games like Dark Souls, Celeste, and Cuphead are extremely hard but widely considered fair. Games that are genuinely unfair lose players who would have persisted through difficulty. This exercise teaches you to diagnose the difference.
Exercise 9: Paper Prototype with Constraint Variations
Type: Creative / Experimental
Time: 50-60 minutes
Deliverable: One paper prototype played under three different constraint sets
Design a simple paper-prototype game (a grid-based board game with tokens works well). The base game should have 4-5 rules and be playable in 5 minutes.
Round 1: Play the base game three times. Note the experience: how many choices per game? How deep do the strategies feel? How variable are the outcomes?
Round 2: Add a constraint. Add one new rule that restricts what the player can do. Examples: "You can only move forward, never backward." "You can only carry one item at a time." "You must discard a card every time you draw." Play three times with the new constraint.
Round 3: Remove a constraint. Remove one of the original rules entirely (not the one you added in Round 2). Play three times without it.
Round 4: Swap a constraint. Replace the rule you removed with the constraint you added. Now you have the same number of rules but a different set. Play three times.
After all four rounds, write a comparison:
| Dimension | Base Game | + Constraint | - Constraint | Swapped |
|---|---|---|---|---|
| Choices per game | ||||
| Strategic depth (1-5) | ||||
| Fun (1-5) | ||||
| Variety between games | ||||
| Session feel (in one word) |
- Which version was the most fun? Why?
- Which version had the deepest strategy? Is that the same version that was most fun?
- What does this tell you about the relationship between rule count, constraint type, and player experience?
What this teaches you: This is the most direct way to experience the chapter's central argument: constraints shape experience. By playing the same game under different constraints, you isolate the effect of each rule and see how it transforms the experience. This builds intuition that reading about constraints cannot provide.
Exercise 10: Rule-Breaking Design
Type: Creative / Critical
Time: 30-40 minutes
Deliverable: Design document for one rule-breaking mechanic
Design a game moment where the rules deliberately change for dramatic or mechanical effect. This can be a plot twist, a boss fight, a hidden mechanic, or a meta-commentary.
Your design must include:
-
The established rules. What rules has the player learned and relied on up to this point? Be specific --- at least three rules that the player takes for granted.
-
The break. What changes? Which rule is violated, altered, or inverted? How does the player discover the change? (Gradually? Suddenly? Through a narrative reveal? Through gameplay surprise?)
-
The purpose. Why does the break exist? What experience does it create that following the rules could not? (Emotional impact? Mechanical novelty? Narrative commentary? Player realization?)
-
The recovery. What happens after the break? Do the rules return to normal? Do they permanently change? Does the player gain new abilities or lose old ones? How does the game re-establish trust after breaking it?
-
The player's likely reaction. Imagine three different player archetypes encountering your rule-break: a completionist, a narrative-focused player, and a challenge-focused player. How does each react? Is the break equally effective for all three?
What this teaches you: Rule-breaking is a high-risk, high-reward design tool. This exercise forces you to think about it structurally: you need established expectations, a meaningful purpose, and a plan for aftermath. Designing a rule-break well requires understanding the rules being broken, which means understanding your game at a deeper level than "it works."
Exercise 11: Progressive Project --- Collision, Boundaries, and Interactables
Type: Implementation
Time: 90-120 minutes
Deliverable: Updated Godot project with collision, boundaries, locked doors, keys, destructible objects, and a written rule set
This is the chapter's core implementation exercise. Complete all tasks from Section 7.16:
-
Add collision to your tilemap. Every wall tile should have collision. The player should not be able to walk through walls or off the edge of the level. Test by walking into every wall and corner --- the player should stop cleanly without jittering or clipping.
-
Set up collision layers. Implement the layer system from Section 7.11. At minimum: Layer 1 (Player), Layer 2 (Walls), Layer 3 (Enemies), Layer 4 (Collectibles), Layer 5 (Interactables). Configure masks so that the player collides with walls and interacts with collectibles and interactables.
-
Add a locked door and key. Implement the
DoorLock.gdpattern. Place the key in a different area from the door. The player should discover the locked door before finding the key (sequence matters). -
Add a destructible object. Create a
StaticBody2D(orCharacterBody2D) with health. When the player's attack hitbox overlaps it, reduce health. When health reaches zero, destroy the object (callqueue_free()) and optionally drop a collectible. -
Write your rule set. Using the template from Section 7.10, write a one-page rule set for your project. Cover movement, collision, interaction, combat, and resources. Be specific: "The player moves at 200 pixels/second in 8 directions and is stopped by Layer 2 collision."
-
Playtest for 10 minutes. Answer the four questions from Section 7.16. Write your answers down.
Stretch goals: - Add a second locked door with a different key color - Add a breakable wall that reveals a secret room - Add an NPC that the player can interact with (walk up and press a button to display dialogue text) - Add world boundaries that prevent the player from walking off the edge of the map without using invisible walls (use visible environmental features like cliffs, fences, or water)
What this teaches you: This exercise transforms your prototype from an open void into a structured space. After completing it, you will have experienced the moment described in the chapter's introduction: the moment when constraints make your prototype feel like a game. That transformation is the practical lesson of this entire chapter, and no amount of reading can substitute for experiencing it yourself.
Exercise 12: Rule Set Peer Review
Type: Collaborative
Time: 35-45 minutes (requires a partner)
Deliverable: Peer feedback on rule sets with revision notes
This exercise requires at least one other person working through the book.
Round 1 (10 minutes): Exchange rule set documents (from Exercise 11 or Section 7.16). Read the other person's rule set without playing their game. Based only on the document, answer:
- Can you visualize the game from the rules alone? What is clear? What is ambiguous?
- Identify one rule that seems well-designed --- it creates a clear constraint that should produce interesting choices.
- Identify one rule that seems underdefined --- it is vague, has edge cases, or might produce unintended consequences.
- Identify one missing rule --- something the game probably needs but the document does not address. (Common omissions: what happens at level edges, what happens when the player has no health, what happens when the player has no keys and encounters a locked door.)
Round 2 (10 minutes): Play the other person's prototype for 5 minutes. Now compare:
- How does the experience of playing compare to your mental image from the document?
- Were your concerns from Round 1 borne out? Was the underdefined rule actually a problem in play, or did it work despite being vaguely written?
- Did the game have any rules that were not in the document? (These are implicit rules that the designer did not realize they had implemented.)
Round 3 (15 minutes): Return feedback. Each person revises their rule set based on the review. Address the ambiguities. Fill in the missing rules. Clarify the underdefined rules. Add any implicit rules that the playtester discovered.
What this teaches you: Writing rules is hard. Writing rules that someone else can understand is harder. The gap between what you meant and what the document says is the same gap between your design intent and the player's experience. This exercise closes that gap by forcing your rules through the filter of another person's interpretation.