Skip to content

Day 29: Revisions

Thursday, April 30th, 2026

🚨

If any groups are ready today, we’ll let two groups present today.

Everyone else, will present tomorrow!

Objectives

  • I can use peer feedback to identify and prioritize the most important fixes to my prototype and presentation.
  • I can revise my prototype and presentation so they are ready to present tomorrow.

Work Session: Final Revisions

Presentations are tomorrow. This is your last chance to fix anything before you stand up in front of the class.

Presentation Rubric

Prototype Rubric

Project Schedule

Step 1 — Review your feedback notes

Pull out the feedback you received from your peers yesterday. Read through every comment.

Then, as a team, answer these two questions before you touch anything:

  1. What is the single most important fix to the prototype? (broken mechanic, missing feature, game-breaking bug)
  2. What is the single most important fix to the presentation? (missing slide content, unclear explanation, no visuals)
Don’t try to fix everything at once. Tackle the highest-impact problems first — if you run out of time, the small stuff matters less than the big stuff.

Step 2 — Fix the prototype

Work through your prototype issues in order of priority:

  • Bugs first — if something breaks the game (crashes, infinite loops, sprites stuck), fix these before anything else.
  • Missing mechanics — if a core feature is absent or unfinished, add it now.
  • Polish last — only adjust sound, visuals, or extra levels if the fundamentals are solid.

After each fix, playtest immediately — make sure you didn’t break something else.

Step 3 — Fix the presentation

Work through your slide issues in order of priority:

  • Fill in any slides that are still empty or have placeholder text.
  • Replace any missing visuals — every slide needs at least one image.
  • Tighten up speaker notes or talking points so every team member knows what to say.

Step 4 — Final run-through

Once your fixes are in, do one complete timed practice run of the full presentation:

  • One person runs the timer — you have 3–5 minutes.
  • Every team member says their part out loud.
  • The person running the demo opens Scratch and plays the game live.

If you go over 5 minutes, trim your slides now — not tomorrow morning.

Your Scratch project must be set to Share (public) before class tomorrow. Double-check this before you leave today. If it is not shared publicly, it cannot be graded.

Checkpoint

  • I reviewed my peer feedback and identified the top fixes for both the prototype and presentation.
  • My Scratch prototype plays from start to finish without breaking.
  • My team completed a full timed run-through and finished within 3–5 minutes.

Closing

Tomorrow is presentation day — there is no more time to revise. Before you leave, confirm that your Scratch project is shared publicly and your presentation file is accessible to Mr. Willingham.

Standards

  • MS-CS-FCP.4.2 — Utilize the design process to brainstorm, implement, test, and revise — students apply peer feedback to make targeted improvements to both the prototype and presentation.
  • MS-CS-FCP.4.10 — Debug a program with an error — students fix bugs identified during peer testing and immediately playtest each change to confirm the prototype works correctly.
Last updated on