How I teach Scratch

This is a sketch of the kinds of projects we offer as ways to help kids get into and figure out Scratch programming.  

This isn’t either 1) a full overview of Scratch, or 2)  a fully fleshed out “Scratch curriculum.” — there are many high quality examples of both of these things.  For general Scratch education resources, I recommend browsing the Scratch Ed website — scratched.gse.edu — where you can find, among other things, the best textbook on Scratch and programming that I’ve found — http://scratched.gse.harvard.edu/guide/

So what is this document, then?  This a set of thoughts about what is going through my head as a teacher and programmer as I help kids with various Scratch projects.

Day 0 — Set up Your Computers

For almost all beginning programming classes I highly recommend having every kid using their own computer.  I think there’s a tendency to want to pair kids up and have 2 kids per 1 computer, either because of resource scarcity, or because of a desire to encourage teamwork and collaboration.  

While there are good reasons to want kids to work and think together, I think that the first stages of learning to program involve a lot of getting used to using the programming environment and becoming comfortable with the idea of editing code, running it, and seeing what happens.  Programming is almost uniquely well-suited to exploratory learning because changes in your program are so easy to make, undo, and receive rapid feedback on (of the form “does it do what it was supposed to or not?”) just by running it.  If you have two students working together on the same computer, you will, at best, significantly slow the pace of exploration and fluency-acquisition, and at worst create a scenario where the student who isn’t actively “driving” the computer zones out while the other one fiddles around and figures things out.

As students gain fluency in basic programming, and start to work on more complex projects, it can make a whole lot of sense to have them work together.  

My heuristic for when this is a good idea is when students start talking about computer programs using human-language terms and can effectively take a human-language description of a computational process and convert it into a computer-language version — when it becomes seamless for them to go from:

“keep checking whether the cat is touching the spider, and if it is lose a life”

to the Scratch block arrangement:

scratch_block_1

Scratch can be run from within the web browser on any computer that has Flash installed.  You can also download the offline editor — https://scratch.mit.edu/scratch2download/ –, which takes a little bit of setup, but is generally worth having available as a back-up for when your network inevitably fails.  

You will have network problems.  The web browser is continually storing the state of the program in its own memory, and then periodically talking to the server and saving it online.  That means that you can save a local copy of a program you’re working on online, even if you’ve lost your connection to the internet.  If someone’s computer stops talking to the Scratch website, have them immediately download their program to their computer, and then reload the page.  Then upload it again if the downloaded version has changes that weren’t correctly saved.  

Day 1 — What is Scratch, how do I get started, and a first project

concepts covered: programming, loops, variables, events, sensing, cartesian coordinates, conditionals

Start with an overview of the various features and structures.  I deliver this as a lecture showing what I’m talking about on the projector.

What is Scratch?  

what are Sprites?  Sprites are the things that make up the world of your program.  They are nouns.

what are costumes?  Costumes set the appearance of sprites.  Every sprite has at least 1 costume but can have as many as it wants.  To change what a sprite looks like, change its costume.  The are adjectives.

what are blocks?  Blocks are the most basic commands we can give sprites.  Blocks tell a sprite to do something or how something should be done.  They are verbs.

what are scripts?  Scripts are collections of blocks snapped together.  They control what a sprite does, how it behaves, and how it responds to other sprites.  Each sprite can have as many scripts as it wants, and each script is made up of a collection of blocks.  Every behavior that a sprite has, everything it does, comes from a script.  They are sentences.

what is a background?  A big sprite that can’t move.

what is a backdrop?  A costume for a background.

The next section is a guided “this is how you do stuff” explanation — I demonstrate on the projector and encourage students to follow along and do the same things on their own computer.  We take breaks and work on our own to solve the various “challenges” that are posed and then come back together to talk about how we solved them.

How do we use it?

using blocks — the script tab starts with the movement section open.  This is a great place to start because it’s very visual and very intuitive — when you tell a sprite to move you see it move immediately.

start by double-clicking on the various movement blocks and watch them happen.  You can trigger a block by double-clicking on it and this is the best way to see what it does!  Then snap a few blocks together and observe how they behave in sequence.  Point out how many blocks, like the “move [10] steps” block have text-field that you can change the value of.

Here I want to pull out a bunch of blocks and play around with them — and get students to do the same thing.  Important things to think about here are the difference between turning+moving steps and changing x,y coordinates — they’re both equally valid ways of thinking about motion, but they are very different models.  Also it should be clear at this point that blocks execute in order starting from the top and going to the bottom, and that, consequently, the order of the blocks matters.

Also show the “pen up/pen down” blocks because they’re fun and handy for the next challenge.

control/event blocks — these blocks don’t do anything directly, but they affect the ways that other blocks behave.  Look at loops, repeats and then offer a challenge!

challenge —  “put your pen down and see if you can make your sprite draw a square.”  For students who get this challenge very quickly, you can give them other shapes — triangle, pentagon, hexagon, etc.  

This is also a great way to talk about geometry (for instance, the sum of all of the angles that your sprite turns to draw a polygon will be 360)

scratch_block_2.png

But how do we program?  It’s worth noting here that so far, we haven’t done much that’s good for anything — we’ve made sets of instructions and had the computer follow them, but the thing that makes programming really cool is that it can be interactive and take input from the user or the environment.  To get to that, we need to talk about the “events” blocks.

When Flag clicked, when [key] pressed — These are the most basic event blocks.  The green flag is generally used as the “start” button for a scratch project.  Clicking the flag starts all of the beneath the “when flag clicked” block.  Demonstrate how “when flag clicked” and “when [space] key pressed” work in some very simple way, and then offer the next challenge.

challenge → make your character be able to be controlled somehow — for instance, move up, down, left, right when the up, down, left, right arrow keys are pressed.

scratch_block_3.png

[In some contexts, this is a good time to take a break and get out of seats and move around.  If this seems desirable, we like to play a game where we pair kids up, and have one of each pair be the programmer, and the other the sprite.  The sprite is blindfolded and the programmer follows the sprite around directing them using only the scratch movement block commands.  Lots of games are possible with this framework, but the simplest is probably that each sprite has a hidden object somewhere in the room that they need to retrieve.]

From here, we’re moving into making our first project, which is a “collect objects while being chased” game.  So, back to the computers, and pick a sprite to be the thing that chases you.  Show the sprite library and the “paint new sprite” sections.

challenge — Make the new sprite always chase your character.  This is a big challenge that we haven’t really covered the prerequisites for, so it can take a little bit of guidance.  If students seem confused, I recommend showing them the “point towards [sprite]” block in the “motion” section.

Students should end up with something that looks something like:

scratch_block_4.png

sensing + conditionals — once we have our cat being chased, we want to lose the game if we get caught.  Show the sensing blocks and if-then statements, and make a script that looks something like:

406F838F-E9DC-781A-90B3-9DFD57B490E1.jpg

It’s worth noting, here, how the shape of a block determines what it is and what kinds of blocks and spaces it can snap into.


Next I’ll introduce the random operator to do “when flag clicked go to random x random y” for the purposes of….

challenge — Add a third sprite (“coins”) that you are supposed to collect and when you touch it you say something and it teleports to a random point.  This is a good time to talk about the coordinate system and the boundaries of the screen, since you’re picking random values for positions that correspond to these boundaries.

variables  — Then it’s back to demonstration on the projector — show how to make new variables and point out the “set” and “change” blocks for variables.  Make variables for “lives” and “score”, have them be set to good starting values when the flag is clicked.

challenge — make it so that when you get hit by the enemy you lose 1 life, and that when you collect a “coin” your score increases by 1.  The main troubles students will have here are 1) forgetting to put their “if-then”  statements in “forever” loops, and 2) having “lives” go instantaneously down to 0 because it doesn’t stop checking after you get hit — I recommend having the player go back to a starting position, but you could also just put in a “wait 1 second” block and make you invulnerable for a second.

Bring everyone back together to show how this is done, let people demonstrate their solutions if they have significantly different ones, talk about what works and what doesn’t and go over the various problems people experienced, and then jump right in to the next challenge:

challenge  — make the enemy get faster as your score goes up.

this is pretty straightforwardly making the enemy “move [score] steps” instead of “move [10] steps”, but it’s a piece of abstract integration that new programmers can be confused so it’s worth doing and making sure everyone understands.

A finished example project is here — https://scratch.mit.edu/projects/26477731/

 

Day 2 — Prettymuch everything else

concepts covered: everything from last time , AND events + interrupts, more sensing, costumes, threads and synchronization

Obviously when I talk about “concepts covered” I don’t mean we’ve become expert at using them yet, just that we’ve seen then and done something with them.  We don’t become expert at computer programming by being told how blocks and functions work — we become expert by using these structures over and over again and using them to translate ideas into code.  

Programming is very much more about acquiring fluency with a set of ideas then it is about learning a set of facts.

So on day 2, let’s get started by reviewing our last project.  Everyone will have gotten various pieces of their games working — spend the first 20 minutes or so of class letting students show off their projects to each other while you help debug individual problems.  Keep a mental list of the problems that students have with their games so that you can go over them, and their solutions, together on the projector as part of an overview of what we’ve already learned before moving on.

After the overview, we want to jump right in to a challenge.  Supply everyone with a very simple story — it can be fun to generate this story in a mad-lib kind of way, and I’ve written a program to generate funny stories in Scratch that I use for this project — you can find it here —

https://scratch.mit.edu/projects/89469685/

By remixing this project and changing the words that are in the “make word lists” section of the code, you can change what words the program uses to generate the story.  It’s fun to brainstorm the list of words with the kids and then run the generator a bunch of times to find a funny story to animate.

This is fun, and a neat way to demonstrate some of the more abstract concepts and possibilities of Scratch without having to get into them just yet.  But really anything you do to come up with a story for everyone to animate is fine.  

It also might be great to make a dice and paper-based “story generator program” with lists and charts and stuff.  This could be a good way of relating computation/programming concepts to concrete real world stuff.

No matter how you end up with a story for everyone to tell, once you have one you’ll want to go over some of the blocks that are most useful for animation — in “motion” you’ll want to demonstrate “glide”, “point towards”, “go to [sprite]” as well as talk about rotation style.  In control, “repeat until”, is very handy for getting sprites to walk up to other sprites, and “broadcast”/”when I receive” are really important for synchronizing events like scene changes.  Also “wait” and “wait until” can be used for timing and synchronization.  In “looks” “show and “hide” will be very important.

challenge — animate our story.

This is a big challenge and will take a while.  This is actually a really good spot to have students pair up and work together.  They will need to think about art and storytelling as well as programming concepts and relate them to each other.  It’s nice to leave this challenge pretty open-ended and let kids mess around to find ways to solve the problems that come up as they work.  Make yourself available to answer specific questions, and whenever an answer feels relevant to the group as a whole, get everyone’s attention and demonstrate it on the projector.

This is our first real taste of the “try something, see what happens, see if you like, and change it if you don’t” method of learning to program.  It’s a great project to start to think like this because adding new scenes and sections to an animation is inherently incremental.  Students will get something to work and then they’ll move on to something new that they don’t know how to solve and they’ll figure it out by experimentation or you’ll show them something to help.

I can’t stress enough that this challenge will take a while.  The students will feel attached to their stories and they’ll want to make them perfect.  At a certain point you’ll just tell them that they have 5 minutes left and then everyone presents and they’ll all finish it up as fast as they can at the last minute.  

It’s best if the story itself is completely ridiculous (which is why the random story generator works well here) because then the whole thing feels silly and playful and nothing feels perfect or polished and it feels more okay to the students when their projects don’t work.

Make sure to have time to show all of the animations on the screen and let students talk about how they solved various problems.  This should be really funny and silly and is a great way to bring everyone together for something light and fun.  Also you should have your own version of the story to show — it probably will be shoddy and ridiculous since you’ve mostly been helping students, and your students will enjoy seeing that you also can’t make something perfect under time-pressure.

Further explorations:

That’s a very-short, very-intense introduction to programming in Scratch.  It covers many of the important concepts, and gives students a taste of what the thought-process behind programming is.

We haven’t gone into making new blocks, or using “clones” of sprites yet.  Both of these are forms of abstraction that allow you to duplicate functionality without writing new code — this is a big part of programming, but one that, as a programmer, I think is very confusing until you’ve actually just written a lot of software.  It’s hard to see what advantages you get out of these abstractions until you run into a problem that is made easier or simpler.  At first, just writing programs that do things is hard enough that it doesn’t really pay to make the flow of the program any more complicated or abstractly complex.  

From here, you really want to alternate between giving students short simple conceptual exercises so that they can see individual ideas in relatively easy-to-understand contexts, and giving them time and space and direction to work on a larger more ambitious project that they are excited about.  

The ScratchEd team — https://scratch.mit.edu/users/ScratchEdTeam/ — has a great series of Debug It! challenges that you can give to students, perhaps as homework assignments or warmup drills at the beginning of a class period.  

Some ideas for further projects include:

Rock Paper Scissors game — have the computer play randomly against a human.  This is a good project for showing the “design process” because rock paper scissors is a game that everyone knows and it’s pretty simple to describe all of the things that the project is going to need:

  1. a way to select rock/paper/scissors
  2. a way to randomly generate computer’s choice
  3. sprites to display ours and computers
  4. system to determine winner+loser
  5. keeping score

Agar.io! — http://agari.io

This is a game that all of the kids I know are super into, and it has incredibly simple (and elegant) gameplay, which makes it a great candidate for a teaching project.  The gist of the game is that you control a blob that gains mass by eating (touching) particles, and if you touch another blob that’s smaller than you, you eat it.  You can make a simple single-player version of this with a randomly moving enemy blob in a bounded playing field pretty easily.  

It’s also great project to teach about clones because you’ll want to make there be lots of identical food particle objects.

Pong — this is quite simple to do a basic version of, but can get more complex if you want to more precisely imitate the way that the ball bounces off of the paddle in the original game.  

Random Story Generator — this is a great project, and once students have more Scratch and programming under their belt, it can be a fun assignment.

Predator-Prey simulation — https://scratch.mit.edu/projects/26812899/ is an example — this is a great project because it suggests an entirely new kind of project, beyond game and movie — the simulation.  It’s nice because it relates to the practice of doing science, and experimentation, because you can pose questions and see results (“what happens if we make the sheep starve more easily”.)  It’s also a nice programming project because it benefits significantly from the abstraction of new blocks and clones.

But basically any sufficiently complex project that a student is interested in will get you to pretty much all of the important programming concepts.  Just be open, encourage the students to be ambitious, and experiment.  

A few final more abstract thoughts:

Don’t let students get away with making things that don’t work right.  When they find bugs in their programs that are confusing to fix, a lot of the time they will respond by saying “I like it like that!”  They don’t want to have their program not work, and are intimidated/confused by figuring out how to make it work, so they will invent this mechanism for not having to fix the problem by defining it as not a problem.  

This isn’t always horrible, but most of the time it’s just a way for new learners to avoid leaving their comfort zone, and therefore avoid learning new things.  Fight against it!  Students should be aware that programming is 99% failure, and once you succeed you just start working on something new to fail at again.  When my students say “it doesn’t work!” my default response is “That’s because you’re programming it!  If it worked, you’d be done.”  

Programming gives us this really great way to figure stuff out experimentally and try and try and try again until it works right.  This is absolutely the most important thing you are teaching your students when you teach them to write software — how to figure something out by working on it, how to think about a problem by exploring the system and seeing what happens, and how to learn about something by messing up over and over again.  This experimental/iterative attitude towards learning will come in handy literally every time they try to learn something new.