CHALLENGE 2: Build and Inspect a Small Scene Tree
====================================================================

TASK
----
Build a small scene tree by hand: a Node2D root named "Player," with
a Sprite2D child and a Camera2D child. Inspect the tree in Godot's
own Scene panel and explain, in your own words, why each node is a
separate child rather than one combined node.

STEPS
-----
1. In a new or existing scene, add a Node2D as the root (or rename
   your existing root). In the Scene panel, double-click the node's
   name and rename it to "Player."

2. With "Player" selected, click the "+" (Add Child Node) button in
   the Scene panel. Search for "Sprite2D" and add it. It appears
   nested under Player.

3. With "Player" selected again, click "+" once more and add a
   "Camera2D" child the same way.

4. The Scene panel now shows a tree:

     Player (Node2D)
     |-- Sprite2D
     |-- Camera2D

5. Save the scene.

EXPLANATION (why separate nodes, not one combined node)
---------------------------------------------------------
Each node type in Godot is deliberately narrow - it does exactly one
job:

- Node2D (the root, "Player") only provides position, rotation, and
  scale. It's the shared anchor point everything else is positioned
  relative to.
- Sprite2D is only responsible for displaying a 2D image/texture.
  It knows nothing about cameras or physics.
- Camera2D is only responsible for what part of the game world is
  visible on screen. It knows nothing about sprites or textures.

If Godot instead had one giant "PlayerCharacter" node that tried to
handle position, rendering, and the camera all at once, it would be
far less flexible: you couldn't swap out just the sprite for a
different image, or attach a second camera, or reuse the camera
logic on a different kind of node, without rewriting the whole
thing. By keeping each responsibility in its own small node and
composing them into a tree, any one piece can be replaced,
reused, or removed independently of the others - which is exactly
the same "do one thing well, then compose" idea behind functions
and classes in ordinary programming.