Tip:
Highlight text to annotate it
X
>> ZAMYLA CHAN: Hello, and welcome to the Scratch walkthrough.
My name is Zamyla and I'll be leading walkthroughs for you this year.
In CS50, every problem set is accompanied by a walkthrough.
During these walkthroughs I'll go over the week's problem set, explain the
concepts required and break up the problem set into manageable bites.
>> For the first p-set in CS50, we actually won't get into typing and
machine code stuff quite yet.
Rather, we're going to use Scratch, a program that allows us to explore
programming concepts in a visual and creative way.
This walkthrough will explore fundamental concepts that we'll use
throughout CS50, as well as serving as a Scratch tutorial.
In every walkthrough I'll list a set of tools that you can use for the
problem set.
From larger course concepts to actual functions, it's good and helpful to
know what you're equipped with before tackling the problem set.
>> First, let's talk about sprites.
Sprites are central to making projects in Scratch.
Every object or every character, be it a cat, a dog or a
ball, is called a sprite.
If I want, say, two cats in my project, I'll need to make two
separate sprites in Scratch, even if they're absolutely identical.
>> Each sprite has scripts associated with that specific sprite.
Scripts are what you're going to be building by dragging
and dropping blocks.
Scripts are instructions that determine and define
how the script behaves.
>> Now, sprites aren't just images.
A sprites costume determines what the sprite looks like.
Any given sprite can have more than one costume.
A bit later during this walkthrough I'll show you how you can have your
sprite change costumes during your program.
>> To create a sprite in Scratch, you can either choose its initial costume for
Scratch's library, draw your own in Scratch's built-in paint editor,
upload your own image, or take a picture with your computer's camera.
All of the sprites are placed on what we call the stage.
The stage is like our canvas where sprites can move around.
>> Though we can have multiples sprites, there can only be one stage.
Otherwise, stages and sprites are quite similar in that the stage can
also have scripts.
Scripts on the stage are very useful when you don't have a script that
doesn't necessarily pertain to one specific sprite.
Maybe it pertains to multiple stripes, or none at all.
>> It's generally good design to place your scripts on the stage if they are
general enough and don't pertain to specific sprites.
And just like sprites have costumes, stages have backdrops that can change
over the course of your program.
And you can draw your own, upload an image, take a picture, or use the
Scratch library of backdrops.
Both the stage and sprites can also play sounds from Scratch's library, or
you can upload and record your own.
>> To start your Scratch program you'll need to click the green flag at the
top right corner of the stage window.
But if you don't connect anything to this block right here, then nothing's
actually going to happen because your sprites and the stage need to be told
to respond to the event of the green flag being clicked.
So you'll need to attach blocks to the groove at the bottom of the green
flag, and then the program will execute those actions when you start
your program.
>> Well, what comes after that?
Well, Scratch has lot of blocks for you to use, and you can
even make your own.
You'll see three tabs, Scripts, Costumes and Sounds.
Under the Scripts tag are categories of statements.
Statements are conveniently organized by color.
You have actions related to movement, sound, looks, and so on.
Though you'll have other blocks built around your statements, it's the
statements that will help the sprites or the stage to do something, whereas
other blocks will help determine when to do them.
>> Let's say you're creating your very first project and you only want the
cat to meow under certain circumstances.
To implement this, we can take advantage of Booleans.
These are expressions that evaluate to either true or false.
In Scratch these are identified by the angles at the end of the blocks.
You'll have a variety of different types of Booleans such as is the mouse
being pressed down, does 2 plus 2 equate to 5, or is the user pressing
down a certain key on the keyboard?
>> Now, you can't just use these Booleans alone.
You'll need to combine them with what we call conditions.
Condition blocks can be found in the orange control statements.
Conditions conveniently have a little placeholder that shows the shape of
the block that you need to put into it.
So depending on the context of the situation, you can choose a Boolean
and place it inside your condition.
And put together, you have a conditional statement.
Once you put statements inside that block you have a structure set up
whereby once a certain condition is met, you then execute those
statements.
>> One of the advantages of computers is the vast power and speed at which they
can execute repetitive processes.
Instead of, say, repeating an instruction over and over and over
again and actually typing that out, or in this case, dragging and dropping
and dragging and dropping, what we can do is encapsulate in a loop.
>> Loops can be used to either execute things infinitely with a forever loop,
or for a set number of times.
For example, repeat the statement, say hi, 10 times, or maybe until a certain
condition is true.
And with this Repeat Until block you see that Scratch is hinting that
you'll need to place a Boolean into the Repeat Until block to make a
conditional statement.
>> Now, we know that we can encapsulate repetitive processes inside of loops,
so you can see why something like this might not be ideal.
It's super long, it just does the same thing over and over
again, 10 times in fact.
It moves 10 steps, says hello, move 10 steps, says hello.
But with the help of loops we can tidy this up a bit.
See how this is much better.
It's shorter, it's smaller and it completes the same thing.
>> Moving on to variables.
Variables are essentially containers for values.
In Scratch, those types of values can either be words or they can be
numbers, values that we have control over.
In this first block we have a text variable containing the
value, Hello, World.
In the second example, it's assumed that we already have a variable named
Counter and we're incrementing it by three.
And then, in the last example, we see an example of variables being used
inside of conditions.
In this block, we ask if the variable Counter is less than zero.
>> Now, when you create a variable you have to decide whether you make the
variable available to all of the sprites in your Scratch program, or
just for the specific sprites selected when you make the variable.
And this is a very important decision to make.
It comes down to what scope you want the variable to have.
>> An example of local scope would be a variable just for one specific sprite,
which means that only that sprite would be able to see or modify it.
If you determine a variable with global scope by selecting for all
sprites, then that means that the stage, as well as all of the sprites,
will be able to see, modify, and access that
variable that you've created.
And in terms of design, it's best to choose local scope whenever you can
just so that the rest of the sprites and stage don't have to worry about
keeping track of that variable.
>> You can actually have two variables of the same name for different sprites as
long as those are local variables.
Sprite one, a cat, can have a variable name Counter, and sprite two, a dog,
can also have a variable named Counter as long as these
are both local variables.
Because the scope of the variable doesn't extend to the rest of the
program, and none of the other sprites or the stage will get confused.
>> Earlier, I mentioned the entry point, the when green flag clicked block.
That block and the accompanying statements are essentially telling
your sprites or the stage, OK, when the green flag is clicked, this is
what you should do.
But that isn't the only event that sprites and the stage can respond to.
We have, for example, an event for when a keyboard key is pressed.
You can actually choose the letters A through Z, zero through nine or the
arrow keys.
>> There are other events, too, such as when your sprite is clicked.
When you start with event blocks like these, you'll notice a trend.
They all have a single group on the bottom and a smooth top, which
indicates that nothing above attaches to that block.
You build under those events blocks and build downwards.
>> Now, what happens if we want some event to happen, say, when a cat is
touching a certain section of the stage?
We actually don't have any built-in event to signify that, so what we'll
have to do is create our own event.
And that's called broadcasting.
>> So when you want to signal that a certain event has happened, then you
use a black called Broadcast, which is found in the Control tab.
There you'll type in the name of the event that you want to broadcast, and
then whichever sprite or stage can react to that
broadcast if you so wish.
The When I Receive block tells the sprites what to do when they're
notified that your custom event has happened.
So remember that whenever you broadcast an event, it's with the
understanding that either one of the sprites or the stage is going to
receive that event and respond to it.
>> Now, the last concept before we get to an actual example of a Scratch
program, is the concept of threads.
That's when your computer is executing simultaneous
processes at the same time.
And I'm sure we've all taken advantage of this.
Like surfing the web while listening to music.
The computer can execute several things at the same time.
>> In this example here, these two scripts can be used for
the exact same sprite.
The entry point block, When Green Flag Clicked, is used multiple times, but
they are two separate scripts.
Indeed, the Green Flag Clicked block will probably be one of the most
popular blocks in your program.
Here we see that when the green flag is clicked, there's one process going
on, as well as another.
So Scratch will actually run these two at the exact same time.
And knowing that you can actually have more than one entry point, even if
it's the same entry point, is going to be really useful if you want to
separate distinct tasks from one another.
>> All right.
So now that we've covered all of these concepts, let's look at an example.
I've made a series of Scratch programs, so try to follow along as we
make a little game.
Let's start by opening Hungry Dino Zero.
>> Let's click the green flag to start it and see what it does.
We have a bug sprite that moves for a few steps, resets at some height, and
then steps back.
And then we have a dino sprite.
By pressing the arrow keys, I'm moving the dino sprite around, making it turn
and rotate.
That can be kind of fun, but there aren't very many
scripts in this program.
We can definitely add to this.
>> For instance, when the dino is moving it can actually get off the screen and
almost disappear from site.
We want to change that because we don't want the dino to escape.
So let's stop our script with the red flag and then edit the dino scripts.
Notice that this particular script has a forever loop, which ends with a
straight edge.
It doesn't have any groove at the bottom.
And this makes sense from the name, a forever loop.
It's executing something infinitely and will never end.
So this is a great opportunity to introduce a thread.
>> All right.
So let's add another script.
I'm going to start with this entry point, When Green Flag Clicked.
And I want to continuously check whether the dino is going to be
touching the edge.
Under Motion there's a neat little block that says, If On Edge Bounce.
And so we want to continuously execute this.
>> What this statement does is checks if the sprite is on the edge of the
stage, and bounces back if it is.
And because the user can always move the dino, we want to find some kind of
loop that allows us to continuously execute this statement.
Looking under Control we'll choose the Forever loop.
So let's drag that into the dino scripts, and then
add If On Edge Bounce.
And then let's test our program.
>> So the bug is moving as per usual, and then if we test out our new script by
moving our dino to the edge, we see that it can't
escape the stage anymore.
It bounces right back.
Now you might wonder why the dino bounces but not the bug.
Well, that's because we wrote our newest script inside the dino scripts
and not the bugs.
So the bug won't listen to the instructions we gave the dino.
>> All right.
So let's add something new now.
If you go to the Costumes tab you'll see that the different costumes that
come preloaded with your selected sprite if you choose one from the
Scratch library.
There's this cute little dino chomp costume, so let's implement the dino
chomping when we press, say, the Space key.
>> Back to the dino scripts.
In this script here, I'm already checking in the forever loop whether
certain arrow keys are being pressed and moving the dino accordingly.
If they left arrow is pressed, the dino rotates counter-clockwise.
If the right arrow is pressed, the dino rotates clockwise.
So if the up arrow is pressed, then the dino progresses forward.
We can just add to the script instead of adding a separate one because this
is already checking in the theme of which keys are being pressed.
>> Let's add one that checks for the Space key being pressed.
These blocks here are checking for the keys being pressed.
They're all in the brighter blue, so let's go to bright blue sensing
statements and look around.
Here's a Key Spaced Press block.
So what we want to do is have the dino switch to its chopping down costume
if, and only if, the Space key is being pressed.
>> So let's mimic the structure here.
Now, changing the costume has to do with how the dino looks so we'll go to
Look statement.
And sure enough, we have a Switch Costume to Dino Chomp.
Now, when we chomp down we don't want the dino to be chomping down forever,
so let's add a statement telling it to switch back.
It'll switch costumes kind of quickly, though, because in Scratch statements
will execute back to back really quickly, almost instantaneously.
So let's go to Control and then make the dino pause for a little by waiting
one second after it chomps down.
>> Now let's edit the bug sprite.
The bug sprite steps forward five steps a total five times after a
moment's pause.
In the top block here the bug places itself at a certain
x-coordinate value.
To find the coordinates you can actually mouse over the screen and
then in the bottom corner of the stage window the coordinates will update so
you can take advantage of this handy feature to implement the coordinates
that you want.
And, in this statement here, we instruct the bug to start at the same
x value every time, but to pick a random height for the bug that still
stays within the constraints of the stage.
>> See here that I'm taking advantage of the event broadcasting in Scratch.
This event handler is called New Bug1.
So whenever the bug receives the New Bug1 event,
it'll execute the statement.
So after it moves forward its set amount of times, it actually
broadcasts the event New Bug1.
>> But how about we change this script a little?
Right now we have the bug moving five steps.
That's not a lot, a total of five times.
We don't really know how many times will be needed until the bug reaches,
say, the end of the screen, so let's make the but reach the end of the
screen, but use some kind of other construct.
>> I'm going to separate this out because we're going to change a few things.
To delete blocks from Scratch you drag the blocks to the
left and then release.
And it gets deleted.
If you decide that you didn't want it deleted then you can
go to Edit and undelete.
But we did want to get rid of that block.
>> What we want to do now is move, say, 50 steps and pause one second, and
repeat this until we touch the end of the screen.
So let's use a loop that allows us to repeat a process until a certain
condition is met, aptly named Repeat Until.
>> What goes inside the condition of a Repeat Until?
Something that tells us whether the bug is touching the edge of the
screen, which is going to be under the Sensing Statements.
Here's this Boolean, Touching.
And you can select here what you want to check for.
So we'll select Touching Edge and add this conditional statement back in.
>> So now if we watch our bug, it'll move back again once it touches
the edge of the stage.
Great.
We're finished with Hungry Dino Zero, so let's open Hungry Dino One.
Kind of like a cooking show, I've added a little bit more features.
For instance, you'll see that the bug is actually gliding quite simply now
as opposed to before.
Under motion there's this glide statement.
Now, the bug glides 70 units to the right of its current exposition, but
stays at the same y position here.
And we can now have a dino chomping as we implemented before.
>> But, this program isn't called Hungry Dion for nothing so let's have the
dino eat the bug.
How might we tell the bug, or tell the dino, that it has chopped down?
How might we communicate this event?
Well, we know that when we switch the costume for the dino to the dino chomp
that we've chomped down.
And say we want the bug to disappear once it's eaten.
Well, we'll have to check whether the bug has been chomped on and
communicate to the bug that it'll have to hide or disappear from the screen
once it's been chomped down.
>> So what kind of concept, what kind of tool can we use to have the dino
communicate to the bug that it has chomped down?
Broadcasting.
So let's go to Events and add an event to broadcast.
Chomp.
OK.
But remember that once we broadcast something we also have to
receive this event.
So which sprite will broadcast chomp?
Well, let's have the dino do that when the Space key is pressed.
>> Let's add a block to receive chomp.
Now, when the dino comes down just on an empty space we don't want the bug
to react to that at all, only if the dino was touching the but at the time
of the chomp do we actually do something.
So we'll use the condition If because we're checking whether something is
true or not.
>> Now if we go back to Sensing, then we can use this Touching
block and select Dino.
Then, under Looks, we find this Hide block that'll basically make the bug
disappear from the stage.
>> We'll make it hide, but we do want another bug, right?
Our dino is hungry.
So we want to give it another bug to chase.
So let's also broadcast the event New Bug1.
Except we want it to wait for a while before another bug appears, so let's
also wait one second.
>> All right.
So let's check this out.
We chomped down, a but disappears, another one appears, and we chomp down
on it again.
This is looking like a pretty fun game, but all games
need to score, right?
So what can we use to keep track of how many bugs the dino has eaten?
A variable.
So let's add a variable called Score.
>> And now we'll have to decide what scope this variable has.
So let's think.
While we might want the but to increase the score if it's been
successfully eaten, and the stage might have something to do with the
score as well, so let's assign this variable to all sprites.
>> We want to increase the score if, and only if, a bug has been eaten.
And we've already written a script that deals with a bug being eaten so
let's add this one statement in, Change Score By One.
That means that once you eat a bug the score increases.
>> Let's play for a bit and eat, I don't know, three bugs.
So you get tired of the game, well, you'll press the red stop
sign to stop the game.
And when you want to come back you'll press the green flag again.
But the score is still three even though I'm playing a new game.
We don't want to give users a head start, so we'll need to reset the
score every time they start a new game.
So let's add a statement to the stage's entry point script to set the
variable score to zero.
So now, whenever you start a game, the score will start at zero.
>> Now let's open Hungry Dino 2 where I've added a few more things.
I right clicked on the bug sprite to duplicate the sprite which made a
sprite identical to my previous one.
Poison Bug is essentially identical to Bug1 but I chose a new costume because
I thought it looked, well, kind of poisonous.
Instead of increasing the score when the poison bug is eaten, I actually
decrease the score by changing score by negative one.
>> And then I made another costume for our dino using the paint editor to
make a sick looking dino and named it Dino Sick.
But we don't use this costume in our program yet, so let's add some
statements and blocks that will change the dino's costume to the green sick
costume whenever it eats a poisoned bug.
>> Now, since we duplicated the bug sprite, the poisoned bug has all of
the scripts that the original bug does.
If you wanted to copy over scripts from other sprites, you can drag the
script on top of the sprite that you want to copy to.
But we won't need to do that here because the poisoned bug already has a
script that checks that the bug has been chomped down on.
And we can take advantage of this to communicate to the dino that it ate a
poisonous bug.
And we communicate between sprites by broadcasting.
So let's broadcast a new event called Dino Sick.
>> And we know that we have a costume for the dino to change to, but we also
know from earlier that it's best to add in a pause
between costume changes.
So when I receive Dino Sick, I'm going to change costume to Dino Sick, wait
one second, and then switch back to Dino Hungry.
All right.
Let's play our game and eat a bug and the beetle.
And the score decreases by one.
>> Now, sometimes you might notice that the variable might not appear on the
left hand corner of the screen.
If you navigate to Data Section under the scripts, you'll see this checkmark
beside the variables that you create.
And this hides or unhides the variable from the screen.
But you can also use a statement called Show or
Hide a Specific Variable.
So let's use this Show Variable Score to make sure that every time we start
the game, the variable is shown.
Great.
>> So let's run the game and eat a poison bug right away.
Now, it's a little odd to have a game to have negative points, right?
So let's introduce another feature.
If the dino eats too many poisonous bugs then it gets too sick and the
game is over.
So to implement this, we'll broadcast another event, Game Over.
How do we know when to execute this Game Over broadcast?
>> Well, we can do this several ways.
We can have a script in the stage that continuously checks whether the score
is negative or not, and broadcasts Game Over when the
score becomes negative.
Or we could take advantage of the fact that the only way the score could ever
be negative, is when a poisonous bug is eaten.
Because when you eat the other bug, the score increases.
There's no use in checking whether it should be Game Over or not when you
eat an edible bug.
>> So we can actually just add to the script that receives the Dino Sick
event broadcast.
We want to instruct the dino as follows.
If the score is less than zero, broadcast Game Over.
So we'll build the Score Less than Zero condition using a block from the
operator section, and dragging in our score to that block.
And see here you can just drag the variable score and put less than zero.
And we're going to broadcast a new event, Game Over.
>> But if the score hasn't gone below zero, we want the dino to
continue the game.
So instead of using an if here, let's use an if else construct.
An if else construct tells our dino to do one thing if the condition is true
and another thing if the condition is false.
The body of our first if can go into the if else, so let's drag that in.
But if the score is not less than zero, then let's switch back to the
Hungry Dino costume.
We don't want to do that preemptively.
Great.
>> But since we broadcast Game Over, we still need to make an
event receiver block.
There's actually a Stop All statement in control, so let's connect this to
when I receive Game Over.
But we also want the bug to stop, so let's drag this script on to all of
the bug sprites as well as the stage.
Let's try this out.
>> Eating a poisonous bug right away, the program stops as expected.
None of the other bugs move and neither does the dino if you press
down the arrow keys.
But let's say we don't want to remind the user of their negative score, so
let's hide the variable score from the stage whenever the Game
Over event is received.
All right.
>> So this is a pretty decent game.
With more time you can add more sprites and more scripts.
Maybe the bugs can move at different speeds.
You can add a new background to the stage--
a Game Over backdrop--
such that, when the stage receives the Game Over event, it can switch to the
Game Over backdrop and all of the sprites hide.
Lots of small tweaks can be made to make your game a little more polished.
>> And this is just one example of a project that you can make in Scratch
using all the tools that we discussed earlier--
sprites, costumes, stages, backdrops, conditions, loops, variables,
broadcasting events and threads.
Hungry Dino doesn't use any sound effects, but you can easily add your
own by navigating to the Sounds tab and exploring the sound statements.
Scratch is a great introduction to programming concepts, so be creative
and, most importantly, have fun.
My name is Zamyla, and this is CS50.