Skip to Content

Ideas for an elementary school Scratch curriculum

Some practical advice from a teacher on how to implement Scratch in an elementary classroom. Includes an instruction sheet and sample game projects.

Retrieved from a discussion thread in Scratch Forums:

 

I have been teaching an after-school class for 2nd to 4th graders. My approach has been to give them some basic programs to start. I make them enter in the basic part of the program and we discuss why it works. Then, I let them modify it. Some of that time is just messing with the drawing editor and the sounds and that is OK. But, I also encourage them to add new capabilities. I note that teams of 3 work best because they tend to help each other and also tend to stay on track. The approach I used was:

1. 1st day: no computer, just go through terms and ideas and how to think like a programmer. I find this helps a lot. I use a cutout of Mario and a grid to with obstacles. This helps them understand the difference between look-and-decide (what a player would do), pre-arrange (animation), and conditional based decisions (such as always turn left when possible, etc). By introducing control, loops, conditions, variables, you really help them learn to think this way. I tell them to use the next few days to think about any task they are given (such as brushing teeth) and to divide it up into parts and conditions and loops.

2. Next day, I give them a simple animation example with Scratch. The 1st step is a repeat loop with turn 45 deg and move 50 steps. This is to get them to think about control and loops. It goes way too fast. So, they then, modify to add wait(0.5) to make it reasonable. Again, it emphasizes the steps of programming. Finally, next-costume and a change to the "hat" (to if-space-key). I do this so they learn how to use Scratch. I then let them play with what it looks like, add sound, add more sprites, etc. They need to "own" it.

3. Next time, I move them to a ball chase game (one sprite is chasing the controllable one). This allows use of key motion, random, conditions, variables (hit counter), collision, etc. They love this because they can play. But, I let them then add a second ball for them to chase. They add new variables and all. Some guidance may be needed, but they usually do this just fine. The more advanced ones will change it to a two player game. Again, customizing is fine, just keep them focused. If you tell them that they are to show the rest of the class what they have done, they are more likely to work on it rather than playing with sound recording.

4. After that, I move to a ball firing "cannon" shooting the dragon. This allows broadcast and receive and emphasizes object oriented concepts. If done right, they can clone the dragon (and change its look) as many times as they like. The hit and miss counters will still work, etc. I leave a few bugs in like not initializing the hit counter. They "discover" this (or I point it out if needed) and then we work out how to resolve it.

5. Finally, I challenge each team to outline a new game they want to do. This then can be reviewed. I work with them to cut the 1st version down to a manageable size and work out how they could add to it incrementally. This is a crucial step in programming: learning to balance ambitions with what is achievable and learning to build in a more modular way. Scratch is not perfect for this due to the lack of "by reference" scripting (so copies become different if you change one), but it is still viable with some care.
My experience is that if they are getting cool playable results each time, they are more likely to focus on it.

 

Other Files: 
Comments
Member

 Thanks for this outline pkimelma ... good to get some pointers on where to start. Justine (Ireland)

 

randomness