With everyone having finished constructing their gamer, I wanted to get started with the 5th lesson, using the Light Dependent Resistor to control the progress of an animation.
A couple of the groups had started this worksheet in the last session but hadn't seemed to get very far. In order to make sure everyone was starting from the same place, I demonstrated the key parts of the session to the whole club. There were still a few blank faces and a few questions about why were doing this activity. Quite a few wanted to know how it related to the game we were going to write for the gamer. I'm not sure that my answers - that you could use the LDR as an extra button or that it could used to build some sort of alarm - were very convincing. To be honest, I've never been able to come up with a great use for the LDR in the context of creating games. The fact that it will always need some sort of calibration based on the actual light levels at the time of use makes it seem a bit difficult to reliably use in a working game.
The clubbers started to tackle the worksheet and I got the impression that they found it quite confusing. All of the groups made the same mistake in the first few pages: they created two void loops functions. Looking at the instructions I can see why. First of all it asks them to create two empty functions (the setup and loop). Then a few pages later it asks them to edit the void loop function to add the code to print the light value to the serial console. I think it needs to say "modify the loop you created in step 6" or at least make it more explicit that you're not adding another loop function.
Every group also struggled with the next section. Opening and closing the different scripts and copying bits from one to the other really had them in a muddle. It does all seem a little futile. They may as well just insert their LDR max/min values into the example animationLDR script and run that. I don't think they learnt anything from typing in a couple of quite baffling lines of code. Although there is an explanation of what the code does in the worksheets, they do require a lot of reading and don't really explain how you might use similar code to control something else (e.g. the IR receiver).
To try to liven it up I suggested they use their own animations from the previous week but I think that just added more confusion.
Certainly compared to the normal CodeClub Scratch or Python projects this all seems quite a slog with very little payout (although perhaps it just feels like that after the excitement of the soldering and assembly).
I'm also concerned that lesson 6 may have similar problems. Although controlling and moving an on-screen object with the buttons is clearly a key learning point, it isn't really used by the Simon Says Game so it feels a bit superfluous again.
Things to do differently next time?
I'm not sure I would bother this week's activity at all, unless the use of the LDR can be more integrated within the overall project objective. An exercise to demonstrate the potential for some of the other gamer components is a good idea but I wonder if a simple program to exchange messages via the IR capability might be more interesting.
One of the gamer's LDRs was only showing a very slight change in the value it reported through the serial console for different light levels. On closer inspection I think the soldering is a bit ropey and the LDR actually wobbles a little. Hopefully re-soldering it will correct the problem. Next time I'd try to check that all LDRs work correctly before the session.
No comments:
Post a Comment