The Scratch project we tackled last week was not a game but a straight-forward animation project. We tried the Fireworks project from Code Club World resources. Not all of my Code Club students will want to make a game for the final independent project. Some may want to do interactive storytelling with animations instead. One of my goals is to expose them to some of the different types of things you can make with Scratch so when it comes time to design their own project they can say, “oh, yeah, we did something like that.” Or, at least, I can say, “Remember when we did such-and-such. That sounds a lot like what you want to do.”
My parent volunteer introduced the project, talked a bit about animation, and gave them the choice to design their own rocket sprite and many of them did. I know I want them designing their own stuff, but give them an option or two and they’ll run with it. Have I mentioned that they are a creative bunch? They are little testing testers, too, and have no qualms about setting speed to a very large number or having a screen full of sprites. Kudos for Scratch for not crashing in these cases. Just goes to show that Scratch was built for and tested by kids.
The only misunderstanding I came across with this project was with the iterative approach to code building. The directions had you start with a simple bit of code and then you built on it, testing as you went. For example, the rocket starts with the simple scripts on the right (in the picture below) then you add the loop and conditional to improve the behavior and end up with the script on the right. I noticed a few of students who had all the different stages of the script in with their sprite and it was interfering with the expected behavior.
We only have time to try one more project before they start designing their own and there are a couple – maybe three – different projects I want to introduce. Now I have to decide.