If you don't get have a Scratch account, click Join Scratch to make one. Remember to pick a password that's easy for you to remember!

Click Create to start a project.

On the right edge of the screen there is a bar with a question mark at the top. Click the question mark to open the tutorial panel.

Click the Getting Started with Scratch link at the top (or click any of the other tutorials in the list). Then follow the steps of the tutorial. (Don't worry about the step at the end for shaing your project. You don't have to share the project if you don't want to.)

Ask a mentor if you have questions or get stuck!

This is the basic version of the racer game. Start with this one, and then try some of the variations below like the Annoying Racer.

Click here to open the instructions in a new tab: racer_basic.pdf

BIG SECRET: Ask a mentor about using Ctrl-Tab to switch quickly between the Scratch and intructions browser tabs.

Some things you can add to the game:

• Add a second sprite with different key controls so you can race your friend around the track.
• Add a finish line and have the code announce the winner.
• How can you keep players from cheating and just turning around to cross the finish line immediately?

In this variation, instead of a regular track we have a screen full of obstacles. If you hit one, you get sent back to the start. That's what makes it annoying. This version also shows how to do multiple levels.

Click here to open the instructions in a new tab: racer_annoying.pdf

BIG SECRET: Ask a mentor about using Ctrl-Tab to switch quickly between the Scratch and intructions browser tabs.

Some things you can add to the game:

• Make some levels with more than one blue goal sprite. The player has to figure out which goal is easiest to reach.
• Use a variable to keep track of how many times a player crashes into an obstacle and gets sent back. If you crash more than 20 times, you lose.
• Add a second sprite with different key controls. The first player to get to the blue gets a point, and the level advances. Use variables to keep track of each player's score.
• On some levels, use another sprite to make a moving red obstacle.

This variation uses a variable to make the cat car accelerate and decelerate. The challenge is that you can only accelerate when you're on an island.

Click here to open the instructions in a new tab: racer_island.pdf

BIG SECRET: Ask a mentor about using Ctrl-Tab to switch quickly between the Scratch and intructions browser tabs.

Go to Scratch and click "Create" to start a project.

On the Stage, change backdrop1 to Vector Mode. Click with the arrow to select the white background and use the Delete key to delete it.

Pick a pen color, and then use the rectangle tool to create a maze. For instance, you could draw a maze that looks like the picture below (or a simple maze, don't worry about making it complicated, and don't worry if your walls are all exactly the same size).

Shrink the cat sprite down so that it is small enough to move through your maze.

Add a "when flag clicked" block to the cat to position the cat at the start of the maze when the flag is clicked.

Add four "when ___ key pressed" blocks to the cat script, one for each arrow key. Each block is similar, but let's do the "when up arrow key pressed" first. When the user pressed the up arrow, we want the cat to move up 5 pixels, so use a "change y by" block.

But what happens when the cat touches a wall? We can keep the cat from moving through the wall by checking if it's touching wall color. If so, we want to move it back the number of pixels it just moved. For the "when up arrow key pressed" block, this means we first move the cat up 5 pixels (as we already did in the previous step), and then use an "if" block to check if it's touching the wall color, and if so we move it down 5 pixels. When the code runs, you'll notice that it's so fast that you don't actually see the cat move into the wall and then back out. If you want to prove to yourself that it does go into the wall, you can add a "say" block to say "I'm touching the wall" for two seconds before it moves back.

Complete the other three "when ___ key pressed" blocks similar to the "when up arrow key pressed" block.

You should now have a basic maze game. Here are some ideas for things you can add:

• Put in something to check when the player has finished the maze. One way to do this is to add another small sprite at the maze exit, and you can check that the cat is at the end of the maze by whether it's touching that sprite. You can add a new (purple) block called "CheckMazeFinished" to do this check. Another way to do your "CheckMazeFinished" block is to just check that the cat's x and y coordinates are within certain ranges. You might try doing it both ways and see which way you like best.
• Make some moving obstacles, such as a spinning line. To do this, make a new sprite that is a red line. For the sprite's script, use a "forever" loop that simply changes it's direction by 1 or 2 each time through the loop. In the cat script, make a new (purple) block called CheckDeath. In this block, check if the cat is touching the color red, and if so send it back to the start of the maze.
• Make a "portal" in the maze that has two points. Make two new sprites, one for each end of the portal. When the cat touches one of the portal sprites, it is automatically "teleported" to the other portal sprite. (Not quite on it, but near it. Why is this important?) When it touches the other portal sprite, it is automatically "teleported" to the first portal sprite.
• Make a "robot" that moves through the maze randomly. Use a "pick random" block to pick a direction for the robot to move, and then move the robot 5 pixels in that direction. The robot is similar to the cat in that if it touches a wall it should move back 5 pixels in the opposite direction. It can make a big difference when you pick a new direction for the robot. One way is to pick a new direction for each move. That will make your robot jitter around quickly, but it won't tend to get very far. Another way is to pick a direction, then move in that direction until it hits a wall, and then pick a new direction. This will make your robot move through the maze much more efficiently.

Starter project (click and Remix it) https://scratch.mit.edu/projects/336064281/editor

For the beginner/intermediate version of this project, do not edit the Witch sprite. Feel free to look at the Witch code, and to try changing things. But it's easy to break the Witch. If you do, you can just delete the Witch and copy the sprite in again via your backpack. (Ask a mentor for help with this.)

Use the color codes at the bottom of the screen to draw any number of backgrounds. Each background is a level.

In addition to fixed drawing on the background, you can add sprites to make moving things. Here are some ideas:

• Make a fire pit like you see in the picture above.
• Make a spinning ball with a mix of red and black.
• Make a red thing that grows and shrinks.
• Make a moving platform.
• Make a flying red UFO.
• What else can you think of?

Talk with a mentor if you need advice choosing or planning a project.

To show you need help choosing or planning a project, hold up a peace sign like the dog above.

To plan your project, answer these questions:

• What sprites will I use in this project?
• What is the basic plan for writing the sprite scripts?
• Is there anything I need to learn about Scratch before doing this project?
• Is there anything I need to learn about programming in general before doing this project?

Follow the pattern of the code in the picture to make your own choose your own adventure game.

Each backdrop is drawn in vector mode. Ask a mentor to learn how to draw in vector mode efficiently.

Make a program that does a crazy animation to catch a mouse, in the style of a Rube Goldberg Machine.

Starter project (click and Remix it) http://scratch.mit.edu/projects/25434547/#editor

Animation sequence (feel free to do your own variations):

1. All sprites go to their starting positions, starting angles, starting costumes, starting hide/show
2. Mouse comes out
3. Cheese moves backward toward mouse
4. Switch switches
5. Panel drops
6. Car goes down ramp, changes angle, and continues across floor until it pushes the match up
7. Rocket catches fire and flies up and hits bowling ball
8. Bowling ball rolls off shelf and falls on seesaw
9. Seesaw changes sides
10. Cage flies up and over and lands on mouse

Make a program that shows what you are going to do for your summer vaction. The surfing animation is just an example.

BIG SECRET: You can either create this project from scratch or you can remix it by clicking the period at the end of this sentence.

BIG SECRET: You can either create this project from scratch or you can start by remixing a starter project by clicking on the period at the end of this sentence.

Make a program that animates characters dancing. Add a sprite for each dancer.

Here are some ideas for things the dancers can do:

• Cycle through their costumes.
• Slide back and forth.
• Jump up and down.
• Do the Twist.
• Challenge: Moonwalk.
• Challenge: One sprite spins another over their head.

Look in the Motion and Looks categories for ideas for blocks you can use.

BIG SECRET: You can either create this project from scratch or you can start by remixing an example project by clicking on the period at the end of this sentence.

Make a program that animates your initials, or your whole first name. Add one sprite for each letter.

Each letter should do an animation that starts with that letter. For instance, the initials in the sample project are MAK. The M does a "move" animation. The A does an "announcement". The K does a "kick". Each letter waits the right number of seconds before doing its animation.

Look in the Motion and Looks categories for ideas for blocks you can use.

BIG SECRET: You can either create this project from scratch using the guides below, or you can start by remixing a project that already has a couple locations by clicking on the period at the end of this sentence.

Add some backdrops to your stage. Pick backdrops that will be good for "joining together" to make an adventure game. You can choose backdrops that exist in Scratch already, or you can make your own, or you can have a mix.

In the example project we used backdrops from Scratch and gave them simple names like "woods", "path", "doors", and so on.

Notice that we showed the sprite's x position and y position on the screen. That is very useful when writing your code.

To understand how the sample code works, get help from a mentor or a friend. You can't add to the code until you understand it. One important thing to remember is that the symbol ">" means "is greater than" and the symbol "<" means "is less than".

It is also important to understand how the x and y coordinates work. Below is a picture. Notice that in the center of the screen x is 0 and y is 0. As you move to the right, x gets bigger. As you move to the left, x gets smaller. As you move up, y gets bigger. As you move down, y gets smaller. Try moving the sprite around on the screen and watch how the "x position" and "y position" values change. If you need help understanding the coordiates and the negative numbers, as a friend or a mentor.

The goal of the project is to add more code to let the sprite move around a larger world. A good starting exercise is to notice that, the way the starter project is set up, when the sprite moves from the path to the castle, it moves right into the interior of the castle. Instead, it would be better if the sprite moved to the castle doors, and then had to move upward to actually enter the castle.

Once you have the doors working, add more to the game to make the world as big as you want. What happens when the sprite goes up the castle stairs?

CHALLENGE: You can make the game more interesting by using other sprites to make objects around the world. For instance, maybe you have to find a key somewhere before you can get into the castle.

In order to keep track of things like whether your sprite has found the key, you will need to use variables. Ask a mentor or a friend for help!

The novice tutorials above introduce you to Scratch by starting from very simple scripts so you understand exactly what's happening at each step.

Another way I like to teach is to give you a picture of the code for a sprite, and have you try to build up that code exactly in Scratch.

You won't understand all the code. In fact once you truly understand all the code for this project you will be ready to take on some of the most advanced projects in this list.

But the idea here is just for you to get familiar with all of the code block groups in Scratch. By the time you get this project working, you will have a cool fireworks program to play with, and you will have used code from almost all the block groups in Scratch.

Start a new Scratch project. Delete the cat sprite and add a single star sprite from Scratch's sprite library.

Mostly you can build up the script code by looking at the picture below and just matching the color of each block with the block groups in scratch. For instance, the blue blocks are in the "Motion" groups.

However, there are two special block groups that are used in this program that require a bit of extra explanation:

The red blocks come from the "Data" group. This section is about creating variables to keep track of things in your Scratch program. This program uses two variables, one called "fall velocity" and one called "move velocity".

To create these variables, you go to the Data group and click "Make a Variable". Fill out the box as in the picture below. It's important to select "For this sprite only." You can learn about why in the more advanced projects on this page.



Make both the "fall veclocity" and "move velocity" variables in this way.

The other special block is the "MakeClones" block, which you make using the purple More Blocks group.

Click the "Make a Block" button. Enter the name MakeClones.

Make sure to check the "Run without screen refresh" box. As you will learn later, this box is used to make a purple block run very quickly. We want this for our fireworks program so the burst of clones will happen quickly.

Here is the rest of the code for the star script. Use color matching to make your screen look like this picture. Remember the goal here is not for you to understand all the code at this point, but just to get familiar with where all the code blocks are in Scratch.

You might want to look at the tip at the bottom of this page about using control-tab to swtich between browser tabs. This will let you quickly switch back and forth between these instructions and your Scratch code.

Once you have the code working, here are some things you can try and think about:

• Look at the Make Clones function. Notice how it makes 60 clones and turns 6 degrees between each clone, for a total of 360 degrees. What if you wanted fewer "streaks" in your fireworks. Can you make it have 45 clones instead of 60? Can you make a "baby" firework that only has 4 clones?
• Look at the lines that set "fall velocity" to 0 and "move velocity" to 3. Play with different starting values of these variables to see what happens. Can you describe what these variables do?
• Look a lower in the code where we change "fall velocity" and "move velocity" by -0.04. Try different values for these change blocks. Can you describe what these change blocks are accomplishing? In particular, what real-world phenomenon does changing "fall velocity" correspond to? (Hint: it's why the apple allegedly hit Isaac Newton on the head.)

BIG SECRET: You can either create this project from scratch using the guides below, or you can just play the game to practice your XY coordinates by clicking on the period at the end of this sentence.

The varialbes and the "Stage" script:

The Beetle script:

The Mouse script (very much like the Beetle -- use the copy tools to make it easy):

The Ghoul script:

The Gift script (very much like the Ghoul -- use the copy tools to make it easy):

Ask for help if you need it.

Follow this link and remix the project: https://scratch.mit.edu/projects/182736114/#editor

BIG SECRET: Ask a mentor about using Alt-tab (or command-tab) to switch quickly between screens.

The "Stage" script:

The "lightning" script:

The "message" script:

The "bat" script:

Ask for help if you need it.

Follow this link and remix the project: https://scratch.mit.edu/projects/126981912/#editor

BIG SECRET: Ask a mentor about using Alt-tab (or command-tab) to switch quickly between screens.

The "cow" script:

The "zombie" script:

Project ideas:

• Use the Stage to make a cool background.
• Try different cow speeds.
• Try different zombie speeds and frequenies.
• Make a different type of zombie that the cow has to avoid.

Ask for help if you need it.

Go to Scratch and click "Create" to start a project.

Set up scripts for the cat sprite (Sprite1) as shown in the picture. Use the Set Size block to set the cat's size to 25%. When the script is done, click the green flag to watch the cat follow the mouse and trace a line.

Add the beetle sprite and set up its script as shown in the picture. When the script is done, click the green flag to watch the beetle "mirrow" the cat's position in the Y axis.

Add the mouse and dragon sprites. The mouse's script is like the Beetle's, but mirror's the cat's position in the X axis. The dragon's script is like the Beetle's, but mirrors the cat in both the X axis and the Y axis.

Follow this link and remix the project: https://scratch.mit.edu/projects/129252513/#editor

BIG SECRET: Ask a mentor about using Alt-tab (or command-tab) to switch quickly between screens.

The "turkey" script:

The "objects" script:

Project ideas:

• Use the Stage to make a cool background.
• Make it so you get points for hitting Homer or Ned (and they disappear).
• Make it so you die when you hit the knife or the arrow.
• Make "dead" costumes for Homer and Ned for when they get killed.
• Make a "dead" costume for the turkey for when it gets killed.

Ask for help if you need it.

Open this document: FelineFighters.pdf

Go to Scratch and click "Create" to start a project.

Create four sprites as in the document, two cats and two apples. Create the scipts for each sprite by copying what is shown in the document.

Ask for help if you need it.

Go to Scratch and click "Create" to start a project.

Name the cat sprite "Manual". Use four "when ___ key pressed" event blocks to make it so that when you use the left, right, up, and down arrows the cat moves 10 steps in the direction you've indicated. Use the "change x by" and "change y by" blocks to make the cat move.

Add another sprite (whatever character you want) and name it "Automatic". Make it so that when the green flag is clicked the sprite positions itself in the lower-left corner of the screen (use a "goto x y" block). It then glides (use a "glide" block) to the lower-right corner of the screen, then to the upper-right corner of the screen, then to the upper-left corner of the screen, then back to the lower-left corner of the screen. You will use four "glide" blocks. Once you have it working, put the four "glide" blocks in a "forever" loop so the sprite will keep moving around the border of the screen forever.

Add another sprite (whatever character you want) and name it "Random". Make it so that when the green flag is clicked the sprite glides to a random location on the screen, then glides to another random location on the screen, and so on, forever. Use a "glide" block with two "random" blocks, one for picking the x and one for picking the y. Make it so it's also random how long each glide is, anywhere from 1 to 5 seconds.

Follow this link and remix the project: https://scratch.mit.edu/projects/93401759/#editor

This project has several sprites, but we'll just use the "stairs" for now.

Make a stick figure sprite.

Make the stick figure walk up the stairs forever. Use a "forever" loop with four "glide" blocks.

Make another stick figure walk down the stairs forever.

Make the stick figure say "hi" to each other when they pass on the stairs.

Add costumes to make the stick figures look like they are walking.

Follow this link and remix the project: https://scratch.mit.edu/projects/64847448/#editor

rest
M P B
ah (hot) ay (height)
ee (heat) a (hat) i (hit)
S, N, D, K G, CH
R, Oh, W
Th, L
F, V

• 100-bpm-Line-A-7.mp3
• amazing.mp3
• are_you_ready.mp3
• be_careful_how_you_use_it.mp3
• cheesy_song_intro.mp3
• cooking_with_evil_gas.mp3
• da-da-da-empire-theme.mp3
• declan-yeah-tuff-im-a-gangster.mp3
• do-ya-think-youre-funny.mp3
• dreaming-of-a-white-christmas.mp3
• felix-the-cat.mp3
• fox_in_socks.mp3
• freaky_squeaky.mp3
• get_up_and_dance.mp3
• greatest_moment.mp3
• hahahahaha.mp3
• here-to-listen-learn.mp3
• here-to-teach-you-how-to-work.mp3
• im_a_star.mp3
• its_the_new_style.mp3
• i-wish-i-had-a-fun-record.mp3
• let_me_clear_my_throat.mp3
• Level1.mp3
• listen-again-and-again.mp3
• never_return_prev_character.mp3
• place_hand_on_keyboard.mp3
• please-check-yr-email.mp3
• something-wrong-with-this-program.mp3
• subway-please-stand-clear.mp3
• subway-the-doors-are-closing.mp3
• sultry_weather_report.mp3
• the-human-psyche.mp3
• the-power-new-generation.mp3
• this-is-fun.mp3
• transfer_complete.mp3
• we-need-expert-in-computers.mp3
• what_time_is_it.mp3
• whatyoutalkinbout.mp3
• yodel.mp3
• you_are_my_fantasy.mp3
• you_wanna_dance.mp3
• you-cant-handle-truth.mp3

Challenge: Use a list (or two lists) to avoid having to use a code block for each mouth position.

Follow this link and remix the project: https://scratch.mit.edu/projects/24621469/#editor

Add a "when ___ key pressed" block to the "thermometer" sprite to make it so that when you press the up arrow the "temperature" variable increases by 2. In addition to using a "change" block, you'll need to broadcast a "show temperature" message.

Add a "when ___ key pressed" block to the "thermometer" sprite to make it so that when you press the up arrow the "temperature" variable increases by 2.

In the "penguin" sprite, make a few more costumes for the penguin, showing the penguin at different temperatures. Make one for when it's cold, one for when it's very cold, one for when it's normal, one for when it's hot, and one for when it's very hot.

Change the "penguin" code so that it shows your different costumes depending on the temperature. That is, if the temperature is average, show the plain penguin. If the temperature is cold (perhaps less than 45 degrees) show the penguin with its "cold" costume (maybe a sweater). If the temperature is very code (perhaps less than 30 degrees) show the penguin with its "very cold" costume (maybe a heavy jacket and snow boots). If the temperature is very hot (perhaps over 100), show the penguin with its "very hot" costume (maybe the swim suit). It's up to you how many costumes you want (how many temperature levels) and what they are.

Bonus: make the penguin say something appropriate for the weather whenever the temperature changes.

In this project you use a simple arrow and box to make lots of interesting patterns, including some 3D-style patterns similar to Minecraft.

Open this project and remix it: https://scratch.mit.edu/projects/78798510/#editor

Open this document: ArrowsAndBoxes.pdf

In the cat's script, enter the two functions at the top of the document. Use the "arrow" function to draw as many of the patterns as you can shown in the first part of the document (the images made of blue lines). To draw the ones where the arrow grows and shinks you'll need to use a variable to keep track of the arrow size.

Now use the "box" sprite's script to draw the box images you see in the second half of the document. Do this by using the "stamp" command to draw the box on the screen.

One type of Scratch program is a "movie", which is just a long sequence of animations that tell a story. The image above shows all the blocks you need to make a movie. This project will help you get familiar with the "broadcast" and "broadcast and wait" blocks.

In this project you will use the Stage as the "director" of the movie. That is, the Stage is where you'll write most of the scripts. However, in Scratch, a script cannot control another sprite directly. To get the Stage script to control the other sprites, you'll need to use "broadcast" and "broadcast and wait". The difference between these two is that "broadcast and wait" waits for the recieving sprite to finish its "when I recieve" block before continuing on, while "broadcast" does not wait.

Think of a story you want to tell that involves a main character and one or two secondary characters. If you already know the story you want to tell, great. If not, here is a special challenge. Try to think of a story where the characters will say each of the following lines somewhere in the story (not necessarily in the order they are listed below). The challenge is to make a story where it more or less makes sense for each of these lines to be said.

• Apparently I can breathe under water.
• I'm free!
• I thought I'd never reach the top!
• That's so beautiful it makes me want to cry!
• Ouch!
• Why is everything upside down?
• Get out of my way!
• Get me out of here!
• That was more slippery than it looked!
• Hey, who turned out the lights?
• Suddenly I seem to have the ability to fly!

Or make a mini-movie that shows a joke. Here are some joke ideas:

• What's brown and sticky? ...... A stick! remix project
• What does a snail say when it's riding on a turtle's back? ...... Weeeee!!
• Why did the chicken cross the playground? ...... To get to the other slide!
• Why did the spider cross the road? ...... To get to his web site!
• What did zero say to eight? ...... Nice belt!
• Where did the king keep his armies? ...... In his sleevies!
• How do you make a tissue dance? ...... Put a little boogie in it!
• Why was 6 afraid of 7? ...... Because 7 8 9!
• Two muffins are in an oven. 1st muffin: Do you think it's getting hot in here? ...... 2nd muffin: Ahh! A talking muffin!
• How did Cookie Monster feel after eating a whole box of cookies in bed? ...... Pretty crummy!
• What has 4 wheels and flies? ...... A garbage truck!
• What do you call a bear with no teeth? ...... A gummy bear!
• How do you catch a squirrel? ...... Climb up a tree and act like a nut!

Remember, the Stage is the "director" of the movie, so the main scripting happens in the Stage. Think of your story as a sequence of scenes. The first scene is called "intro". Make a new block called "intro" (as in the picture) and call this block from the "when flag clicked" block (as in the picture). Add code to the "intro" block. Set the backdrop to your starting backdrop. Show your main character. Use "say" and "wait" and "glide" commands to have your main character. Since the Stage cannot make your main character sprite do things directly, it needs to broadcast messages to the sprite. For instance, the Stage might broadcast a message like "do intro" to the main character sprite. When the main character sprite receives this message it might show itself, say something, glide somewhere on the screen, say something else, and so on.

Keep adding to your "intro" script until your intro scene is complete. Perhaps the intro scene involves your main character and another character having a short conversation. When the "intro" scene is done, add another scene (maybe the scene is called "at the beach" if your story has a beach) by adding another purple block and calling this block in your "when flag clicked" block. In this way, keep adding actions to your scenes and more scenes until your story is done.

This project is similar to the Movie Story, but is a very specific sequence from a famous cartoon. If you haven't done the Movie Story project yet, at least look at the picture shown with that project, since it shows the blocks you need for this project also.

Click this link and remix the project: https://scratch.mit.edu/projects/45791408/#editor

Using the sprites in the project, make the following movie sequence:

• In the intro screen, Lucy shows Charlie Brown the football and says, "I'll hold the football and you kick it."
• Charlie brown says, "You always pull the football away right before I kick it."
• Lucy says, "Trust me, this time I promise to hold it."
• Charlie Brown says, "Hmmm, well, okay."
• Then we jump to a scene using background2 showing Charlie Brown standing there alone on the right side of the screen.
• After a few seconds, Charlie Brown runs to the left side of the screen. You can make him run by switching back and forth between the "run1" and "run2" costumes as he moves to the left.
• When Charlie Brown reaches the left side of the screen the scene quickly flips back to background1 and we see Charlie Brown enter from the left side of the screen. Lucy is there holding the ball.
• Charlie Brown keeps running and just before he reaches Lucy she pulls back the ball.
• Charlie Brown starts flying through the air and flies off the screen to the left.
• The scene quickly flips back to background2 and we see Charlie Brown fly in from the left.
• Charlie Brown flies up in the air and flips over two times while screaming.
• Charlie Brown lands on his back. As an extra challenge, use the "dust" sprite to make a dust cloud as Charlie Brown lands. By changing the size and "ghost effect" of the dust cloud you can make it look like it's growing and fading.
• Finally, Lucy appears next to Charlie Brown and says, "Ha ha! Tricked you again, Charlie Brown!"

Open this document and follow the instructions: CrazyCatClaws.pdf

Ask for help as you need it.

Go to Scratch and click "Create" to start a project.

Make a quiz game that asks you several questions in a row. The questions can be about math, movies, geography, or anything you want to ask.

Use an ask block to make the cat ask a question. Then use an "if" statement, the "answer" block, and an "=" block to check if they got the right answer. If so, make the cat say "Correct!". If not, make the cat say "Nope. The right answer is ___." (put the answer where the blank line is)

Once you have your first question working, add several more questions.

Make it so that at least one of your questions allows two different correct answers. For instance, if one of your questions was "What is 2 + 3?", you could allow the user to answer either "5" or "five". Use an "or" block to allow both answers.

Add a variable called "score" that keeps track of how many questions you got right. Start the score at 0 and increase it by 1 each time the user answers a question correctly.

Challenge: At the end of the quiz, tell the use how many questions they got right, and also show a percent. For instance, if you asked them 8 questions and they got 6 right, the cat would say "You answered 4 out of 8 questions correctly. That's 75%." You can construct this sentence using several "join" blocks. You can compute the percentage by dividing the number correct by the number of questions and then multiplying by 100.

Big Challenge: You probably noticed that you repeated a lot of code asking all those questions. In fact, the code for each question was basically the same, and the only thing that changed was the text of the question and the correct answer. We can make the program much shorter by putting all of the questions in a list, and all of the answers in another list.

• Make a list called "questions", and enter the text of each question as an item in the list.
• make a list called "answers" and put the answer to each question as an item in the list, in the same order as your "questions" list. (For this challenge, don't worry about allowing two answers for your questions, we'll just stick with one answer for now.)
• Make a variable called "question number" and start it at 1.
• Use a repeat loop to ask each question in the list. Use an "item" to access the items of the "questions" and "answers" lists.

Go to Scratch and click "Create" to start a project.

Shrink the cat down to a small size so it's easy for you to see the pen trail.

Write a function (purple block) called "Square" that draws a square with sides of size 40. Use a "repeat 4" loop. To test your function, drag the cat to different places on the screen and then click the "Square" function.

Write a function called "Triangle" that draws a triangle with sides of size 40. As for help if you can't figure out the angle to use.

Write a function called "House" that draws a house by calling the Square function and then calling the Triangle function. You may have to move the sprite a bit between the two function calls. Alternatively, you should be about to modify Square or Triangle a bit to make it that House can simply call Square and then call Triangle.

Write a function called RowOfHouses that draws 5 houses in a row, with a bit of space between each house.

Bonus: Modify all of the functions you've written (Square, Triangle, House, RowOfHouses) to make a number input called "size", and to use the size as the side length of the shapes, instead of the fixed value 40 that we used above. Start with the Square function. Once it has the size input, you should be able to draw squares of any size. (Try it out!) Then add the "size" input to Triangle also. Similarly, add the "size" input to House and RowOfHouses. Note that House and RowOfHouses "pass on" the input value to the functions they call. If this input stuff is confusing, don't worry, it's a bit tricky. But it's also important. Talk with a mentor or another student to ask questions about inputs.

Bonus: Write a loop to fill the screen with houses of random sizes in random locations.

Bonus: Make a variable called "current size" and use it to write a function called ShrinkingRow. Make ShrinkingRow draw a row of 10 houses where each house is a bit smaller than the one before it.

Go to Scratch and click "Create" to start a project.

Add a "catcher" sprite that you can either draw or find an appropriate sprite from the library. The catcher is some kind of bowl or something else that could catch apples.

The code for the "catcher" sprite positions the sprite at the bottom of the screen, and lets you move it back and forth across the bottom of the screen using the left and right arrows. You can use brown "when ___ key pressed" blocks for this, or for smoother motion you can use blue "key ___ pressed?" blocks inside of "if" statements.

Add an "apple" sprite. When the flag is clicked, do a "forever" loop that starts the apple in a random position at the top of the screen, and then has the apple move down the screen until it touches the catcher or reaches the bottom. You can modify the speed at which the apple falls to make the game as challenging as you want.

Make a variable called "score". If the apple touches the catcher, increase the score. If the apple hits the bottom of the screen without touching the catcher, decrease the score.

Use cloning to make it so lots of apples are falling at once. Make one apple clone per second. When an apple touches the catcher or the bottom of the screen, delete the clone.

Make a program to draw pictures like the one above. Pick a point on the screen, and then use the pen to draw a line from that point to each point along the top of the screen, stepping by some amount. For instance, if the point you picked was x = 40, y = 25 and you were stepping by 5, you'd draw a line from 45, 25 to the point -240, 180 (top-left of the screen), then a line from 45, 25 to the point -235, 180, and so on until you had gone all the way across, ending with a line from 45, 25 to 240, 180 (top-right of of the screen). Then continue the process for the right side of the screen, the bottom of the screen, and the left side of the screen.

Pick a random x, y for the starting location. You can also pick a random stepping distance (perhaps from 2 to 10 pixels) and a random color. Make the cycle repeat over and over.

You'll need to use variables to keep track of the starting x, y location, the stepping distance, and the progress along each side.

Write a program where the cat plays a number guessing game with you. The cat thinks of a number between 1 and 1000. In a "repeat until" loop, the cat asks you to guess a number, and tells you whether your guess is too high or too low. If your guess is correct, the cat tells you that you are right, exits the loop, and tells you how many guesses it took you. You will need at least two variables for this: one to hold the secret number, and one to keep track of the number of guesses.

Now use a second sprite to play the same game, but where you pick the number and the computer does the guessing. Here is a plan: Use two variables to keep track of the range of possible numbers. At the start, these variables are 1 and 1000. Each time through the loop, guess the number that is half way between these values. So let's say the number you pick in your head is 123. Here is how the game would go:

• The first time through the loop, the computer guesses 500.
• You respond by saying "high". Now the computer knows the number is between 1 and 499.
• It's next guess is 125.
• You respond by saying "high". Now it knows the number is between 1 and 124.
• It guesses 62.
• You respond by saying "low". Now it knows the number is between 63 and 124.

The game continues in this way until the computer guesses your number. Hint: You'll need to use the "floor" function to keep the computer from guessing decimal numbers. Why is this?

Make a game where you have to move from location to location and go on an adveture.

Start by making a map on piece of paper. For instance, here is a sample map with several locations and ways of going between locations.

You move among locations on the map by clicking parts of the screen. For instance, if you are at the Enchanted Forest and you click near the top of the screen, you go to the Castle. If you are at the Castle, and you click near the bottom of the screen, you go back to the Enchanted Forest.

There are two methods you could take to checking if the user clicked a certain place on the screen. Method 1 is to let the Stage script handle moving around. (This makes sense since the stage will also change its backdrop as you move from one location to another.) So you'd use the "when Stage clicked" block, and then, depending on what location the player is at and the x, y location of the click, you'd figure out where to move (or not to move, if they didn't click on meaningful area). Method 2 is to use sprites that the player has to click on. For instance, when you're at the Enchated Forest a sign shows up at the top of the screen that says "To the Castle" and when you click on that sprite. You will probably find that the screen-coordinate method works out better.

Once you have the it working so that you can navigate among all of the places on your map, it's time to make the "puzzles" of your adventure game. In adventure games, there are usually various items in the world that the player can find, pick up, and use. For instance, there might be a treasure chest at the "beach" location, but the player can't open it without the key, which is found in the dungeon of the castle. So the player has to go to the dungeon, pick up the key, go to the beach, and then open the chest.

Here is one way you might handle the location of objects like the key and the treasure chest in your game.

• There is a variable called "player location" which stores the current location the player is at. This variable gets values like "beach" or "dungeon" or whatever the places are in your game.
• Each object is a sprite.
• For each object, there is a variable that stores its location. For instance, for the key object there is a variable called "key location" that stores the current location of the key. At the start of the game, you could set "key location" to "dungeon", meaning the key is in the dungeon. When the player picks up the key, "key location" changes to "inventory". (You can think of "inventory" as a special location meaning that the player is carrying the object.)
• Have each object receive a message called "show or hide". In "when I receive 'show or hide'" the object checks if it's location variable is the same as "player location" (the location that is currently being displayed). If so it shows itself. If not it hides itself.
• You can have a button on the screen that says "inventory", when you click this button you can go to a special "inventory" location, and simply by doing that, all the objects the player is carrying should show on the screen.

There are various ways you can handle interacting with the objects.

• A simple way is that when you click on something, it just does a default action. For instance, when you click on the key in the dungeon, it knows you want to pick it up, so it goes into your inventory. When you click on the treasure chest it knows you want to open it, so it either opens (if the key is in your inventory) or it says a message that it's locked so you can't open it. When you go to your inventory and click an item the default action can be to drop the item in your current location.
• The simple plan described above can get you pretty far, and you could make a whole adventure game using just that mechanism for interacting with objects.
• A fancier way of interacting with objects is to introduce the idea of "verbs".
• You could have several "verb" buttons on the screen, such as "take", "drop", "eat", "examine", "use on", and perhaps more.
• In this case, the way the player does things with objects is to first click a verb button and then click the object. For instance, to pick up the key they would click "take" and then it would ask them to click an object, and if they clicked the key it would put the key in the inventory. On the other hand, if they clicked "examine" and then clicked the key, they might see a message that says "It is a small gold skeleton key, the kind a pirate might use.
• The "use on verb would be a bit different, and would ask the player to click two objects, meaning to use the first object on the second. For instance, if the player clicked the key and then clicked the treature chest, the treasure chest would open. But if the player clicked the apple and then clicked the duck, it might say "The apple does nothing to the duck."

This classic game uses realistic physics. The goal is to flap the wings of a bat to help it avoid obstacles that poke up from the bottom of the screen and poke down from the top of the screen. The bat just moves up and down and is always positioned near the left side of the screen. The obstacles move from right to left giving the feeling that the world is "scolling by" as the bat flies through it.

You can simulate physics by thinking in terms of y velocity: each time through the main "forever" loop you move the bat up or down by its y velocity. You increase the y velocity by flapping the bat's wings, but also gravity is constantly operating, making the bat's y velocity more negative.

So in your main "forever" loop, you'll have the lines show in the picture below. The line on the left changes the bat's y position by its y velocity. The lines on the right change the y velocity by -0.4 to simulate gravity (you can try different values to make gravity stronger or weaker). Note that there is also a check to keep the y velocity from going too far negative. (Why is this check needed?)

Not shown in the picture above is the "if key ___ pressed" block you'll need to check if the playing is holding down the space bar. If so, you increase the y velocity by a certain amount. Again, you'll want an "if" block to make sure the y velocity doesn't get too large. (Again, why is this needed?)

For the black bars, make two sprites named "bar 1" and "bar 2". You can make it look like these sprites keep coming forever by sliding them across the screen and when they reach the left side start them sliding from right again.

Although it says in the rules of thumb to try not to use "if touching", you will probably find it convenient to use "if touching" to see if the bat is touching one of the obstacles. However, you can also do this by checking coordinates instead of using "if touching". You will find as you do more and more advanced Scratch projects that checking coordinates is almost always better than using "if touching".

Here are some additional challenges for this game:

• Keep score. Every time the bat passes an obstacle it gets a point.
• Make it so that each time the bat touches an obstacle it says "ouch" and you lose five points.
• Make it so the obstacles aren't all the same length. Some poke in farther than others.
• Make power pellets that scroll by like the obstacles scroll by. The bat can try to touch the power pellets for bonus points.
• Make an airplane fly across the middle of the screen once in a while. The bat has to avoid the airplane just like it avoids the line obstacles.

This is a classic arcade game and a good example of a game that uses realistic physics. The goal of the game is to land a space craft on a landing pad on the moon. The landing must be accurate and gentle -- the space craft is destroyed if you hit part of the moon that is not a landing pad, or if you land with too much downward velocity or when the ship is tipped at too much of an angle.

Draw the moon surface on the Stage's backdrop using one color for the terrain (brown in the picture above) and one color for the landing pads (pink in the picture above). Normally it's best to draw things in vector mode, but in this particular case it might be easier to stick with bitmap mode.

You can simulate physics by thinking in terms of velocity: each time through the main "forever" loop you move the ship by its velocity. You can change the velocity by using the ships thruster, and also gravity is constantly operating, making the ship's downward velocity more negative.

You can think of the velocity in terms of two variables -- "y velocity" and "x velocity". "y velocity" tells you how fast the ship is rising (if "y velocity" is positive) or falling (if "y velocity" is negative). "x velocity" tells you how fast the ship is moving to the right (if "x velocity" is positive) or to the left (if "x velocity" is negative). Gravity is constantly affect "y velocity".

So in your main "forever" loop, you'll have the three lines shown on the left side of the picture below. The first two lines move the ship at it's current x and y velocities, and the third line applies gravity to the y velocity. (You can play with other values that -0.04 to affect how strongly gravity pulls the ship downward.)

You'll want to use a some "if key ___ pressed" blocks to check if the player is holding down the left arrow, the right arrow, or the space bar. If the left or right arrow is pressed, the ship rotates. If the space bar is pressed, the ship thrusts. Remember that the thrusting does not "move" the ship directly, but rather affects the ship's x velocity and y velocity.

The two lines on the right side of the picture above show how you can change the two velocity values based on the angle the ship is facing. For instance, if the ship is facing straight upright, when you thrust all the "thrust power" increases the ship's y velocity upward, but does not affect the ship's side-to-side x velocity. However, when the ship is turned at a 45 degree angle to the right, half of the "thrust power" pushes the ship upward (increases the y velocity) and half of the "thrust power" pushes the ship to the right (increases the x velocity). At other angles (for instance, when the ship is turns just slightly to the right), different distributions of the "thrust power" between the y velocity and x velocity are needed. The way to figure out this distribution is to use the sin() and cos() functions as shown in the code above. Normally you don't learn about sine and cosine until you study trigonometry in about 10th grade. But you can look up sine and cosine on Wikipedia and/or talk to a mentor to understand how these two lines of code work.

In the "rules of thumb" above, it says to try not to use "if touching color". However, in this particular game, it is especially convenient to use "if touching color" to see if the ship is touching a landing pad (perhaps pink, as in the picture above), or the moon surface (brown in the picture above). In general, it is best to check coordinates instead of using "if touching" or "if touching color", but sometimes, as in this game, it just makes so much sense to use them that it's smart to break this "rule".

The picture above shows that when the ship is thrusting (when the player is holding down the space bar), some fire is seen coming out of the bottom of the ship. One problem with using "if touching color" is that if the fire is poking out of the bottom of the ship as it's landing, and if the fire is part of the ship's costume, the fire might be touching brown, and you'll think the ship as crashed, but really it should only crash if the main part of the ship is touching brown. One idea is to use "if color touching color", but unfortunately we have found that "if color touching color" doesn't always work because of a bug in Scratch. A way around this is to make the fire it's own sprite and to have the fire "follow" the ship and show itself when the player is thrusting.

If the ship touches the moon surface or doesn't land gently, make it crash. Remember that landing gently means not falling too fast or being at too much of an angle when you hit the landing pad.

Here are some additional challenges for this game:

• Start the ship with a certain amount of fuel. As the ship thrusts it uses up fuel. If you are out of fuel you can't thrust anymore.
• Make a "fuel refilling station" somewhere. If the ship touches the fuel refilling station it disappears and sets the ship's feul back up to the starting value.
• Make it so that you get more points for landing on a landing pad that is more difficult to reach. To do this, you'll have to do more than just check "is touching color" pink. You'll need to use coordinate comparisons to figure out which landing pad the player landed on.
• Make an alien ship fly around so that in addition to having to land you also have to avoid crashing into the alien.
• Make multiple levels. When you complete a level, go do the next level by changing the Stage's backdrop.

Open this guide document: qbert.pdf

Use this starter project (remix it): https://scratch.mit.edu/projects/168349535/#editor

Here is a project where the board is complete (remix it): https://scratch.mit.edu/projects/168349535/#editor

If you start with the starter project, follow the guide to make the board. To do this, edit the variables, then make the scripts for the "box" sprite. After you get the board working, try the challenges to make the board look different ways. This will help you understand the "Compute Coordinates" function.

If you start with the project where the board is complete, add code to make Q-Bert and the snake jump around. Ask for help to get started.

This game is no so different from the "Flappy Bat" project above, but has more going on. The player controls a rabbit that stays in the center of the screen, and the world scrolls by to make it look like the rabbit is running through the world.

When the rabbit is on the ground, it runs. (You can do this by having one costume with the legs together and one with the legs sticking out.) The player can make the rabbit jump by pressing the space bar. If you want, you can make allow the player to make a second jump when the rabbit is in the air. (This is not very realistic physically but a lot of games let you do a double jump like this.)

Several different kinds of objects scroll by: trees, bushes, grass, carrots, and poison onions. You can handle all of these different objects as one sprite with different costumes. The idea is to generate clones of the object using a random time delay. Once cloned, the object moves across the screen from the right side to the left, and when it reaches the left edge the clone is deleted. By starting the object's position a bit off the screen to the right you can make it scroll in from the right instead of just "popping" in.

Nothing happens when the rabbit touches a tree, a bush, or some grass. When it touches a carrot the carrot is deleted and the player gets a point. When it touches a poison onion the game is over.

Here are some challenge ideas:

• Make it so the number of jumps is limited. You need to get carrots to earn more jumps.
• Make other dangers besides just the onions.
• Make it so the rabbit can shoot a missile as a way to knock out the onions and other threats, both as a defense mechanism and a way to get more points. When a missile hits an onion, a nice effect is to make the onion fall to the ground instead of just disappearing.
• Harder: Make it so the terrain goes up and down. The picture below shows two ways you might do this. On the left, the terrain "jumps" up and down suddenly. On the right is a version where the terrain rises and falls smoothly -- this is much harder; talk with a mentor if you want help thinking about how you would do this.

Create a list of words to choose from. Alternatively, you can make it so that one player types in the secret word while the other player looks away.

Use a variable to keep track of the number of guesses the player has made. Depending on the number of guesses, draw the "hangperson" in different states of completness.

To keep track of what letters the player has guessed, use a list. When displaying the secret word, any letter that is in the list is displayed, and any letter that is not in the list is shown as a blank.

Make a game that's a bit like the Apple Catcher game (see the Beginner section) except instead of Apples, random letters are dropping from the top of the screen.

You can "blast" these letters by typing them on the keyboard. When a letter is blasted, it disappears. Bonus: You can also make a nice little "blast" animation showing the letter get destroyed.

The player gets a point for each letter blasted. If a letter reaches the bottom of the screen without being blasted the player loses a point. If the player types a letter that is not currently on the screen, a "buzzer" sound plays and the player loses a point.

Some hints on how to make this program:

• Make a single sprite that has all the letters of the alphabet (use one of the letter sets from Scratch's sprite library).
• As in the Apple Catcher game, use cloning to generate each falling letter.
• Unfortunately, the simplest way to check for each letter being pressed is to use a "when ___ key pressed" block for each of the 26 letters. That's a lot of blocks, but at least be sure to only use one line in each of these blocks to keep the code as short as possible. This one line of code calls a function with a number representing the letter: A is 1, B is 2, etc.
• Advanced Bonus: See this program for an idea on how to check for any key being pressed without using 26 "when ___ key pressed" blocks: https://scratch.mit.edu/projects/10750787/#editor
• It's actuallly not so easy to check that a letter pressed does not match any of the letters on the screen. One way to make this work is to use a list to keep track of which letters are on the screen. You can use a list that has 26 items, and each item is the number of the given letter on the screen.
• Advaned Bonus: If there is more than one of the same letter on the screen, the easiest thing is to have all of them blast when the letter is pressed. As an advanced challenge, try to make it so that only one of them blasts for each key press.

Look up "15 puzzle" on Wikipedia if you need to be reminded of how this game works.

One way to keep track of the state of the board is with a list. You can use a list of 16 elements. The first four elements are the first row of the board. The next four elements are the second row of the board, and so on. Each element holds either a number from 1 to 15, or the number 0, which represents the "blank" tile.

When the player presses one of the four direction arrows, slide the tile if they can move in the given direction. For instance, if the game state is like in the picture above with the "blank" block in the lower-right corner of the board, the only choices for a move are right-arrow or down-arrow. From the point of view of the player, right-arrow means to move the 15 tile to the right and down-arrow means to move the 12 tile down. From the point of view of the code, you can think of things in terms of moving the "blank" tile in the opposite direction: for instance right-arrow means you want to move the "blank" tile to the left (and move the tile it's replacing to the right), and down-arrow means you want to move the "blank" tile up (and move the tile it's replacing down).

At the start of the game, you need to "shuffle" the board. If you think about it and read about it, you'll realize that not all arrangements of tiles are "solvable". So if you just place the tiles 0 through 15 on the board, it might not be a solvable configuration. One way to get around this is to do the shuffling by starting with a solved board (as in the image above), and then making a large number random tile slide moves on the board to mix it up.

This game is kind of like Lunar Lander, but there is no gravity. Instead, the ship's velocity only changes when you thrust. When you thrust, the sin() and cos() functions are used as shown below.

The interesting part of this game is that the ship is always in the middle of the screen and the rest of the galaxy moves around it. There are two kinds of things in the galaxy besides the ship, stars and planets.

There are two key variables: "ship x" and "ship y". As the ship moves, "ship x" and "ship y" change, but instead of moving the ship to a different part of the screen, the stars and planets move in the opposite direction of the ship. For instance, if "ship x" increases by 10 (meaning the ship is moving to the right), all of the stars and the planets move 10 pixels to the left.

The stars are very important because there are always a lot of them on the screen, and they give an idea of the speed and direction of the ship. Here is a plan for handling the stars:

• Make variables called "star x" and "star y". When making these variables, it's important to check the "for this sprite only" box. This is because, in Scratch, "for this sprite only" means that each clone of the sprite gets its own copies of these variables.
• Clone 50 stars at the start of the program. These 50 stars last for the whole program. Before making each clone, set "star x" and "star y" to random screen coordinates. Again, remember that because these variables are "for this sprite only", each clone will get it's own copies of these variables.
• In the clone's "forever" loop, use the following line:
• Think about what that code line does. It positions the star at "star x"/"star y" (those are the random screen coordinates chosen when the star clone was made) but subtracts from that position "ship x"/"ship y" (the location the ship has moved to). As dicussed above, by subtracting the ship's position from the positions of the stars and planets, we make it look like the ship is moving in the given direction.
• The rest of the code in the star clone's "forever" loop is about keeping the stars on the screen by "recycling" them. That is, when a star goes off the screen, it can pop back on the other side of the screen. For instance, if the ship's position has changed such that the star has gone off the left side of the screen, we can change "star x" by adding 480 (the width of the screen), to make it come back in the right side of the screen as if it's a new star (but really it's same sprite clone being "recycled" as a new star). In this way, we can make it feel like there's an infinite universe of stars when really there are only 50 clones.

The planets are like the stars, but a bit simpler because they don't "recycle". You can make a single sprite called "planet" which has two or three different costumes (a red planet, a blue planet, maybe a green planet).

• Again, make two variables "for this sprite only" called "planet x" and "planet y".
• When the game starts, generate a few planet clones. Before creating each clone, set the "planet x" and "planet y" variables to where you want the planet to be in the galaxy. These starting locations might be big numbers that put the planents off screen so the ship has to move to them to see them.
• In the clone's "forever" loop, use the same code shown above for the stars to position the planets taking into account "planet x" and "planet y" (where the planet is in the universe) and "ship x" / "ship y" (where the ship is in the universe).
• The planets don't "recycle" the way the stars do when they go off the screen. However, Scratch keeps all sprites at least partly visible on the screen. That is, even if you set a sprites x,y position to 10000,10000 Scratch will still show the sprite on the side of the screen. (Scratch does this because they think it might be confusing if your sprites go off the screen.) To counter this "feature" of Scratch, you'll need to show or hide the planet sprite based on whether it should be visible on the screen. That is, if the planet is in a position that makes it at least partly shown on the screen, show it. But if the planet's position is off the screen, you need to hide it.

Here are some additional ideas for this game:

• The goal of the game could be that you have to find and visit all the planets. Show a display on the screen indicating which planets you've visited.
• Create an alien ship that flies around randomly, but that tries to stay near to where the player's ship is. You can make the alien ship hostile. You could in fact make the ships shoot at each other. Alternatively, you could make the ships more like space fruit, and the goal of the game is to chase them all down and collect them all.
• One problem is that the game allows the player to fly off as far as they want in any direction. This can make it very easy to "get lost" in the universe. Try to think of some way to help the player with this. You might create a kind of "boundary" to the universe to keep the player from going too far off. Another idea is to notice when the player is far away from where the planets are and to show an arrow on the screen to guide the player back.

Write a program where the computer plays tic-tac-toe against you.

Start by making a program where the computer let's two people play tic-tac-toe against each other.

• It shows a board and says whose turn it is (X or O).
• The player clicks in a space on the board and the right shape (X or O) is shown in that space.
• Then it's the other player's turn.
• When one player makes three in a row, the computer says that player wins.
• If the board fills without either player winning, the computer says it's a tie.

Here are some some hints for how you might get this working:

• Use a list to store what's on the board. The list has 9 items. You'll need little formula to pick the right item for a given x, y grid space on your board.
• Draw the Xs and Os by clearing the pen drawing and then using "stamp" to draw the Xs and Os.
• Write a function to check if there are three in a row in a given direction.

Now make a version where the computer plays against you. Start by making a list of "rules" that explain how you play tic-tac-toe. For instance, one rule you probably use is that, if you can win by making a play, you make that play. Another rule is that if your opponent can win on the next turn, you make a play to block that. List some of the other rules you play by, and when you think you have a complete description try writing it as a program.

Look at the Wikipedia page for Conway's Game of Life.

Make a Scratch program to play this game. Here is a plan:

• Use a list to keep track of the board state, where each list is string, and the letters of the string indicate whether a cell is alive or dead. For instance, if your board is 20x20, you'd have a list of 20 items representing the 20 rows of the board. Each item is a string of 20 letters. For instance, the first item might be "01000000000000000011". This means that on the first row all of the cells are dead except the second cell and the last two cells.
• You'll actually want to have two of these lists, one for the current state of the board, and one for the state of the board at the next generation. To compute the next generation, set the next generation board to all 0s, and then walk through the current generation board, apply the rules of the game, and set the surviving cells on the next generation board. When you are done, copy the rows of the next generation board to the current generation board.
• Draw the current generation board on the screen by clearing the drawing and using "stamp" to draw the live cells.
• To make the program run quickly enough, you'll definitely want to use a "run without screen refresh" function to do the board computation and the drawing.

Make a Pac-Man game.

Use a list to represent the board. Each item in the list is a "row" of the board. Each item is a string representing a "cell" in that row. (You have to think of the board as a grid with "wall" spaces and "blank" spaces.)

Use a list to represent the board. Each item in the list is a "row" of the board. Each item is a string representing a "cell" in that row. (Think of the board as a grid with "wall" spaces and "blank" spaces.) You can use "stamp" to draw the board on the screen from the data in the list.

The players and ghosts move within the "blank" spaces of the board. It's important to decide exactly how you want to think of the player and ghost movement. Suppose the player (or a ghost) is "on" a particular blank cell of the grid, and then decides to move to an adjacent blank cell. You could use a "glide" block for the motion, but that means that once a player (or ghost) decides to move from one cell to another, there is no way changing direction until it has fully "arrived" at the destination cell. Another way of thinking about things is that the player (or ghost) moves one pixel at a time (or maybe two pixels at a time, if one is too slow), and can change direction at any point. Talk this decision over with a mentor.

The best way to learn to program is by working on lots and lots of programming projects.

Start with very simple things. Get the cat to move across the screen and say hello to you. Look at projects other people have made. Don't just play other people's Scratch games. Think about how you could write a program to play the same games, or at least to do little parts of what their games do.

Work on projects that you want to work on. Programming is about making things that you want to make.

Try lots of things and ask lots of questions when you get stuck. Professional programmers ask each other questions all day long. (If you want to see a site where millions of professional programming questions have been asked and answered, visit https://stackoverflow.com.)

When you are working on a project from this page, you often want to switch back and forth quickly between the instructions (this page) and another browser tab where you programming the project in Scratch.

Set up your browser like in the picture below, where you have this page in one tab, and Scratch in the other tab.



Then hold down the Ctrl (control) key with your left thumb, and then tap the Tab key with your left pointer finger. This switches quickly from one tab to the next. This takes a bit of practice but once you get good at it you'll be happy you did, because you'll be able to switch back and forth between instructions and project really quickly.

Coming soon...

Coming soon...

Coming soon...

Coming soon...

Coming soon...

Coming soon...

Coming soon...

Coming soon...

Coming soon...

We meet once a week on Sunday afternoon from 2:10 pm until 4 pm. Most of the students are from 7 years old to 15 years old, but we do get some younger and some older. We generally have about 20 students in the class, and most students sit with one or both parents. Having the parents there is helpful so that the lesson can go at a fairly fast pace, and parents can later explain to their kids anything the kids might have missed. The lesson itself is aimed mostly at the students but sometimes more at the parents.

We don't assume any Scratch knowledge. Each class day stands alone so students can come to any class without worrying about where the class is in a sequence. Once in a while we will do a project that spans two class days, but even then we start the second day without assuming any particular knowledge.

We use a screen projector so everybody can see what's on the teacher's computer. We use Scratch's magnify feature to make the Script tab easily visible to everyone.

We try to encourage kids to use the vector drawing tools unless they specifically want a bitmap image. The vector drawing tools make it much easier to change things.

1. Before class I put up a sprite saying "Welcome to Scratch. Class starts at 2:10 pm. All questions will be answered then."
2. When class starts, everybody (every single person in the whole room) closes their computers so they can look at the screen and listen to the lesson.
3. (20 to 25 minutes) The teacher introduces Scratch and shows a demonstration project. I used to stop and ask questions as I went along during the demonstration to keep things interactive and make students think. However, I started doing that less and less because I found the same already-expert kids were the ones always answering questions, and even when I made an effort to call only on less experienced kids, it didn't seem overall to help beginners understand things better, and I think just made them insecure that they didn't know the answers that other kids seemed to know.
   • Briefly introduce the sprite concept and show how instruction blocks can be moved into the script area and clicked to make the sprite do things. Give a general sense of the categories of instruction blocks.
   • Shows a demonstration project.
     • The ideal demonstration project ends with one screenful of code that students can copy verbatim during work time. I have gone back and forth on the value of having kids copy code without fully understanding it, but I've come to believe that it's a valuable way for beginners to get familiar with the blocks and mechanics, and the exercise of making sure code is copied verbatim is itself a valuable exericse in being detail oriented. It's important for the instructor to complete the code ahead of class to make sure it ends up about the right length. Sometimes I start with most of the code alrady on the screen and just break it apart to show how it works. Sometimes I start with an empty screen and build up all the code.
     • There are a few "greatest hits" that work well for intro projects. I used to feel that it was important not to repeat intro projects in a given year, but now I think it's fine to reuse the greatest hits more frequently. Some of the winners are:
       • The car racing game. https://scratch.mit.edu/projects/187416271/#editor This is a favorites because you can make a compelling game with very little code. Also, creating the board is a good introduction to the vector drawing tools.
       • The "Maze" project from the Beginner section. This is a counterpart to the car racing game in that it is a similar game but uses XY movevent instead of "Move" block movement. One tip here is not to let kids spend too much time drawing the maze. Tell them to make a very simple maze with just a few lines in order to get the code working, and they can make the maze better later at home.
       • The Lundar Lander game. https://scratch.mit.edu/projects/174900014/#editor This is good because you can make a fancy game with very little code. It does involve the use of a variable and the concept of velocity. Still, it tends to work well for all ability levels as long as the code is clearly visible.
       I've decided to make a section before the "Beginner" section that just says "Racing Games". It will have the car game and lots of variations, including the maze game. I think it's probably fine to always one of these projects as the demonstration project, unless an instructor is inspired to do something else. These projects use short code that's mostly all on one sprite. They involve moving a thing around on the screen using the keyboard, which applies to many/most of the games kids like to make.
4. Ask if anybody has any questions about the demonstration code/project. Explain that copying in the code from the demonstration is one option, but it's also okay to work on any project from the suggestions list and/or a project not on the list, such as a project a kid has already started at home or at school. Explain that after work time there is (usually) time for kids to show their projects.
5. Show how the ScratchCats.org site has lots of suggestions for different projects. I usually pop open the sections for a few different projects, such as the Maze and Adventure Game. Be careful to emphasize that the absolute beginners should probably either copy in the code from the demonstration project, or do one of the tutorials built into Scratch and explained at the top of this page.
6. Ask if anybody has any questions about the overall flow of the class.
7. Leave the code for the demonstration project on the screen.
8. Tell the kids that before work time they have to introduce themselves to three other kids in the class they don't know. Specifically they have to tell each other (1) Their name. (2) What grade they're in. (3) How much Scratch they know. I make a sprite "Say" these three things so students can refer to it on the screen. I encourage them, if they are a Scratch expert, to find beginners they might be able to help, and if they are beginners, to find experts who might be able to help them. A few kids are too shy for this exercise and I don't force people to do it if they really don't want to. But generally the parents help and it works out well.
9. Work time. It took a while to decide to let kids work on whatever they wanted during work time. The fear was that there would be so many different kinds of questions from kids working on so many different things at such a variety of skill levels that it would be too chaotic for the teacher and mentors to be able to handle it. But in practice it ends up working well. Most of the beginners work on the demonstration project or a built-in Scratch tutorial. With the other kids, it just tends to work out that we can answer their questions and keep them moving along. Of course, this depends on how many mentors we have. Generally there is at least one other mentor aside form the instructor. If there is not, I ask if any parents with Scratch knowledge can help other kids during work time. I also usually tell the super expert kids that they can be kid mentors (with a red name tag and everything).
10. Demo time. On most days we reserve the last 30 minutes for students to show a project that they've worked on that day, or perhaps have been working on at home. Teaching this part of the class is more energy intensive for the instructor and involves improvisation and thinking on your feet. Here is they way I usuall y do it:
    • I bring up a document in Notepad with a large font that everyone can see. This is used to keep a list of which kids will do presentations, in order.
    • I ask for the intial set of volunteers. Often there are only one or two initial volunteers. Sometimes there are several. I tell everyone that I'll sweep the room left to right and write down each kid's name in order. I tell them that after the first person does their demonstration, lots of other kids will want to volunteer, so I'll sweep the room again at that time and add the names to the list. Generally as time goes on more and more kids want to volunteer. Usually it works out, but sometimes there is not enough time to get to everyone and I tell the kids who didn't make it that they can be first next week.
    • We tell the kids that to present their projects they need to share it in Scratch. Sharing involves the parent having responded to the email when the kid registered to say it's okay for the kid to share. Occassionally we have kids who do not yet have sharing power when it comes to their turn, so we skip them and they can work with their parents on setting up the share and present when they get it figured out.
    • The reason kids need to share is that the way we do all the presentations on the instructor's machine. This saves a lot of time not having to plug each kid's computer into the projector. After the kid shares their project, I have them read the project number from the URL address bar at the top of their browser. The URL looks like https://scratch.mit.edu/projects/247994228/#editor, so they read me that number 247994228 and I type it into my address bar. This only takes a few seconds and is the fastest way I've found to show one kid project after another.
    • The kid comes up to present their project. A few of the kids become too shy to come up, and I say I can just present it and they can stay standing by their seat instead of coming up to the front.
    • Except in the rare case where two players are needed to demonstrate the project, or when a project is so complicated I just can't figure out the controls, the kid stands by the screen and I do the controlling of the computer. "You talk, I'll click." I give the kid a chance to explain the project up front, and a few do, but most of them just want me to click the green flag to show what it does.
    • Some of the kids are natural presenters and talk loudly in front of the room. With many kids the tendency is for them just to talk quietly directly to me, so I have to repeatedly point to the room and tell them to talk loudly to everyone instead of just to me.
    • It is a bit of an art form deciding what to focus on with each kid. Here are some variations:
      • Some kids have just done the demonstration project, usually with a small variation in art or some other small twist. Even if there is basically nothing different about the project than what was presented during the demonstration, you can always ask which part they found the most diffult, or you can focus on some detail of the code and have them (try to) explain what it does, as a way of reinforcing the lesson.
      • Some kids have the start of an original, creative project. If it's just the start, the trick is trying to get them to talk about what their plans are for it, how they will do the code, etc.
      • Some kids have a fully working game. These are usually very popular. Often they have made some parts extremely hard for the player, often even impossible. It is a good source of humor for everyone to mockingly give the kid a little grief for making the game so impossible.
      • Another variant is a complicated original game that is not quite fun. Like maybe there is a monster but it's extremely easy to avoid it. This can often lead to an interesting discussion for the room about what changes could make the game more interesting.
      • Often I will do some quick edits of the kid's game, either to fix things in the code or just to demonstrate something about Scratch. For instance, if there is an initialization function that draws the board slowly, you can show how to use "run without screen update" to make the function run quickly. Or sometimes kids will use message broadcasting in their programs but will have the messages just named "message1" and "message2". So I ask them if they can think of better message names based on the purpose of the message. This part requires improvisation, as I say. The main thing is to keep it all fairly snappy so the room doesn't get bored as you get bogged down in some particular code detail.
      • Related to this is what can sometimes happen if you ask kids to explain how their code works. I used to ask that a lot, but I soon realized that this is an extremely difficult task for most kids. Mostly they just start reading the code line by line, which makes sense since after all, that's what the code does, line by line. What I am always hoping for, of course, is for them to be able to summarize the key things about how the code works without getting bogged down in the details. But that's super hard for most kids. Which is fine. The lesson I've learned is that it's fine to talk about the code during a kid presentation, but it takes a lot of structuring from the instructor, and often boils down to the instructor asking the kid about one or two specific aspects of the code.
    • Regardless of whatever else has been said, we end each kid's presentation by asking (having the kid ask the room) if there are any questions or suggestions for the project. For a given project there may or may not be suggestions. I use this opportinity to make my own suggestions. This is especially important when nobody else in the room makes a suggestion. Sometimes this turns into a little discussion with kid brainstorming on what could be done.
    • To conclude each kid's presentation I say "Thank you Sally for showing us that creative game." or some variation of that, and we all clap as the kid goes back to sit down.

Introduction and demonstration project (first 20-25 minutes of class)

• Setup: Have everyone in the room close their computer screens. Wait until they have all done this. This makes people know you are serious about them listening to you. Also, for volume, basically no loudness of your voice is too loud. People listen much better when you talk loudly and slowly.
• Overview: "I will present a project that introduces Scratch. I will leave the code up on the screen if you want to work on this project today. But you are free to work on what you want, and we have a long list of suggested tutorials and projects."
• Reassurance: "Don't worry if you don't understand everything that's presented. You can copy in the code for the project and that's a good exercise even if you don't understand it all. There are also plenty of tutorials for beginners."
• scratchcats.org: "This site has a bunch of suggested tutorials and projects [I scroll down and click on the arrows to expand a few projects to show how that page works.] We can show you how to use control-tab to switch quickly between instructions and workspace."
• Project/Demo: Depending on the amount of code, try to focus on the main ideas and don't worry about explaining every line. Try to focus also on any things that require special user interface in Scratch, such as making a variable, using the drawing tools, make a "More Blocks", etc. Also, try to focus on data variations. Kids like it when you try different speeds, different sizes, different numbers of clones, whatever. Tweaking data values also gives beginners a way to play with modifying the code without understanding it.
• Introductions: "If you are a beginner, try to introduce yourself to some experts who can help you. If you are an expert, try to introduce yourself to some beginners you can help."
• Screen: Leave the code on the screen. Put up one sprite that says "scratchcats.org". Put up another sprite that says, "3 kids: name, grade, how much scratch".

Kid project presentations (last 30 minutes of class)

• I like to write the names of all the initial volunteers on a list. This makes it fair in case we run out of time, that the initial volunteers have highest priority. Generally after the first few presentations more kids volunteer and I add them to the bottom of the list.

• What to say during each kid's presentation is something of an art. For advanced kids with a lot of code I generally try to just give a broad overview of the code and ask them which parts were the hardest. For beginners I ask more detailed questions where they can show they understand what the basic commands do.

• Unless the kid is very shy, I usually let them ask for "questions and suggestions" themselves, and call on people themselves. Most kids like calling on people.

People like to talk about the differences between different programming languages. But the main thing to know as a beginner is that all programming languages are actually very similar to one another. If you learn one programming language, you will have learned a lot about all progamming languages. All languages have lots of the things you see in Scratch: if statements, loops, variables, lists, functions, mathematical expressions.

Scratch is different from most other languages because you program by fitting blocks together instead of just typing code in a text editor. That's helpful for kids because you it keeps you from making many of the mistakes tha can happen when typing code, such as forgetting to close a parenthesis that you opened (like this.

Here are some important things that most other programming languages have but Scratch does not have. These features were likely left out of Scratch to make it easier for beginners. But in some cases they make it a bit harder to do things you can do more easily in other languages.

• Scratch doesn't let you make functions that return values. In Scratch, you can use the purple "More Blocks" to give names to blocks of codes, and you can give inputs to these blocks of code. In other programming languages More Blocks are usually called "functions," and the inputs to them are called "parameters." But other programming languages let you do something very important with functions that Scratch does not let you do with More Blocks: you can return values from the function. For instance, you could have a function called "Double" that takes a number as input and computes the double of the number (that is, multiplies the number by 2) and then returns the doubled number so that the code that uses ("calls") the Double function can then use that value. In Scratch, you can do kind of the same thing by having the a More Block named double that takes a number input and sets the value of a variable to the doubled number. The code that uses ("calls") the Double block can then use that global variable to do something with the value. That works okay in some cases, but doesn't work well as you want to write more complex programs. In contrast, most programs in other programming languages are based largely on functions that return values. So this is big difference between Scratch and other languages.
• Scratch does not let you share code between sprites. In Scratch, suppose you want to make a game where an orange cat and a blue cat jump around on platforms. After figuring out the code to make the orange cat jump around on the platforms like Luigi from Mario Bros. (which is not so easy to program) you want to make the blue cat jump around in the same way (the blue cat uses different keys to move than the orange cat but otherwise the code is basically the same). You have two choices. One is to copy all the code from the orange cat sprite to the blue cat sprite and make small changes to it. Copying code like that isn't a great idea because if you later want to make changes to how the cats jump, you have to remember to make the exact same changes in both sprites. The other idea is to use Scratch's "clone" feature. This lets you use just one sprite, but have multiple copies of it sharing the same code. That's a good plan, but cloning can sometimes be hard for beginners to understand. In most other programming languages, you can easily share code between different sprites (sprites are sometimes called "objects" in other languages).
• Scratch doesn't have two dimensional lists (called "two dimensionaly arrays" in other languages). There are lots of types of computer games that are fun to make that are based around a grid structure. Think about Pac-Man, Space Invaders, Centipede, Tic-Tac-Toe, Memory Match, Tetris, and Candy Crush. These and many other games are based on a two-dimensional grid of "spaces". To write these games, we usually want to store information in a programming structure that is also a two-dimensional grid of data spaces. In Scratch, we only get flat, one-dimentional lists. There are some tricks we can do to use a flat list to hold a "grid" of data, but it's harder to do it that way than if the language provided a grid data structure.
• Scratch is multi-threaded. In most programming languages, if you wan to make two things happen at once (like a ball sprite spinning while another sprite bounces on a trampoline), there are a couple ways to do it, but one of the ways uses "threads," where the threads a parts of the program that run at the same time. One thread spins the ball sprite and one thread bounces on the other sprite on the trampoline. Threads make it easy to make multiple things happen at once, but programming with threads can be very tricky, even for advanced programmers, because we have to be careful that the two threads don't try to do the same thing at exactly the same time. (For instance, if a player in a game gets a point every time the ball spins around and every time the other sprite lands on the trampoline, the score can get messed up if the ball completes a spin at exactly the same moment the player lands on the trampoline.) In Scratch, the sprites are multi-threaded automatically. This makes it easy for us to write games and other programs where multiple things need to happen at once. But a drawback is that, for certain programs, when two things happen at exactly the same time, it can cause tricky problems. These problems don't come up until you work on more advanced Scratch programs, but it's something to be aware of.