Health-o-meter Sprite and Stamping

Last week I introduced my Health-o-meter sprite to the students.  It’s based on the Health Meter sprite Colleen Lewis, the professor of the Scratch Programming MOOC on edX, shared in the class.  I noticed a couple of students adding the sprite to their project or making their own version.  It will be interesting to see it in action.

Health-o-meter script and costumes

Health-o-meter script and costumes

In general, Code Club went well again last week.  Students are making progress on their individual projects and the number of issues that crop up are not overwhelming.

Although one student’s query had Alex, my high school volunteer, and I stumped.  The student is making a paint program similar to Paint Box, a Code Club World project we worked on earlier in the term.  She has taken the basic project and is adding more colors and features to it.  One addition she is working on is a stamp tool.  She has drawn a few sprites: rainbow, present, balloon, lightning and wants the user to be able to place copies of the stamp on their drawing. Scratch 1.4 has a stamp block in the Pen menu but she was having trouble getting it to work.  Alex and I both looked for help on Scratch Wiki, but were not successful in getting any code to work in the moment.

I spent some time today researching and testing some code and I think I have a couple of different algorithms for her to try tomorrow.  I did find a good resource through the Scratch Wiki – a Stamping tutorial and explanation, which helped get me started.

One way to work the stamp tool would be to have the sprite “stamp” itself in a random location on the stage.  Here I have a ball sprite and when the sprite is clicked, a copy of the sprite will appear on the stage in a random position.

stamp tool, version 1 -random placement

stamp tool, version 1 -random placement

That’s okay, but I’m sure the “painter” would like to pick the place where the stamp will go.  So I worked again to improve my solution.  Here the ball sprite moves with the mouse when clicked.  When the painter presses the “s” key, it makes a stamp of itself and the sprite returns to its original position on the toolbar.

Screen Shot 2015-03-24 at 7.49.02 PM

Stamp tool, version 2 – click and press “s”

That is better.  Now, though, I have to instruct the “painter” to press the “s” key to stamp. So I took one more try at the code.

Stamp tool, version 3 - on click

Stamp tool, version 3 – on click

This seems to work in my simple case, but I know in her paint program a lot of drawing happens with mouse down, for example, the pencil goes to the mouse-pointer. She will have to try it and test it.

Screen Shot 2015-03-24 at 7.58.06 PM

Something else could go in the repeat until – like the sprite could say “click to place”.  As always with code – different algorithms can give similar results.  One way may more pleasing to the coder than another.

I can’t believe there is only two more weeks of Code Club.  Students will need to finish up tomorrow and we all need to prepare for Showcase #2.


Rookie Mistakes

After a merited, welcomed, two-week break, we have Code Club again tomorrow.  It’s our next to the last meeting and I’m concerned. I don’t think their “create your own game” projects are ready for the showcase – I don’t think they are one hour away from being ready. There’s a lot of work to do, errors to be found, logic to be thought through, and no rigorous testing has been done. (Do I sound like a software manager a week before a new release deadline?)

I had planned to approach each of the 4th grade coders during school over the last two days and find out how they thought their project was coming along.  I talked to two (out of 23) and they didn’t seem concerned.  I actually think they were confused about what I was asking as if the two-week winter break had wiped out all thoughts about Code Club.  So maybe I’m the only one who’s nervous about this. This is my rookie season as a Code Club leader, I must remember.  Maybe everything will get done on time?

Yeah, right.  Here’s the thing.  I recall the last Code Club meeting as being less than productive.  I believe others also found it frustrating. Besides the fact that it was the week before Christmas and two days before vacation, things didn’t go as well as I’d hoped. Students were stuck, teams weren’t working well together, projects were behaving strangely, stuff was lost, etc. That kind of stuff happens. I expect some of that, I’m not a complete rookie.

What bothers me most is not every student was able to get some help. On the whiteboard, next to the list for using the microphone, a student started a list for those who needed help and added their name.  I didn’t even notice the list until the end. It’s a good idea, really, and we’ll start a list like that tomorrow.  Not really sure what to think, but I feel that I’m letting them down. The list was an interesting expression of frustration. On one hand I expect them to need some help as they are just beginner Scratchers, but perhaps am I helping too much or unevenly. Maybe I haven’t provided enough foundation to give them the confidence to persevere in troubleshooting? Or the projects were too complicated and it was a failure in the design review process. More things to learn.

Truth is, I don’t have that much more experience using Scratch than they do. Problems and questions have come up that I didn’t have the answer to.  For example, a couple of students wanted to add gravity into their game.  Turns out there are lots of ways to simulate this, even more than those listed on the Scratch Wiki for Simulating Gravity (I didn’t even know about the Scratch Wiki until researching the gravity problem).  One team is using a timer to simulate gravity.  Another is using simple direct movement method.

Screen Shot 2015-01-06 at 10.48.50 PM

I’m sure more stuff like this will crop up tomorrow. Of course, I need to remember – rookie season, rookie mistakes.