# Homeschool Math with Scratch

Created on August 23rd, 2014. Built on the MacBook Air.

Devon hasn’t been as interested in Scratch lately, so we haven’t been building any new games. He did, however, just start kindergarten. We’re homeschooling, and I figured since he has to learn his math anyway maybe we could create a game for him. He wasn’t very interested in building it at first, so I told him I would do it and as soon as I started building it, he jumped right in and wanted to help type out the variable names.

I started with a google image search and imported the image to create a sprite of numbers:

The first version of the game was kind of silly in that I made a sprite out of each number and each sprite stored its own value. As with most programming, I generally try to get a working prototype first and then go back in and refactor it once I’ve proven the concept. The final version of this game comes complete with a displayed answer and much less complexity and duplicated code.

Once I changed things up, it was helpful to export the costumes as individual images (which I used the editor to obtain):

Here are the sprites for the left hand number, right hand number, 10’s place answer, and 1’s place answer:

Each sprite contained all of the numbers as costumes, named accordingly so we could access them via code:

Here’s the main stage code using variables for left, right, and answer:

The code for the left and the right is pretty straight forward, the only different being the variable we use to display the costume (either left or right):

Displaying the answer gets a little more tricky. You have to think about the one’s place and the ten’s place differently. I coded it this way in case I want to add more complex answers in the future beyond 18 (that’s the highest number you can currently get out of this):

The mod function wasn’t working as I thought it would, so I had to put in some test variables and display them on the screen to figure out what was going on. As with all programming, it’s really important to view the data and not make assumptions.

It would be easy enough to add other math functions to this such as subtraction and multiplication. You could add a menu and then just change out the functions used and the stage costume which currently shows addition.

This was a fun way to spend a bit of time on Saturday. I hope it gets you thinking about creative ways you can build tools to help educate your kids.

Here’s a demo:

Here’s the full Scratch file: Counting Refactored

# Helicopter Fighter Game

Created on July 13th, 2014. Built on the MacBook Air.

I have some games on my iPhone Devon loves to play. One of them is called Heli Hell:

Devon had the idea of building a version of this game in Scratch. It sounded like a fun challenge. Devon really likes this one and has some further ideas for it including building out what he calls a giant spike ball coming out from the helicopter which another player can control to attack the bad guys. I haven’t quite figured out how we’ll make that work, but for now wanted to show the progress we’ve already made.

I haven’t yet added a fancy start or game over screen, so the stage code is pretty simple:

For the helicopter, I used the same trick we learned last time when building the helicopter fire fighter game. You simply rotate through two costumes which makes it look like the helicopter blades are spinning:

And here’s the code:

The sprites used for the game, including some islands to give the impression the helicopter is flying forward:

The bad guy code is pretty interesting. It follows a pattern of moving left to right and back again until it reaches the bottom of the screen. It’s also in a loop so when its done, it will announce another ship to appear. The ship appears after a random interval and it fires its weapon between 2 and 7 seconds later (a number we had to adjust as the game started out being too difficult for Devon).

And here’s the bad guy weapon:

The helicopter can shoot back with its own bullets. They both follow a similar pattern:

If the bad guy’s lives run out, it releases three coins which each increase the player’s score when they are collected:

To create the illusion of flying forward, these islands all have similar code with the only difference being the names of the announced events.

We could add a lot more to this game and fancy it up a bit as well, but for now it works and Devon has a lot of fun playing it. The “spike ball” may come later. ðŸ™‚

# Hidden Objects Game

Created July 4th, 2014. Built on the MacBook Air.

Have you ever played any of those silly hidden object, point and click flash games? The idea is pretty simple… you hunt around and click on stuff to find clues and solve problems to get further along in the game. I was curious how hard they would be to build in Scratch. I was also curious if Devon would enjoy playing them. Devon didn’t build this one with me, I was mainly playing around to see how difficult it would be to make.

This 4th of July, I was recovering from a stomach bug from the day before. When Corinne took the kids out to play, I rested on the couch and started tinkering with Scratch. Seeing the included backgrounds got me thinking of the hidden object games I had played with years ago. I wanted to see if Devon would be interested in building similar games in the future. I figured the development of a game like this would be pretty boring compared to the other games we already built together, and I wasn’t really sure what I was doing, so I wanted to try it on my own first. After completing it, I was really surprised how much he enjoyed playing it! I’m adding it to the website here just in case it’s helpful for others building Scratch games as well. The code is pretty rough as it was mainly a proof of concept, and I did run into some strange issues getting the mouse clicks in the right places figured out, but that may have just been my post-sickness brain not firing on all cylinders.

The stage code and backgrounds which are the “rooms” for the game:

When you enter the first room, you see a chalkboard where you click to reveal a code which is randomly picked from a list of four codes.

Here’s the code and costumes behind the sprite involved.

You get to the next room by clicking the right part of the screen where you need the secret code to move on.

Here’s the code behind the key sprite.

The final room with the red door has the key following the mouse as you move it.

Here are all the sprites used for this game.

Â Â

As mentioned, Devon didn’t help me build this one. It was mainly just me tinkering away but since he enjoys playing it so much, I figured we should put it up on the site. Maybe we’ll revisit the hidden object game idea in the future and create something better.

Created on June 27th, 2014. Built on the MacBook Air (so it currently plays really slowly on the Raspberry Pi).

This was our biggest challenge yet. Can we recreate the classic Space Invaders game? Unlike the other games, we built this one directly on my laptop. Â Devon was sitting on my lap, typing out variable names one character at a time (God give me patience!).

He kept wanting to be able to control the alien ship, but I explained to him how the game works and how the aliens will come down and we’ll have to fight them off. He really wanted it to be two player though so he convinced me to add another space ship. I’m glad he did! We’ve had so much fun playing this gameÂ collaboratively so even if one of us dies, the other can keep going. I never would have thought of doing that. ðŸ™‚

I added some extra touches and styled out the sprites a bit more when he was asleep. I had a lot of fun building this one.

This one has a lot of complexity and when we moved it to Devon’s Raspberry Pi, it barely ran… so it probably needs some rework there.

Here’s the stage code.

We again created multiple costumes for various stages of the game.

We have a lot of sprites, but started with just one alien and one ship and then later added the others.

The ship code is pretty straightforward for handling movement and if the game is over or not.

Each ship also has a rocket they can fire. It starts from the location of the ship and moves upward until it hits an alien or the edge of the screen. We used purple there because Aria, my 3 year old, insisted on it.

It’s funny how we find and fix various bugs. When we first started, even ships which had been blown up and were not currently visible could still fire missiles. We added a check against the number of lives left for the ship before firing.

We set it up to have three lives per ship, but displaying the variable on the page got in the way so we created an indicator to show how many lives the ship has left.

If a ship gets hit by an alien shot, we display a little fire indicator.

Speaking of aliens, lets dive right in to the code there.

We created a fun little cycle where the aliens move right, down, left and down again. We keep track of he current direction the aliens are moving and adjust things as needed. We also use broadcast messages to let the system know which missiles hit. For a fun twist, we change the color each time an alien ship is hit until they reach the “alien hits before exploding” variable. If the alien reaches the bottom of the screen or touches one of the ships, the game is over.

The alien bullets are interesting as well because of the random delay we added. We found a need for a second if check because even if the alien ship was no longer visible, they could fire seconds later.

As mentioned above, the current version of this game runs really slow on the Raspberry Pi. The best place for improvement is probably in the alien code. Instead of each one keeping track of movements, we could link them together a bit. We might also want to change the glide method to a simple movement per cycle.

Thanks for joining our fun! If you learned something, feel free to contribute to Devon’s bitcoin fund.

After finishing this post, Corinne reminded me of this video she took while we were building Space Invaders. This is a typical glimpse into what our time together building games looks like.

While growing up, I watched my dad program and I know some of this is sinking in. If he continues to enjoy building games, hopefully some day he’ll be building them on his own.

# Devon’s First Bitcoin Purchase!

Devon and I just used his bitcoin donations to purchase his first and very own swiss army pocket knife! He’s been practicing how to safely use a pocket knife using one of mine, and we both thought he was ready to own his own knife. Here’s the knife we bought:

Of course, we paid for it in bitcoin thanks to Overstock.com!

I’m so glad the fun and effort we’ve put into building these games is now going to relate to something tangible Devon can hold in his hand.

UPDATE 7/17/2014: Unfortunately, we just found out Overstock was actually a bit under stocked. I was concerned when we never got a shipping confirmation email and Devon has been bugging me non-stop about when his knife will arrive. They just emailed us to say an error in their inventory system caused the site to show more knives than they really had. Devon is pretty bummed, but they did give us a \$5 credit and refunded the bitcoin to my Coinbase account which I immediately transferred back to Devon’s wallet.

Tonight we’re camping out in the backyard and we just ordered another knife (this one has a flashlight!) using my mobile phone and the blockchain.info app. I was surprised to see the mobile version of Overstock.com doesn’t support bitcoin payments. I had to use the link at the bottom of the page to go to the desktop version.

Anyway, here’s the new knife Devon got:

# Brick Breaker Game

Created June 22nd, 2014. Built on the Raspberry Pi.

I remember playing brick breaker type games when I was a kid and wanted to give Devon the same experience. As I started building this game, I realized how many cool features we could add later such as special bricks and power boosts. We started with what we learned from building Pong previously.

Devon didn’t really get what I was trying to do on this one so he kept trying to take things a different direction. I eventually had to work on it myself a bit because I was really getting stumped on getting the angles right when the ball hits a brick or bounces off the paddle. Eventually I got it working and he enjoyed playing it, but he hasn’t shown enough interest to add more features yet.

First we have the stage code which handles showing the correct costume and configuring global variables.

These are the sprites in use. Notice how each brick is its own sprite.

The paddle code is super simple as we keep the complex logic in the ball (taking queues from the Pong Game we already created).

The brick code is also pretty simple for keeping track of the score and hiding the brick if it gets hit.

And now for the details of the ball code. It took a lot of trial and error to figure out how to handle the angles correctly for sending the ball back away from the bricks or up from the paddle. Devon and I wrote some triangles on paper and played around with different options. Once we had the equations figured out (Bricks: 180 – abs(direction), then put the direction back in, either positive or negative), Devon excitedly read them back to me as I plugged in the code.

Just like the pong game, we used the super helpful “if on edge, bounce” command to handle the walls and the ceiling.

We did some fun stuff with the paddle edges, each having a different color. If hitting the edge, we randomly change the angle by +-10 degrees. In addition, if you hit the right side of the paddle while traveling left, it will bounce the ball back to the right again (same thing for the other side).

Another little gotcha we ran into is if you trigger a hit, you need to force the ball to move away so it doesn’t trigger again and head back the direction it came (that’s what the move speed*2 steps call is for).

# Pong Game

Created June 21st, 2014. BuiltÂ on the Raspberry Pi.

The all time classic video game. We had to build it.

One of the tricks I’ve found useful in Scratch is to put a sliver of a specific color in the stage background so you can later trigger something when your sprite is touching that color. In this case, we have a different color for right and left side of the stage so we can keep track of the player’s scores. We also found the “if on edge, bounce” command very helpful.

Here are the sprites involved.

For the players, we created a slightly different color on the edges of the paddle so we could randomly change the angle in use. More on that later.

Here’s the stage code which keeps track of a timer and speeds up the ball to increase the difficulty as the game goes on. For this game, we also added a space bar to start the game and various stage costumes for when the game first starts and when it’s over.

The player paddle has edges with slightly different colors so we can do some interesting things when the ball hits them. That logic is stored in the ball as the paddle code is pretty straightforward.

Note: You’ll need to adjust this code for each player.

The ball code is where the meat of the logic lives. It checks to see if the ball hit the edge of the screen to score the correct player. We also change things up just slightly by adding a random value to the angle the ball leaves the paddle. If the ball hits the edge, we increase that randomness for more fun. Another thing worth noting is how many variables we use (instead of magic values directly in the code) so we can easily fine tune and tweak the game to get the play we like.

Controls:
Space bar to start.
Player 1: W, SÂ for upÂ andÂ down.
Player 2:Â Arrow keys for up and down.

# The Bone Digger Game

Created June 16th, 2014. Built on the Raspberry Pi.

We had a lot of fun with this one. When I was a kid, I remember my dad purchasing probably 80 different 5Â¼ inch floppy disk computer games (yes, the old ones which were actually floppy) at fractions of a dollar for each game. Many of them didn’t work because of the increase in computer speeds (they were CPU cycle based and were now too fast to play) and they all had these distinctive yellow and black striped sleeves the disks would come in.

One of those games stuck out in my memory as a game you had to dig around in. Devon had just been talking about dinosaur bones and his Minecraft pickaxe so I figured we’d make a couple pickaxe-wielding characters who would dig up dinosaur bones to score points. While working on this game, Devon also discovered you could import some sprites which come from ScratchÂ so we had to include the dragon. As for the colors of the diggers, those are the colors Devon wanted. I know. I tried to change his might but that’s what he wanted.

First the stage code:

I’m not sure why I had two different forever’s in there, but it seems to work okay. One speeds the game up over time.

The diggers are pretty straight forward.

The bone code could probably be cleaned up (especially since it had to be duplicated for each bone), but it gets the job done. It keeps track of which sprite it might be touching and adjusts accordingly.

I had fun doing animations on the bones going through different costumes. The rotate button in the editor was helpful here.

The dragon was a fun thing we added after we had the basic game working:

As with the diggers, I adjusted the costumes of the dragon based on which direction it is heading:

Here’s the Scratch file for Bone Digger Game for you to play with.

# Missile Attack Game

Created June 15th, 2014. Built on the Raspberry Pi.

This game isÂ by far the most challenging we’ve built yet. We actually had to use some trigonometry! I felt like an idiot drawing triangles on paper to figure out if it was the sin, cosine, or tangent I needed… or the inverse of them. Â (Remember SohCahToa?)

Turns out we needed theÂ arctangent to figure out which angle to send the missiles once we selected a random end point. Here’s the code:

I used a lot of broadcast signals in this game, primarily because I didn’t realize you could dig into variables of other sprites so I thought you had to broadcast information between them.

Before I get too far ahead of myself, here’s the code for the stage:

We set up the game so you start with only one missile coming down. Once you get to ten points, a second missile and a second defense system appears so you can fire off two defense shots at the same time. Adding in some random values here and there (like waiting between 1 and 3 seconds per shot) makes things fun. If you notice, for the missile code above, we also used a random speed for each missile shot.

Also, I started using different costumes on the stage for doing things like a game over screen.

The house code is pretty straight forward. I apologize for the color of the houses. That’s what Devon wanted and I couldn’t talk him out of it.

The defense guns are simple but I wanted to end the game if they got hit since you’d have no way to keep shooting. Later when we added a second defense gun, I realized that’s not exactly the case, but yeah… details.

I had fun with the defense shots also as they grow in size like an explosion when they reach their destination point.

Keep in mind, I’m only showing the code for one version of the sprites above, but you have to write click and duplicate them as needed, along with modifying the code and creating individual variables and broadcast messages.

When fixing a bug or adding a feature which other sprites also need, I find it really helpful to take the whole code block and just drag it over to the other sprite. It automatically creates a duplicate block for you.

This was a challenging game to build but it’s a whole lot of fun to play. It’s amazing to remember these games from my childhood and then rebuild them starting with just a blank slate. Super fun. ðŸ™‚

If you want to try it out, here’s the Scratch file for the Missile Attack Game.

Do you remember playing this game as a kid?

# Firefighter Helicopter Game

Created June 14th, 2014. Built on the Raspberry Pi.

We had a lot of fun building this one. Devon wanted a helicopter game, and I was interested in creating the animation effect of the rotor blades. He then started talking about firefighters and such and I figured we could combine the two and make a firefighter helicopter! Brilliant!

I’ll be showing the final code here, but most of the fun in building these games is starting with something simple and then adding bug fixes and features as you go. When I just started with Scratch, seeing a command stack this long would have freaked me out:

As I’ve built more games, I’ve realized how helpful it is to have a variable like “flying” or “playing” to control the whole loop. I’ve also tried to remove “magic” values by storing them in variables so they can easily be adjusted later.

I put those variables in the stage code like so:

This game has the helicopter always moving and the arrow just changes the direction and the costume. The changing costumes also creates the animation effect of the rotors. Devon and I discussed various ideas and he liked having to refuel so we created a refueling station.

The ways you can lose the game is to run out of fuel or to crash into the ground. You gain points by putting out fires with your water. It’s fun to use the “touching X” sensor to figure out if you’re touching a specific color or sprite. The background design of the stage can be helpful for creating specific colors and features you want your characters to respond to.

Next we’ll look at the fire:

For this I created a list of x and y coordinates for the places I want the fire to show up. We then pick a random number and use that entry in the list to display the fire.

And the water:

We start with location of the helicopter, drop the pen and let it flow! If it hits the ground or hits the fire, we hide it.

That’s basically it! Want to try it out? Here’s the Scratch file: Helicopter Game

Things we could improve: I noticed there’s little incentive to fly higher. It’s easier to put out the fires when you’re low to the ground. I was thinking we could make the water run out and require the helicopter to go up into the clouds to collect more water. Might be a fun addition.

What do you think?