Last week we held a game jam event at Bournemouth University with 15 KS3 kids from IPACA (Isle of Portland Aldridge Commity Academy). We've been working up to this for a few months, rolling out various supporting code and worksheet resources, so that (we hoped!) we could teach them Sniff to the level of having some kind of working game within 2 days.
That's a big challenge, which wasn't helped by traffic on the A35 from Weymouth to Bournemouth on the first morning... so they arrived almost 2 hours late. That's a big chunk of time out of the first day! Second day was able to start a bit more promptly by we still ended up with about 9 hours to do a project we thought was ambitious in 12 hours!
Sniff's actually based in the NCCA at Bournemouth University (You may have heard of us from the NESTA NextGen Report) so we had use of one of the Linux labs there (not sure of the spec, but I believe there's around 1.6 Terabytes of RAM installed in the room!). We were able to divide everyone up into groups of 3, and give them their own work area with one machine each. While its hard (on this scale) to have more than one person working directly on code, this meant that in their teams they could have 1 person developing assets, 1 programming, and a 3rd assisting/coordinating). This worked really well.
We ran a smaller pilot session at the end of the summer term, which some of the students had attended, but most of them hadn't used Sniff before, so I kicked of the session with a 20minute crash course on Sniff. This generally goes something along the lines of getting them to run sniffpad, and then throwing a few examples at them:
make count number
.set count to 1
make count number
.set count to 1
..if count mod 5 = 0
You might recognise this final example as a simplified version of fizz buzz - in fact its just fizz (which is much easier to code). Look closely and you'll see what a great example it is - sequence, iteration, selection. It's all there. It also lets me talk about indention, typing, and with a bit of tweaking you can also explain the broadcast mechanism (which even kids who claim to be "expert" at Scratch seem to have rarely used).
While I'd normally take a little longer to cover this it really doesn't take very much time to throw down some basic Sniff examples. The general reaction is "OK - I get it", can we make a game now. If you've laid the foundations in Scratch then there's no need to spend much time "teaching Sniff" - you can move on quickly to making things, and learn the rest of Sniff indirectly.
To do that we've got a bunch of worksheets/cards that Michelle developed over the summer. Throwing them straight into sprites is a little unfair, as its quite a complex library, but their enthusiasm for coding games helps make up for that.
These contain fragments of code to do all sorts of useful things with Sprites. However they're not complete programs, and also require small modifications depending on how you want to use them. We give out a basic framework which contains all the generic boiler plate where all the devices are made, and then kids can work through the cards to implement all the basic features they'll need in a game. Though there's a general "order" to the cards (they're numbered!) you don't need to cover them all sequentially, so you can hold back certain bits of code until they're needed.
It took an hour or two for everyone to more or less get through these and produce some kind of crazy moving object that they could control with the keyboard.
Sandwiches and crisps were provided by the CDE (Centre for Digital Entertainment - thanks Dan!), and as we were running late, Phil Wilkinson (a DEng student attached to the CDE/Bournemouth and IPACA) asked everyone to discuss what sort of game they might like to make for the rest of the workshop over lunch. Phil is interested in how getting kids to make games can be used to explore social issues with chi. For this sessions we wanted something fairly lightweight, so he decided "to teach something relevant, something modern. The Internet!" [those of you over the age of 16 who don't see why that's funny, are welcome to google it. It may be NSFW depending on where you work!].
So we asked them to build a game around the theme of the internet. The idea was that it was open enough that they could make more or less anything, but there was at least a jumping off point for discussion.
After lunch I introduced sniff paint, which proved very effective, and we immediately started getting some great artwork.
Over the course of the rest of the afternoon icons started to appear, and the some sort of vague game play ideas started to be discussed.
On the morning of day 2, Phil worked with them to turn their rough game ideas into concepts that could be realised within a few hours, while I ran around fielding technical questions. Almost all of these were really solid questions about how they could implement features of their game. As we were doing this in an intense 2 day session, there was a lot about the sprite library that we didn't have time to teach in advance. However I you learn better if you already have a need for the knowledge, and I was able to explain features on-demand. Some better reference documentation would be useful here, or if you were working at a more relaxed pace, perhaps over a number of shorter sessions, you could introduce some of these in a more structured way. At around this time as they started to get seriously into development we encountered a bug in the Sprite "load costume" code, which I had to make a quick patch to, and distribute round the lab (yes it was stressful). However apart from that the system help up pretty well to some serious testing.
One concept we'd deliberatly kept back was how to dynamically create sprites at runtime. This is a more advanced feature, but only one team needed it.
Just after lunch one of the teams accidentally deleted their code - someone clicked save when they mean to click load and saved over their program. Michelle was able to work with them to quickly rewrite most of what they'd lost, but they never quite caught up. Things like this are always going to happen, as they were under quite a lot of pressure at this stage to get everything working. Some sort of automated backup script would probably be a good idea.
At 3pm we called time on the development to allow for everyone to go around and play everyone else games. While everyone would have benefited from "a little more time", pretty much all the teams had produced a game that was to some extent playable. If we'd had another day most of them could have been refined into something that was actually finished. My main concern was that at some point they might just get stuck and not know how to progress. In fact this never came close to happening - they all knew what they wanted to do and worked hard, and asked a lot of questions to get there.
Most importantly everyone seemed to have a fun 2 days, and the teams all worked well to get something working within the time limit. They went home enthusiastic about programming, and knowing that with a bit more practise and a less crazy schedule they could actually make their own game.
Here are 4 of the 5 games which you can play online:
Virus Defence (use the mouse to block the virus)
Ad Invaders (space invaders - cursor keys)
Internet Survival (another shooter variane - cursor keys)
Oops We Deleted Everything (they didn't get finished - cursor keys)