Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Session 8: Milestone project work day 1

Phase 1 — Scratch · Session 8 of 9

What we’re learning today

Today is your day. You’re going to plan a game of your own choosing, then start building it. There’s no new programming concept this week — instead, you’ll use everything you’ve learned to make something that’s yours, not Mr. Eric’s. Next week you’ll finish it and show it to the class.

You’ll need to remember from last time

  • Everything from Sessions 1-7. No, really. Sequences, loops, events, conditionals, sensing, variables. You’ll use all of them.
  • Apples and Rocks from Session 7 — proof that you can build a complete game. If you built it, you can build something else too.
  • The idea you brought with you today. (If you didn’t bring one, that’s okay — Part A will help.)

Part A: Plan your game

The most important thing a programmer does isn’t typing code. It’s deciding what to build before they start. Real software projects fail far more often because nobody decided what they were building than because the code was hard. Today you’ll do the planning step.

The plan

Take a piece of paper (or open a text editor). Answer these questions about your game. Don’t think too hard yet — first answers are usually fine.

  1. What’s the name of your game? (Make one up. You can change it later. Examples: “Donut Drop,” “Cat vs. Asteroids,” “The Royal Quest.”)

  2. In one sentence, what is your game? (Try to fit it on one line. Example: “You’re a wizard catching falling books to build a tower.”)

  3. What sprites do you need? (List them. Example: “Wizard sprite, three book sprites, a tower-base backdrop.”)

  4. What does the player do? (How do they control things? Arrow keys? Click sprites? WASD? Some combination?)

  5. What’s the goal? (How does the player know they did well? Score that goes up? Reach a place? Survive a long time?)

  6. What can go wrong? (How does the game end, or get harder? Game over? Missed too many? Time runs out?)

  7. What’s the simplest version that’s still fun? (This is the most important question. If you only had today and next week to build this, what would you do FIRST? What would you add LATER if there’s time?)

Talk it over with your buddy

Spend 5 minutes telling your buddy about your plan. Then your buddy tells you about theirs. Each of you says one thing about the other’s plan — could be a question (“how does the player restart?”) or a suggestion (“you could add a sound when they win!”) or just an observation (“that sounds fun”). One thing. Don’t redesign each other’s games.

Show Mr. Eric

When your plan is ready, show it to Mr. Eric. He’ll either say “go build it” or ask one question that helps you tighten it up. If he asks a question, that’s not a bad thing — it means there’s something worth thinking about for two more minutes.

Checkpoint: You have a written plan with all seven questions answered, and Mr. Eric has signed off on it. This is the natural stop point if class is cut short — you can start building next week, and you’ve done the most important thing already by planning.

Part B: Start building

Now you build. The rest of class is yours.

Where to begin

Don’t try to build everything at once. Real programmers build the simplest version that works first, then add to it. Look at your answer to question 7 above — that’s where to start.

If your game is “wizard catches falling books,” the simplest version is:

  1. Wizard sprite that moves with arrow keys.
  2. One book sprite that falls.
  3. When the wizard touches the book, score goes up.

That’s it. Then add a second book. Then add a way to lose. Then add the tower visual. Then add sounds. Each step works before the next one starts.

This is called iterative building and it’s the secret most programmers wish they’d learned earlier. Build small. Test it. Build more. Test it. Repeat.

When you get stuck

When (not if) you get stuck:

  1. Read your code carefully. Did you tell the computer the exact thing you meant? (Remember the peanut butter problem.)
  2. Ask your buddy. They might see something you don’t.
  3. Look at how you did something similar before. If the apple in Apples and Rocks worked the way you want, copy that pattern.
  4. Ask Mr. Eric. Last resort, after the first three.

Getting stuck is normal. Programmers spend most of their time stuck. The skill isn’t avoiding stuck — it’s getting unstuck.

Wrap-up

Last 5 minutes: each of you, in one sentence, tell the room one thing you got working today in your project. Could be a sprite that moves. Could be a score that updates. Could be a backdrop that loads. Whatever’s working — that’s a win.

Don’t worry if you didn’t get as far as you wanted. Most projects take longer than the plan said they would. That’s why the plan asked about the simplest version first — so you’d have something working even if you ran out of time.

Bring your project file (or just your machine if it’s your class computer) next week. We’ll finish, then demo to the class.

If you missed this session

Open Scratch and start a new project. Then:

  1. Spend 10-15 minutes answering the seven planning questions above on paper or in a text file.
  2. Start building the simplest version of your game (look at your answer to question 7).
  3. When you come next week, you’ll be ready to keep building.

If you don’t have an idea, here are some starting points:

  • A different falling-things catcher (catching donuts, coins, letters of the alphabet)
  • A maze game where the player has to reach a target
  • A pet care game (click the sprite to “feed” it; a hunger variable goes down over time)
  • A whack-a-mole game (a sprite appears at random spots; click it before it disappears)
  • A tiny choose-your-own-adventure (sprite asks a question, you click left or right side of the screen, the story branches)

Any of those can be built with what you know. Pick one and modify it — make it your own. Don’t just copy.

Stretch and extension ideas

If your base game is working and you want to add more:

  • A second screen — use a backdrop change at game over so the player sees a different background.
  • Multiple difficulty levels — a variable that controls how fast things fall, increased by score.
  • A start screen — when the green flag is clicked, show instructions until the player presses space, then start the game.
  • Sound effects for important moments (catch, miss, game over).
  • A costume change for any sprite at an interesting moment.

Whatever you add, add it one piece at a time and test after each piece. Big changes that touch many things are how games break.

What’s next

Next week you’ll have time to finish, polish, and demo your game to the rest of the class. Each person will get 3-5 minutes. Don’t worry — it’s a friendly demo, not a test. Bring a working game, bring your enthusiasm, and the rest takes care of itself.