Expected result
Write down what should happen before editing.
Topic Guide
Debugging begins with a precise difference: what should have happened, and what happened instead?
Guessing becomes expensive as a project grows. Students reproduce the problem, inspect a relevant value, choose one possible cause, and run a test that can prove them wrong.
If a bicycle chain slips only in one gear, that detail matters. A useful game bug report works the same way: it records the exact state and actions that produce the fault.
Write down what should happen before editing.
Describe what happened, without adding a guessed cause.
Name one possible explanation.
Inspect or change one thing that bears on that explanation.
Read x and y when movement goes wrong.
Check whether the game records PLAYING, WON, or LOST.
Run one sprite, sensor, or rule by itself.
Find a sequence that makes the same problem happen again.
Program connections
Students author games, animations, simulations, and strange interactive stories while learning how events, rules, and state fit together.
Students write commands, wire simple circuits, read sensors, and trace physical cause and effect through the Sense–Decide–Act loop.
A possible later step from visual programming into Lua, 3D objects, events, and larger game rules.
A possible later program for testing patterns, predictions, prompts, mistakes, and the limits of AI tools.
The bug disappears, but the useful evidence disappears with it.
The centre of the stage works while the edge remains broken.
A mistaken sign or state rule is left unexamined.
Extra blocks hide the fault without correcting the underlying value.
Build a fast chase game with known positions, collision rules, win and loss states, and reliable restart behaviour.
See how it worksWrite a robot route, predict where it will end, and trace the first command that goes wrong.
See how it worksBuild a reaction timer with a random delay, an early-press rule, and results in the correct units.
See how it works