- Learnt27 min · the name clash, the naming rule, a third game
- Basic25 min · fill all three doors
- Challenge 1–327 min · your third game, clean swaps, one look
- Extrabonus · tokens every game pays into
Review — where we got to 5 min
The cabinet works with one game in it. Adding the second is not the same job twice.
- A screen is a broadcast, and every sprite answers it with show or hide.
- Leaving a game means
stop [other scripts in sprite v]anddelete this clone.
Quick-fire
Both your games have a variable called score. What happens when they end up in the same project?
Reveal the answer
There is only one of it. Both games write to the same number, and each one wipes the other’s.
Today’s Topic 3 min
- What happens when two games share a variable name
- A naming rule that keeps three games apart
- Messages belong to a game too, and clash the same way
- A whole third game, built from nothing, in ten minutes
Learning outcome
By the end of this lesson you will be able to:
- Spot a name clash by the bug it causes.
- Name variables and messages so three games can share one project.
- Build a small game quickly from parts you already know.
Learnt — the clash, the rule, a third game 27 min
1 · Two games, one score
Bring Paddle Bounce in beside Jump Dash and something odd happens. Neither game is wrong. They are just both right about a number that only exists once.
- Backpack the Paddle Bounce sprites into the arcade project.
- Change their hat blocks to
when I receive [bounce v]. - Play Jump Dash and get a score you are pleased with.
- Go home, open Paddle Bounce, and watch the number.
- Go home again and open Jump Dash. Your score has gone.
How to use this: Click the green flag, then click the left button and watch the score climb. Now click the right button — the score you just earned is gone.
2 · One name each
The fix is dull and it is the whole answer: every game’s things get that game’s name in front of them.
- Right-click each variable and rename it:
dash score,bounce score. - Scratch changes every block that used it, so nothing breaks.
- Do the same for lives, speed and level:
dash lives,bounce lives. - Now the messages.
game overbecomesdash overandbounce over. - Play both games again and check both numbers hold.
How to use this: Click the green flag, then click one button and then the other. This time both numbers survive, because each game has its own.
3 · A third game in ten minutes
Star Tap is small on purpose. Every block in it is one you have used, and the whole game is nine blocks.
- Add the Star sprite.
- On
when I receive [tap v]: show, set the score to 0, reset the timer. - Add
repeat until <(timer) > (20)>. - Inside it: go to a random spot, then
wait (0.8) seconds. - On a second stack:
when this sprite clicked, a sound, and a point. - Play it. Twenty seconds is longer than you think.
when I receive [tap v]
show
set [tap score v] to (0)
reset timer
repeat until <(timer) > (20)>
go to x: (pick random (-200) to (200)) y: (pick random (-130) to (130))
wait (0.8) seconds
end
hide
broadcast [tap over v]
when this sprite clicked
start sound [Collect v]
change [tap score v] by (1)
How to use this: Click the green flag, then click the star as many times as you can before the twenty seconds run out. It moves every 0.8 seconds whether you catch it or not.
Basic — fill all three doors 25 min
Do the renaming before you add anything. It is much worse later.
Step 1 — rename what you have
- Every Jump Dash variable gets dash in front of it.
- Every Jump Dash message too.
- Play Jump Dash once and check nothing broke.
Step 2 — bring the second game in
- Backpack its sprites across.
- Rename its variables and messages before you play it.
- Change its hat blocks.
- Give every one of its sprites a menu stack.
Step 3 — build the third
- Add the star and its two stacks.
- Give it a menu stack like everything else.
- Wire the third button to it.
Step 4 — the round trip
- Play all three, in every order you can think of.
- Check each score after playing the other two.
Step 5 — write it down
- List every variable and every message in the project.
- Mark which game each one belongs to, or write shared.
- Anything you cannot label belongs to nobody and should go.
Renaming the variable broke a block.
It did not. Renaming updates every block. If something broke, a second variable with a similar name was made instead of renaming the first.
Both games start when I click one button.
Two games are listening for the same message. Check the receive hats.
The star can be clicked on the menu.
It is hidden but its clicked stack still runs. A hidden sprite cannot be clicked in Scratch — so it is not hidden. Check its menu stack.
Star Tap never ends.
reset timer is missing, so the timer was already past 20 when the game started.
Make the third game yours
Star Tap as built is the simplest possible version. Add one idea to it.
- Something new: a second thing to click, or one to avoid, or a star that shrinks.
- It still ends after twenty seconds.
- The score still makes sense.
Leave at the worst moment
Quit each game at the most awkward point you can find, then start it again. It should not be able to tell.
- Leave mid-hop, mid-rally, mid-click.
- Leave while a game-over message is on screen.
- Every restart begins exactly as it should.
Teacher note — the three awkward moments
Mid-clone is the one that breaks: rocks or crystals left flying. Mid-say leaves a speech bubble on the menu. Mid-wait leaves a script sleeping that wakes up during another game.
All three are fixed by the same menu stack, which is why this mission is a check and not new work.
One machine, not three
Your three games were built weeks apart. Make them feel like they came out of the same box.
- The home button is in the same corner in all three.
- Scores are shown in the same place in all three.
- The same sound means the same thing everywhere.
- Every game says its own name when it starts.
Teacher note — consistency is a design idea, not a tidy-up
The point is that a player learns the machine once. Ask the class where the home button is on their phone: it does not move between apps, and that is not an accident.
One number all three games pay into
Every score belongs to its own game. Add one that does not — a token count that goes up whatever you play.
How to use this: Click the green flag, then click each of the three buttons in turn. Every game pays into the same tokens number, and it never resets.
- One shared variable that every game adds to.
- It is never reset when a game starts.
- The three games pay at rates that feel fair for how long they take.
- It is on screen on the menu, and only there.
Teacher notes — the fair rate, and what tokens are for
A twenty-second tap game and a three-minute bounce game should not pay the same. Ask pupils to time a game of each and set the rates from that — it is their first piece of balancing across two different things.
Tokens with nothing to spend them on are just another score. If a pupil asks what they are for, that is the right question, and the honest answer is that a shop needs more than Level 1 has. Level 2 builds one.
Going further: next lesson the scores stop belonging to whoever is sitting there and start belonging to a name.
Summary 4 min
Three games in one project, and the hard part was none of the games.
- A variable belongs to the project. Two games sharing a name share the number.
- Put the game’s name in front of everything that belongs to it.
- Broadcasts clash the same way, and cannot be renamed — so choose them first.
- A small game built from parts you know takes ten minutes, not a term.
- Name clash
- Two things wanting the same name, so they end up being one thing.
- Shared
- A variable or message that really does belong to the whole project.
- timer
- Seconds since it was last reset. A whole game can be built on it.
- Consistency
- The same thing in the same place in every part of a project.
Next lesson: a scoreboard, a name typed once, and three records worth beating.