Snack Discussion

I’ve started my eleventh 4th-grade after school Code Club session. We’ve met three times and things are going well, but I’ve neglected to blog.  I’m using the same club format and the same projects I’ve blogged about before, so there was really not much to write about.  After this week’s session, though, I found I have something to share.

Week 2 project: Maze game by a 4th-grade code club member

Code Club starts right after school – literally, the last bell rings and the students walk from their classroom to the computer lab. We start by circling up the chairs and having a meeting time where I take attendance, talk about what project we are going to do, and have a snack. (Snacks are provided by members who volunteer to bring something to share with everyone.)

Since we can’t eat while coding on the computers (school policy and good rule in general), I use this beginning time to talk about computer science, my coding objective for the day, etc.  This group is a very easy-to-manage and attentive group so I have made an effort to start a snack discussion to fill this time. Their thoughts and ideas are helping me craft the club to fit their needs.

This first day I asked them what their favorite computer/video game was. Their favorite games ranged from themed games like Harry Potter to popular MMO games like battle royale type games.   No real surprise there.

The second week I asked them what types of games or projects they wanted to learn to make. I wrote down their list of ideas.  There weren’t many surprises, but I do have a number of girls who want to make a virtual pet style game, so I’ve added that to the learning projects I will present to them.

This week I asked them what they thought was the hardest part of coding. This was exciting because many of them felt comfortable enough to share their concerns.  I listened and affirmed that all of these were difficult parts.

I have a volunteer, who is a middle school math teacher, and she shared her concern that the hardest part for her was when a student asked for help but only said, “this isn’t working”.  It is true, that it is difficult to figure out what is not working in code at first glance. It would be helpful for the students to explain what they were hoping would happen and what was actually happening in their code.

Some of the other parts they thought difficult were:

1. finding the code blocks they were looking for.  (I have to remember that they are very new to Scratch.)
2. using the costume editor. (Another student gave some tips on this – like switching out of vector mode to draw. I thought it was great that they are helping each other.)
3. coming up with the design of the project they want to make. (I affirmed this was a difficult part. A good design plan makes the rest of the project go smoothly. For some games, the design phase takes 50% of the total time from start to finish.  I also told them that when designing their game, they would fill out a Game Design Document to help them make those design decisions.)
4. finishing the project/ getting the project to match their expectations. (Wow, these are insightful kids.  Yes, I told them that I and the volunteers would help them manage their project.  First by making sure it was a project that could be done and second, by helping make a plan for them to get it done in time.)

The snack discussion has become a favorite part of Code Club for me.  I hope I can come up with more good prompts.  Maybe I’ll ask about getting unstuck next.

I am also enjoying teaching them to code and playing some of their creative projects, too.  Here are a few screenshots.

Week 3 project: Quiz-type Chatbot by 4th-grade Code Club Member

Coding Their Own Way

The students have begun their independent projects for our showcase in May.  They are really into their projects already.  At our last meeting, I met with (most of) the teams or individuals to go over their Game Design Document (GDD).  Over time I’ve been adding things to the GDD to make it more comprehensive but it has gotten a bit unwieldy.  Students don’t always fill it all out or their ideas don’t fit in with the description. I definitely need to reflect on the GDD and figure out what should remain and what can go.

Let’s go back to basics.  Why do I have the GDD?  Is it for the students or for me?

To make a project that takes multiple weeks to complete, but has a hard deadline, you’ll need a plan.  Planning is part of the engineering design process. In this sense, the GDD is for the students.

If you are working in a team, the need for a plan is crucial.  Who will create the backdrops? Who will code the Sprites? Do we agree on the gameplay? A team definitely needs a GDD to define roles, divide the labor, and to communicate ideas.

How do you know if it is a project that can be done in 4 weeks? What parts of the game are you not sure how to code? What should you work on first?  These questions are why the GDD is for me.  I see myself as the project manager for these 10-year-olds.  I want to ensure a project isn’t too large: “There will be 5 levels and a boss level with an army attack and when you die you turn into a zombie with a special power and then….” Yikes. I want to see that team members have communicated their ideas and agreed on the design. I want to make sure each team member has a job to do.  I want to know what parts of the coding will be tricky for them so I can find some examples of code to help them.

All of the projects this time seem pretty well thought out. There are no “try not to laugh” projects.  No Makey-Makey projects either, sadly.  There are a couple of maze games, two games with gravity, one animation, one karate game, and some adventure games.

One or two of the projects aren’t very complicated and I worry that they’ll finish too early.  I shouldn’t, though.  It will be good to have a couple of more polished, well-tested games for the showcase.

This student is going to use this as her independent project and make a “Flappy Bird” type game.

I can’t end without sharing a few screenshots of student work.  The previous week I showed the students how to use the Tips tab to get step-by-step instructions on different games.  I suggested they try the “Make It Fly” tutorial.  This was an optional project and many chose that time to work on their GDD instead.

This shows interesting graphic editing skills and some good coding.

Makes you smile.

Spring Code Club Session Begins

Code Club session #8 met for the first time on Wednesday.  There are eighteen 4th graders and two high school volunteers.  This is the second time I’ve had a mixture of students from both elementary schools in my city in one club.  Another thing that is cool about the Spring session is that I have returning Code Club members, or, as we call them, “experts”.  Only 5 students are new to Code Club and there was only one student I didn’t know.

A New Scratcher’s take on Maze game

After introductions, I asked the “experts” what favorite project they had from the last session of Code Club.  They remembered and liked the Maze game, Space Junk and Chatbot from CodeClubWorld. They also enjoyed the projects they had created themselves, not surprisingly.    I like starting with the Maze game and had already chosen that project for our first meeting.  It’s a simple game with many ways to make it more exciting and complex.

We started out by reviewing the maze design and refreshing our programming vocabulary.  What was the object of the game? How does the Sprite move (arrow keys or follow the mouse were options)?  What happens when you touch the edge of the maze?  How do you win?  Then we talked briefly about ways to make it more exciting – more levels, obstacles, villains, etc.

Then they got to it. They were fairly independent coders, for the most part, and they helped each other a bit, too. My high school volunteers and I think we will be able to try some more complex coding  projects this round.  It was a really fun 75 minutes.

First time Code Club member

“Expert”

Thinking ahead, here are some goals for this session of Code Club:

• Encourage more animation: We have some artists, so I’d like to share with them and encourage more creative uses of costumes for animation effects.

• Explore “more blocks”: someone is already exploring defining their own blocks.  I’d like to encourage more of this.  As well as random numbers.

• Clearing up misconceptions: We will have to revisit some concepts like the forever block and support better debugging habits

Find the glitch in this code.

It seems this “expert” puts everything in forever blocks.

• And finally – I want to use MakeyMakey‘s this time. I told them I want to use them with our projects – especially our final projects. Those couple of students who have played a bit with MakeyMakey’s were quite excited. I’m really excited (and a bit nervous). I don’t have much experience using MakeyMakey devices, with or without students.  Luckily that won’t stop me.

Engineering Design Process

This week I will become the “project manager” for some 30 Scratch projects between my two Code Clubs.  It is Design Review week and the students will meet with me to go over their Game/Project Design Document before beginning to code their own projects to share at our Showcase for parents at the end of the term.

Last time we met I handed out the GDD (Game Design Document) for them to work on and complete before I meet with them for the design review process this week.

I’ve updated the GDD again.  (It is a work in progress).  This time I’ve added the EiE diagram of the Engineering Design Process to the front page and used language to support this process idea within. We use EiE curriculum in school, in our Hypertherm Hope grant supported after school clubs and summer Title I engineering camps. Many students have seen this before.

In the “Ask” phase I explained that they would have an opportunity to make their own Scratch project and opened it up for their many questions.  We also spent some time looking at past 5 Code Club Showcase projects to see what others have done. (I really hope the llamas don’t get remixed again this time around.  They are hilarious the first time you watch, but… well, even the students were tired of them by the end)

I also gave them some time to “Imagine” and sent the “Plan” GDD home with them.  Some were quick to come up with their ideas and completed the GDD before Code Club ended.  There will be some time this week while I meet with the groups to work on their “Plan”.

Once the “Plan” is approved it is time to “Create” then test and “Improve”.

Also new to the GDD is the Team Member Jobs plan. – I am letting them pick a partner of their choice (this is a club, not school) but I’ve found it is often ambiguous who will work on what part.  I’m hoping this part of the GDD will help me help them get work done.

Cute story:  One of my high school volunteers came to me, concerned, with a question about the “working with a partner” option.  A code club member had asked him, the high schooler, to be his partner. So I had to specify to the nine year old, “You can work together with any other code club member, but the high school volunteers will be helping everyone and can’t be your partner.”

Change in Plans

I’ve been thinking about a comment I heard from a student at the Showcase of projects earlier this month.  He was testing his game out before the parents arrived and said, “It isn’t how I imagined it would be, but I like it.”  I think that explains many coding projects. You start with an idea, plan it out but during the coding of it you end up with behaviors you didn’t expect, or you have to make compromises to fit the limitations of the language or your ability to code in that language. You might even like the results better than what you had planned.

I went back and looked at their game design document, and he’s right.  The finished game is not what they (he and his partner) had originally planned.  They did want an adventure game where there would be Sprites to avoid and a “boss” Sprite to defeat.  It was going to be two levels – one in space and one underwater.  There were going to be coins to collect.

In the end, they were able to code one Sprite that you have to avoid – the Cheetos monster and one “boss” Sprite – the Apple guy.  You, the unicorn, has to jump on top of the Apple guy to get points.  They call their project IDK Adventure.   In their presentation they said their favorite part was the Cheetos monster and that if they had more time they would add a different background and add more Cheetos.

It doesn’t look like a lot of code, but it was quite challenging for them.  They spent one Code Club just working out “gravity” where the logic was to only “fall” (change y) when not on “touching” the “gray” moon.   Then to get the points for defeating the Apple guy, you have to jump on the top “touch the brown color” part of the stem.  The Apple guy hides when you touch him, so it is a challenge to win.

They weren’t the only pair to have to settle for something less than they were hoping to complete, but they seemed happy with the project they were able to finish.

Their Game Design Document had them designing a wrestling game where you play against the computer. If you jump on your opponent, you go to the next level. I think they changed their minds about what they wanted from one week to the next, or they weren’t sure if they wanted a 2 player or 1 player game.  In the end, they weren’t able to get the fight behaviors to work the way they wanted. 

While you do get to pick the player you want to be, there’s not a lot of animation of the wrestling match.  There’s a bit of smack talk. In the end their favorite part is the cloning. I don’t know how this became part of their project, but they’re right.  It makes a great addition to Daboomdocbros,  even if it wasn’t planned in the beginning.

These are two examples of projects that did not turn out exactly as originally imagined.  As with many creative processes, the end results doesn’t always match your original idea.  I don’t consider this failure, and I’m glad my students don’t either.  I’m hoping their flexibility in working with the design process will serve them as well as their introduction to coding.

 

 

Game Design Review

Last week game designs were due and with the help of my two parent volunteers, we were able to go through and review each design.  I am very lucky to have great volunteers.  We divided the task between us. My high school student volunteer manned the lab while we separately met with each student or pair to go over their design. We had time to meet with everyone and they all had time to start their projects before the end of Code Club.  Now I’m looking back through the designs once again.

Dodge all the obstacles. Get at least 10 points per level and have fun!!

Some chose partners, some were on their own.  Most had filled out the game design document.  Some were very detailed, others just had rough ideas.

It took a while to think about what the game should do… but after awhile one game popped into my head.

In this student’s game you are a hedgehog that moves around trying to catch bugs to eat.  Here’s how this 4th grade designer describes the game flow.

If you eat a bug that isn’t orange, you will get a point.  If you eat a bug that is orange, the bugs get a point and you will lose a point. To win you have to score more points than the bugs.

I think that is a totally do-able project and I look forward to seeing it progress.

Some had trouble using the drawing editor on Scratch.  I don’t know the best solution.  We could try scanning a drawing in.  I know you can take and add photos and import other artwork.  They might have to learn to live with what they can do.

The game design below looks complicated. I’m a bit concerned because I’m not sure I could code this in Scratch.  We’ll see how well they manage.  I foresee them compromising some of their goals to get something working.

Looks like a lot of creative work and debugging will be taking place at Code Club this week! Awesome way to spend Hour of Code week.