Learn how to use all of the parts of the Scratch user interface. Learn why Scratch is not an object-oriented language. Learn how to write a Scratch animation that illustrates many programming concepts that are far too numerous to list here. Have fun in the process.
Published: May 17, 2008.
Last revised: May 26, 2008
By Richard G. Baldwin
Homeschool Programming Notes # 120
This tutorial lesson is part of a continuing series that is designed specifically for teaching computer programming to homeschool students and their parents. However, even though the series is designed for homeschool students, everyone is welcome to use the lessons to learn computer programming.
If you have been studying the previous lessons in this series, you have been working hard. Although there are many more fundamental programming concepts that you need to learn, you have learned enough that you can start having some serious fun writing Scratch animations and games. This lesson is the first lesson in the series that departs from teaching fundamentals and teaches the fun side of Scratch.
I will begin this lesson by providing information on how to use Scratch to write animations and game programs. For example I will explain how to use all of the parts of the user interface.
Then I will explain why Scratch is an object-based programming language but is not an object-oriented programming language.
Finally, I will present and explain an animation program that is much more significant than most of the earlier programs that have been presented in this series of lessons. The objective of the program is to get you beyond the fundamentals and to help you move into the areas that make Scratch-programming fun.
My version of this program has been posted online so that you can run and/or download it from there. (See Resources for the link to the online version.)
I recommend that you open another copy of this document in a separate browser window and use the following links to easily find and view the figures while you are reading about them.
I recommend that you also study the other lessons in my extensive collection of online programming tutorials. You will find a consolidated index at www.DickBaldwin.com.
In this lesson, I will present and explain a single Scratch program named StarDoors01. I have posted on online copy of this program for you to run online, download to run locally, or both. (See Resources for the link to the online version.) Before you continue reading, I recommend that you go online and run this program. If it doesn't start running immediately when you access it, click the green flag.
Non-interactive animation
When you run this program, you will see that it is a non-interactive animation. The animation begins with red text on a black starry sky background as shown in Figure 1.
Figure 1. Program StarDoors01 at startup.
|
|
The viewer seems to be moving towards the text because the text is growing in size. During the time that the viewer is moving toward the text, a very transparent boy (the evil master of the empire) is standing on the left side of the Stage observing what is going on. (If you look very carefully, you should be able to see the boy in Figure 1.)
A moonscape scene
After the text grows until it almost fills the screen, it fades from view and the background switches to a moonscape scene as shown in Figure 2. In the moonscape scene, the evil master of the empire (a boy sprite) is pacing back and forth on the moonscape thinking about his nemesis Duke Flywalker, his ally Dark Raider, and the love of his life Princess Lisa. Initially the sprite is very transparent. As time progresses, the sprite becomes more opaque until it is completely opaque.
Figure 2. The evil master pacing and thinking.
|
|
Okay, I know that he doesn't look like an evil master of the empire, but he is in disguise.
Thinking and speaking
As the boy walks, he thinks three different thoughts in a specific order. Periodically he stops, shrugs, and speaks one of three different phrases. The phrase that he speaks each time he stops is based on his current position on the x-axis. This makes it appear that he is speaking the phrases in a random order.
After a few minutes, the program terminates leaving the boy standing on the moonscape.
Scratch features illustrated by the program
This animation illustrates the following Scratch features, plus some other features not listed here:
I have been so busy teaching fundamental programming concepts in previous lessons that I haven't taken the time to step back and explain the big picture insofar as it relates to programming with Scratch. The time for such an explanation is at hand. However, you should consider this material to be supplemental to and not a substitute for the following three documents that you can expose by clicking the "Want Help?" button at the top of the Scratch user interface:
Getting Started
Help Screens
Reference Guide
For those who may not have been doing hands-on programming using Scratch, I will present and provide a brief explanation of the user interface. Figure 3 shows a screen shot of the interface that has been significantly reduced in size to make it fit into this narrow publication format. (You will also find a fully annotated image of the user interface on Page 2 of the Scratch Reference Guide mentioned above.)
Figure 3. The Scratch user interface.
|
|
The buttons at the top
There is a line of buttons across the top with the following labels:
|
With the possible exception of the Share button, the purpose of each button should be fairly obvious based on its name. The Share button makes it possible for you to post your Scratch projects on the Scratch website at MIT and share them with others.
Starting at the left and working toward the right, the leftmost column in Figure 3 is divided into two frames. The top frame contains eight toolbox buttons labeled:
|
I will refer to those tools as blocks, mainly because the Scratch Reference Guide refers to them as blocks. (Frankly, I don't care for that terminology and would prefer to call them tiles because the term block is too easily confused with the more conventional use of the term for blocks of code in other programming languages such as Java.)
The middle column
The middle column is also divided into an upper frame and a lower frame. This is where you actually construct the scripts that constitute your program. I will have a lot more to say about the contents of this column later.The rightmost column
The rightmost column in Figure 3 is divided into four parts. Near the top left of this column you see five buttons in a horizontal row with the leftmost button containing an arrow and colored blue. (The Scratch Reference Guide refers to this group of buttons simply as the Toolbar.) These buttons are used to control the behavior of the mouse cursor when you use the mouse to manipulate the objects (sprites) in the Stage area immediately below the row of buttons. (I will have much more to say about objects and sprites shortly.) According to the Reference Guide, you can click on the Toolbar to select a tool and then click on other objects to perform an action:
The start and stop buttons
The button with the red hexagon is an unconditional stop button. If you click this button when a Scratch program is running, that program will stop.
Generally speaking, the button with the green flag is a start button, but it is much more than that. When you click this button, the system fires an event that can be recognized and responded to by scripts that you construct and place in the center column.
According to the Reference Guide, the green flag provides a convenient way to start many scripts at the same time. You can click the green flag to start all scripts that have a block with a picture of a green flag at the top. (See Figure 4.)
I will have much more to say about this later also.The Stage area
The large rectangular area immediate below the button with the green flag is the Stage area where the visual parts of a running Scratch program play out. According to the Reference Guide, this is where you see your stories, games, and animations come to life. Sprites move and interact with one another on the Stage.
The Sprite List area
The bottom-right rectangular area below the Stage is a sprite-directory area. (The Reference Guide refers to this area as the Sprite List.) A thumbnail image will appear here for the Stage and for each sprite that you add to the program. When you click on a thumbnail image in this area, the center column of the user interface becomes temporarily dedicated to that object. This makes it possible for you to construct scripts and design other behavioral aspects of that object.
The thumbnail image for the Stage and for each sprite in the list is labeled with the sprite's name, the number of scripts that belong to the sprite, and the number of costumes that it has.
The Reference Guide also tells us:
"To show, export, duplicate, or delete a sprite, right-click on the sprite’s thumbnail in the Sprite List. To show a sprite that is off the stage or hidden, Shift+click on the sprite’s thumbnail in the Sprite List - this will bring the sprite to the middle of the Stage and show it."
Presentation mode
Clicking the small button immediately below the left side of the Stage area will cause the Stage area to expand to full screen. This is referred to as presentation mode. Pressing the Esc key while in presentation mode will restore the user interface view shown in Figure 3.
Creating, retrieving, and deleting sprites
Clicking one of the three buttons immediately to the right of the presentation mode button will allow you to:
The Reference Guide refers to these three buttons as the New Sprite Buttons. The sprites that you create or retrieve using these buttons will appear as thumbnail images in the Sprite List area at the bottom-right of the user interface.
To make a sprite that looks like part of the Stage background, right-click the Stage and select
grab screen region for new sprite.To delete a sprite, right-click on the sprite in the Sprite List and select delete from the popup menu that appears.
The mouse coordinates
In Figure 3, you can see the residue of some text to the far right of the New Sprite Buttons described above. This text provides a continuous readout of the x and y coordinate values of the mouse pointer when the Scratch user interface is active.
Saving project notes
Clicking the small rectangular button immediately above the stop button opens a simple text editor that you can use to record project notes that are saved with your project. Be aware that by default, these notes are visible to online viewers when you share your project online, so be careful what you place in the notes. (You will have an opportunity to modify the notes during the sharing process.)
Scratch is a very specialized object-based programming environment designed to make it relatively easy to write 2D programs containing graphics, sound, animation, etc.
|
Lest you become confused about programming terminology, Scratch is not an object-oriented programming language. It does not support the fundamental requirements of an object-oriented language:
You won't learn about object-oriented programming in this series of tutorial lessons until we get into Java.
Important object-based characteristics
Even though Scratch is not technically an object-oriented programming language, it does support some important object-oriented concepts. In particular, a Scratch program consists of a group of objects (called sprites in Scratch) that exchange messages and work together for the purpose of accomplishing a particular goal. That goal may be a relatively simple animation such as this one or a very complex game.
A Scratch object knows how perform none, one, or more potentially complex behaviors when requested to do so. This is another important object-oriented concept. For example, a Scratch object can grow, move, vanish, rotate, make sounds, play drums, etc. I will get into the details of how objects make and receive such requests later.
|
What are the objects in a Scratch program?
Every Scratch program consists of one object named Stage and none, one, or more additional objects called sprites. (Actually, the Stage may also be a sprite, but if so it is a special kind of sprite with special restrictions and characteristics.) By default, the sprites are named Sprite1, Sprite2, etc. You can rename the sprites to just about any name you please. (You should probably make certain that no two sprites are given the same name if for no other reason than developing good programming habits.) However, you cannot change the name of the Stage. Also, there can only be one Stage.
Different visual manifestations
An individual object (sprite or Stage) can have one or more visual manifestations called costumes or backgrounds. (They are called costumes when you are speaking of sprites and backgrounds when you are speaking of the Stage.)
While you might reasonably expect that all of the costumes belonging to a particular object would be related in some visual sense (such as the walking boy sprite that you will see later), that is not a technical requirement.
|
Consider the case of a butterfly
For example, it might make sense to have a sprite for which one or more costumes look like caterpillars in different positions and states of development while one or more additional costumes look like butterflies in different positions and states of development. That would make it possible to create an animation where the caterpillar manifestation of the sprite crawls along a limb, changes into a butterfly and flies away.
Each costume is an image
Each costume and background is a two-dimensional image. A gallery containing hundreds of such images is provided with the Scratch software. Hundreds more images that are suitable for costumes and backgrounds are available for downloading from various websites. A paint program is included in the Scratch user interface that you can use to create your own costumes from scratch (no put intended) or to modify an existing costume to produce a new costume.
Importing images to use as costumes
The paint program also makes it possible to import existing image files such as photographs from the disk. According to the Reference Guide, the following image file formats are recognized by Scratch:
JPG
BMP
PNG
GIF (including animated GIF)
An alternative for importing images for costumes
As an alternative to using the paint program to import images for use as costumes, under Windows at least, you can simply drag an image file from a disk directory and drop it on a sprite. That image will then become a costume belonging to that sprite.
You can even drag images straight out of some programs, such as Microsoft Word, and drop them onto a sprite to cause those images to become costumes for that sprite. This makes it possible, for example, to use Microsoft Word clip art images as costumes for sprites.
Sprite-formatted files
The Scratch gallery also contains some sprite-formatted files and you can create your own. These are not simple image files. In addition to containing one or more images, these files can also contain one or more scripts. (I will have a great deal to say about scripts later.) Once you create a sprite by combining images and scripts, you can export the sprite into a sprite file by clicking a button labeled Export at the top-right corner of the center panel (see Figure 3) in the Scratch user interface. You can then use that file as a sprite in a future program.
A little more about the Stage
With the restrictions that there can be only one Stage object in a Scratch program and that you can't change its name, much of what I have said about sprites also applies to the Stage object. However, as mentioned earlier, instead of being called costumes, the multiple images that can be used with the stage are called backgrounds.
Apparently, however, once you combine scripts and images for your Stage object, you cannot export that Stage and use it in a future program. At least if you can, I don't know how to do it at this time. There is no Export button on the center panel of the user interface when the Stage is selected in the Sprite List.
Each object knows how to behave
As mentioned earlier, each object (Stage or sprite) in a Scratch program knows how perform none, one, or more different behaviors when requested to do so. Each individual behavior is performed by the execution of a particular script that you define when you are creating the object. For example, Figure 4 shows two very simple scripts that belong to the Stage in this program.
Figure 4. Two simple scripts that belong to the Stage.
|
|
Note that the two tan-colored blocks in Figure 4 have the same shape. The Reference Guide refers to blocks of this type as Hats and has this to say about them:
"Hats: These blocks have rounded tops... These blocks are placed at the tops of stacks. They wait for an event to happen, such as a key being pressed, then run the blocks underneath them."
When are scripts executed?
The physical position of a script in the panel does not control when the script is executed. Instead, the execution of a script is triggered by other things that happen in the program. For example, the top script in Figure 4 is executed whenever the user clicks the green flag in the upper-right corner of Figure 3. As you might have surmised from the white text on the purple block belonging to that script, this script causes the background of the Stage to be set to the black sky containing stars shown in Figure 1.
The second script in Figure 4 is executed when another object broadcasts a message containing the text "Scene 2". This script causes the background of the Stage to be set to the moonscape shown in Figure 2.
Event-driven programming
These two scripts are examples of a programming style often referred to as "event-driven programming." (I will have more to say on this topic later.) In a nutshell, the two scripts shown in Figure 4 are event-handler scripts (or event handlers for short) designed to cause the Stage object to respond to two different types of events and to perform a different behavior for each type of event. One behavior results from the occurrence of the user clicking the green flag (one type of event). The other behavior results from another object broadcasting a specific message (a different type of event).
Note that there is nothing to prevent two or more objects from responding to the same event but the order in which the objects respond to the same event is probably up for grabs insofar as the programmer's knowledge is concerned. Therefore, you need to be careful how you write your scripts if the order of the responses to a given event is important.
What comprises a script?
Individual scripts consist of various combinations of fundamental actions such as:
Constructing scripts
Each fundamental action is identified by a block that is available in one of eight different toolboxes. As I indicated earlier, the toolboxes are named:
Also, as I mentioned earlier, each of the eight buttons in the upper left in Figure 3 opens a toolbox and exposes its contents. Each toolbox contains many different blocks.
|
To construct a script, you drag individual blocks from the leftmost column in Figure 3 to the center column in Figure 3. Then you arrange the blocks in specific combinations and click them together like pieces of a jigsaw puzzle to construct the script. The Reference Guide refers to a set of blocks that have been clicked together as a stack.
Blocks range from simple to complex
Figure 5 shows a number of unrelated blocks that were dragged into the center panel for illustration purposes. These blocks have not been clicked together so they do not constitute a script or a stack.
Figure 5. An assortment of unrelated programming blocks.
|
|
Stack blocks
Note that some of the blocks in Figure 5 have bumps on the bottom and/or notches on the top. These bumps and notches make it possible to snap blocks of this type into stacks. The Reference Guide refers to blocks of this type as stack blocks.
|
Reporters
Some of the blocks in Figure 5 have rounded ends and some have pointed ends. The Reference Guide refers to blocks of this type as reporters. They are designed to fit into holes or pockets in other blocks. Reporters with rounded ends report numbers while reporters with pointed ends report boolean values (true or false).
Monitors
Some reporters have a checkbox next to them in the toolbox. In that case, if you put a check in the checkbox, a
monitor appears on the stage and displays the current value of the reporter. As the value of the reporter changes, the monitor updates automatically.A monitor can display the value of the reporter in several different formats. You can right-click on the monitor to select the desired format.
Simple blocks
Some blocks such as the show and hide blocks are very simple. Images of these two blocks are shown at the top in Figure 5. As the names imply, these two blocks are used to cause a sprite to be totally visible or totally invisible. (Note that you cannot hide the Stage.)
A complex block
As an alternative to showing and hiding a sprite, an effect called the ghost effect can be used to cause a sprite to be transparent in degrees ranging from totally transparent to totally opaque. This is accomplished using the third block down from the top in Figure 5.
Different effects available via a pull-down list
In addition to the ghost effect, the pull-down list that is built into this block can be used to select additional effects, each one of which can be used to produce some interesting results:
Blocks with pockets or text areas
Some blocks, such as the purple ghost block and the tan block containing the words if and else in Figure 5 provide one or more pockets and/or text areas into which you can insert other blocks or literal values.
A conditional block
In some cases, you construct composite blocks from other blocks and insert the resulting composite blocks into a pocket. A good example is the construction of a conditional block for use in the pocket of an if-else block (such as the tan if-else block in Figure 5), using arithmetic, relational, and logical operators along with variables and literal values.
A simple example of such a composite conditional block is the green block with the blue inserts shown in Figure 5. This composite block was constructed from three different blocks. It uses a relational operator block (from the green Numbers toolbox) along with the mouse x block and the mouse y block (from the blue Sensing toolbox) to compare the x-coordinate of the mouse pointer to the y- coordinate of the mouse pointer and to return true or false depending on which value is greater.
Blocks with pull-down lists
As I mentioned earlier, some blocks, such as the ghost block in Figure 5, provide pull-down lists that allow you to customize the behavior of the block. As I indicated earlier, this block allows you to select among seven different visual effects, to set a value for the effect, and to cause the selected effect to be applied to a sprite.
Mathematical functions
As another example, the green block showing the word sqrt in Figure 5 has a pull-down list on the left and a pocket on the right. The pull-down list allows you to select any of the following mathematical functions and to apply the selected function to the contents of the pocket:
The pocket can contain a literal value as shown in Figure 5, or it can contain any other block with the shape of a rounded rectangle. Figure 5 also shows several other blocks that match that shape, including the sqrt block itself, a variable block, an arithmetic operator block (which itself has two rounded-rectangle pockets), and a random number block.
Programming logic
Scripts are constructed using various sequence, selection, and loop control structures as is the case with most modern programming languages. These structures provide the mechanism for creating programming logic within a script. Variables, literals, arithmetic operators, relational operators, and logical operators are available for use in constructing such logic.
Figure 5 shows a tan if-else control block as well as a tan repeat until block. These blocks along with several others are used to create selection and loop structures.
Begin with a hat block
Every script must be constructed with a block having the general shape of the tan blocks in Figure 4 as the topmost block in the script. As I mentioned earlier, the Reference Guide refers to blocks having this shape as hats. Given the hat block as a base, you can construct the script down from that block using a wide variety of other blocks provided that they snap together properly. Of course, you must fill in the pockets, if any, with blocks having compatible shapes.
Insert other blocks into the mouth
Note that each of the tan blocks in Figure 5 also has a C-shaped mouth. When such a mouth exists on a block, you insert other blocks into the mouth to create usable code. For example, all of the blocks inserted into the mouth of the repeat until block will be executed until the reporter block that is inserted into the pocket reports true.
Triggering a script to execute
There are at least four different ways that a script representing a behavior for an object can be triggered and caused to execute:
Event handlers
Figure 6 shows some of the blocks that can be used to trigger the execution of a script. The top three blocks in Figure 6 show hat blocks for three different kinds of event handler scripts.
Figure 6. Blocks that trigger the execution of a script.
|
|
A green flag event
Any script that is constructed using the "green flag" hat block will be executed whenever the user clicks the green flag shown in the upper-right corner of Figure 3. (If a program contains multiple scripts that use a green flag hat block, they will all be executed when the user clicks the green flag.)
For want of a better term, we might refer to this as a green flag event. A program containing multiple sprites will typically have event handlers for this type of event on different sprites.
A key pressed event
The second block shown in Figure 6 is used as the hat block for a script that is designed to handle a key pressed event. The pull-down list on this block makes it possible to assign this event handler to:
As a result, you can use different keys to cause a single sprite and/or different sprites to execute different behaviors. For example, you might use the four arrow keys to cause a sprite (or a group of sprites) to move up, down, right, or left in a game or animation.
A click event
The third block in Figure 6 is used for the hat block in a click event handler that will respond when the sprite that owns the script is clicked with the left mouse button. (The middle and right mouse buttons won't trigger a click event on the sprite.)
Message handlers
The fourth block shown in Figure 6 is used as the hat block for a script that is designed to respond to a message broadcast by some other script belonging to the same or to a different object. Messages are broadcast using one of the bottom two blocks in Figure 6. (A message is simply a unique text string.)
The pull-down lists in the broadcast blocks
The pull-down lists in the bottom two blocks expose all of the messages previously defined within the program plus a new item. The new item makes it possible to define and broadcast a new message. Therefore, you can cause a sprite to broadcast any previously defined message or you can define a new message and cause the sprite to broadcast that message.
The pull-down list in the fourth hat block, which is labeled when I receive, exposes all of the previously defined messages. Therefore, you can cause a sprite to execute a message handler script to respond to any single message that has been previously defined during the development of the program.
The order of creating scripts can be important
As you may already have figured out, the order in which you create the scripts for the different objects can be crucial when your objects are broadcasting and receiving messages. In other words, you can't completely define a script to receive a message unless you have already included the definition of that message in another script.
Objects cannot be created or deleted at runtime
Unlike Java and other object-oriented programming languages, all objects that are required for the successful execution of a Scratch program must be created and programmed during the development of the program. You cannot write program code to create new objects. Similarly, you cannot write program code that will destroy existing objects. However, you can hide existing objects and show them only when you need them.
Sound capability
In addition to the capabilities described above, Scratch provides an impressive capability for importing and playing sounds such as music, sound effects, etc. It also provides what seems to me to be an impressive capability to create and play new music. Having very little musical talent, however, I haven't been able to do much with the capability to create new music.
Drawing capability
As I mentioned earlier, Scratch has a built-in paint program that allows you to create new sprites or to modify existing sprites.
Scratch also provides the capability to create line drawings such as sine waves under program control.
The time has come for me to present and explain the animation program named StarDoors01.
Usually if you are going to put on a show, you need to begin by building the stage, so that seems like a good place to begin. Start the Scratch program and click on the New button at the top of the user interface. This will open a new project.
It would probably be a good idea to save your project now and often, so click on the Save button at the top of the screen. Select a directory, type the name for your new project and click the OK button.
The right side of the user interface should look something like Figure 7.
Figure 7. A new Scratch project.
|
|
A new Scratch project
A new Scratch project contains a cat sprite and a blank Stage by default. We won't need the cat sprite. Right click on either image of the cat and select delete from the popup menu. Both images of the cat should disappear and the Stage icon, as the only remaining object, should be highlighted by a blue halo.
Scenery for the Stage
Now select the Backgrounds tab in the center panel. You should see something like Figure 8.
Figure 8. Backgrounds tab for a new project.
|
|
Add two new backgrounds and delete the plain white one
By default, you have a plain white background for your Stage. We want to add two new backgrounds and delete the default white background. To add a new background to the Stage, click the Import button shown in Figure 8. You will find the stars background as well as the moon background in the Nature folder that will be exposed when you click the Import button. I will assume that you know how to work through the mechanics from that point forward until you have three backgrounds showing in the Backgrounds tab. A little button with an X will have appeared to the right of each background thumbnail image in the Backgrounds panel. Click that button to delete the white background. (The delete button wasn't there originally because you cannot delete the only background.)
Your Backgrounds tab for the Stage should now look like Figure 9.
Figure 9. The Backgrounds tab for the Stage.
|
|
Create two scripts for the Stage
Now select the Scripts tab for the center column. That panel should be blank at this point.
Click on the tan Control button in the upper-left corner of the user interface. That will expose the programming blocks shown in Figure 10.
Figure 10. Preparing to create scripts for the Stage.
|
|
Drag the two hat blocks shown in Figure 4
Now go back and take a look at Figure 4. Both of the tan blocks that you see in Figure 4 are now available in the tan Control toolbox in your user interface. Grab each of those blocks with your mouse, drag, and drop it on the Scripts tab in the center column. Leave some space between them.
Get two purple Looks blocks
Now click the toolbox button to open the purple Looks toolbox. You should see both of the purple blocks from Figure 4 in that toolbox. Grab the top block labeled switch to background and drag it onto the Scripts tab. Slide it up under the tan green flag hat block. When you do, the two blocks should join together just like a magnet and a piece of metal.
Do the same thing again and connect the purple block to the tan when I receive block.
Now use the pull-down list on each of the purple blocks to specify the background that will be displayed when each of the scripts is executed. When the user clicks the green flag, the top script in Figure 4 will be executed, causing the stars background to be displayed on the Stage.
Houston, we have a problem!
When you open the pull-down list on the tan block labeled when I receive, you won't find "Scene 2" on the list. However, you will see the word new... This is because we haven't yet written the script that broadcasts the message named "Scene 2". We will have to put this script on the back burner and come back to finish it later. After the script is finished, when another script broadcasts the message "Scene 2", this script will be executed causing the moonscape background to be displayed on the Stage.
Other than the requirement to go back and enter the name of the message in the script discussed above, that is all we need to do to construct the Stage on which our animation will play out.
Too much detail?
This is probably more detail than many of you want to see in this lesson, and I won't continue to explain things at this level of detail. However, I decided to explain the development process up to this point in great detail so that those students who have not been programming with Scratch can quickly catch up with everyone else.
Three sprites are required
In addition to the Stage, we need three sprites and several scripts to complete this program. We will name the sprites Text, BoyWalking, and BoyShrug. Once the program is finished, the sprite list will look like Figure 11.
Figure 11. Sprite list for final version of the program.
|
|
The sprite named Text
Let's begin with the simplest of the three sprites insofar as scripts is concerned. This is the sprite that is used to display the text shown in Figure 1.
You have probably guessed by now that a script with this costume is not provided with the Scratch software. Therefore, we must create it from scratch. (Oops, there's that word again.)
Adding a new sprite to the program
The procedure for adding a new sprite to your program is as follows:
Adding the sprite named Text
In the case of the sprite named Text, you can apply any costume to the sprite when you create it because we are going to delete the original costume anyway.
Once you get down to Step 5 above, click the Paint button. You need to create a new costume using the paint program shown in Figure 12. This is a fairly typical paint program and I am going to assume that you can figure out how to use it with no help from me. (You can find instructions for using the paint program beginning with page 8 in the Reference Guide.)
Figure 12. User interface for the built-in paint program.
|
|
Enter the text in the paint program
Enter the text shown in Figure 1 on the drawing canvas in the paint program and click the OK button. This should return you to the Costumes tab with the original costume and the new costume showing. Delete the original costume. Your screen should now look like Figure 13.
Figure 13. Final Costumes tab for the Text sprite.
|
|
Create a script for the Text sprite
We still need to create the script shown in Figure 14 for the Text sprite to cause it to have the desired behavior.
Figure 14. The script for the Text sprite.
|
|
Must create a variable first
Before we can create this script, we must create the variable named xTitle as shown in the left panel in Figure 14. All you need to do to create a variable is to:
By default, the checkbox to the left of the variable name will be checked. This causes the value of the variable to be displayed in a monitor on the Stage. In this case, we don't want it to be displayed so you should clear the checkbox.
Drag, drop, and create
Drag, drop, and connect the necessary blocks to create the script shown in Figure 14. With the possible exception of the blocks labeled set size to and change size by, I have explained the use of all of the blocks shown in Figure 14 in the earlier lessons in this series. Therefore, I am simply going to refer you back to those lessons if you need to learn more about a particular block.
Execution of the script
The code in the script in Figure 14 performs the following initialization each time the user clicks the green flag:
Then control enters the tan repeat block where three blocks are executed in sequence and the sequence is executed 800 times in a loop.
Possible confusion regarding the term size
The first action controlled by the purple block that is labeled change size by can be very confusing if you take the label literally. At a very low level, the costume for a sprite consists of a collection of coordinate values that are rendered in particular ways to produce images on the screen. The size of the sprite depends on the values of the coordinates. Considering the word size to represent the physical size of the sprite, it makes no sense to say change size by (some numeric value). If you were to add or subtract that numeric value from each coordinate value, you wouldn't change the size of the sprite. Instead, you would change its position on the Stage.
A different interpretation of the word size
For this process to make sense, you must think of the word size as used in the labels set size and change size as not referring to the physical size of the sprite. Instead, you need to think of the word size as being the name of a scale factor that will be used to multiply all of the coordinate values that describe the sprite in the process of rendering them onto the Stage. Multiplying the coordinate values by a scale factor will change the physical size of the sprite when it is rendered.
An example
For example, if you plug a value of 25 into the set size block, you are in effect setting the scale factor to a value of 0.25. (Note the decimal point and remember the difference between absolute scale factors and percentage factors.)
If you plug a value of 10 into the change size block, you are adding a value of 0.10 to the current value of the scale factor. This is an extremely important statement. Think about what it says.
Thus, the initialization code in Figure 14 that reads set size to 25% causes the Text sprite to be rendered at 25% of its original size. Note however that the information defining the original size is not lost. If you were to follow that block with another block that reads set size to 100%, the rendering of the sprite would be restored to its original size.
Summary on size
In summary, the set size block sets the value of a scale factor named size that is used to multiply the coordinate values of the sprite before it is rendered. The block that is labeled change size by (some value) modifies that scale factor in an additive manner as described above.
Therefore, as the repeat block executes 800 times in Figure 14, the scale factor takes on the following values:
25.25% 25.50% 25.75% 26.00% ... 225.00%
The rendering of the text in Figure 1 starts at about one-fourth of its original size and ends up about twice its original size. This causes the text to start out small and grow over time, giving the illusion that the user is moving toward the text or the text is moving toward the user.
Changing the horizontal position of the text
The Text sprite starts out roughly centered on the origin of the 2D space that represents the Stage. As the text grows in size, it must also be moved to the left to keep it from simply protruding off the right side of the Stage. That is the purpose of the orange and blue blocks inside the repeat block discussed above.
Another repeat block
The repeat block discussed above is followed by another repeat block that executes the same purple block 100 times. This is the code that causes the text to fade from visibility. You should be able to understand this code based on the earlier discussion of the ghost effect.
Broadcast a message
The final block in the script in Figure 14 broadcasts the message "Scene 2". This is a signal to the Stage to cause it to switch its background to the moon background.
Recall that you weren't able to specify this message earlier when you created the scripts for the Stage. Now that you have defined the message, you can go back and update the bottom Stage script shown in Figure 4.
That's it for the Text sprite
That concludes the programming requirement for the sprite named Text. Next we will take a look at the programming requirements for the sprite named BoyShrug shown in Figure 11. First, however, I will show you where the costumes for the two remaining sprites came from.
Figure 15 shows a screen shot of a portion of the contents of the People folder in the Costumes folder.
Figure 15. Screen shot of People folder in Costumes folder.
|
|
Five costumes for the sprite named BoyWalking
Figure 15 shows seven separate images of a boy wearing a purple sweater. Going from left to right, top to bottom, the first two images labeled boy4-laughing and boy4-shrugging are considerably different from the remaining five images.
The remaining five images, beginning with boy4-walking-a and ending with boy4-walking-e were designed by the artist to represent a sequence of five different still shots of a boy walking from left to right across the screen. We will apply these five costumes to the sprite named BoyWalking in Figure 11 so that we can produce an animation of the boy walking back and forth across the Stage.
Will use two different sprites to produce the animation
We will use the costume named boy4-shrugging as the only costume for the sprite named BoyShrug shown in Figure 11.
The animation will show the boy pacing back and forth across the Stage. Periodically, the boy will stop pacing, shrug his shoulders, and then resume pacing. We will use two different sprites to accomplish this
We will use the sprite named BoyWalking to produce the animation while the boy is actually pacing. We will periodically hide the BoyWalking sprite and show the BoyShrug sprite for a short period of time. This will make it appear that the boy stopped pacing, shrugged his shoulders, and then resumed pacing. We will use messaging to control the switch from one sprite to the other and then back to the first sprite.
Several important details
In order to make this work, there are several important details that we will need to deal with:
Position
We must make certain that every time we show the BoyShrug sprite, it is in the correct position relative to the most recent rendered position of the BoyWalking sprite. We will accomplish this by synchronizing the positions of the two sprites.
Size
Unfortunately, we have another size issue to deal with. Figure 16 shows a separate rendering of each of the six costumes that we will use with each costume shown at its actual size. As you can see, the shrugging costume is noticeably smaller than the walking costumes. We will need to deal with this when we write the script for the BoyShrug sprite.
Figure 16. Individual renderings of six costumes.
|
|
Transparency
The sprite with the shrugging costume will occasionally replace the sprite that is walking for a short period of time. Therefore we will need to make certain that when it appears, it has the same level of transparency as the sprite that it is replacing.
My initial inclination was to explain the programming requirements for the sprite named BoyShrug first because it is the simpler of the two remaining sprites. However, to some extent, it plays follow the leader with the BoyWalking sprite being the leader so I will explain the programming requirements for the sprite named BoyWalking next.
Costumes tab for the sprite named BoyWalking
Figure 17 shows the costumes tab for the sprite named BoyWalking. At this point, you shouldn't see anything surprising about Figure 17. Well maybe there is one thing that is surprising or at least it is new. I'm speaking of the three small buttons to the immediate left of the thumbnail image at the very top of Figure 17.
Figure 17. Costumes tab for the sprite named BoyWalking.
|
|
Sprite rotation around its center point
Every costume has a center point that was established by the artist that created the costume.
The Motion toolbox contains the three blocks shown in Figure 18.
Figure 18. Blocks that rotate and bounce a sprite.
|
|
The top two blocks can be used to cause a sprite to rotate by a specified number of degrees around its center point. For example, by default, if you cause a sprite to rotate by 180 degrees, it will turn upside down. The only difference between these two rotation blocks is the direction of the rotation. The top block causes the sprite to rotate in a clockwise direction. The second block causes the sprite to rotate in a counter clockwise direction.
|
The three small buttons
The three small buttons at the top left of Figure 18 control the behavior of a sprite when you use either of the rotation blocks to rotate it around its center point.
The top (default) button
The default button selection is the top button in the stack of three buttons. When this button is selected and you rotate the sprite, the behavior should be exactly what you expect. The sprite will rotate by the specified number of degrees around its center point.
The center (face left or right only) button
If the center button is selected (as is the case in Figure 18) and you rotate the sprite using one of the rotation blocks, the behavior might not be exactly what you would normally expect. In this case, nothing happens until the cumulative angle of rotation exceeds 90 degrees. At that point, the sprite turns and faces in the opposite direction. If the center button is selected, the sprite will only face left or right. It will not turn upside down, lie on its back, or change its normal upright angle relative to the horizontal.
The bottom (disable rotation) button
If the bottom button is selected and you rotate the sprite, nothing will happen regardless of the cumulative angle of rotation. In other words, selecting this button effectively disables the top two blocks in Figure 18.
The bounce button
The purpose of the bottom block in Figure 18 is to cause sprites to bounce if they run into the edge of the Stage. However, the behavior of the sprite when it hits the edge will depend on which of the three buttons discussed above is selected.
|
Bounce and turn upside down
If the top (default) button is selected, and a forward-moving sprite hits the edge, the sprite will rotate by 180 degrees and continue moving forward. The problem is that rotating a sprite by 180 degrees turns it upside down by default. Therefore, the sprite will bounce off the edge and turn upside down in the process. If the sprite makes it to the opposite edge, it will bounce off of that edge and turn right side up again.
Simply turn around
If the center button is selected and a forward-moving sprite hits the edge, the sprite will simply turn around and start moving in the opposite direction. It won't turn upside down in the process.
Don't turn around and don't turn upside down
If the bottom button is selected and a forward-moving sprite hits the edge, the sprite will simply bounce without turning around or turning upside down and will move backwards in the opposite direction.
Will select the center button
We will select the center button in this program to cause our sprite to turn around and start pacing in the opposite direction when it hits the edge.
The initialization script
That takes care of the costume issues for the sprite named BoyWalking. Now let's take a look at the script that is executed when the user clicks the green flag as shown in Figure 19.
Figure 19. Initialization code for the sprite named BoyWalking.
|
|
Although I didn't discuss it when I showed you the variables in Figure 14, I also created a variable named count. As you can see in Figure 19, I will use that variable in controlling the behavior of this sprite.
|
An aside, instance variables versus class variables
There is also another matter regarding variables that I have never explained in this series of lessons:
Although this topic isn't particularly germane to this program, this seems like just as good a place as any to explain the difference between the two. By the way, the variable named count that I use in this program is a class variable.
The variable creation dialog
When you create a new variable, you are confronted with the dialog shown in Figure 20.
Figure 20. Dialog for making a variable.
|
|
This dialog requires that you do two things before clicking the OK button in order to successfully create the new variable:
Specify an instance or class variable
The radio button on the left is selected by default. This is the button that causes the variable to be a class variable, meaning that it is accessible to all objects. The button on the right causes the button to be an instance variable, meaning that the variable is accessible only by a single object.
Differences between the two kinds of variables
There is no obvious difference in the appearance of the variable when it appears in the Variables toolbox of Figure 14 regardless of whether it is created as an instance variable or a class variable. However, if you check the box and allow the variable to be displayed in a monitor in the Stage area, there is a difference in appearance there. When instance variables are displayed in the Stage area, the name of the owner object is displayed in addition to the name and value of the variable.
Another difference is that instance variables don't appear in the Variables toolbox unless you have selected the owner object in the sprite list of Figure 3. Therefore, they can only be used in scripts that are constructed for the owner object.
Getting back to the initialization code...
The initialization code in Figure 19 performs the following actions when the user clicks the green flag:
These are typical initialization actions. They cause the BoyWalking sprite to be barely visible on the left side of the stage during the early part of the animation.
When the Text sprite broadcasts Scene 2...
Recall from Figure 14 that when the Text sprite finishes everything that it needs to do, it broadcasts the message "Scene 2". This signals the Stage to switch to the moonscape costume as you saw in Figure 4. It also signals for the BoyWalking sprite to become active and start pacing back and forth by executing the code shown in Figure 21.
Figure 21. Script that animates the BoyWalking sprite.
|
|
As you can see in Figure 21, when the BoyWalking sprite receives the message "Scene 2", it waits for 0.5 seconds and then repeats the execution of a large block of code 50 times. (A loop such as this is often referred to an animation loop.) After the code has been executed 50 times, the program terminates.
Increment the counter
Before breaking the code in animation loop down into fragments for discussion, let me point out that at the beginning of each iteration of the loop, the value of the variable named count is increased by a value of one. Therefore, that variable can be used by other code within the loop to determine how many times the code inside the animation loop has been executed.
An if-else-if structure
Now it's time to break the code down and explain it in fragments. The code shown in Figure 22, which is the first major block of code in the animation loop, is often referred to as an if-else-if structure.
Figure 22. An if-else-if structure.
|
|
The general idea of an if-else-if structure
The general idea behind such a structure is shown by the pseudocode in Figure 23.
Figure 23. Pseudocode for an if-else-if structure.
If you are hungry, eat something Else if you are sleepy, take a nap Else if you are restless, take a walk Else (if none of the above is true) do your homework |
This is a sort of multiple-choice structure, and there is virtually no limit to the number of choices that we can program in such a structure. (Hardware constraints, such as the amount of available memory, may impose practical constraints, however.)
As you can see from Figure 22, we construct an if-else-if structure in Scratch by inserting an if-else block inside another if-else block.
The think and say blocks
Let's begin the explanation of the code in Figure 22 with the purple think blocks. The execution of each of these blocks produces a thought bubble above the sprite's head as shown in Figure 2. (A say block produces something similar with the major difference being the connection between the bubble and the sprite's head. The connecting image is more solid for a say block than for a think block.)
The purpose of the code in Figure 22 is to examine the current value of the variable named count and to think one of three different thoughts depending on the value of the count. This is a very common programming structure.
The mod operator
Remember that the behavior of the green mod operator is to divide the left operand by the right operand and to return the remainder (not the quotient). If you divide any value by 3, the remainder will always be 0, 1, or 2. (Think about that. What are the possible remainder values if you divide any value by 5?)
Further, if the left operand of the mod operator is a value that increases by 1 during each iteration, the remainder will be a member of the following repeating pattern:
0 1 2 0 1 2 0 1 2 0 1 2 ...From this, you should be able to see that the code in Figure 22 cycles through three thought messages, displaying one of those messages each time the code in the structure is executed.
Cause the BoyWalking sprite to make 20 costume changes
If you refer back to Figure 21, you will see that the code in Figure 22 is followed by the code in Figure 24.
Figure 24. Cause the BoyWalking sprite to make 20 costume changes.
|
|
The code in Figure 24 repeats the execution of six blocks 20 times.
Make the sprite slowly become opaque
Recall that the BoyWalking sprite was made almost totally transparent in the initialization code of Figure 19 by setting the ghost effect to a value of 90. (Experimental results indicate that an absolute value of 100 or more is totally transparent and a value of 0 is totally opaque. Experimental results also indicate that there is no difference in transparency for ghost values of 50 and -50. So far, I haven't found any documentation to confirm this, however.)
The first purple statement in Figure 24 reduces the ghost value by one during each iteration of the loop. (Experimental results indicate that the statement will not reduce the ghost value below 0, but I have found no documentation to confirm that is true.) As a result, the sprite becomes more opaque (less transparent) during each iteration of the repeat loop in Figure 24.
Send a message to the BoyShrug sprite
Later on, you will see that some of the code in the script for the BoyShrug sprite essentially tracks the code for the BoyWalking sprite, at least insofar as position and transparency are concerned. The broadcast block in Figure 24 sends a message to the BoyShrug sprite telling it to also reduce its ghost effect value so as to remain in synchronism with the BoyWalking sprite.
Move, change costume, and wait
The five rightmost costumes in Figure 16 are assigned to the BoyWalking sprite. The walking animation, (exclusive of the ghost effect), is shown by the pseudocode in Figure 25.
Figure 25. Pseudocode for the walking animation.
Begin with a particular costume
A. Move 10 (coordinate) steps forward
Change to the next costume in the sequence
Wait 0.2 seconds
If at the edge
Turn around and head in the opposite direction
Go back to A and do it again |
A clarification on the word steps
As a matter of clarification, the word steps in Figure 24 and Figure 25 does not refer to physical walking steps. Instead it refers to units in the Cartesian coordinate system of the Stage. The Stage is 480 units (or steps) wide with coordinate values ranging from -240 at the left edge to +240 at the right edge. It is 360 units (or steps) tall with coordinate values ranging from -180 at the bottom to +180 at the top. The origin, where the x and y coordinates are both 0, is at the center of the Stage.
|
Wrap-around behavior
As another clarification, when the next costume block is used (as in Figure 24) to change to the next costume in the sequence and the current costume is the last costume in the sequence, the first costume in the sequence is automatically selected as the next costume.
Hopefully, by thinking about the pseudocode explanation in Figure 25 and comparing it with the actual code in Figure 24, you will be able to understand the code in Figure 24.
Do a shoulder shrug
The code in Figure 24 controls the animation of the BoyWalking sprite between the appearances of the BoyShrug sprite. As I mentioned earlier, the walking animation and the shrug animation are actually accomplished using two different sprites wearing costumes that cause them to look like the same boy.
The last three blocks in the animation loop in Figure 21 are shown in Figure 26.
Figure 26. The last three blocks in the animation loop.
|
|
Hide the BoyWalking sprite
When a hide block belonging to a sprite is executed, the sprite will become totally invisible. When a show block belonging to a sprite is executed, the sprite will become visible to the extent that the ghost effect, if any, being applied to the sprite will allow it to be visible.
The code in Figure 26 causes the sprite named BoyWalking to become invisible by hiding the sprite. Then it sends a message to the BoyShrug sprite telling it to do its thing. Then it waits for some amount of time, following which the BoyWalking sprite becomes potentially visible again. The assumption here is that the BoyShrug sprite has once again become invisible so that both sprites won't appear on the Stage at the same time.
A different kind of broadcast block
Note that the broadcast Shrug and wait block in Figure 26 is different from the simple broadcast MoreOpaque block used in Figure 24. Also note that you can't specify the amount of waiting time using the block in Figure 26 as you can with the simple wait block in Figure 24.
How long does the BoyWalking sprite wait?
I don't believe that I have mentioned this before now, but you can get help on the behavior of any block by right-clicking the block and selecting help in the popup menu. When you do that with the broadcast Shrug and wait block, the resulting help screen indicates that the message will be broadcast and the executing script will pause at the broadcast block until all of the scripts that are listening for that message execute their code and terminate.
In this program, this means that, the execution of the script belonging to the BoyWalking sprite will pause and wait for a script belonging to the BoyShrug sprite to finish executing. (There are no other scripts listening for the "Shrug" message in this program.)
Once the waiting period shown in Figure 26 has ended, the BoyWalking sprite is once again made visible and control returns to the top of the animation loop shown in Figure 21. The entire walking animation process will be repeated until the process has been executed 50 times. Then the program will terminate.
As mentioned earlier, the BoyShrug sprite has only one costume, which is the leftmost costume in Figure 16. Therefore, there should be no need for me to present an image of the Costumes tab for this sprite. By now, you should have a pretty good idea what it looks like.
Controlling the ghost effect
This sprite has three scripts, two of which are shown in Figure 27. The two scripts shown in Figure 27 control the ghost effect as it relates to the sprite named BoyShrug.
Figure 27. Scripts that control the ghost effect for sprite BoyShrug.
|
|
Initializing the ghost value
To begin with, the first script causes the value of the ghost effect for this sprite to be the same as the initial value of the ghost effect for the sprite named BoyWalking. (See the matching initialization code in Figure 19.)
Also note that the first script in Figure 27 hides the sprite when the user clicks the green flag.
Maintaining the ghost value
Recall that the BoyWalking sprite broadcasts a "MoreOpaque" message each time it reduces its ghost value by 1. The second script in Figure 27 responds to each such message and also reduces the ghost value for the BoyShrug sprite so as to keep the ghost values for the two sprites the same. As a result, whenever the BoyShrug sprite appears on the stage as a temporary replacement for the BoyWalking sprite, it will appear with the same level of transparency as the current transparency level of the BoyWalking sprite.
The animation code
The script in Figure 28 is executed each time the BoyWalking sprite broadcasts the "Shrug" message in Figure 26.
Figure 28. Animation code for the sprite named BoyShrug.
|
|
Set the position
The first blue block in Figure 28 causes the BoyShrug sprite to move to the current position of the BoyWalking sprite.
Set the size and become visible
Recall that I pointed out earlier that the costume applied to this sprite is smaller than the five costumes applied to the other sprite. (See Figure 16.)
The first purple block in Figure 28 increases the size of the costume on this sprite to 115% of its original size. I determined experimentally that this makes this sprite look to be about the same size as the other sprite.
Recall that the other sprite hid itself before broadcasting the "Shrug" message that triggered the execution of this script. (See Figure 26.) The second purple block in Figure 28 causes this sprite to show itself and become visible to the extent that its ghost value will allow it to be visible.
|
Another if-else-if structure
The show block in Figure 28 is followed by another if-else-if structure that causes this sprite to say three different phrases. However, rather than dividing the value of a counter by three and using the remainder to determine which of the three phrases to say (as in Figure 22), this code divides the current horizontal coordinate of the sprite by three and uses the remainder to determine which phrase to say. As a result, the three phrases do not appear in an obvious pattern, but rather appear to be in random order.
Hide yourself
After the BoyShrug sprite says the selected phrase, which remains on the screen for approximately one second, the script hides the BoyShrug sprite and terminates. As I indicated earlier, this is just what the code in Figure 26 is waiting for. That code resumes execution, at which time it causes the sprite named BoyWalking to show itself and resume pacing back and forth on the moonscape.
An online version is available
My version of this program has been posted online so that you can run and/or download it from there. (See Resources for the link to the online version.)
I encourage you to use the information provided above to write and run this program. Experiment with the code, making changes, and observing the results of your changes. Make certain that you can explain why your changes behave as they do.
I began this lesson by providing a large amount of information on how to use Scratch to write animations and game programs, including an explanation on how to use all of the parts of the user interface.
Then I explained why Scratch is an object-based programming language but that it is not an object-oriented programming language. Basically, it is not an object-oriented programming language because it fails to support the three concepts required of all object-oriented programming languages:
Finally, I presented and explained an animation program that is much more significant than most of the earlier programs that I have presented in this series of lessons.
My version of this program has been posted online so that you can run and/or download it from there. (See Resources for the link to the online version.)
In keeping with the current theme of the series, "Fun with Scratch," the next lesson will deal with perspective and animation.
Copyright 2008, Richard G. Baldwin. Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.
Richard has participated in numerous consulting projects and he frequently provides onsite training at the high-tech companies located in and around Austin, Texas. He is the author of Baldwin's Programming Tutorials, which have gained a worldwide following among experienced and aspiring programmers. He has also published articles in JavaPro magazine.
In addition to his programming expertise, Richard has many years of practical experience in Digital Signal Processing (DSP). His first job after he earned his Bachelor's degree was doing DSP in the Seismic Research Department of Texas Instruments. (TI is still a world leader in DSP.) In the following years, he applied his programming and DSP expertise to other interesting areas including sonar and underwater acoustics.
Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.
-end-
