Create Your Own World

I don’t usually blog in the summer, but I’m running a weekly summer code club at the library in July and I’m being a bit reflective about the monthly one that I helped lead this last year.

Earlier in the year, I introduced a new (to me, too) project to the Lebanon Library Creative Coders. We decided to take two of our monthly meetings, February and March, to work on the Create Your Own World project from Code Club World.  I knew this middle school age group would enjoy creating a platform game. One of them even continued to work on it for a third month and was able to add a lot of detail like hit points, inventory list, and bad guys.

 

Screen Shot 2018-06-29 at 8.05.47 AM

World detailed with inventory, hp, weapon and bad guys.

The first meeting we focused on setting up the player movement.  We remixed Code Club Rik’s Resources for this project so we could jump right in with the coding.  When I was prepping for our meeting, I went ahead and changed the character from a square to an overhead view of a guy walking.  One of my original groups of students created Showcase projects called Tomb of Terror and Shadow Swamp with Hatty McWalker.  That’s who I was thinking of with this guy.

Screen Shot 2018-06-29 at 7.49.15 AM

Overhead view of my player.  I added a costume with the mirror image and a “next costume” block in my code to make him look like he is walking.

The Creative Coders were certainly creative with the movement options.  I’m used to using arrow keys for movement, but these middle schoolers liked ASWD and this creative ghoulish option with side arrows for turning and up for forward:

 

I’m finding it useful to look at the code more closely.  There are some interesting, creative coding going on and I’m seeing some misconceptions that will help me help them debug their code.

Screen Shot 2018-06-29 at 7.27.01 AM

Well coded ASWD movement and wall checking

I’ve seen this forever-forever coding before. Something is not working like they expect and they try to solve it with nested forever loops.

Screen Shot 2018-06-29 at 7.27.37 AM

Nested infinite (practically) loops didn’t fix the problem – switching to the “play sound until done” block did.

Or they are checking for an event and forget to put in the forever loop:

Screen Shot 2018-06-29 at 7.55.25 AM

One time event checking?

This wall checking code has been separated from the key-press event giving no response.

Screen Shot 2018-06-29 at 8.02.31 AM

If touching wall move in all directions at once.

A couple of the coders explored more blocks where you can define your own.  This led to a teaching moment for me to explain how these function blocks worked.  It turned out less useful than my right-click to duplicate code suggestion.

 

 

All in all, they impressed me. In the moment I’m not always sure what is going on with everyone and even at the end when we stop to share what we’ve accomplished I don’t always know how they did.

Some of them didn’t want to continue what they had started the month before, but they were self-motivated and independent enough to work on their own projects.

I love that this crew is supportive of each other and willing to share their ideas and compliments.

Screen Shot 2018-06-29 at 7.23.54 AM

I appreciate good, supportive commenting

Some of the same students have signed up for the summer session. I’m looking forward to it.

Advertisements

My Own “Programming in Scratch” Challenge

Last week was Design Review Day for my code club. In one week’s time the students were able to come up with an original idea for a game, design it, plan its creation and pitch it.  Amazing!  This time I manned the lab while Alex, my high school volunteer and a parent volunteer conferenced with each group.  Both volunteers were pleased with the pitches in general. I admit that I haven’t had a chance to review any of the completed game design documents myself.

Instead I’ve been busy working through a Scratch language MOOC on edX, from my alma mater, called: HarveyMuddX: CS002x Programming in Scratch. I’ve been excited about taking this online class since I first learned of it and started following the course professor Colleen Lewis on Twitter and at CSTeachingTips.org. The course has a nice balance of video lecture, directed “play” in Scratch and rigorous quizzes. The class has helped fill in gaps in my knowledge of Scratch. For one thing, I hadn’t played around much with the Sound blocks in Scratch, so that was a fun week.

I also learned about race conditions, which I hadn’t heard of before.  A race condition is where two things are competing to set a variable or perform two operations at the same time and you cannot be sure of what the outcome will be.  For example, below I’ve set the score to two different values when the green flag is clicked.  Which will Scratch choose?  -whichever setting wins the race.

race condition

An example of a race condition

I had fun making some little drawing projectsScreen Shot 2015-03-10 at 8.27.51 PM and a helicopter game.

Screen Shot 2015-03-10 at 8.16.57 PMNow I have to design a final project. And I have been directed to think about it first…

Rather than just diving into a project, we want you to start thinking about different ideas for things what you might do.

Hmm.. that’s like what I asked my students to do.  The tables have turned and I’m not sure how they did it, now.  I’ve been toying with a couple of different ideas for awhile now and I’m still not sure what I want to tackle.  I’m going to have to make a decision soon and get to work.

This is my favorite question in the final project design phase of this MOOC:

Think about breaking your project into a series of simpler steps. What are the FIRST three things that you would make work?

I wish I had put some wording like that in my game design document for my students.  At any rate, I will remember to ask my students how they will break up their tasks as they continue work on their projects tomorrow.

Rookie Mistakes

After a merited, welcomed, two-week break, we have Code Club again tomorrow.  It’s our next to the last meeting and I’m concerned. I don’t think their “create your own game” projects are ready for the showcase – I don’t think they are one hour away from being ready. There’s a lot of work to do, errors to be found, logic to be thought through, and no rigorous testing has been done. (Do I sound like a software manager a week before a new release deadline?)

I had planned to approach each of the 4th grade coders during school over the last two days and find out how they thought their project was coming along.  I talked to two (out of 23) and they didn’t seem concerned.  I actually think they were confused about what I was asking as if the two-week winter break had wiped out all thoughts about Code Club.  So maybe I’m the only one who’s nervous about this. This is my rookie season as a Code Club leader, I must remember.  Maybe everything will get done on time?

Yeah, right.  Here’s the thing.  I recall the last Code Club meeting as being less than productive.  I believe others also found it frustrating. Besides the fact that it was the week before Christmas and two days before vacation, things didn’t go as well as I’d hoped. Students were stuck, teams weren’t working well together, projects were behaving strangely, stuff was lost, etc. That kind of stuff happens. I expect some of that, I’m not a complete rookie.

What bothers me most is not every student was able to get some help. On the whiteboard, next to the list for using the microphone, a student started a list for those who needed help and added their name.  I didn’t even notice the list until the end. It’s a good idea, really, and we’ll start a list like that tomorrow.  Not really sure what to think, but I feel that I’m letting them down. The list was an interesting expression of frustration. On one hand I expect them to need some help as they are just beginner Scratchers, but perhaps am I helping too much or unevenly. Maybe I haven’t provided enough foundation to give them the confidence to persevere in troubleshooting? Or the projects were too complicated and it was a failure in the design review process. More things to learn.

Truth is, I don’t have that much more experience using Scratch than they do. Problems and questions have come up that I didn’t have the answer to.  For example, a couple of students wanted to add gravity into their game.  Turns out there are lots of ways to simulate this, even more than those listed on the Scratch Wiki for Simulating Gravity (I didn’t even know about the Scratch Wiki until researching the gravity problem).  One team is using a timer to simulate gravity.  Another is using simple direct movement method.

Screen Shot 2015-01-06 at 10.48.50 PM

I’m sure more stuff like this will crop up tomorrow. Of course, I need to remember – rookie season, rookie mistakes.

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.