CS 1150 PEEE   Scratch I: A Simple Story

Overview

We have seen some "programming" activity (via the code.org course) and discussed what programming is. There are a variety of things you (or your students) can do with Scratch)—animation, having the computer draw, games, trivia/quizzing, etc. Another is story telling. And, the complexity of the story telling can vary a lot. For this assignment a modest amount of complexity is expected.

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 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 your story (or modify it a bit) so it is reasonable to meet all or most of the expectations.

• Uses multiple sprites
• Sprites are animated in some way
• Sprites interact, e.g., take turns speaking or moving
• Sound is used
• Passes the green flag test

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.

Submitting your work

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:

• making sure the project is named
• "sharing" it on Scratch and in adding it to our "studio"

  I prefer the following approach

  • click the See project page button near the top right corner
  • enter any instructions you want people to see
  • enter "Notes and credits" ... minimally the user ids of the student(s) submitting the work
  • click the Share button (near top right of window)
  • scroll down (and left) till you see a bar containing four links: a star, a heart, "Studios", and "Embed"
  • click on the Studios link/tab

    It should show our class studio (PEEE_fall17) as a link and a checkmark (also as a link)

  • click on the checkmark link

    It should turn green.

  • click on the PEEE_fall17 link

    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 individually 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.

Grading

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 than two sprites, involve multiple aspects of animation and/or sprites that are animated, have commented code, appear well planned rather than the result of guess and check coding, use additional Scratch features in reasonable/appropriate ways, etc.

Controlling Sprite Interaction

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.
Use broadcast     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.