Terminology and Concepts to look out for

Folder 4 — Scripts — Interactive Element — verb — trigger — when-clause — behavior

Relevance to Me

Yesterday you finished the NPCs — the checker board. Today you build the checkers.

Folder 4 of your project's repo is Scripts — Your Game's Behavior. It holds "How does the game begin?", "What triggers a win? What triggers a loss?", and at least five Interactive Elements — the things a player actually interacts with.

An Interactive Element is a part of the screen that changes during play. That is the whole difference. If it never changes, it is an NPC and it belongs back in Folder 3.

Each Interactive Element is one paragraph answering four questions together: what is it, what does it look like, what does it do, and what causes it to do that?

Board Question

Chromebooks open to /vibes — click the link on Deck 2. No code, no password. Open the Google Form on the right pane and hit "Edit your response." Get your spec back into the tool — paste folder by folder, or click Paste full spec and drop the whole thing in at once. Then Folder 4: how the game begins, the win and lose triggers, and your Interactive Elements. Build one at a time. Get one working, compile, then add the next. Every verb needs a when. Commit back to the form.

Two days building the checker board. Today, the checkers.

You fill in Folder 4 — Scripts, your game's behavior. Folder 4 has three kinds of items: how the game begins, what triggers a win / a loss, and Interactive Element 1 through 5 — the things a player truly interacts with. Each Interactive Element gets a single paragraph that answers four questions together: what is the element, what does it look like, what does it do, and what causes it to do that?

Interactive Elements are not NPCs.

Yesterday's Folder 2 was NPCs — the static parts of the screen. The container. The play area. The border. The mood-setting stuff. NPCs do not react to the player; they set the stage.

Today's Folder 3 is the actors on that stage. The paddle the player slides. The ball that bounces. The button that starts the game. The score that changes. The brick that disappears when hit. These are the elements the player truly interacts with, directly or indirectly. They react. They respond. They change.

Why the form puts everything about an Interactive Element in one paragraph.

For an NPC, you can describe the HTML (what it is) separately from the CSS (how it looks) — the two are related but independent. Yesterday's paired HTML and CSS lines reflected that.

For an Interactive Element, the four parts fuse together: what it is, what it looks like, what it does, what causes it to do that. A paddle that slides has to look like something that can slide. A brick that disappears has to look like a brick, be located somewhere the ball can reach, and vanish when the collision happens. The description carries all of that at once, so the form asks for it all at once.

Example — Interactive Element 1: "The paddle: a wide flat orange rectangle at the bottom of the play area, about a fifth as wide as the play area is. It slides horizontally along the bottom edge — left when the left arrow key is pressed, right when the right arrow key is pressed."

Read that back. What: paddle. What it looks like: wide flat orange rectangle, a fifth as wide as the play area. What it does: slides horizontally. What causes it to do that: left/right arrow key press.

One paragraph. Four questions answered together.

How does the game begin?

This item on the form is important and often skipped. Folder 3 asks it directly. When a player loads the page, what do they see? What is the first thing that happens? Are elements already moving? Is there a Start button? A title screen? A countdown?

Answer this in Folder 3 Item 1 of the form. "The player loads the page and sees the play area, with the paddle at the bottom and the ball above it, stationary. The score reads zero. The player presses any arrow key to begin — the ball starts moving diagonally."

That is a behavior — it describes what happens on page load, and what triggers the ball to start moving. Behavior.

What triggers a win? What triggers a loss?

Folder 3 Item 2. Two sentences. Each is a verb-plus-when.

"The game is won when every brick has disappeared. The game is lost when the ball falls past the paddle."

Both are Interactive Elements at heart — a win state (something happens) and a lose state (something happens) — with triggers.

Every verb needs a when.

If you type "the paddle slides left" — no when — the model has to guess. Does it slide on a timer? When you hover? When the ball hits it? The compile will land somewhere, but not necessarily where you meant.

Real triggers — events a computer can actually notice:

• A key press — "when the left arrow key is pressed"
• A click — "when the Play Again button is clicked"
• A timer — "every 16 milliseconds," "on a timer"
• A collision — "when the ball hits a brick"
• A boundary — "when the ball reaches the top of the play area"
• A game-state change — "when the score reaches 100," "when every brick is gone"

Vague whens do not work. "When it's cool." "Sometimes." "In the middle of the game." Those are not events a computer can hear.

The three tests, still holding.

• On the screen → HTML → NPCs (Folder 2). If today you catch yourself adding a new element to Folder 3, back up: the element should exist in Folder 2 first, then react in Folder 3.
• Size, color, mood → CSS → NPCs (Folder 2). Same as above — style lives with structure, in Folder 2.
• Does something with a when → JavaScript → Interactive Elements (Folder 3). This is today.

Something can sound like CSS but belong to Behavior. "The paddle turns red when the ball hits it." The word "red" is a color — CSS-adjacent — but the whole sentence is a behavior because it has a when. Red-when-something-happens is Interactive. Red-all-the-time is NPC style.

Same logic for a game-over screen: "the game-over screen appears when the ball falls past the paddle." "Appears" plus "when" — Behavior. Even though the game-over screen itself has to exist as an NPC in Folder 2, its appearance is an Interactive Element in Folder 3.

Give your game ONE working Interactive Element.

Do not try to wire five Interactive Elements on Thursday. Pick the one that most makes your game feel like a game — usually the player's own input. The paddle sliding. The character moving. The button starting the game. Get one right today, and let the others follow if you have time.

Real game engineers build behavior one verb at a time. When one works, add the next.

The compile workflow.

1. Open your Google Form and hit "Edit your response." 2. Get your spec back into the tool. Fastest way: in the form's Section 5, copy your complete proto-spec, then in MuggsOfVibes click Paste full spec and drop it in. Folder by folder works too — copy each folder from the form into its matching folder in the tool. 3. Fill in Folder 4 — Scripts: - "How does the game begin?" - "What triggers a win? What triggers a loss?" - Each Interactive Element, one paragraph each. 4. Need another Interactive Element? Add one at the bottom of Folder 4. 5. Compile. Test. Refine.

When one Interactive Element works — commit it back to your form. Click Copy on the Folder 4 header. The whole folder serializes in form order: how the game begins → win and lose triggers → each Interactive Element in turn. Paste it into your form's Folder 4 field. Submit with "Edit your response."

Add the next Interactive Element. Compile. Test. Commit. Repeat.

Before the bell:

Folder 3 of your form should have at least: how the game begins, what triggers a win / a loss, and one to three Interactive Elements fully described. Tomorrow you verify all of it.