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.

Why no posts?

Simple.  The Monster, her mom and I have been overseas for the past two Fridays.  I considered trying to do some programming while we were abroad, but better judgment got the best of me.  The opportunity for a 9 year old to see a new, foreign country is not one to be squandered when we're talking about genuine education.

We'll be back next week though!

A review of non-programming lessons so far

Part of my core belief about this project, which this is really a test of, is that by teaching The Monster computer programming, I'm also teaching a variety of other lessons in a pragmatic way.  So periodically I'm going to review these and see how that part of the project is coming...

1) Combined Words.  "Pixel" is "Picture Element".  This is very useful to explaining what a pixel is and how it is useful... but it's also a reality of language (especially the English language).  We've reviewed this many times, as I insist that she give me this two-word definition of "Pixel."  This evening, she asked me what the pieces of "request" mean.  Coincidence?  Maybe.

2) Cartesian Coordinates (X and Y values for position).  This one is going to take more review, but at the end of the day it is too crucial to our project to believe that she won't grok it sooner or later.  Particularly interesting is that Scratch places 0,0 at the center of the screen, not the lower left.  This has a lot of implications for #3, Negative Numbers.

3) Negative Numbers.  The Monster has not been taught this in school yet, so this is tricky.  She understands subtraction, but not negative numbers.  However since the middle of Scratch's world is 0,0 there's no getting around a constant flood of negative numbers.  We've mostly danced around this thus far, but it's going to continue to recur.

4) Multiplication vs. Addition.  Multiplication and addition have a funny relationship, really.  By looking at the difference between a nested loop (which creates a multiplication) and consecutive loops (which are addition), this difference is given a new perspective.

5) Measurement of a Circle in Degrees.  While The Monster was familiar with the terms "a 180" and "a 360," she was not familiar with their mathematical/geometric underpinnings.  In order to get her Pear to rotate in a predictable way, she had to get a crash course in circle geometry.  This also involved division and multiplication (using a hand calculator of course) to sort out increments of rotation.

I'm not counting stuff like variables yet... I was getting ahead of myself when we did these.  But that's not a bad list for three lessons.

Lesson 3 part 2: the IF statement

The Monster had more momentum than I had planned for in Lesson 3, so I decided if we're doing loops, we might as well do IF.

The IF statement is in many ways the core of computer programming.  If you understand the IF statement, you understand how conditional branching is such an essential element of computing.  So I was nervous digging into IF, and I'm pretty sure that The Monster will be reviewing this a few times.

In Scratch, an IF statement looks like this:

The hexagon is where the conditional is placed, via drag and drop.  While this made sense to me, it was tricky to figure out what could go inside the hexagon and what couldn't.  There's no clear indication of "conditionals" in Scratch's color coded selection of action types.  The clearest ones we'd found, the ones that The Monster had already used, were things like keypresses.  But these were going to blow by way to fast when executing a script.  I was quickly getting into trouble.  We hadn't even used a variable yet!

The bottom line:  this was a mistake.  I should have been doing variables before I considered jumping in to the IF statement.  For us to get anything out of IF, we had to know variables, and variables are way out in front of where The Monster currently sits.

So I made a judgment call.  I decided, let's roll with this momentum, and just show The Monster how to do something cool.  I took over the mouse and, explaining everything I was doing, created a main update loop (a "forever" loop in Scratch-speak), created a locally scoped variable to store keyboard input as a directional state, and then put the variable into a series of IF statements.  It went pretty fast, and I'm pretty darn confident that it sailed right past The Monster, even though she claimed to be understanding it every step of the way.

Here are some of the ridiculous list of concepts that came into play:

• A main update loop
• Variables
• TRUE and FALSE as logical concepts
• Conditional branching
• Grouped statements (inside an IF statement's brackets)
• Flow of control (what happens if no statement matches an IF?)
• X vs Y coordinate space
• Negative numbers (!!)
• Moving in relative space (relative to the sprite) as opposed to absolute space (X/Y)

Do I think The Monster took all that in?  No chance.  But I did let her put in quite a few of the parameters, and to see how they affected the interactive outcome.  I suspect that we'll spend the next several weeks deconstructing and reconstructing this script.  I think next would probably have to be variables...

Meanwhile, here it is, in its glory:

A simple but functional interactive prototype

Lesson 3: Loops

Today, we begin logic.

You might remember that long, ugly string of rotations last week.  It's messy, but it worked.  It also had the distinct advantage of teaching a lesson in multiplication:  24 copies of a rotation of 15 degrees equals 360 degrees... one full circle.

Today, we'll compress those 24 discrete steps into one nice little loop.

But first, review.  Pixels, check.  Objects, check.  Had a little struggle with how many degrees are in a circle... but we got there.  Check.

a basic "for" loop in Scratch

Now to loops.  Scratch has a nice, highly visual display of loops.  It's these little "C" shaped structures that automatically wrap around whatever commands are inside the loop.  It also uses understandable terms like "forever" and "repeat".  I like that.

Logic, it turns out, is difficult and foreign to the monster.  While she understood the basic usefulness of repeating something, when she accidentally created a nested loop (which is easy to do in a drag and drop programming environment), things got funky.  It was time to step in and play debugger.  I pointed to the steps in the script as they were being executed.  Eventually she sorted this out.

144 iterations (multiplication)

Once again, math... I had never really thought of it this way, but it turns out that stacked loops are addition, whereas nested loops are multiplication.  Fortunately I saw this one coming.  After she inadvertently built a nested loop, I threw the monster a loop by asking her to create the 24 iterations she needed to do a complete 360 degree spin (yes, it was time for a little review on the number of degrees in a circle).  Sure enough, she created the first (nested) example, and the poor dizzy pear spun six times around, instead of the expected one.

24 iterations (addition)

Once she understood (with a little help by the Daddy-debugger) how nested loops really work, she recognized this as a multiplication problem.  She went for the more elegant solution of two loops of twelve iterations, but the stacked (additive) solution would have worked as well.  This simple visualization of multiplication versus addition is pretty neat.

This is right about the point in the lessons when I run out of ideas.  But it seems like the monster picks up speed.  I didn't think we'd really get much past basic loops, so we kicked in to conditionals.

Stay tuned for Lesson 3, part 2:  conditionals!