Chapter 3 Quiz: Setting Up Your Design Laboratory

Multiple Choice

1. Godot Engine is licensed under:

a) A proprietary license with a revenue cap
b) The GPL (GNU General Public License)
c) The MIT License
d) A royalty-based license (percentage of gross revenue)

2. In GDScript, what does the @export annotation do?

a) Makes a variable accessible from other scripts
b) Exports the variable to a JSON file
c) Exposes the variable in the Godot Inspector for editing without modifying code
d) Makes the variable immutable

3. Which lifecycle function should you use for player movement in Godot?

a) _ready()
b) _process(delta)
c) _physics_process(delta)
d) _input(event)

4. What does input_vector.normalized() do?

a) Rounds the vector to the nearest integer
b) Sets the vector's magnitude to 1 while preserving its direction
c) Converts the vector from world space to screen space
d) Inverts the vector's direction

5. Why is diagonal normalization important for character movement?

a) Without it, the game crashes when moving diagonally
b) Without it, diagonal movement is approximately 41% faster than cardinal movement
c) Without it, the character can only move in four directions
d) Without it, the character ignores collision shapes

6. The delta parameter in _physics_process(delta) represents:

a) The total time since the game started
b) The difference between the player's position and the origin
c) The time in seconds since the last physics frame
d) The distance the character moved since the last frame

7. In Godot's architecture, the fundamental building blocks of a game are:

a) GameObjects and Components
b) Actors and Blueprints
c) Nodes and Scenes
d) Sprites and Scripts

8. What does move_and_slide() do in a CharacterBody2D?

a) Moves the character and destroys any objects it collides with
b) Moves the character by its velocity and slides along surfaces on collision
c) Moves the character to a specified position instantly
d) Moves the character and applies gravity automatically

9. Which of the following is the correct way to check if the player just pressed a button (one-shot, not held)?

a) Input.is_action_pressed("attack")
b) Input.is_action_just_pressed("attack")
c) Input.get_axis("attack_left", "attack_right")
d) Input.is_action_held("attack")

10. What is a signal in Godot?

a) A visual indicator displayed on the screen
b) An event emitted by a node that other nodes can listen for and respond to
c) A global variable shared between all scripts
d) A networking protocol for multiplayer communication

11. The $` operator in GDScript (e.g., `$Sprite2D) is shorthand for:

a) create_node()
b) find_node()
c) get_node()
d) load()

12. Which prototyping approach is best for testing whether a game's core loop is fun?

a) Building a full digital prototype with polished art
b) Writing a detailed design document
c) Paper prototyping with index cards and dice
d) Creating concept art and mood boards

Short Answer

13. Explain why GDScript uses func instead of Python's def, and identify two other syntax differences between GDScript and Python.

14. A new developer puts their movement code in _process(delta) instead of _physics_process(delta). The game works fine on their machine at 60 FPS. Explain what problem this creates and when it will become apparent.

15. Describe the difference between a CharacterBody2D and a RigidBody2D in Godot. Give one example of a game object best suited for each.

16. A designer writes a 50-page Game Design Document before writing a single line of code. Using concepts from this chapter, explain why this approach is problematic. What should they do instead?

17. Explain the Observer pattern (signals in Godot) in your own words. Why is it better for a player node to emit a health_changed signal than to directly call health_bar.update() on a health bar node?

Analytical Questions

18. The chapter argues that "if your game is fun on a table with index cards and a coin, it will almost certainly be fun as a digital game." Under what circumstances might this claim be false? Name a type of game where the fun comes specifically from something paper cannot simulate, and explain why.

19. Consider the following two approaches to designing a sprint mechanic:

Approach A: The player holds Shift and moves 50% faster. There is no cost and no cooldown.

Approach B: The player holds Shift and moves 50% faster, but a stamina bar depletes while sprinting and recharges while walking.

Analyze both approaches using the framework from Chapter 1 (particularly Costikyan's "uncertain outcome through player effort"). Which approach creates a more interesting decision? Why? When might Approach A actually be the better design choice?

20. The chapter presents three levels of design documentation: the one-page concept, the GDD, and the task list. For a solo developer working on a small game (3-6 months of development), which document is most important? Justify your answer. Would your answer change for a team of 10 developers? Why?

Answer Key

1. c) The MIT License.

Godot is MIT-licensed, meaning it is free for any use --- commercial or non-commercial --- with no revenue caps, royalties, or usage restrictions. This distinguishes it from Unity (which had a runtime fee controversy in 2023) and Unreal (which takes 5% of gross revenue above $1 million).

2. c) Exposes the variable in the Godot Inspector for editing without modifying code.

@export makes a variable visible and editable in the Inspector panel. This is critical for game design iteration because it allows you to tweak values (speed, health, jump force) in real-time without opening the script editor. Design is iteration, and @export makes iteration fast.

3. c) _physics_process(delta).

_physics_process() runs at a fixed rate (default 60 Hz) regardless of the machine's frame rate, ensuring consistent movement behavior across all hardware. _process() runs at the variable rendering frame rate, which means movement would be faster on fast machines and slower on slow machines.

4. b) Sets the vector's magnitude to 1 while preserving its direction.

Normalization scales a vector so its length is exactly 1. This is essential for movement because it ensures that moving in any direction (cardinal or diagonal) produces the same speed. Without normalization, diagonal vectors have a magnitude of ~1.414, making diagonal movement faster.

5. b) Without it, diagonal movement is approximately 41% faster than cardinal movement.

A cardinal direction vector like (1, 0) has a magnitude of 1. A diagonal vector like (1, 1) has a magnitude of √2 ≈ 1.414, which is ~41% larger. Multiplying both by the same speed value means diagonal movement covers more ground per frame. Normalizing the diagonal vector back to magnitude 1 eliminates this discrepancy.

6. c) The time in seconds since the last physics frame.

delta (typically ~0.0167 seconds at 60 Hz) enables frame-rate-independent calculations. Multiplying a per-second value (like speed in pixels/second) by delta produces the correct per-frame increment regardless of the actual frame rate.

7. c) Nodes and Scenes.

Godot's architecture is built on nodes (atomic units with specific behaviors) composed into scenes (reusable trees of nodes). Scenes can contain other scenes as children, enabling composable, modular game architecture. This contrasts with Unity's GameObject/Component model and Unreal's Actor/Blueprint model.

8. b) Moves the character by its velocity and slides along surfaces on collision.

move_and_slide() is CharacterBody2D's built-in movement function. It applies the velocity property, detects collisions, and adjusts the character's path to slide along collided surfaces rather than stopping dead. This produces natural-feeling movement without requiring custom collision response code.

9. b) Input.is_action_just_pressed("attack").

is_action_just_pressed() returns true only on the single frame when the key is first pressed. is_action_pressed() returns true every frame the key is held down. For actions that should fire once per press (attacks, jumps, interactions), use just_pressed. For continuous actions (movement, sprinting), use pressed.

10. b) An event emitted by a node that other nodes can listen for and respond to.

Signals implement the Observer pattern in Godot. A node emits a signal when something happens (timer expires, collision detected, health changes). Other nodes connect to that signal and execute a function in response. This enables loose coupling --- the emitter doesn't need to know who's listening.

11. c) get_node().

The $` syntax is a convenience shorthand. `$Sprite2D is equivalent to get_node("Sprite2D"). It retrieves a child node by its name in the scene tree. For deeper paths, you can chain: $Body/Sprite2D is equivalent to get_node("Body/Sprite2D").

12. c) Paper prototyping with index cards and dice.

Paper prototyping is the fastest way to test a core loop's fundamental appeal. A paper prototype can be assembled in minutes and iterated rapidly. If the loop isn't engaging on paper (explore → fight → collect → upgrade), adding digital polish won't fix it. Paper tests the system; digital tests the feel.

13. GDScript uses func instead of def because it is a separate language purpose-built for Godot, not a Python variant. Two additional differences: (1) GDScript requires var for variable declarations (var speed = 200.0), while Python allows direct assignment (speed = 200.0). (2) GDScript supports optional type annotations with colon syntax and return type arrows (func heal(amount: int) -> void:), while Python uses similar syntax but with different conventions for type hints and does not have engine-integrated types like Vector2 and Color.

14. The game will behave differently on different hardware. On the developer's 60 FPS machine, movement feels correct. On a machine running at 30 FPS, the character moves at half the expected speed because _process() is called half as often. On a machine running at 120 FPS, the character moves twice as fast. The problem becomes apparent when players with different hardware report that the game feels "too slow" or "too fast." _physics_process() avoids this by running at a fixed rate (default 60 Hz) regardless of the rendering frame rate.

15. A CharacterBody2D is moved directly by code --- you set its velocity and call move_and_slide(), giving you precise control over movement. It's ideal for player characters, enemies with scripted movement, and anything the designer wants full control over. Example: a player character in a platformer.

A RigidBody2D is moved by the physics engine --- it responds to forces, gravity, collisions, and momentum automatically. It's ideal for objects that should behave "physically" --- bouncing, rolling, tumbling. Example: a barrel that the player kicks and it rolls down a hill, or a crate that falls when its support is destroyed.

16. A 50-page GDD for a game that doesn't exist is problematic because: (1) it consumes development time on documentation instead of prototyping and testing; (2) the majority of design decisions will change once the game is playable, making much of the document obsolete; (3) it creates a false sense of completeness --- the designer feels "done" designing when they haven't tested anything. The better approach is to write a one-page concept document, build a playable prototype of the core mechanic, and expand the GDD incrementally as features are implemented and tested. The GDD should document decisions that have been validated through play, not decisions that exist only in theory.

17. The Observer pattern works like a radio broadcast: one node "broadcasts" that something happened (by emitting a signal), and any number of other nodes can "tune in" (by connecting to that signal). The broadcaster doesn't know or care who's listening.

Emitting a health_changed signal is better than directly calling health_bar.update() because: (1) if you remove the health bar, the player code doesn't break --- there's just no listener; (2) you can add new listeners without modifying the player code --- a sound effect player, a screen-shake system, and a game-over checker can all respond to the same signal; (3) it keeps the player script focused on player logic, not on managing other systems. Direct calls create tight coupling (changing one thing breaks another). Signals create loose coupling (systems communicate without depending on each other's existence).

18. The claim is false for games where the fun depends on real-time execution, timing, or game feel --- qualities that paper cannot replicate. A rhythm game like Beat Saber or Guitar Hero cannot be meaningfully paper-prototyped because the entire experience depends on the precise timing of button presses synchronized to music. A platformer like Celeste is fun largely because of the feel of the jump, dash, and wall-climb --- the precise timing windows, the acceleration curves, the coyote time --- none of which exist on paper. Games that depend on audio feedback (Rez, Crypt of the NecroDancer), visual spectacle (Geometry Wars), or frame-precise execution (fighting games) also resist paper prototyping. Paper tests systems; it cannot test feel.

19. Approach A creates no decision. Sprinting is always better than walking (it's faster with no cost), so the "decision" to sprint is trivially obvious --- the player should hold Shift at all times. By Costikyan's framework, there is no uncertainty of outcome because the optimal strategy is clear: always sprint.

Approach B creates a genuine decision. Sprinting is faster but depletes stamina, forcing the player to manage a resource. Should you sprint to escape an enemy and risk being out of stamina for the next encounter? Should you walk to conserve stamina before a boss fight? The stamina cost creates tradeoffs, and tradeoffs create uncertainty about the optimal choice. This aligns with Costikyan's definition: the outcome (survival, efficient progression) becomes uncertain because the player must make meaningful choices about resource allocation.

However, Approach A is the better design choice in games where sprint is a quality-of-life feature rather than a mechanical decision. In Breath of the Wild, stamina-gated sprinting adds to exploration tension. In a narrative walking simulator or a casual exploration game, stamina-gated sprinting would be annoying --- the player just wants to move faster through a large space. If sprinting is not meant to be a decision, don't make it one.

20. For a solo developer on a 3-6 month project, the task list is most important. A solo developer already knows their game's concept (they conceived it) and doesn't need to communicate the vision to teammates. What they need is a clear, prioritized list of what to build, in what order, with realistic scope boundaries. The task list prevents scope creep, makes progress visible, and forces the "must-have vs. nice-to-have vs. cut" decisions that solo developers often avoid until it's too late.

For a team of 10, the one-page concept becomes most important. Ten people need a shared understanding of what they're building. Without it, the programmer and the artist and the designer will build three different games. The concept doc is the alignment tool that keeps the team pointed in the same direction. The task list is still critical (you'd probably use a project management tool like Jira or Trello at that scale), but it's useless if the team doesn't agree on what they're building.