An algorithm describes ordered steps for achieving a result. It can exist on paper: route instructions are algorithms too when they specify the necessary actions. A program expresses instructions in a language a computer can execute. In Scratch we use blocks. The machine follows what we have specified, so an intention such as ‘arrive successfully’ must become observable actions and conditions. We must also agree where the route starts and which way the character faces.

Decomposition means dividing a problem into parts we can understand and test. In an interactive story we can separate the introduction, the user’s choice and the response. Each part has an input or starting action and an expected result. We then check how the parts relate. This helps locate errors: if the choice works but the response does not change, we investigate that relationship. Writing the plan before dragging blocks lets partners discuss it and improve an ambiguous instruction without rebuilding the whole project.

A flowchart represents a process’s order using shapes and arrows. We usually use ovals for start and finish, rectangles for actions and diamonds for questions. The shapes execute nothing: they communicate a proposal. An arrow indicates where to continue; at a question, each outgoing path needs an answer such as Yes or No. If a branch has no destination, another person cannot know what to do in that case. A clear route therefore matters more than decoration.

An interactive program may check a question again. The diagram must show that return when the action needs repetition. Asking about a key once differs from monitoring it throughout a game. In diagrams.net we draw readable paths and add a short written description so someone can follow them without interpreting the shapes. Partners can trace the branches using concrete cases. Exporting a PNG makes the drawing easy to include in the design document, while keeping the editable file allows later revisions.

Scratch lets us create animations, stories and games by connecting blocks. The stage shows the result of execution. Sprites or characters can have their own scripts, costumes and sounds; the backdrop belongs to the stage. The palette groups block categories, and the coding area contains instructions for the selected element. Before adding or changing blocks, check which sprite you are editing. A correct movement instruction placed on the target moves the target, even if you were thinking about the player.

Colors help locate categories, but we must also read names and recognize shapes. A start block identifies the event that launches its sequence. Disconnected blocks do not run with it simply because they are nearby on screen. A costume changes a sprite‘s appearance without necessarily creating a new character. Depending on the classroom setup, we can use the editor or Scratch Desktop and keep an .sb3 file without creating a personal account. That project preserves editable blocks; a screenshot shows only one moment.

Position is expressed as a coordinate pair, x and y. In Scratch‘s usual stage, the center is (0, 0), the horizontal axis runs from −240 to 240 and the vertical axis from −180 to 180. Increasing x moves right; increasing y moves up. Negative values indicate the opposite side of the center. These coordinates describe the stage, not centimeters in the physical world. To trace movement, keep the axes separate and include the starting position.

Setting x to a value replaces the previous coordinate. Changing x by a value adds that amount to the current position; a negative increment subtracts. Repeating an assignment does not produce the same route as repeating an addition. Direction is another property: it indicates where the sprite points. Moving steps follows that direction, whereas changing x acts along the horizontal axis. Setting both position and direction at the start makes tests comparable and helps explain whether a difference comes from the program or a different starting state.

An event is something a program can respond to: a key press, a click on a sprite or activation of the flag. The event block starts the instructions connected below it. Order matters within that sequence: saying a message before moving communicates something different from saying it afterward. Waiting lets us observe an action for a period, but adds no distance by itself. To explain what happened, first identify the event you triggered, then follow its instructions in order.

The flag can prepare the initial state while a key triggers another action during use. These are separate sequences. Several sprites may respond to the same flag, and one sprite can have several scripts; do not assume everything runs as one ordered list across sprites. At this introductory level, avoid simultaneous instructions changing the same property without coordination. If nothing happens, inspect selection, connections and the event before changing movement. Separating preparation from control makes restarting and repeating the same test easier.

A loop runs a group of instructions several times. Each pass is called an iteration, and the boundary of the Scratch block shows which actions belong to it. When we know how many iterations are needed, we use a finite repeat. Instructions placed afterward wait for all iterations to finish. By contrast, forever keeps repeating while the project is running: that sequence cannot reach a later action while it remains inside the loop. Each block’s position therefore changes the behavior.

To understand this behavior, we can write a trace: a record of the states produced step by step. The initial position counts too, so there will be one more recorded position than movements. If each iteration adds an increment to a coordinate, the trace lets us follow intermediate positions and predict the final one. A pause inside the loop gives us time to observe each iteration; outside a finite repeat, it waits after all iterations have finished.

This organization avoids copying the same instructions and lets us change a shared rule in one place. It also helps explain an animation: repeating movement, a message and a pause creates a different experience from repeating only movement and showing the message at the end. Even if the sprite finishes at the same point, the visible sequence can differ. Comparing from a known starting state reveals that difference. Repeating an incorrect instruction more often preserves the error; understanding one iteration helps us decide what should repeat and what should remain outside.

A condition is a question that a program evaluates as true or false at a particular moment. The if block runs the instructions inside it when the answer is true; if / else chooses between two alternatives. The question and its consequence have different roles. Detecting that two sprites are touching supplies an answer, but does not itself change position, messages or score. Behavior depends on the instructions we associate with that result.

When we need to retain information, we use a variable: a value associated with a name, such as points. This memory lets an arrival relate to previous arrivals. Setting points to zero establishes the initial value; changing points by one adds one to the previous value. Setting them to one replaces that value and therefore does not count successive arrivals. The difference between replacing and incrementing explains why two blocks containing the same number can produce different scores.

A condition also depends on when we check it again. A single check cannot detect a key pressed later; repeating the question inside forever keeps the control active. However, prolonged contact can remain true across many iterations and trigger several additions. Separating sprites after collection or waiting for contact to end lets us distinguish new arrivals. Tests involving still contact, separation and return check that rule. On restart, initializing values and positions restores a known state without results inherited from the previous run.

Testing means performing an action from known conditions and comparing the outcome with a prediction. A test states what you did, expected, observed and concluded. A screenshot can support it but cannot alone demonstrate control or restart behavior. Debugging investigates and corrects differences between expected and observed behavior. To reproduce a discrepancy, keep the initial position, direction, values and action sequence consistent. Without that reference, we might compare different situations and attribute the change to the wrong block.

Investigate one cause and change one thing at a time. Then repeat the failed test and check another related function. This distinguishes a repair from a change that merely hides the problem. An improvement addresses a need, such as clearer instructions, and must also be tested. The project combines plan and product: A01 keeps the design and microtest; A02 brings together the program, tests, correction and improvement. Partners alternate operating and observing, save versions and explain their own decisions. Choose extensions after understanding the main function; tutorials do not become extra submissions.