CodeClub: TWSU DIY Gamer Week 10

Nearly everyone was starting the lesson 8 worksheet this week (one superstar is already on lesson 9).  This is really the first session of the final project - building the Simon Says game - and this seemed to be good news for the clubbers as the last couple of weeks have felt a little unconnected and disjointed, There were a few questions about why we'd bothered with the spaceship animation last week and whether this fitted into the final game, but I explained that the idea was that they could use moving images to customise the opening sequence of their game.

The basic premise of this session is to design variations for the various screen images used in the game: left, right, up and down arrows, a tick, a cross and the word go. I must admit I was slightly dubious about this session. Although one thing that I think has been missing from this whole project is the flexibility for the children to customise what they're doing, this seemed like a another distraction with the originality being more about design than coding. I was also sceptical because it seemed to me that there only a few ways to make an arrow on an 8x8 grid different.

As usual, the children demonstrated the power of their imaginations and creativity (and, I guess, the feebleness of my own).

Minecraft axes, smilie faces, stick figures.... just brilliant!

Things to do differently next time?

If I'm honest, I'd completely chuck away the worksheets and either write my own or just try to introduce what they have to do through a demonstration.  It took me a couple of read-throughs to work out exactly what you were being asked to do, so I expected the children to struggle.  The over-achiever who completed this part of the project last week had run into problems so I knew what to expect.   There are a number of areas where I think this session's worksheet could really be improved.

A big problem is that the first 4 pages are basically just information for the children to read.  A couple of the children were asking what they were supposed to do and my only answer was basically  "just read it". That's not so bad, but then the actual practical instructions that follow are quite confusing. 

First of all, there are two many small but important steps that are easily missed out.  Part of this problem is that the children just don't take the time to read them carefully. So crucial steps - like closing the file you've just opened and then opening another one (with a similar name) need to really stand out and be made clear.

Secondly, the description of how to modify the code shows two array blocks side-by-side in a sketch window. So naturally,  a couple of the children tried to type up their sketch to make it look just like that, not really comprehending what the red arrow meant. 

Thirdly, the children wanted to use the DIY Gamer Image Painter software to design their arrows. This is completely sensible, and the worksheet even has a screenshot of the application (even though it says to use the design worksheets).  I don't know why you'd edit the ones and zeroes of the code directly when you have a neat tool that makes the task much easier. However, doing it this way leads to some additional complications. 

The problem is, if you open a sketch window with the code to be modified (i.e. your version of the Simon game) then open the Image Painter app, every time you try to copy the code version of your design (using the insert code button), it will overwrite your entire existing sketch. 

There is a simple work around - open a new (empty) second sketch window and then launch the Image Painter app from that window. That way, the code for the image you create will be inserted into the empty sketch so it is easy to copy-n-paste into your game sketch. 

This still isn't fool-proof. If you close the sketch editor window from which you launched the Image painter app,  it has nowhere to insert the code but doesn't raise any kind of error message - it just does nothing. 

A final problem is that the code generated by the Image Painter is not formatted in the easiest way for easy copy-n-pasting. Several times the children accidentally included the  curly bracket and semi-colon (or missed out the last one or zero) which meant their code would not compile.  By the end of the session they certainly all agreed with the opening sentence of the worksheet: the basic C programming language used by Arduino is very picky!

Suffice to say I was kept busy this week!