Learning to debug
Why does the Scratch score not reset when a new game starts?
The green flag starts scripts; your code must establish the starting score. Make the problem repeatable, check the reset block and test one change at a time.
Describe the bug before moving any blocks
A score of 8 appears after the green flag is clicked, even though the game should start at 0. That is a useful bug report. Saying that the game is broken is much harder to investigate. Ask your child what they expected, what actually happened and which action produced it. Those three observations are enough to begin without an adult knowing the whole project.
The official Scratch scoring tutorial uses a set block to establish the starting score. Pressing the green flag is not a substitute for writing that instruction. First save a separate copy of the project, then identify the variable whose value is shown on the stage. Keep the original available so an experimental fix can be undone.
The people in the hero are fictional AI-generated illustrations. The guide below describes block behaviour, not the unreadable screen in the image; it is not a photograph of our tutors or a client project.
Build the smallest possible scoring test
In a separate practice project, choose one sprite and create one variable named score. For a shared game score, select the option that makes the variable available to all sprites. Show its monitor on the stage. A beginner can now see each change without needing to understand a large game.
Make two short scripts on that sprite. The first is when green flag clicked, followed by set score to 0. The second is when this sprite clicked, followed by change score by 1. These are two separate event scripts, not one stack. Start the project, click the sprite three times, then start again. The visible scores should be 0, then 1, 2, 3, then 0.
Ask your child to predict the next value before each click. If the small test behaves correctly but the original game does not, the problem probably lies in the original project's additional scripts or variable choices. That comparison narrows the investigation without replacing all the child's work.
Set and change do different jobs
Set score to 0 replaces the previous value. Change score by 0 adds nothing, so a previous score of 8 remains 8. Change score by 1 increases the current value by one. Set score to 1 repeatedly replaces it with one, which explains a game that awards its first point but never reaches two.
You can practise the difference away from the computer. Write 8 on a card. For set to 0, replace 8 with 0. For change by 0, leave 8 alone. For change by 1, write 9. This is a simple model of the numerical operation, not a rule that variables must always contain numbers; Scratch variables can also hold text.
Return to the actual blocks and check their names. A child may understand the idea but have selected the neighbouring block in the menu. Let them make the correction and explain what it changes. That explanation is more useful than an adult silently repairing the script.
Match the symptom to a specific inspection
Do not add another reset block every time the score misbehaves. A reset inside a forever loop may keep overwriting points as soon as they are awarded. Two independent point-awarding scripts may both respond to one action. A second variable with a similar name can make the code update one value while the stage displays another.
Look through the Stage and each sprite for every block that sets or changes the score. Temporarily disconnect one suspect stack in the saved test copy, then repeat the same action. If the behaviour changes, reconnect it and explain the result before choosing a permanent fix. Avoid changing the reset, collision logic and game-over code all at once.
| What you observe | What to inspect first |
|---|---|
| Old score survives a new start | A connected startup set score to 0 block for the displayed variable |
| Score returns to zero while playing | A reset inside a loop or another repeating script |
| Every click leaves the score at one | Set score to 1 where change score by 1 was intended |
| One action awards two points | More than one script responding to that action |
| The expected monitor never changes | The variable name and whether it is local to another sprite |
Give the start of the game one clear owner
As a project grows, several green-flag scripts can begin together. Rather than relying on an assumed order between unrelated scripts, organise the reset in one obvious place. A simple pattern is to reset the score and other starting values, then broadcast a start message. Scripts that depend on those values can begin when they receive that message.
This pattern needs to match the rest of the project. A restart button may need to end existing gameplay before starting a new round; adding a broadcast alone does not solve every timing problem. For a first debugging exercise, keep the two-script click test small and reliable. Add one feature back only after the baseline still works.
AI-generated debugging still life, not a real project or software screenshot. Use a notebook to record the action, expected value and observed value while testing.
Finish with a repeatable test, not just a working screen
Run the same sequence twice: start, earn three points, stop, restart and earn one point. The score should begin at zero on each start and finish at one after the final click. Also restart after earning no points. Write down the result rather than relying on a memory that it looked right once. Keep a note of the block changed and the reason.
If your child wants help understanding the logic, our coding lesson information explains the scope and the need to confirm a suitable tutor's availability. A useful enquiry includes age, experience, the intended project behaviour and the smallest example that still fails. Never share account passwords or private information embedded in a project.
Families considering an in-person session in Berawa can use the Berawa lesson-planning page to discuss the location and practical arrangements. For the adult's role during the work, our guide to teaching rather than completing homework offers a helpful boundary: the child should remain the person making and explaining the changes.
Frequently asked questions
Do I need to rebuild the whole game?
Keep the original and make a test copy first. Reduce the problem to one variable, one reset and one scoring action. If that works, restore features gradually. Rebuilding everything at once makes it difficult to learn which instruction caused the problem.
Should every sprite reset the score?
A shared score is usually clearer with one deliberate startup reset. Multiple resets in different places can make the project harder to reason about. Sprite-specific values may need their own initialisation, so inspect the variable scope instead of applying one rule to every variable.
Related
Message us on WhatsApp: +62 858 6969 6869 · info@privatetutoringbali.com · We reply within one working day.
Sources and further reading
Published by Private Tutoring Bali. Sources and corrections.