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!

Lesson 2: Objects

Last week, we learned pixels, and painted a copy of The Pear.  She looks great, so The Monster was ready to put her into Scratch!

Now was the time to talk about what an object is, or at least an object in the language of Scratch.  We talked about how computer programs are comprised of data and instructions, and that when we think of an object, it's about combining the data and instructions into one thing.  In Scratch, this works very cleanly with the fact that scripts are attached directly to sprites.  The programmer never dictates what data (sprite) is being addressed by the script, because the script is tied directly to the sprite (no sprites = no code).

Scratch is imperfect here too... it's actually quite tricky to instantiate a new sprite, and I made the mistake last week of having The Monster create a new "costume" (new sprite animation state) from the original default sprite, rather than starting anew with a fresh sprite.  A little tomfoolery though and The Pear was its own sprite, and we were ready to go.

I was amazed at how quickly The Monster was able to get The Pear under her command.  I gave her the assignment to make The Pear do a complete spin and though she didn't do it the most elegant way (hmm, looks like maybe loops are a future lesson?), her solution does indeed have The Pear spin, just about right:

(sorry for the lousy photo quality)

Well, almost.  The Pear was spinning a little bit too much.  Each of the steps she plopped in was rotating the sprite 15 degrees, and she was overspinning a bit.  Time for a lesson in measuring angles of a circle.

Being a modern soul, I couldn't even find a protractor on my desk... but the internets quickly remedied that.  We looked at a picture of a protractor and talked about one circle equaling 360 degrees, and the various subdivisions of that, including the 15 degree increments her script was using.  I then took out a pocket calculator (which doubles as an iPhone) and asked her if she could determine how many of these 15 degree steps would really be required to get to exactly 360 degrees.

This was a tough one.  She knew that the problem was division, but had to work her way through what gets divided by what.  Eventually she sorted out it was 360/15, which provided the answer:  there should be 24 steps.  When we made sure there were exactly 24 steps, sure enough, The Pear spins perfectly.

I thought that was enough for a day, but The Monster wanted to plow forward!  So, sticking with today's lesson of objects, she imported a new sprite, gave it its own behaviors, and we watched the two sprites operate independently on the screen, not interfering with each other, as proper objects shouldn't.  Right now, she's making a brand new sprite, which she says is an enemy.  It'll apparently get its own behaviors too.

Go Monster, go!

First Week's Lesson: Pixels

The Little Monster is creating her software in Scratch, which means that she needs to start by having a Sprite to control.  Scratch works by having Sprites and their behaviors tightly linked (sort of a primitive object-oriented structure).  It comes with a default kitty cat (who we conveniently just call "Scratch") but it didn't feel right to have the Monster work just with some other person's sprite.

So it was time to create The Pear.

To create the Pear, we first need an understanding of what a pixel is.  We had a couple routes for this.  First we talked about what the word "pixel" means.  It took a while but the Monster now knows, "picture element".  Then I had her lean way forward and look closely at the screen of the iMac, right up where she could see the little square blocks that make up the screen image.  This was a revelation!  Wow, the whole screen is just a bunch of those little blocks!  Yup, those are pixels.

Next, it was time to create the Pear.  For this, we had a secret weapon.  The Monster's very creative mom had hit think geek for xmas ideas and had gifted the Monster and Daddy D with the toy called pixelblocks. These things are a fun toy, and a great tool for understanding the concept of pixels.

Using pixelblocks, The Monster and I had already built a prototype of The Pear.  It looks like this:

This prototype was great because we could talk about the concept of X and Y coordinates, and the fact that the computer scans left to right as it draws the image.  So just like how the computer draws one pixel at a time, we can count the pixels in The Pear here, and replicate that on the computer.

We started at the top of the head, and, counting as we went, The Monster re-created the pixel blocks version on the computer.

This turned out to be very difficult and awkward.  Single pixels weren't going to work very well on this high-res screen, and I couldn't find a decent pixel editing program (what ever happened to Dpaint, anyway?).  So we had to draw large squares in Scratch's primitive bitmap editor.  It was a lot of work, and I had to help out the Monster quite a bit in getting those squares lined up correctly.

But, success!

There The Pear is, in all her glory!  (Yes, The Pear is a girl.  The Monster says so.)

Next week... time to get The Pear into the software!

The Monster Wants to Make a Game

A couple of months ago, my daughter (for the purposes of this blog I'll refer to her using her nickname, "The Monster") and I were on the train heading into San Francisco for a day of sightseeing, and she said to me, "Daddy, I want to make an app."

"You mean, like an iPhone app?"

"Yes."

"What sort of app?  What does it do?"

"Well, I want to make an app where you point the camera at a plant or a flower, and it tells you what that flower is."

"Wow, that would be an amazing app!  But, that would be very hard to make.  Can you think of something a little bit easier?"

"Well, I like playing games on your iPhone Daddy.  Do you think I could make a game?"

"I do.  I think that's a fun idea."

So for the next half hour, and then the ride back to my place south of the city, we designed a game together.  It's got a pear as the main character, and it uses tilt and physics to solve puzzles.  It seemed kind of neat, and I enjoyed the process, and she seemed to too.  And I thought, that's the end of it.

Then, in November, a good friend of mine and fellow game designer talked me into joining him in giving a workshop.  The workshop was for local high school teachers, to talk to them about how to help their students make games.  The sponsor of the workshop was the Alliance for Young Artists and Writers , who have sponsored a wonderful and famous contest for creative high school students for many years, and have recently added the creation of games to their awards.

In preparation and then at the workshop, my colleague and I ultimately despaired.  The hurdles are too high to tell the teachers a few simple steps to turn their students into creators of computerized interactive art.  The teachers were grateful, and gracious, but I felt like I had failed.

In the days after the workshop I thought, this task would have been so much easier if only kids were taught to program.  If kids had programming literacy, we could put a tool like Flash or Torque or Unity in front of the kids and just watch what wonder they'd create.  Yet programming is still viewed as an advanced, or niche, skill.  But I've done programming... I know... it really isn't that hard!

So I started to think, maybe we should make The Monster's game, she and I.  And a few days later, I installed Unity and we started to experiment with the editor.  I mixed in some lessons about what hardware is, and software, and things like that.  But this was way too much, way too fast.

So I took a step back, and discovered the marvelous tool from the MIT Media Lab called Scratch.  It's a graphical, object-oriented programming tool that's perfect for elementary school kids.  The Monster spent some time with it and started having success, creating programs, debugging them, and learning about the process.

Now, every Friday afternoon after school, The Monster and I spend an hour or so doing programming.  This week, we started on The Monster's game, and I started this blog.  We'll let you know how it goes!