Maze Race Game

Last week’s Code Club took a lot of planning and preparation.  I’m going to write about it in 2 parts. Here’s part 1.

I introduced one last project for Code Club on Wednesday.  I wanted them to learn that Sprites can sense what they are touching, like a color, or the stage’s edge, or another Sprite. Collision detection is a fairly basic element in many computer games and not trivial to code for in many programming languages, in my opinion. Scratch makes it fairly intuitive. I found three different instructional resources that teach the creation of a maze or race game in Scratch.

Code Club World has a Boat Race project in beta form. It is so new, in fact, that when I went looking for a project of this type, it was only available from Code Club (for UK clubs only).  Looks like a fun project and I want to try it next time.

In Jeremy Scott’s “Starting from Scratch” guide, there’s a maze game that introduces collision detection. I like this resource from the Royal Society of Edinburgh.  It explains basic computer science concepts and ideas that the students will be exposed to using Scratch. That helps me use the correct terminology and know the “why” do I teach this behind the “how” do I teach this. The maze game instructions looked easy to follow to me, but it wasn’t in the Code Club format that the students had grown used to.

Maze game -use the arrow keys to reach the dragon. Don’t touch the sides.

I also came across Simon Haughton’s website and in his second Scratch lesson he has a car racing game. The goal is to cross the finish line without driving off the track.  Driving off the track sends you back to the beginning. I like how he has the students make their own race track in 3 simple steps: Flood the stage with color,  draw or erase the “track”, and draw a finish line in a different color.

My take on Race Game

I used his instructions first with a group of 4th grade students who have been learning a bit about Scratch during school.  We didn’t have time to do any extensions, like adding a timer, enemies or sounds, but a couple of students added a “crashed” costume to their car. Turns out if the new costume is bigger or a different shape than your original, you may be touching the edge of the track even when sent back to the start.  Another student was starting to add an oil slick, like my water hazard, before we ran out of time.

Unsure of how much coding time we’d have in Code Club this week, because we had a guest speaker coming talk about software development, I decided to started with Jeremy Scott’s Maze game instructions. We used the maze gif resource for the stage but I let them choose any two sprites for explorer and target. One student spent the whole time editing the sprite to his satisfaction -a graphic designer in the making, perhaps?  Next we set up the arrow key controls on the explorer sprite and added collision and target detection.   By the end of Code Club some were able to start a second level of their own design.

Second level student example

Second level, student example

The jump to using different sources for instruction was hardest on my volunteers.  Our speaker stayed to assist and I had my high school student there as well. I had experience fielding questions with this after my 4th grade class earlier that day, but my volunteers were grasping the concepts at the same time as the students. Also the handouts weren’t as readable as they could’ve been. After a rough start, things settled down and the students seemed pretty independent.  Hey, I think that’s success right there.

What about that guest speaker, you ask?  That’ll be part 2.

Oo-Ah-Animation

The Scratch project we tackled last week was not a game but a straight-forward animation project. We tried the Fireworks project from Code Club World resources.  Not all of my Code Club students will want to make a game for the final independent project.  Some may want to do interactive storytelling with animations instead.  One of my goals is to expose them to some of the different types of things you can make with Scratch so when it comes time to design their own project they can say, “oh, yeah, we did something like that.” Or, at least, I can say, “Remember when we did such-and-such.  That sounds a lot like what you want to do.”

My parent volunteer introduced the project, talked a bit about animation, and gave them the choice to design their own rocket sprite and many of them did. I know I want them designing their own stuff, but give them an option or two and they’ll run with it. Have I mentioned that they are a creative bunch? They are little testing testers, too, and have no qualms about setting speed to a very large number or having a screen full of sprites.  Kudos for Scratch for not crashing in these cases.  Just goes to show that Scratch was built for and tested by kids.

How students test code.

The only misunderstanding I came across with this project was with the iterative approach to code building.  The directions had you start with a simple bit of code and then you built on it, testing as you went.  For example, the rocket starts with the simple scripts on the right (in the picture below) then you add the loop and conditional to improve the behavior and end up with the script on the right. I noticed a few of students who had all the different stages of the script in with their sprite and it was interfering with the expected behavior.

The script on the left side is improved to become the script on the right

We only have time to try one more project before they start designing their own and there are a couple – maybe three – different projects I want to introduce. Now I have to decide.

Everyone is Doing It

About a half dozen years ago my school district went through a “consolidation” where some schools closed and a new school was built. The result was that my school’s population got younger. I went from teaching graphing with Excel to fifth graders to mouse skills to Kindergarteners.

Click on the star side

But gee, those Kindergarteners are so cute and so effervescent.  What a blast to find little online activities for them to try.  We love StarFall.com and ABCya.com and ToyTheatre.com and the list goes on.  BBC & PBS Kids and well as some textbook publishing companies all have interactive games on the web for free.  There are even more resources if you have monies to pay for a subscription or don’t mind setting up accounts for your students.

During that first year, I searched long and persistently to find free, appropriate, educational, curriculum related web-activities for my younger students to use during their computer lab time. My success varied. What I did come across was a number of little learning games, simple enough in their construction that, I thought, perhaps, even I could make a game like that.  That became a motivator for me, something I could challenge myself with. So when I was unable to find online resource on a specific topic I envisioned or for different parts of our curriculum, I imagined I could just write my own.  It seemed everyone was doing it.

I was also inspired by ABCya.com story.  Here was another person, like me, looking for good resources on the web and when he couldn’t find much, started making the resources himself. The ABCya! site has grown into a great resource and achieved many accolades.  Their stuff just keeps getting better and better with each iteration.

While what I’ve been able to do can’t compete with the likes of ABCya!, I did start making my own games.  You can find them at MrsPollardsGames.com.  My original plan was to learn how to make games, then teach some older students (like high school kids) to make resources for the younger kids.  We would use the little ones ideas and artwork and the older ones ability/desire to code (and I would facilitate the collaboration).  Sounded like fun and learning all around.  (And I naively thought I could just do it.)

As it turns out, it’s more complicated than I thought to make even the simplest of games. When I started with this idea a lot of the resources that I found online were FLASH games and the .swf file extension of these assets were made with Adobe ActionScript.  So I decided to learn it.  My daughter drew the pictures for me and I wrote my first game in 2010 – the Farm Game.

Count the farm animals FLASH game

I can only make one or two games in a year. As much as I enjoy the process and the sense of accomplishment in producing a new game, it just takes so much time and energy. It really challenges my ability to think like a programmer: break down the game into logical steps, specify the outcomes, plan game play, set up the objects, think about the outcomes, animate, test, debug.  I can credit part of my success in this endeavor to the software engineer who is my spouse.  He doesn’t like Adobe’s FLASH environment, but he helps me with ActionScript, the object-oriented programming (OOP) side. He’s great at making me think through all the logical steps and suggesting what I should test to figure out why things aren’t doing what they are supposed to.  Books help, too.  I’ve amassed a few ActionScript animation and game building guides.  I took a Java course online to learn more about that type of programming (a MOOC on OOP).  I suppose if I created more games and spent more time at it, I’d get better at it.  I just don’t think I can teach it to anyone else. I need too much help with it myself.

And the web is changing.  It’s not enough to have a little game on a web-site.  It has to be mobile ready, use rich, dynamic web-design, etc, created by acronyms like JSON, HTML5 & CSS, AJAX, etc.  I won’t be able to keep up.

But it’s okay, because I’ve got a new challenge now with Scratch.  It’s a different vision than the one I started with, but I am teaching kids to code and it is a blast.

We didn’t have Code Club last week, but we do tomorrow.  And it’s all about animation…. Stay tuned.