Terminology and Concepts to look out for

specification · proto-spec · overview · structure · style · behavior · Google Form as repo

Relevance to Me

You are going to build a video game this week. But you are not going to touch code. Today, you are going to describe your game in English, in a guided form, and hand it in — that description becomes your project repo. Every day this week, you will open that same form, refine it, and see if your writing produces a working game.

Today: no tool. All writing.

Board Question

Chromebooks stay closed for the passage — this is a reading, not a tool day. When the form goes up, fill in Folder 1: Overview completely. You may sketch answers into folders 2 (NPCs) and 3 (Behavior), but the form stays open all week — you will refine those Tuesday through Thursday. Folder 4 (submission + reflection) waits until Friday.

This week you are going to build a video game. But you are not going to type a single line of code. You are going to write English — precise, layered English — that a machine will turn into code for you. What you write is what you get. What you do not write, you do not get. The tool that stands between your words and the code is called MuggsOfVibes, and you will meet it tomorrow.

Today is design day. Today you decide what your game IS, in a form you fill out and hand in. That form is not a homework question. That form is your project's repo — the durable record of what your game is supposed to be. Every day this week, you will reopen that form (using the "Edit your response" link on the confirmation screen) and add to it. By Friday, that form will contain the whole English description of your game. You will paste it, one turn, into a fresh MuggsOfVibes session, and if the game that comes back is the game you built, you have passed.

The four folders of your form.

Your form has four folders. Today you fill in Folder 1 completely and sketch what you can into folders 2 and 3. Folder 4 waits until Friday.

1. Overview of Your Game — What is your game? Name, one-sentence pitch, win condition, lose condition, mood. (Monday's main work.)
2. Structure and Style of Your Game — The "checker board," not the "checkers." The parts of the screen and how each looks. HTML + CSS paired per element. (Tue–Wed.)
3. Your Game's Behavior — The parts a player truly interacts with, and what makes them react. (Thursday.)
4. Submit + Reflect — Friday. Final compressed proto-spec + reflection.

NPCs and Interactive Elements.

There are two kinds of things on your game's screen, and they get described in two different folders.

NPCs — Non Playable Components. The static parts of the screen. The container that holds the game. The play area itself. A decorative border. A title at the top. A frame around the score. None of these move. None of these react to the player. But they have to exist and they have to look right, or the game does not feel like a game.

The checker board is an NPC. The checkers are not.

You describe the NPCs in Folder 2 — Structure and Style. Each NPC gets an HTML slot (a noun and a prepositional phrase — "a container, holding the whole game") and a CSS slot (adjectives — "the container is centered, with a thin dark border"), paired together. Minimum five NPCs.

Interactive Elements. The things a player truly interacts with. A paddle they move. A ball that bounces. A button they click. A brick that disappears. A score that changes. These are the "checkers." They have to react, respond, change.

You describe the Interactive Elements in Folder 3 — Behavior. Each Interactive Element gets a single slot 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? All four in one description, because for an Interactive Element the appearance and the behavior are inseparable — a paddle that slides needs to look like something that can slide.

The three tests you can run on any sentence.

Every sentence you write in your form belongs somewhere. To know where, run three tests:

• If it needs to be on the screen, it needs HTML. A paddle, a ball, a score, a container, a Play Again button. Nouns and prepositional phrases.
• If it needs size, color, or mood — it is CSS. Colors, sizes, shapes, positions, mood. Adjectives.
• If it needs to do something — if it drives interactivity — it is JavaScript. "Slides when the arrow key is pressed." "Disappears when the ball hits it." Verbs with when-clauses.

If the thing you are describing only needs HTML and CSS to exist — it is an NPC. Put it in Folder 2. If the thing needs JavaScript to react to the player — it is Interactive. Put it in Folder 3.

Why the form is your repo.

Programmers who work on real projects for real jobs use a system called a repository — a "repo" — to keep the durable version of what they are building. When they make a change to the project, they commit the change to the repo, so tomorrow's version and today's version are both preserved. The repo is the truth; anything not in it is not part of the project.

This week, your Google Form is your repo. Every time you learn something new about your game, you open the form and commit — you update the form with what you learned. Whatever is in your form on Friday is what gets graded. Whatever is not in the form does not exist.

Starting Tuesday, when you use MuggsOfVibes to compile your form into a working game, the same rule holds: if it works and looks good in the tool, you commit that back to your form. You copy from the tool, you paste into the form, you save. The tool is temporary; the form is permanent.

Today's job, section by section.

• Fill in Folder 1 completely. Name your game. Pitch it in a few sentences. Say how someone wins. Say how someone loses. Say the mood in two or three words.
• Sketch Folder 2 if you have time. Describe where your game takes place. Name five NPCs. For each, write an HTML slot and a CSS slot. You do not have to finish today — the rest of the week is for that.
• Sketch Folder 3 if you have time. How does the game begin? What triggers a win / a loss? Name a couple Interactive Elements.

A guided example.

A brick-breaker called Breakout Lite. Pitch: "You control a paddle at the bottom of a play area, bouncing a ball off it to break rows of bricks above." Win: "break every brick." Lose: "let the ball fall past the paddle." Mood: "retro, calm, one color."

Folder 2 sketch (NPCs): 1. Play area: "A rectangular play area, centered on the screen, with a thin dark border. Dark blue background. The bricks and the score are inside this area." 2. Element 1 (HTML): "A container, holding the whole game." (CSS): "The container is centered horizontally, with a subtle drop shadow." 3. Element 2 (HTML): "A score, at the top of the play area." (CSS): "The score is large, yellow, in a retro monospace font." 4. Element 3 (HTML): "Three rows of bricks, at the top of the play area, below the score." (CSS): "Three shades of red, each row a slightly darker shade than the one below." 5. ...and so on for elements 4 and 5. 6. Overall mood: "Dark blue background, retro monospace font, sparse."

Folder 3 sketch (Interactive Elements): 1. How the game begins: "The player clicks Start. A paddle appears at the bottom. A ball appears above the paddle and starts moving diagonally." 2. Win/Lose: "The game is won when every brick has disappeared. The game is lost when the ball falls past the paddle." 3. Interactive Element 1: "The paddle. Rectangular, orange, at the bottom of the play area. It slides left when the left arrow key is pressed and right when the right arrow key is pressed." 4. Interactive Element 2: "The ball. Small, white, circular. It moves diagonally on a timer, bouncing off the walls and the paddle. When it hits a brick, the brick disappears and the score goes up by ten." 5. ...and so on.

One rule about what the tool does.

The tool does not know your game. It only knows what you write in the tree. Writing "I want to build Breakout" in Folder 1 does NOT summon Breakout — the tool will not put a paddle, a ball, or bricks on the screen unless you describe each one, by itself, as an element in Folder 3 (for the static ones) or Folder 4 (for the moving ones). The pitch is intent. Folders 3 and 4 are content. Empty folders produce empty screens.

Folder 2 is the minimum. Nothing renders until you describe your Playing Canvas — the stage your game lives on. Once the canvas exists, Compile will show it: visible, styled, and empty. That is a real, useful thing to see — the room your game will happen in. It is not playable yet. Add NPCs in Folder 3 and they appear inside the canvas as static parts. Add Interactive Elements in Folder 4 and the game becomes playable.

That is the whole point of this week. You do not learn to build a game by naming a famous one. You learn to build a game by describing every element clearly enough that a machine can reproduce it from your words. Silence in a folder means nothing appears from that folder.

One rule about what you build.

This is a school. Build a school-safe game. No violence, no weapons, no gore, no depictions of humans or animals being hurt. That does not mean your game has to be boring — it means the language changes.

Love zombies? Build Hydro Zombies: you spray zombies with water and they become calm, hydrated, and walk away. Same shape as a shooter — a moving target, a score, a challenge — with a mechanic that fits the room you are in. Fighting game? Make it a dance-off, a tag game, a block-and-dodge. Weapons? Water sprayer, paint gun, beanbag launcher, foam noodle. The tension in your game comes from the rules — the timing, the difficulty, the score — not from the harm.

Keep the challenge. Change the language.

Today ends with a form submitted.

Fill in Folder 1 completely before the bell. Submit the form. The confirmation screen has an "Edit your response" link — copy that link somewhere safe (your notebook, a doc, an email to yourself) because that is how you will open your form again tomorrow. If you lose the link, ask Mr. Muggivan — the form is set to allow response edits, so you can always reopen it.

Tomorrow you meet the tool. Today you write the game.