Hopefully, your familiarity with Scratch and with programming are allowing you to feel more comfortable as you program. This programming activity should expand your repertoire a bit and show an activity you can use with elementary students. We've used Scratch for drawing and explored animation. This time we will use Scratch to tell and illustrate a story. We expect that most elementary students in third grade or above should should be able to do something like this activity. This document has two parts—the specifications for the assignment and information that should help you better understand how do to the assignment.
The first step in this assignment is to consider several fairy tales, nursery rhymes, jokes, etc. and think about how they might be presented in Scratch. Then, choose one to work on. I suggest each partner bring a couple ideas to the table and that you discuss the alternatives before choosing.
The program you plan and implement should meet as many of the expectations below as is reasonable for the story used—you should pick a story that allows you to do many of them.
Remember the "pair programming" process as you work. One person types and the other person watches and corrects, questions, etc. After a bit (at most 30 minutes) you change roles.
When you are finished with your program you will want to share it with the class by placing it in our studio. That process involves:
I prefer the following approach
It should show our class studio (PEEE_spring18) as a link and a checkmark (also as a link)
It should turn green.
You should be able to see that your project has been added to the studio.
That should be all it takes to "submit" the program. Whichever partner submitted the program should have the other partner sign in to Scratch and double check that the project is available in the studio. Don't forget that both partners need to jointly complete the PAC assignment for this activity.
Note that you should always be able to get back to the project page or to the Scratch programming environment from which you can access the project page. If you joined Scratch, your projects should all be available and be saved regularly by the system.
I will be checking the programs to see if they meet the specifications (noted above). A program that minimally meets all the specs is at least "okay" (will get a C or better). Better programs will go beyond the the minimal specs, e.g., have more sprites, have longer or more involved interactions (e.g., not just three or four lines), have commented & "cleaned up" code, appear well planned rather than the result of guess and check coding, use additional Scratch features in reasonable/appropriate ways, etc.
There are at least three ways to control the interaction between sprites when some sprite(s) should be idle while some other sprite(s) are active. Possibilities with example scripts for two sprites from a program similar to the above knock knock example are shown in the following table.
|Implementation Approach||First Sprite Script(s)||Second Sprite Script(s)|
|Use wait __ secs (time all actions)
While one sprite is active the other(s) are idle (a wait block is used for the idle sprites). When the planned amount of time has elapsed a different sprite becomes active while others are idle.
Each sprite carries out its actions and has a broadcast block as its last action in a script. Other sprites have a script that starts with a when I receive ... block that includes the actions it is to take. When it gets done, it will broadcast a (different) message which the other sprite(s) will receive and act on.
|Use broadcast __ and wait
One sprite acts and the other sprite(s) react. The one (controlling) sprite carries out its sub-activities each of which ends with a broadcast __ and wait block. The other sprite(s) will have appropriate when I receive __ blocks that contain their actions. The broadcast __ and wait block of the controlling sprite will keep control until all sprites that had the matching when I receive __ block before the block after it is allowed to occur.