Make the world react to the player's location. Connect physical space to game logic.

Every open-world game knows exactly where you are at all times. Step into a danger zone and the music changes. Walk into a store and the UI shifts. But HOW does the game know? Today you'll build that system yourself.

Video: Elastic Collisions — The Coding Train (10 min)

Daniel Shiffman demonstrates how to detect when objects interact in space. While this video shows circle collisions, the core concept is the same as zone detection: checking if one object's position is inside another object's boundaries.

Discussion after watching: The video checks if circles overlap. Your game checks if a POINT (the player) is inside a RECTANGLE (a zone). What math do you need? (Hint: is player.x between zone.left and zone.right? AND is player.z between zone.top and zone.bottom?)

Position triggers state. When the player walks into a zone, the game state changes. This connects the 3D world to the systems we'll build in Week 3.

You need: Masking tape (painter's tape), a room with floor space, and your voice.

Setup:

  1. Use masking tape to mark 2-3 rectangular zones on the floor. Label them: "DANGER", "SAFE", and "SHOP" (or whatever matches your game).
  2. One person is the "player." The other person is the "game engine."

Play:

  1. The "player" walks freely around the room.
  2. The "game engine" watches their feet. The MOMENT a foot crosses into a zone boundary, they shout: "ENTERING DANGER ZONE!" or "ENTERING SAFE ZONE!"
  3. Important rule: The game engine only shouts when the player CROSSES a boundary — not while they're standing still inside a zone. No repeating!

Key questions after playing:

  • What information did the "game engine" need to do their job? (The zone boundaries and the player's position.)
  • Why did they only shout on CROSSING, not every second? (That's the previousZone !== currentZone check.)
  • What happens if zones overlap? (Confusion! That's why zones must NOT overlap in code either.)

This is EXACTLY what your code does. Every frame, the code checks: "Is the player's x,z position inside this rectangle?" If yes and it wasn't before, trigger the zone-change event. The masking tape is the boundary. Your feet are player.position. The shouting is console.log().
Ami — Combat Risk Engine

If in Manhattan zone → riskLevel increases. If in Camp → can bank (later). For now, console log "Danger Zone" or "Camp".
Ida — Economic Growth Engine

If on a lot → can build (later). If outside lots → no action. For now, console log "On Lot #3" or "Off Lot".

Define game state and check player position each frame:

const gameState = { zone: "safe", previousZone: "safe" };

Position checking inside the animation loop:

// Update zone based on player position if (player.position.x > 50) { gameState.zone = "danger"; } else { gameState.zone = "safe"; } // Log only on zone change (not every frame) if (gameState.zone !== gameState.previousZone) { console.log("Entered zone:", gameState.zone); gameState.previousZone = gameState.zone; }
  • Define zone boundaries using position coordinates
  • Check player position against zone boundaries each frame
  • Update gameState.zone when crossing boundaries
  • Console log zone changes (trigger only once per crossing, not every frame)
  • Test: walk between all zones and verify detection
  • Add a visual indicator: change the ground plane color or player color when zone changes
  • Verify: zone detection matches the graph paper coordinates from Day 9
    •
    Checkpoint

    Walking into a new zone prints a message ONCE (no spam). State updates correctly.

    No encounters yet. No battles. No store. Just detection. Systems come Week 3.

    Logging every frame instead of only on zone change — the console fills with thousands of identical messages.

    Wrong boundary coordinates — the zones from Day 9 don't match the detection boundaries.

    Not storing previous zone to detect transitions — without comparing old vs new, you can't detect the moment of crossing.

    The tape zone activity is the most important part of this lesson. It makes an abstract concept (boundary checking) completely physical and intuitive. When kids later see if (player.position.x > zoneLeft && player.position.x < zoneRight), they'll think "Oh, that's checking if my foot is inside the taped rectangle."

    The "only shout on crossing" rule teaches the trickiest concept: transition detection. Without tracking previousZone, the console would print "DANGER ZONE" 60 times per second. The tape activity makes this obvious — you wouldn't keep shouting "DANGER!" every second while someone stands still.

    This completes the 3D world foundation. After today, both kids have a walkable world with zones. Celebrate this — it's v0.2! Point out how Days 1-5 (design + text prototype) now connect to Days 6-10 (visual world). They've gone from paper to pixels.

    Celebration ideas: Screenshot the game running. Have each kid demo their game to the other. Point out everything that works: camera, movement, zones, detection. That's a LOT of progress in one week. Next week, the systems merge — encounters, jobs, stores.

    Common debugging moment: If zone detection doesn't work, compare the zone coordinates in the code with the graph paper from Day 9. The mismatch is usually obvious when you have both side by side.

    Next week: We add encounters and jobs — things that HAPPEN in these zones. Walking into Manhattan will trigger combat. Walking onto a lot will let you build. The zones you built today become the stage for real game mechanics. Celebrate: you shipped v0.2!

    Both games have a working 3D scene with camera, player movement, defined zones, and zone-based state detection. The stage is set for systems.