We did some more programming over the weekend.
I was wondering yesterday, as we were going through it, how much of it he is getting and if I am letting him grasp enough of it, or if I am rushing him through it due to my impatience.
Today, I got a bit of a hint towards that, because we needed to add buttons. Which don’t really exist in the Scratch world, except as their “sprites” and so every button is an “actor” in a sense. So we started making buttons as sprites and I was explaining to him how they need to have two costumes, a “selected” costume and a “notSelected” costume. And we colored the two states of the buttons differently so one could tell when they were in each state.
“It’s like you have this all planned out, Dad” he commented as he went through the repetitive process of putting the same set of actions on each of the buttons.
And I laughed and said that I’ve been programming for most of my life, so I am able to see problems earlier. But I’m conflicted between making the process seem like a natural conversation and having dedicated design sessions with him. I think that this stage, we want things to flow and have quick, fast iterations and not be weighed down by “lectures”. Though at the same time, I want to avoid spoon feeding him solutions and make sure that he’s able to learn how to see problems and break them down. Though I don’t know how to do that explicitly, so we’re going with a leap of faith on implicit learning for now.
Since this hit my soft spot, I changed the subject and told him that our implementation already had a bug in it that I could see. I asked if he could see it and he couldn’t. If he could have, I probably would have annoyed everyone with how many times I’d tell the story bragging about his ability to see that changing the state of one button necessitated the states of the other buttons to be updated.
Though he had fun discovering the bug by running the game.
And we had a lot of fun (I think) writing this last game. And the part he thought would be the hardest, actually took less than 2 minutes. Programming the “hard” mode of our game turned out to be pretty easy. I think that aspect of the program tickled his soft spot for word play.
Anyway, to be safe, I think we’ll design our next game (tic-tac-toe?) on paper first. To go through some of the design process. I think he’s taking for granted how easy it is to design an application with me as a tour guide. As we played some other rock-paper-scissors games on Scratch, we felt ours matched up rather nicely.
Though we’re completely biased. And Sal’s willing to give you a bajillion dollars if you can beat our game in Hard mode. Good luck.
As a final point, he did understand the abstraction between our internal representation of a rock (1), paper (2), and scissors (3). We took a walk after we hit a big conceptual design flaw in our program (in “easy” mode, our first mode we wrote, we programmed the computer to always play paper – our result screens were based on that. So when we wrote “medium” mode, where the computer plays randomly, the results screens weren’t handling the computer’s new freedom of choice. That change demanded a dog walk) and on the walk, among other things he was talking about, he mentioned the desire to make a elemental based version of the game. And we found it on Scratch. Where fire, water and ice battle each other instead of rock, scissors and paper.
So we talked about what we would need to change in our program and it was really only the “costumes” of our sprites. Internally, our program could still call things rock (really the value 1) and just draw it as fire – and the game would be the same. We could even just have it as a choice for the user – if they would like to play Rock Paper Scissors, or Fire, Ice and Water. I was pretty pleased that the idea clicked so fast.
But to test it, when we design tic-tac-toe on paper, we’ll try and use math only to sum up the rows/columns/diagonals to check for a winning condition. Or maybe we’ll come up with a better way. You know, cause it’s not like I’ve got it all planned out already…sheesh.