LMS Winter Carnival

Last week I ran two coding sessions at the middle school for their Winter Carnival.  There are a wide variety of activities offered for the 5th- to 8th-grade students during the morning, divided into two 1.5 hours sessions. Options ranged from skiing, dancing, and ping-pong, to cookie decorating, tic-tac-toe, and D&D.  I was invited to offer Scratch coding.

Winter Carnival Project Studio

My activity, Coding/Scratch, had this description: “Students will have the option to create a game, animation or pursue a passion project of their choice using Scratch 3.0 coding environment.”

Despite the unlimited options in the description, I wanted to offer some project guidance as I didn’t know the coding experience of those who would sign up. I decided on three projects from Code Club World that in my experience offer students the greatest creative choice coupled with step-by-step instructions.  The first option was Chatbot.  I’ve discussed how much I like this project before and with the added text-to-speech options in Scratch 3.0, I knew this would be a hit. The second option was a “clicker game” presented with Code Club World’s Ghostbusters project.  The third project was the “side-scrolling platform game” Flappy Parrot from Code Club World.  I feel any of these three projects can be accomplished in 1.5-hours with this age group.

Centaur Chatbot 

In preparation, I went through and created starter versions of these projects. I also set up a Scratch studio for everyone to share their projects. Once the students were logged into Scratch (some had to make their own, new accounts), I invited them to be curators so they could add their projects to our group studio. This part required a bit of administrative time but it is not difficult and works well for everyone to have a single place to go to play each other’s projects. I feel it is important to carve out time to share and showcase what everyone has accomplished, knowing that we all had a limited amount of time and that the projects aren’t perfect or even finished.

Chatty Winter Chatbot example

About ten students signed up for each session but only one girl in each session.  One of the math teachers joined me- she is eager to learn Scratch and we work well together.  I knew more than half of the students and some of them were with me in past Code Clubs. I think the students had a good time. I definitely feel like we supported their ideas and creativity. I’d love to get feedback from them. I shared the project studio with the school administrators and they thanked me for participating.

Chungus Run – a creative Flappy Parrot game – good instructions, too 

Some notes from the sessions:

• Time management is key with short sessions – I posted our schedule – Intro 10min/ Plan 10min/ Code 55min/ Share 15min
• The project guides were helpful even if only to get them started before they went off on coding tangents.
• These students showed creative, flexible thinking. Scratch supported their creativity by making coding flexible to their ideas.
• It is difficult to share something you know is incomplete.  I announced a time check at 15 minutes before we wanted to share, so no one was caught unaware.

Fishie Click game – former 4th grade Code Club member

Coding projects are like art – they are never really “finished” or “perfect”.  They are “done” when you decide to stop working on them. – I said this to someone who was bemoaning the end of the coding time and another student laughed.  She clarified that she was an artist and understood that fact very well.

The Majestic Bird – Well done and so annoying!

 

Workshop Reflections

I’ve been reflecting on my #ScratchMIT2018 conference Saturday workshop.  I had a lot of information and student work to share and I did that. It was a nice size group of educators from around the world. The people who attended were great and some were definitely excited about it.

@scratch @MrsPollardprime #ScratchMIT2018 excited to be at this session! pic.twitter.com/H3hzklX8Pk

— Uloaku Ojiaku (@uloakuojiaku) July 28, 2018

I spent more time talking about my design review process than I expected. When we finally broke into groups, people seemed engaged when they were looking at my students’ work and thinking about how to support them.

#ScratchMIT2018 : Finding your peeps and learning from them, too! #GettingUnstuck @ScratchEdTeam @MrsPollardprime pic.twitter.com/uHUzldIhVx

— Kathleen Fugle (@kathleenfugle) July 29, 2018

This was my first time presenting a workshop at such a big conference and I learned a lot. One thing I could improve is my facilitation of the discussion. I need to prepare better follow-up questions and do less talking.

I made four different packets of student work to share. Different groups looked at different packets which I thought would facilitate more varied conversations but I was the only one who knew all the work and that hindered the whole group discussion.  I should have at least brought up the finished project under discussion on the screen so that the rest of the group could have a frame of reference.

One project that we discussed was Penguin Trivia. It was noted that its design document matches the executed project well.

I could have followed up with what “supports would you put in place for this student?” Since her communication and time management skills seem strong, she could have used more support on game flow code examples and more time testing and debugging. (Although this is always true)

Another example project that was brought up was Thee Annoying’s Return. In this example, we thought the student could improve how he communicated his project.

Someone noted that he says there are no rules, but clearly, there are. So what clarifying questions should we ask during design review so we know he has thought carefully about his game?

The design document serves as a way for students to think deeply about their project before embarking on its creation. The thing with creative adventures is that plans change. That’s okay. The design document is a guide. There were some helpful suggestions about how to refer the student back to the guide during the creating process as a self-check-in. Older students may be able to reflect on their progress and assess the status of their project themselves.

Some other great ideas came up during the discussion.  One was having a peer review in the middle of the process as a way for students to support students.

Another idea was to have a checklist of things that should be in the project.  I’m not sure if this would be a general or project specific checklist, but it would aid in assessment, either way.

One problem we weren’t able to solve was having the time to meet with each student/group when the numbers are large or the time is short. I generally rally some additional help on Design Review Day so I know everyone’s project gets at least a quick approval so they can get started. I do check in with students each week to see where they are, where they are going, where they are stuck, etc.  There are a lot of pieces to project management, but the benefits of letting students pursue these passion projects are huge.

Overall, I am happy with how it went and I’d enjoy running it again.

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!

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.

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.