Terminology and Concepts to look out for
Folder 3 · NPC · noun + prepositional phrase · adjective · mood as compass · five-element minimum · form-as-repo
Relevance to Me
Yesterday you built the stage — Folder 2, the Playing Canvas — and started Folder 3, the NPCs. You wrote Elements 1, 2 and 3.
Today you finish Folder 3 and reach the five-element minimum. Then you go back through what you already wrote and make the adjectives carry more.
Today is also when style starts to matter. Not decoration — fit. Every adjective you add should serve the mood you named Monday.
Board Question
Yesterday you counted your NPCs and named one more.
- Write that one's HTML. A noun, and where it sits on the screen.
- Now its CSS. Two or three adjectives, not one. "Orange" is a color. "Bright orange, wider than it is tall, with rounded corners" is an element.
One element, two lines.
Your answer now is not supposed to be right.
Chromebooks open to /vibes — click the link on Deck 2. No code, no password.
Open the Google Form on the right pane of Deck 2 and hit "Edit your response" to see your running spec. Paste your folders back into the tool, or click Paste full spec and drop the whole thing in at once.
Today: Elements 4 and 5 in Folder 3, then go back and thicken the adjectives on 1, 2 and 3. Compile. Look at it. Compile again only when you have changed something.
When Folder 3 looks like the stage of a game you would want to play, commit it back to the form.
Yesterday you built the stage and put the first three things on it. Today you finish Folder 3 and make it look like something specific.
Two jobs today.
- Reach five. Elements 4 and 5, so Folder 3 meets its minimum.
- Thicken the adjectives on the elements you already wrote.
Reaching five.
If you are stuck for a fourth and fifth NPC, picture the arcade machine your game would live in. The name across the marquee. The instruction card under the screen. The artwork around the edge. The frame around the score. Most of that is Folder 3.
These five work for almost any game:
- The game's name across the top
- The word
SCORE:— the label, not the number - A frame or box around the score
- A line of instructions — "Press the arrow keys to move"
- A border or decoration on the edge of the play area
And remember the test. Does it change during play? If yes, it is not an NPC — it goes in Folder 4 tomorrow.
Thickening the adjectives.
Yesterday you may have written "the paddle is orange." One adjective, done. Today look at each element and ask: does this carry enough to make it look like something specific?
- "The paddle is orange" — you get an orange rectangle. Fine. Generic.
- "The paddle is bright orange, wider than it is tall, with rounded corners and a soft shadow underneath" — now there is a specific paddle to build.
Every adjective you add takes something away from the model to guess about. That is the whole trade.
But do not lie.
If your mood from Monday is retro, calm, one color, and you write "metallic silver with a shiny chrome finish," the paddle will look wrong against everything else on the screen. Not because chrome is bad — because it is fighting the game you said you were making.
Mood is a compass, not a decoration. When a style fights the mood, one of them is wrong. Either tone the style back, or go change the mood in Folder 1. Both are legitimate. Leaving them at war is not.
The reverse question.
A habit worth building today. After each compile, most people ask "did the model give me what I asked for?" Ask the other one instead:
> Does the model's code describe what I actually wrote?
Open the code pane and read the CSS.
- You wrote "the paddle is orange." The model wrote
background: #FF6B35. That is orange. Match. - You wrote "orange with rounded corners." The model wrote
background: #FF6B35; border-radius: 8px. Match. - You wrote "the paddle is small." The model wrote nothing about size. Miss — "small" was too vague to act on.
When you find a miss, the fix is in your sentence, not in compiling again.
And if the model added something you never asked for — a glow, a gradient, a hover effect — that is worth noticing too. Tighten the line so there is less room for it to invent.
Blank CSS is not neutral.
Leave a CSS line empty and that element comes back a plain grey box. The tool will not pick something nice for you. An element you styled should look designed; an element you did not should look unfinished. The page is showing you where your writing ran out.
It is not a game yet, and that is correct.
You will compile this afternoon and nothing will move. The ball will not bounce. The paddle will not slide. That is not a bug.
Today's compile should look like a screenshot of your game — one frame, frozen, everything in its right place looking the way you meant it to look.
Motion is a verb, verbs are JavaScript, and JavaScript is Folder 4. Tomorrow.
The reason it works this way is worth sitting with: tomorrow you will add behavior to this exact screen, and you will be able to see precisely what behavior added. If everything had moved from the start, you would never get to see what a verb actually does.
Compiling is not the work.
The tool refuses a compile when nothing has changed since your last one — it would build the exact same page. It will also ask you to take a break if you hammer it. If the screen is not what you wanted, the fix is in your writing.
The commit rule.
Every time a compile looks right, commit it. Click Copy on the Folder 3 header, open your form, paste it into the Folder 3 field, submit with "Edit your response."
The tool forgets when the tab closes. The form is your repo, and it remembers.
By the bell, Folder 3 should be complete — five elements, all styled, all fitting the mood you named Monday.
Tomorrow is Folder 4 — Scripts. Tomorrow the ball starts moving.