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.

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.”

A New Plan

(I know, 3 blogs in one week.  Bear with me. This one is short)

I spent some time over the weekend hashing out the project plan and learning objectives for my two code clubs.  I feel better with a plan and ideas in mind and on paper.

I also revised my expectations for last week.  My learning objective for the students last week was to get to know Scratch and the code blocks that include Events, Motion, Looks and Sound.  I have to remember there’s also a new costume editor they will have to get a feel for as well as the notion of the Stage and Sprites and how they are different.  That’s actually a lot. I think the majority of the students have got a grasp on some of those concepts. (If they haven’t forgotten them in the meantime)

One student came up to me today and said, “I wish Code Club was everyday!!” What an awesome sentiment.

This week I’d like to focus on Initial Conditions, Conditionals and Sensing blocks. To that end, I’ve updated the maze project to use for Scratch 2.0. And we will try it out tomorrow.

Scratch 2 Maze Project – Google Docs

I wonder if I’ll have time to mention the “Think like a Programmer” ideas of make one change, test it, make another change, test it?

Then next week both clubs can work on the same project.

Game Design Challenge Accepted

Last week in Code Club students began the design phase of their individual Scratch project. I planned the session to go the same as Key Steps in Game Design did: guest speaker, game design document, short Scratch project. Things didn’t go quite the way I planned…

Guest Speaker: We had the same parent volunteer come and give the same talk about planning & time management. I was worried the ones who had heard it before wouldn’t pay attention, but each returning Code Club member has experienced the pain of running out of time and dealing with unfinished, buggy projects. So they listened.

Game Design Document:  GDD Spring2015 This is the document where the students write out the plans and goals for their project, draw out their ideas for Sprites & Stages, define game flow & control elements, and set a schedule for achieving their goal.

Game goals defined in the GDD

Example of the Sprite and Stage design from the GDD of a new coder

Scratch Project: When I had finished going over the GDD, instead of wanting to work on a Code Club project, they all started to work on their game design and got down to planning. No one was interested in a project handout.  They had their own project to think about and that could not wait.  I was most impressed.

It is helpful, for me and the coders, to have been through this process once before. What made the difference, I think, from last time, is that this time I had examples of how a GDD turns into a completed project. I showed them a couple of different GDDs from the Fall -actual student work-  and then brought up the game it turned into from our Showcase#1 -more actual student work.

One student finished the GDD, with a bit of help from me, and had time to start working on the Sprites. Already!

Sprite designs for new project

Two separate groups of three asked if they could work together.  My rule is these are individual or pair projects.  I turned one group down because I know them and one student would be doing all the work while the other two would have all the ideas. I have given a qualified ‘okay’ to the other trio on the condition that the jobs of each member are specified in the game document and divided evenly. I know them as well, and they might be able to manage. It is always interesting to watch team dynamics with students.  Another duo started out together but by the end of the hour had already decided to work independently.  Best to figure that out in the beginning.

By the end of Code Club I had a few finished GDDs ready for the design review this week. Some look pretty interesting and of reasonable scope. I’m not as nervous about their projects as last time.  The students have had less time to plan, but I’ve seen some of the planning they’ve done and I know what they are capable of.  I can’t wait to see what they’ve come up with!

Key Steps in Game Design

For the next four weeks of Code Club the students are going to make their own game in Scratch. This is the reason they joined.  This is what they’ve been telling me they want to do. I could just let them go at it but I want to help them be successful so I’m making them follow some guidelines.  In fact, I’m having them create a detailed plan, put their ideas down in a GDD (Game Design Document), and pitch it to me or another adult volunteer before they start coding.

Last time we met I handed out this Scratch_ Game Design Document – Google Docs  GDD template. I created it after looking at a number of sources from the video game industry and from some online teaching projects. It’s a revised, more detailed version of one I used last year with my 4th grade math group when they made Scratch Math Games.  Code Club members have the choice of working with a partner or by themselves.  The game planning was their homework. It is due tomorrow.

I also sent home Code Club World’s Create Your Own Game Project idea packet for some basic directions.

The last time Code Club met, we had a special guest speaker. She is a parent volunteer who manages a team of software developers and she came and gave a nice presentation on key software development steps: Planning, Testing and Time Management. For a fairly dry topic, the students were respectful and attentive, which I greatly appreciated.

Software design steps outlined

Here are some of the great points she touched on:

• Make a plan – think about the steps it takes and how long to do each step
• What if I want to add a really cool thing that was not in the plan? Make your plan flexible
• Sometimes you have to move on even if something is not perfect
• Test and test again – test often, get other people to test

These are real world ideas from, well, the real world.  They seemed to take the presentation seriously and I hope that means they’ll do a good job on their pitch tomorrow. I’m excited to see what they’ve come up with and a little nervous, too.