Chapter 3 Exercises: Setting Up Your Design Laboratory

Exercise 1: Install Godot and Create Your First Project

Type: Setup / Technical
Time: 15-20 minutes

Download and install Godot 4.x from godotengine.org. Create a new project called "DesignLab" (or any name you like). Open the editor and familiarize yourself with the four main panels:

  1. Scene tree (top left) --- create a root Node2D
  2. Inspector (right) --- select the Node2D and examine its properties
  3. Viewport (center) --- add a ColorRect child and resize it to fill the viewport
  4. Script editor (center, Script tab) --- attach a script to the root node and write print("Hello, game dev!")

Run the project (F5). Confirm the Output panel shows your message.

Then explore further: - Add a second ColorRect with a different color. What happens when you change which one is higher in the scene tree? (Nodes lower in the tree draw on top of nodes higher in the tree --- this is Godot's draw order.) - Add a Label node. Type "My First Game" in its Text property. Change the font size in the Label's theme override settings. - Add an AudioStreamPlayer node. Don't worry about loading audio yet --- just note that it exists. This is the node type you'll use for sound effects and music starting in Chapter 30.

Deliverable: A running Godot project with a colored background, a text label, and a print statement in the console. You should be comfortable with the scene tree, Inspector, and the F5 run cycle.

Exercise 2: Build the Moving Character

Type: Technical / Code
Time: 30-40 minutes

Build the Player scene from Section 3.7 from scratch. Do not copy-paste --- type every line of player.gd yourself.

  1. Create a new scene with a CharacterBody2D root
  2. Add a Sprite2D child (use icon.svg or any placeholder sprite)
  3. Add a CollisionShape2D child with a RectangleShape2D
  4. Write the movement script with @export var speed, Input.get_axis(), normalization, and move_and_slide()
  5. Instance the player in your main scene
  6. Run and test

After it works, experiment:

  • Change the speed to 50. Then 500. Then 1000. How does it feel at each value?
  • Remove the input_vector.normalized() line. Move diagonally. Can you feel the speed difference?
  • Change _physics_process to _process. Does the movement still work? (Yes, but now it's frame-rate dependent --- a bug waiting to happen.)

After all experiments, write a brief paragraph answering: What speed value felt best, and why? There is no right answer. Some games want slow, deliberate movement (Dark Souls). Some want fast, twitchy movement (Celeste). Your preferred speed reveals something about the kind of game you want to make.

Deliverable: A playable scene with 8-directional movement. Your own player.gd typed by hand. A brief note on your preferred speed value.

📝 Note: Typing code by hand instead of copying it is not busywork. It forces you to read every line, notice the syntax, and build muscle memory. Programmers who copy-paste learn slower. You are building a skill, not filling a file.

Exercise 3: Paper Prototype a Card Game

Type: Design thinking / Analog
Time: 30-45 minutes

Design a card game using only a standard deck of playing cards and these constraints:

  1. Two players
  2. Playable in under 10 minutes
  3. Must involve both a strategic choice and a random element
  4. Rules fit on one index card (approximately 100 words)

Write the rules. Then play the game at least three times (with a partner or simulating both sides yourself).

After playing, answer: - Is the outcome uncertain? Does player skill affect the result? - What's the most interesting decision a player makes during the game? - What would you change after playtesting? - What did paper prototyping reveal that you wouldn't have discovered by just thinking about the design?

Deliverable: Written rules on an index card (photograph or scan it). A brief (half-page) playtesting reflection covering the questions above.

🔄 Recurring Theme: This exercise mirrors Exercise 8 from Chapter 1, but with a design lens instead of a definitional one. In Chapter 1, you were asking "is this a game?" Here, you're asking "is this a good game?" --- and you're using the fastest possible tool (paper) to answer the question. Notice how quickly you iterated. Your third set of rules is almost certainly better than your first. That speed of iteration is the entire argument for paper prototyping.

Exercise 4: Write a One-Page Design Concept

Type: Design / Writing
Time: 25-30 minutes

Write a one-page concept document for the progressive project game you're building across this book. Follow the template from Section 3.11:

  • Title: Working title
  • Logline: One sentence
  • Genre: Be specific (e.g., "2D top-down action-adventure with light puzzle elements")
  • Platform: PC (for this book; you can note additional targets)
  • Target Audience: Who will play this?
  • Player Fantasy: Your statement from Chapter 1's Exercise 11
  • Core Mechanic: The one thing the player does most
  • Core Loop: The repeated cycle of play
  • Unique Selling Point: Why this game and not another one?
  • Reference Games: 2-3 games yours draws from

Constraints: - Exactly one page. Not two pages. Not one and a half. One. - Someone who has never played a game should be able to read it and understand the concept. - No technical jargon (no "CharacterBody2D," no "tilemap," no "FSM").

Deliverable: A one-page concept document. This is a living document --- you'll update it as the project evolves.

🎯 Design Focus: The hardest part of the one-page concept is the Unique Selling Point. "It's fun" is not a USP --- every game claims to be fun. "The temple's rooms physically rearrange every time you die, so knowledge from previous runs becomes unreliable" is a USP. It tells you exactly what makes this game different. If you can't articulate your USP in one sentence, you may not know what your game is yet.

Exercise 5: Add a Sprint Mechanic

Type: Technical / Design
Time: 20-25 minutes

Modify your player.gd to include a sprint mechanic:

  1. Add a new @export variable: sprint_multiplier: float = 1.5
  2. Check whether the player is holding the sprint key (Shift, or create a custom "sprint" action in the Input Map)
  3. When sprinting, multiply the speed by sprint_multiplier
  4. When not sprinting, use the base speed

Here's a starting structure to build from:

@export var speed: float = 200.0
@export var sprint_multiplier: float = 1.5

func _physics_process(delta: float) -> void:
    var input_vector = Vector2.ZERO
    input_vector.x = Input.get_axis("ui_left", "ui_right")
    input_vector.y = Input.get_axis("ui_up", "ui_down")
    if input_vector != Vector2.ZERO:
        input_vector = input_vector.normalized()

    var current_speed = speed
    if Input.is_action_pressed("sprint"):
        current_speed = speed * sprint_multiplier

    velocity = input_vector * current_speed
    move_and_slide()

After implementing: - Does the sprint feel good? Adjust sprint_multiplier until it does. (Try 1.3, 1.5, 1.8, 2.0.) - Should the player be able to sprint indefinitely? What would change if you added a stamina bar? - How would you communicate to the player that they're sprinting? (Visual feedback? Sound? Trail effect?)

Design extension: Sprint is one of the simplest mechanics you can add. But it immediately raises design questions:

  • If the player can always sprint, why would they ever walk? (Answer: they wouldn't, which means sprint becomes the default speed and "walking" becomes "slow mode." This might not be what you intended.)
  • Does the camera need to adjust when sprinting? (Wider FOV? Pull back slightly to show more of the world ahead?)
  • Should enemies also be able to sprint? What happens to encounter design if the player can outrun everything?

Write 2-3 sentences reflecting on how a single mechanic (sprint) creates cascading design implications. You'll encounter this pattern constantly: adding one feature changes the context for every other feature.

Deliverable: Updated player.gd with a working sprint mechanic, a note on what multiplier value felt best, and a brief design reflection.

Exercise 6: Connect a Signal

Type: Technical
Time: 15-20 minutes

Practice using signals by building a simple interaction:

  1. Add a Timer node as a child of your player's CharacterBody2D
  2. Set the Timer's Wait Time to 3.0 seconds and Autostart to true
  3. Connect the Timer's timeout signal to the player script (use the editor or code)
  4. In the connected function, print a message: "3 seconds have passed!"
  5. Make the timer repeat by setting One Shot to false

Then extend the exercise: - Instead of printing, change the player's sprite color on each timeout (alternate between two colors) - Create a custom signal called color_changed that emits whenever the color changes - Add a Label node to the scene that listens for color_changed and updates its text

Deliverable: A scene where the player's color changes every 3 seconds, driven by Timer signals, with a Label displaying the current color state.

🔗 Connection: This signal pattern --- Timer → emits timeout → triggers function → emits custom signal → other nodes respond --- is exactly how you'll build cooldown systems (Chapter 5), invincibility frames (Chapter 8), and dialogue timing (Chapter 21). Every complex system in your game will be built from simple signal chains like this one.

Exercise 7: Explore the Node Library

Type: Exploration / Research
Time: 20 minutes

Open Godot's "Add Child Node" dialog (right-click any node in the scene tree and select "Add Child Node"). Browse the complete list of available node types.

For each of the following categories, find at least two node types and write a one-sentence description of what each does (use the built-in documentation --- F1 or hover over the node name):

  1. 2D visual nodes (nodes that display something)
  2. Physics nodes (nodes involved in collision and physics)
  3. Audio nodes (nodes that produce sound)
  4. UI/Control nodes (nodes for user interface elements)
  5. Utility nodes (Timer, AnimationPlayer, etc.)

Then answer: which three nodes are you most curious about? What could you use them for in your progressive project?

Deliverable: A list of 10+ nodes with descriptions and three nodes you want to explore further.

🧩 Design Insight: Browsing the node library is like browsing a design toolkit. Each node represents a capability --- a thing your game can do. AnimationPlayer means your game can have keyframed animations. ParallaxBackground means your game can have depth-layered scrolling backgrounds. RayCast2D means your game can detect what's in a particular direction (useful for enemy line-of-sight, laser beams, and ground detection). Knowing what tools exist, even before you need them, expands your design vocabulary.

Exercise 8: Paper Prototype Your Progressive Project's Core Loop

Type: Design thinking / Analog
Time: 30-40 minutes

Using index cards and a flat surface, paper-prototype the core loop of your progressive project:

  1. Write each game element on a separate index card: player abilities, enemy types, items, obstacles, level elements
  2. Arrange them on a table to represent a single "room" or encounter
  3. Use a coin or token as the player character
  4. Simulate 5 minutes of gameplay by moving the token through the arrangement, resolving encounters with dice rolls where needed

During the simulation, track: - How many meaningful choices did you make? - Was there ever a moment where you had no interesting option? - Did any game elements interact in unexpected or interesting ways? - Did any game elements feel unnecessary?

After the simulation, remove one card (cut one element from the game). Run the simulation again. Is the game worse? The same? Better?

Deliverable: Photos of your paper prototype layout (before and after removing an element) and a half-page reflection on what the simulation revealed. Keep these photos --- you'll compare them to your digital implementation later.

💡 Intuition: The single most powerful paper prototyping technique is subtraction. Remove elements one at a time and test whether the game gets worse. If removing an element doesn't make the game worse, it shouldn't be in the game. This is the same principle you'll apply in scope management (Chapter 37), but it's easier to learn with index cards than with code you spent three weeks writing.

Exercise 9: GDScript Syntax Drills

Type: Technical / Practice
Time: 20 minutes

Without looking at the chapter, write GDScript code for each of the following. Then check your answers against the chapter text or the Godot documentation:

  1. Declare a variable max_health of type int with a value of 100, exported to the Inspector
  2. Declare a constant GRAVITY with a value of 980.0
  3. Write a function heal that takes an amount: int parameter and adds it to health, capping at max_health
  4. Write an if/elif/else chain that prints "dead" if health is 0 or below, "critical" if health is below 25, and "healthy" otherwise
  5. Write a _physics_process function that moves a CharacterBody2D to the right at 100 pixels per second
  6. Declare a custom signal called item_collected that passes a String parameter
  7. Write a for loop that iterates through an array of enemy names and prints each one
  8. Write a match statement that handles three states: "idle", "walking", "attacking"

Deliverable: Your handwritten (or typed) code for all eight prompts. Check each against the documentation. Note which ones you got wrong and why.

⚡ Efficiency Tip: If you got most of them right, good --- you internalized the chapter. If you struggled, that's also good information. Go back to the specific section, re-read it, and try again. Syntax fluency comes from repetition, not from reading. Write the same patterns five times and they'll stick. Write them once and you'll forget by tomorrow.

Exercise 10: Tool Comparison Research

Type: Research / Analysis
Time: 25-30 minutes

Research two game engines or design tools other than Godot. Choose from:

  • Unity
  • Unreal Engine 5
  • GameMaker
  • PICO-8
  • Bitsy
  • RPG Maker
  • Construct 3
  • Ren'Py
  • Twine

For each tool, answer: 1. What type of games is it best suited for? 2. What is its pricing/licensing model? 3. What programming language does it use? 4. Name one commercially successful game made with it 5. What is one advantage it has over Godot? One disadvantage?

Then write a brief paragraph (3-5 sentences) explaining why the tool you use matters less than most beginners think. (Hint: the answer involves design thinking, not technology.)

Deliverable: A comparison table and a short paragraph on why tool choice matters less than design thinking.

🪞 Learning Check-In: If this research made you second-guess choosing Godot --- stop. You've just learned a lesson about the "grass is greener" trap. Every engine has advantages that other engines lack. The question is not "which engine is best?" It's "can this engine make the game I want to make?" For Godot and the 2D action-adventure you're building: yes, unambiguously. Move on. Build the game.

Exercise 11: Add Screen Boundary Walls

Type: Technical
Time: 20-25 minutes

Your character currently moves off the screen and into the void. Fix this by adding boundary walls:

  1. In your main scene, add four StaticBody2D nodes (one for each edge: top, bottom, left, right)
  2. For each StaticBody2D, add a CollisionShape2D child with a RectangleShape2D
  3. Position and size each collision shape to form a wall along the edge of the screen

The StaticBody2D is Godot's node for immovable objects. Unlike CharacterBody2D (which you control with code) and RigidBody2D (which the physics engine controls), a StaticBody2D doesn't move at all. It exists solely to be collided with.

Your player's move_and_slide() will automatically detect and respond to these walls. You don't need to write any collision code --- the node types handle it.

Testing: Run the game. Move toward each edge. The player should stop at the boundary and slide along it (not through it, not stuck to it). If you're passing through walls, check: Did you add CollisionShape2D children to the StaticBody2D nodes? Did you actually assign a shape (not just add the node)?

Extension: Make one wall a different color by adding a ColorRect child to its StaticBody2D. This is how you'd visually represent walls in a prototype. In a finished game, you'd use tilemap tiles or sprite art instead.

Deliverable: A bounded play area where the player cannot leave the screen.

🎯 Design Focus: Boundaries are a design decision, not just a technical one. Some games use hard walls (the player bumps into them). Others use screen wrapping (the player exits one side and appears on the opposite side --- Asteroids). Others use soft boundaries (the camera stops but the player keeps moving off-screen, then takes damage --- Super Smash Bros.). How you handle boundaries communicates the rules of your game's world.

Exercise 12: Flowchart Your Game's Menu System

Type: Design / Planning
Time: 15-20 minutes

Draw a flowchart for your progressive project's menu system. Include at minimum:

  • Title Screen
  • New Game / Continue
  • Settings (Audio, Display, Controls)
  • Pause Menu
  • Game Over Screen
  • Return to Title

For each screen, note: - What buttons or options are available - What transitions connect to other screens - What input (key/button) triggers each transition

Use any tool: hand-drawn on paper, draw.io, Figma, or even ASCII art. The medium doesn't matter. The clarity of the flow does.

Think about edge cases: - What happens if the player presses Escape during a cutscene? - What happens if the player presses the pause button during the game over screen? - Can the player access settings from the pause menu, or only from the title screen? - What happens when the player quits --- is there a "are you sure?" confirmation?

These questions seem trivial. They are not. Inconsistent menu behavior --- where Escape does different things on different screens, or where the player can't find the settings they just changed --- is one of the most common sources of frustration in indie games.

Deliverable: A complete menu flowchart covering all screens and transitions. You'll implement this in Chapter 29 (UI/UX).

Exercise 13: Debug a Broken Script

Type: Technical / Analytical
Time: 15-20 minutes

The following player.gd script has five bugs. Find and fix each one. (Do not run the code first --- read it and identify the problems, then check your answers by actually running the fixed version.)

extend CharacterBody2D

@export var speed = 200.0

func _process(delta: float) -> void:
    var input_vector = Vector2.ZERO
    input_vector.x = Input.get_axis("ui_left", "ui_right")
    input_vector.y = Input.get_axis("ui_up", "ui_down")
    velocity = input_vector * speed
    move_and_slide

func _ready() -> void:
    print("Player ready! Speed is: " + speed)

For each bug: 1. Identify the line number 2. Describe what's wrong 3. Write the corrected line

Hints: - One bug is a keyword typo - One bug is the wrong lifecycle function - One bug is a missing function call syntax - One bug is a missing normalization step - One bug is a type conversion error in print()

After fixing all five bugs, run the corrected script to verify it works.

Deliverable: A list of all five bugs with corrections. The corrected script running without errors.

💀 Hard Lesson: Reading broken code and identifying bugs is a skill you will use more than writing new code. In professional development, you spend more time debugging, reading, and modifying existing code than writing code from scratch. This exercise trains that skill deliberately.

Exercise 14: Progressive Project --- Complete Chapter 3 Deliverables

Type: Technical / Comprehensive
Time: 45-60 minutes

This exercise consolidates everything from the chapter. Complete all Chapter 3 progressive project requirements:

  1. Godot project created in a dedicated project folder with organized subdirectories (scenes, scripts, art, audio)
  2. Player scene (player.tscn) with CharacterBody2D, Sprite2D, and CollisionShape2D
  3. Player script (player.gd) with: - @export var speed: float = 200.0 - 8-directional input via Input.get_axis() - Diagonal normalization - move_and_slide() in _physics_process()
  4. Main scene with a background (ColorRect) and an instanced player
  5. The game runs --- F5 produces a movable character

Stretch goals (attempt at least two): - Custom sprite (not the Godot icon --- find one on itch.io or OpenGameArt, or draw a simple one) - Sprint mechanic (from Exercise 5) - Camera2D following the player (add a Camera2D child to your player scene, check "Make Current" in the Inspector) - Screen boundary walls (from Exercise 11) - Damage flash using signals (from Section 3.9) - A Label displaying "Speed: [value]" that updates as you sprint/walk

Self-evaluation checklist: - [ ] The character moves in all 8 directions - [ ] Diagonal movement is the same speed as cardinal movement (normalization works) - [ ] The speed variable appears in the Inspector and can be changed without editing code - [ ] The game window opens without errors in the Output panel - [ ] The project is organized in folders (not all files dumped in the root) - [ ] (Stretch) At least one stretch goal is implemented

Deliverable: A running Godot project with all required elements. Save this project in a permanent location --- you will build on it in every subsequent chapter from here to Chapter 40.

🚪 Threshold: If your character moves when you press the arrow keys, you have crossed the most important threshold in this book. You have gone from thinking about games to making a game. Everything from this point forward is iteration, expansion, and refinement. The hard part --- starting --- is done.

📝 Note: If you completed all required deliverables and at least two stretch goals, you are ahead of schedule. If you completed the required deliverables but struggled with stretch goals, you are exactly where you should be. If you couldn't get the character to move, go back to Section 3.7 and rebuild the player scene from scratch, checking each step against the chapter text. The most common issues are: wrong root node type (must be CharacterBody2D), missing CollisionShape2D, or the script not attached to the root node.