What should Lesson 5 be?

As I'm sure is obvious, this project is being done very much on the fly.  I'm inventing the lessons as we go, and especially with the relative infrequency of the lessons, it's hard to keep continuity.  So I found myself struggling a bit with what to do with lesson 5.

• The Monster could use more help with math.  She's struggling with some math concepts in her regular school lessons.  Should I create a programming challenge around math?
• There are lots of programming concepts that are just barely being brushed.  Variables are a key example.  Should we be building more logical concepts?
• The Monster is really engaged by her "going to the market" prototype.  Should I encourage her creativity and nascent procedural authorship?

I already know the answer of course :).  I'll take door number three please.  While I love the potential of programming to teach math and logical concepts, my bias is toward programming as a mode of expressiveness.  When I saw The Monster get so excited by her little arrow-keys drama in Lesson 4, I was thrilled.

So for lesson five, we'll work on the drama... what if we actually showed the mysterious enemy that is apparently scaring The Pear away from the market?  And what if the player could make that enemy appear or disappear as a mechanic?  That will be our next lesson.

Lesson 4, part two: "Going to the market aahhhhhh!"

In the last post, I mentioned that The Monster had discovered tweaking.

The Monster had managed to create an interactive app that in some slight way begins to vaguely resemble her initial design.  Well, started anyway.  The Pear moves left and right, it changes its animation state in accordance with its direction of movement, and, most importantly, it is under direct user control.  Yes, sliding left and right is pretty primitive, but it's software.

At this point, I suggested to the Monster, perhaps she should adjust the speed of the character.  This was pretty straightforward: Scratch has a simple command for moving the sprite along the X axis, and it looks like this:




Pretty simple.  So I suggested to The Monster, how would you speed up the movement?  Pretty simple.  She had already set up a couple of these commands, so she changed them both to -16, theoretically doubling the speed from 8.  But The Pear stayed pinned to the left side of the screen.  What could be wrong?

All I told The Monster was, this is a bug.  This is your fault.  You have to figure it out.  She looked at it carefully and... she said, "oops, they both say minus 16."  My kid, negative numbers!  She quickly remedied it, and sure enough the speed doubled.

Then I said, go ahead and play with the numbers however you like.  She did, and ended up with this:

So interesting... it's asymmetrical now.  It moves at a rate of eight to the right... and sixteen to the left.  This was The Monster's preferred tweaking value.

And this is where the magic happened.  Before we go any further, perhaps you'd like to actually play with this software.  Scratch allows you to quickly and easily upload any project:

Going to the market ahhhh!

Why did The Monster choose these values?  Because for her it told a story:  whenever The Pear was moving to the right, relatively slowly, she'd chant "I'm going to the market, doo doo doo..."  Then she'd hit the left arrow key and the Pear would suddenly run away to the left, twice as fast, and The Monster would shout "aaaaahhhhhh!"  The specific values in these fields had created an interactive story in her head, however primitive:  An ordinary day is transformed by something scary and unseen.

Cool work Monster.  There will be lots more of that... is there maybe even a game mechanic there?

(Oh and yes, I know I named the animation frames badly... The Pear is supposed to be female...)

Lesson 4, part one: Review, and animation

After a few weeks away, the first order of business for lesson four was definitely review.  I printed out the current script for the Pear game, and had The Monster walk through it step by step and explain what each statement does.  There was a lot of work to be done.  Some of the concepts, particularly loops, she remembered perfectly.  However the math required a lot of review.  We were back to square one on circle geometry... but that's OK.

Also I recognized the deep importance of understanding booleans (true/false) for programming.  While The Monster intuitively remembers how IF statements work, the mechanics of it, the judgment of true/false, was not something she could articulate.  I'll be continuing to work with this concept to keep it fresh for her.

Eventually we had walked through the whole project and she could recall what worked and why.  (I took the opportunity as well to talk about division and "remainders," something she's learning about in her regular school math lessons.)  Now it was time to move forward.

We agreed that the spinning character, while an interesting math challenge, really didn't look that great.  So the monster gladly removed this feature from the game.  Now the character slid gracefully from side to side under keyboard controls.  The Monster was pleased.  But I pointed out, the pear looked a bit silly, because though it looked good going left to right, it looked bad going right to left; the single animation frame didn't look so good going backwards.

Here's where a decision had to be made.  In order to create a "looking left" animation frame, I needed to duplicate and mirror the sprite.  This is relatively straightforward using Scratch's "costumes" feature... but if you've never dealt with a pixel editor before, far from intuitive.  I made a decision:  I'm teaching The Monster programming, not pixel manipulation.  I quickly created the mirrored image myself, and named it using Scratch's costumes feature.

Now, armed with two possible animation frames ('costumes'), The Monster could get the Pear to look left or right, corresponding to the left/right movement commands.  On her first go, she got it backwards.  This was not surprising to me - The Monster has a habit of "ready, fire, aim" in her regular math homework, and this came into play here as well.  Only in the case of a computer program, her mistake was immediately obvious.  She quickly fixed it.

Now the Pear moves back and forth, and looks correct doing it.  She immediately started playing with her running code, making the Pear switch directions rapidly, and starting to speak on its behalf.  This was clearly far more engaging!

This was only the beginning of the magic though... stay tuned for Part 2, where The Monster learns the value of tweaking, and creates something very cool.