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 provide some fun. As noted before, Scratch is good for story telling, drawing, games, trivia/quizzing, etc. This assignment addresses the basics of animation which can be used in many other contexts. This document has two parts—the specifications for the assignment and information that should help you better understand how do to the assignment.
This activity asks that you produce a Scratch program that uses a variety of animation activities, some or much of it influenced by user actions (pressing an arrow key or space bar or ...) and perhaps user data input.
The program you plan and implement should meet the following expectations.
Having them interact in a meaningful way is a plus.
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., change/set sprite names, use non-standard pen sizes and colors, have neat code areas, comment code if helpful, use input from the user in the program, have multiple new blocks, use more than one parameter to the blocks, avoid glitches (e.g., extra lines, interfering graphics, etc.), etc.
Animation in movies occurs because many pictures are taken each second and when placed together on a continuous piece of film and shown the show what appears to be animation even though each image is a still picture. Animation in Scratch occurs by changing some feature(s) of a sprite, probably repeatedly (as in a movie). Things you can change to produce animation include (but probably are not limited to):
Might occur using the point in direction __ block or the point towards _____ block. You will want to be careful here. Facing right (90°) or left (-90° or 270°) seem straightforward. However, a sprite may turn upside-down when you have it point in direction -90.
You can also have the sprite turn some amount either to the left or the right. Having them do so in small steps (e.g.,
Think about what pointing in some direction might mean. As you move through the spectrum of where you might point you will be rotating. If you have only two dimensions (like spites) you will have to rotate your whole body as you point in the various directions.
So, you will want to be aware that you can control this action of sprites by using the set rotation style to ______ block. Three choices are provided—face left or right only; rotate all around; or don't rotate.
Changing position can occur in many ways and generally is pretty much instantaneous. So you may want the sprite to make the overall movement in multiple small increments that when added up produce the overal movement and simulate motion. Some ways to change position are:
move __ stepsgo to x:__ y:__change x by __set x to __change y by __set y to __Changing costumes can simulate motion. A sprite with two costume having legs in different positions can appear to be stepping back and forth. When combined with moving the appearance of walking is produced. Similarly, winged things can appear to be flapping their wings and flying. Just put a move __ steps block and a next costume block inside a repeat loop. There are two ways to change costumes:
next costumeswitch costume to ____________Note that next costume "wraps around" to the first costume after the last costume.
Growing or shrinking in size will produce animation. It is particularly effective if the sprite is moving to the front or back of the stage, producing perspective. As with changing position changing size will often be associated with repeated movement.
Two blocks affect size: set size to __% and change size by __. Both are in terms of percents.
Though I have not thought of a specific example, it seems to me that animation should be possible using repeated use of show and hide.
Have a sprite bouncing up and down on a trampoline and when the user presses the left or right arrow key the sprite rotates (flips) that direction or if the user presses the space bar the sprite extends arms & legs. Uses repeat loops to cause the up and down movement and when __
Have a sprite flying across the top of (or randomly around) the screen and when the user presses the space bar the sprite casts a spell (or belches fires) toward something on the ground.
Have a shark "follow" the cursor around and when the user presses the space bar, the shark opens its mouth and attempts to chomp down on a fish.
The task here is to come up with your own program that incorporates similar kinds of animation in some context that goes beyond the animation. Some sprite (as in the examples above) interacts with one or more other sprites in a way that makes sense beyond two sprites interacting for no purpose (other than to write some code).
Some examples of putting code together to do animation are shown below.
set rotation-style [left-right] repeat until (not (go = true)) move __ steps next costume if on edge, bounce
Use the variable go which must be set to true during initialization (places). There will need to be something that changes the value of go—I often have the stage have a script like:
when __ key pressed set [go] to [false]
I think using forever is bad coding style—they don't stop when the program does and are not really under programmer control. So, as above, I use a repeat until loop to control this kind of repetition. The code is:
repeat until (not (go = true)) xChange = pick random from -20 to 20 yChange = pick random from -20 to 20 go to x:(x position + xChange) y:(y position + yChange) wait .1 secs
Note that you can have more than one script running at the same time or have one running and another that responds to some keypress and something happens for an instant. You'll seem some examples in class.