This page was created in an effort to show not bad (hopefully good) ways to code common, important, or tricky tasks in Scratch. It is difficult to show everything you want students to be aware of in a programming class and still provide time for them to do stuff (designing and coding) and to think about stuff (why and how to teach). It is also difficult to remember stuff when you don't use it frequently. Hopefully, this will allow us to write better code and to have a reference when teaching Scratch.
If you have suggestions for improvement of what is included or something to include, please contact the author.
Point in direction __ & move OR change x/y by ___
can switch costume to cause sprite to point in a particular direction
AVOID using a forever block to continuously check for key presses. Instead, consider the when-[some-key]-pressed block, e.g.,
when [right arrow▼] key pressed
point in direction (90▼)
move (10) steps
To avoid the point-in-direction block you can merely change the X- or Y- coordinate by an appropriate amount. You can speed up or slow down by increasing or decreasing respectively the number of steps or the magnitude of the coordinate change.
A nice alternative if you wish to allow the user to hold the key down to repeatedly move is:
when [right arrow▼] key pressed
repeat until < not <[right arrow▼] key pressed?> >
change x by (10)
wait (.15) sec
Note: the wait instruction allows some control of the speed of the movement. The given value (0.15) allows for approximately the same speed as moving without the repeat loop.
In Scratch we often use the metaphor of the programmer being the director. In plays & movies we imagine the director saying to the cast, "Places everyone." and shortly thereafter saying, "Action!". We suggest using that metaphor when you code. It involves using the:
broadcast [message▼] and wait When I receive [message▼] & broadcast [message▼] blocks.
A programmer is not part of the program so there must be some mechanism for including the appropriate code in the program. We recommend that the stage be the surrogate for the director/programmer and do the broadcasting. The code we would include is:
When (green flag) clicked
broadcast [Places▼] and wait
broadcast [Action!▼]
Notice the "and wait" on the first broadcast block. The Scratch system will broadcast the message and essentially watch for all the sprites to be done before proceeding to the next command/instruction/block.
Every sprite then would need to act appropriately in response to the broadcasts. They would each include in their scripts a When I receive [message▼] block for each message, i.e.,
When I receive [Places▼]
...
and
When I receive [Action!▼]
...
The instructions inside the "when I receive" blocks could be anything but will typically include getting to the appropriate starting position, facing in the appropriate direction, setting a size or color or costume characteristic, etc.
Doing this allows the program to pass the green flag test, i.e., no matter when the green flag is pressed, the program actions will always start in the same way.
When the program ends, everything should stop. That can sometimes be a bit tricky to recognize and carry out. Instead of using forever blocks consider a repeat until loop.
repeat until <halt=true>
...
halt is a variable that is initialized to false and set to true at the appropriate time, e.g., when I receive [all-done ▼]. You will need to determine which script will recognize the halting condition and broadcast the message. The stage is an appropriate actor to set or change this variable.
The when [some] key pressed start block can cause problems because it works even when the program is not officially running, i.e., before the green flag is clicked and after the program is all done. Perhaps the easiest fix for this is to have a variable running that gets set to true when the program starts and gets set to false when the program ends (see above about halting—have the stage initialize running and set it to false when the program halts.
Using a quotient to determine level.
speeding up
the problem>/p>
Both sprites and the stage can "ask" the user for input. When sprites ask the question appears as a cartoon bubble. When the stage asks, the question appears with the input box at the bottom of the screen.