My Scratch Project

Ta-da! Here's the Scratch project I made this week: https://scratch.mit.edu/projects/102693993/

As you can tell, I'm still a gigantic nerd!

This project turned out exactly how I wanted it to, and I'm very proud of it! So, what did it take for me get so invested in a programming project? Papert and Resnick et al. are right; making it personally meaningful and developing a relationship with the project really helps! The open-source nature that allows for "looking inside" and remixing Scratch projects also helped me reach my goal.

The project is a remix of a "fruit catching game," only instead of fruit, you try to catch Star Wars: The Force Awakens characters in a trashcan. You get points when you catch the movie's villain Kylo Ren (and lots of points if you catch the wild card, Anakin). You lose points if you catch Rey or Finn, because they are heroes and they don't belong in the trash! Every time you catch a character, you see a little message. The game starts out with 10 points. If you lose all 10 points, then it's game over. If you last all 105 seconds without losing all your points, then you win!

Almost every decision I made here reflects some sort of joke about the Star Wars fandom, and each joke has multiple layers of meaning. I intentionally made the project to include those jokes and because I knew other Star Wars fans would enjoy them. There's nothing I and the fandom love more than making fun of our problematic favorite wannabe-Sith lord Kylo Ren. My choice of "trash" as the theme has a long history in fandom. I'm not sure of its origins, but when a fan calls a character or a romantic pairing they like "trash," they're acknowledging both the problems with the character/pairing and their own silliness in liking them. So they're calling both the character/pairing and themselves trash. In addition, I've seen fannish blog posts calling Kylo Ren a "trashcan" because he wears a "trashcan" on his head, and he's also a whiny brat who needs to learn a lesson, so it's even more appropriate to associate him with trash. There are also these two Tumblr images that further inspired the idea, which I credited in my description of the project. All of the things Kylo Ren says when the trashcan catches him are somehow based on his character or are plays on his actual lines. They are all about how he belongs in the trash. Finn and Rey's lines are similar, except they chastise the player for putting them in the trash. Poking some fun at my favorite fandom right now was a great way to make a personal connection to the project and to motivate me to do it well.

As for the process, I was really grateful that Scratch lets you remix other projects. There's no way I could have coded this whole game from scratch! (pun intended) I searched for "catching game" on the Scratch website and found this game, called "fruit catching game." I thought my remix would mostly involve design work, i.e., modifying the sprite's costumes to be the Star Wars characters instead of fruit and junk food, replacing the player character with a trashcan, switching out the background for a more Star Wars-y one, etc. I also added one "say for 1 sec" block to each character sprite, so they would react with a speech bubble when they touched the trashcan sprite. All this was quite simple, especially since I've worked with Scratch a little in the past.

However, there were some things about the original fruit catching game that I didn't like much. For instance, all the fruit that scored you points (i.e., Kylo Rens in my game) fell from the left side of the screen, while most of the junk food that lost you points (Finn and Rey in mine) fell on the right, so it was too easy to just stay on the left until time was up, and avoid most of the junk food. To resolve this over-simplicity, I had to tinker around with the x-positions of the sprites. Just like the kids in Mindstorms tried different numbers for angles to see what would happen to the Turtle in LOGO, I also used trial and error on the x-position numbers, until I figured out that the negative numbers were for the left side of the screen, and the positive for the right, just as you would expect from a coordinate plane. I also found that the numbers went pretty high up, into the hundreds. I modified some of the numbers, but left others the same. It's still not quite as random as I'd prefer, but it's okay.

I also didn't like that the original game simply said "Game over" at the end without telling you if you had "won" or not, no matter how many points you had collected. The "Game over" made it sound as if you always lost. I wanted to make it so you really could lose if your score got too low, but if you got enough points by the end of the 105-second timer, you would win and see a "Congratulations" message. This required more advanced programming than I had ever done before in Scratch. I looked at the existing blocks on the stage. At first I tried to use the "lives" variable, but I quickly realized that the original programmer hadn't specified a real role for "lives," so I deleted that variable and all of its associated blocks. I used the score instead. To change the score to start from 10 rather than 0 (making it so you kind of have 10 "lives"), I had to change the starting score on all sprites to 10. This took some exploring to figure out why changing it for only the primary sprite (the trashcan) wasn't effective. I changed the original "Game over" message to "Congratulations! You took out the Star Wars trash!", and still had it appear at the end of the timer's countdown, but only if the score was greater than 0. This required the use of an "If-then" block and a green "greater-than" (>) operator. To make the "Game over" message appear when your score went below 0, I again had to use the "If-then" block and a green operator block, but it was "less-than" (<) this time. After this didn't work, I discovered that you had to drag the score variable into the green operator block, instead of typing the word "score." The last problem I ran into was that the "Congratulations" message would work if you won the game, but the "Game over" message that would stop the game before you reached the end of the countdown would not work. I clicked on the little question mark button (Block help) and opened the help text for the operator block. In looking at the example code they had there, I realized I had forgotten a "forever" loop! What a rookie mistake! I've programmed e-textile lights to flash forever so many times that I should have known better. After I added the "forever" loop to the "Game over" code, it finally worked. The "Congratulations" code doesn't have a "forever" loop. Instead it's programmed to appear after a "wait for 103 secs" block.

I really saw the benefits of Scratch's "remix" function. I learned things about variables and operators that I probably never would have if there were not already examples of them in the project I remixed. If I'd started from scratch, I probably would have made a much simpler project and would have stuck to those blocks I was already familiar with. Being able to remix, and having motivation through a personal connection to the topic motivated me to go beyond my comfort zone. This is the way learning should always work!

Toy Hacking

I live in a small apartment, and when I moved there, I didn't bring old toys with me from my parents' house. The only electronic item I could think to bring to class for Toy Hack day was a light-up Christmas decoration. I also brought a laser pointer and a cube with an LED in it, but I opted not to take those apart. None of the things I brought seemed very interesting, so I was glad that Kylie brought a few more for us to choose from. I picked out a few toys before settling on one. Here's a picture of all the items I was trying to choose from:

My Christmas tree, LED cube, and laser pointer are in the front-center-left. The three other toys I found in class were the shark car, a spy headband, and Darth Peanut M&M.

First I tried taking apart the Christmas tree. As I suspected, it was far too simple. I was able to twist the tree part off, unscrew the battery compartment, and easily remove the entire electronic module from the tree's base. It appeared to just be a single color-changing LED. I don't know what controlled its color-changing pattern. I didn't see a circuit board or anything programmable. Perhaps it was integrated into the LED itself. I was easily able to put it back together. In any case, I was unimpressed and wanted to try hacking another toy.

The "guts" of the light-up Christmas tree. The ring near the bottom was just hot glue, which was the only thing holding it all together at the top of the base.

I finally chose the Hot Wheels shark racecar. First I played around with it to see what it did. It had three buttons on top, each responsible for something different, like lights, growling noises, and one button that shot the car forward, with the shark's jaw moving up and down as the car drove. There had to be some pretty sophisticated electronics for all that to happen! Taking it apart, it turned out, required a whole bunch of unscrewing.

Look at all those screws! And that's just the bottom layer!

Inside, the toy gave up its secrets. I found buttons below the buttons on the outside, a circuit board, an LED, and a speaker. But the motor was in its own compartment, and I still wasn't sure how it worked. Remember how in my last post I said I didn't know how a motor made things move besides just directly spinning? I could see a single motor, but it was facing the wrong direction for it to be directly spinning the wheels. It was perpendicular to the axle rather than in line with it. I decided to focus on finding out how that worked, since I knew this was a gap in my knowledge of machines.

Well, it took a little more unscrewing and finagling, but I finally split apart the motor's compartment. And I had an exciting moment of realization that I'm sure a young Papert would have been able to relate to: Oh! Gears!

I never had an emotional attachment to gears the way Papert had as a child. I knew they could turn each other, but I never knew how they worked when attached to actual motors (maybe I should pay more attention to the gears in my bike!). The most surprising aspect of this discovery for me was that some gears were at right angles to each other, entirely changing the direction of the spin. That was how it was possible for a motor perpendicular to the axle to spin the axle!

This was an extremely satisfying discovery for me. I could finally appreciate why Papert's "object to think with" as a child had been gears. But I also realized a few other things. Electronic toys like this are not meant to be taken apart. I'm pretty sure I broke some plastic pieces in forcing open the motor's compartment, so I don't think I could ever properly put the shark car back together again. This difficulty and "black-boxing" of how the electronics work is greatly limiting to the kind of learning that can happen with these toys. They are not "construction kits" "designed for designers," as Resnick and Silverman put it. But they could be! If toy cars like this were modular, easy to take apart and put together again in a different way, with easy access to their electronic parts (i.e., no white compartment "black-boxing" the motor and gears!), then kids could learn so much more from these toys, and probably have even more fun!

Building a Scribbling Machine

Constructionists often distinguish between "planners" and "tinkerers" (e.g., Resnick & Rosenbaum, 2013). Planners are more "top-down" and have a predetermined goal and an idea of how to get there, usually using formal rules to help plan. Tinkerers, on the other hand, use a more open-ended "bottom-up" approach that involves iterative exploration, and they may not have more than the vaguest of goals, which could change at any time as new ideas emerge while they work. I have always considered myself more of a planner. For instance, I think about stories for months before I ever write a single word down. I like to outline papers before writing them. When I start a project, I almost always have a very specific goal, or at least a theme, in mind. I don't know why I'm this way, but I suspect it has something to do with anxiety over the quality of the final product. Perhaps school, which values planning over tinkering, conditioned me to prefer planning.

But as this week's make showed, it's still possible for a planner to tinker! This week our task was to create a scribbling machine out of batteries, a motor, markers, and recyclable containers as the body. Our first goal was to get the body of our robot to move with the motor. Many of us stuck with that goal and did not incorporate markers. However, since I was familiar with the Maker Shed's Spinbot kit, I wanted to challenge myself to make a robot that could spin and draw in circles with markers. I thought that could make some nice spiral-like patterns. So I did start with a goal, but it was far vaguer than my goals usually are because I wasn't sure how to achieve it. I also continuously  "had a conversation with the materials" (Schon, 1983), getting ideas from the configuration of the materials themselves, especially when I ran into trouble.

I started by wanting to get the motor to spin the body of my robot directly, basically because I know that motors spin, and I don't really know how to get them to move things in any other way. This worked, at first. I cut a hole into the center of the bottom of a plastic pint-sized tub, and stuck the motor on top of it. I had to tinker around with the batteries to find out how many of the 3V coin cells were needed to get the motor to spin fast enough. Two were enough--at first.

When I added three Sharpie markers, though, the device would no longer spin. I tinkered with it some more, by adding a third battery, by taping the markers lower on the tub, by putting the motor inside rather than outside the tub, etc. Nothing worked! It appeared the contraption was too heavy for the motor to spin, even with an additional battery.





First iteration



The materials seemed to be telling me that I needed a lighter body. I tried a plastic cup, but poking a hole in the bottom caused it to crack. So I went downstairs to the little café in the School of Ed and got a paper coffee cup. When I poked a hole in the bottom of it, though, the hole turned out to be too big for the motor's pin to grab onto it. I puzzled over this for awhile. Finally, just as classmates were cleaning up the area at the end of class, I caught sight of a notecard right before someone picked it up to put it away. It really did feel like a flash of insight! The card was lighter than the cup and would be easier to spin. So I carefully hot-glued it to the pin of my motor, then glued the card to the bottom of the cup.

My "light bulb moment:" A notecard as an "intermediary" between the motor and the cup

Second iteration

 

At this point, one of my materials failed me miserably. One of the wires on my motor broke off! I tried to solder it back on, but it just broke further. So I had to find a new motor and re-glue it to the card.

Broken motor wire :(

The new motor worked great, though! Now all that was left was to attach the Sharpies! I found that the blue painter's tape was too weak to hold the Sharpies on while they were spinning around wildly, so I replaced it with duct tape. And now my Scribble-bot was complete!

Ta-da! Final iteration! (I'm holding the batteries up above the frame of the picture)

The materials held one last surprise for me, though. As my Sharpies were sitting uncapped on the cardboard, facing downward as they held up the contraption, they had been gathering little pools of ink. When I held the batteries to the wires (which I must do manually, because the motor needs to be held up by its wires in order for it to spin anything), the result was...well, not so much a scribble as a Jackson Pollock machine! Check out the video below!

I would say that I successfully explored and iterated with the materials in an experimental and open-ended manner, so this planner was totally able to tinker! I gained a lot of insight into how these materials worked, and the affordances and constraints of things like motors, wires, and plastic vs. paper. I even discovered something new about Sharpies! I learned the most when I got stuck. As Wilkinson and Petrich put it, "Failure tells you what you don’t know, frustration is making sense of that failure in the moment, and taking action leads to a new way of knowing." I truly did feel as if my insight about the notecard led me to a "new way of knowing" in which I was starting to understand how a motor could lead to motion of things that are not directly attached to it. Overall, it was a fun experience! I still don't think I'm ever going to be the type to tinker without a reason, though. :)