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.

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.

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.

Screen Shot 2018-01-07 at 5.08.50 PM

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.Screen Shot 2018-07-30 at 5.41.08 PM

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.

Advertisements

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.

Screen Shot 2015-03-02 at 10.05.46 PM

Screen Shot 2015-03-02 at 10.07.03 PM

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.

gameplay

Game goals defined in the GDD

technical

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!

Screen Shot 2015-03-02 at 10.31.13 PM

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!!!!!

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.

20141207_201549The 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.

20141207_201434

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

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.