Snap! Coding Guide/Suggestions

J. Philip East — University of Northern Iowa

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.

Some Tasks

Director responsibilities (Places Everyone & Action)

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 Everyone▼] 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▼] hatted 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.

Moving with arrow keys

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

An alternative to the move block is to 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.

Program end—stopping scripts

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 all-done message. The state is probably the appropriate actor to receive the all-done message and set the variable, halt to true. The stage should probably be responsible for setting to halt to false at the start of the program (when it broadcasts Places & Action1.

Key press actions at unwanted times

The  when [some] key pressed  hatted command 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. Then you use an if block in the when block, e.g.,

    when <right arrow▼ key pressed >
        if <running=true>?
            desired actions when key is pressed