Week 8: It's Project Time!

Some of our more advanced students (mostly those who attended our Summer Camp) have been working on their end of term project for a while now. For the rest, today was a big occasion: they finally got their hands on the first project handout.

Not that there's anything all that special about the handout*, but what it represents is a major vote of confidence in all they've learned so far this term. We've been building up to it since September, and now we finally think they have all the skills (or enough, at any rate) to build the block dodging game we've been teasing them with the past few weeks.

What are those skills?

Well, they need to be able draw objects on the screen (using functions). They need to be able to move those objects around (using setup() and draw() blocks, variables, and basic arithmetic). They need to understand program flow (that's setup() and draw() again, and how the computer moves through the code in those blocks). They need to detect key presses (using if statements, comparison operators and system variables), and they need to detect collisions (using more comparison operators along with some slightly more complicated arithmetic).

There's other stuff too - despite the mainstream narrative that all kids these days are "digital natives", the reality is that there's all sorts of other, more fundamental IT skills they've learned in the past 8 weeks as well. Things like using ctrl-c to copy and ctrl-v to paste have come in handy. Using ctrl-z to undo has, unsurprisingly, come in even handier. They've become a bit more familiar with the windows file system (finding where on the computer they actually saved things), and they've become more used to highlighting specific bits of text they need to cut or copy (not much call for that while using a smartphone or tablet, it seems).

The block dodging game is simple relative to a modern 'AAA'** game of course, but is not dissimilar in appearance to something like Tetris. The basic idea is that you start by having a block or ball drop from the top of the screen, and the player controls a block moving left-to-right on the bottom of the screen trying to dodge that block. If the player is hit he loses, if not the game continues. We add layers of complexity when we randomise the position and size of the block, when we start keeping score, when we make the game harder as time goes on, and in many other ways as well***.

Progress was overwhelmingly positive across the board. Everyone managed to get either the player block moving left and right on key presses, or the "attacking" block dropping from the sky and then moving back to the top once it had passed the bottom of the screen. If anything, four more weeks seems like way too much time - but over achieving students are hardly a teacher's worst nightmare.

The advanced cohort also made great progress (but then, they always do, consistently outstripping even our most optimistic projections for them). We'll be featuring some of their work on the site over the next few weeks, as well as the finished projects from all of the kids in both the Tuesday and Wednesday classes.

Until then! 

*Actually it's one of our less interesting handouts - no colourful code blocks, no pictures, just a single A4 page of text with the scant consolation of a colourful "The Academy of Code" footer. Pretty disappointing relative to the high bar we like to try and set.

**'AAA' being the tag used to describe the kind of super high budget games which, with a few notable exceptions, you probably love if you're a kid and hate if you're a conscientious parent. 

***Simon (one of the teachers here at the Academy) decided it would be fun to add his own face to the "player" block, and make the falling blocks look like ninjas. Based on our experience demoing at the Wednesday class it seems there's no better way of endearing yourself to a 9- or 10-year-old than write a computer game where you escape from ninjas. Take note, parents! 

Week 6: Becoming a Nodding Bear (or a Rubber Duck)

The essence of good programming is being able to approach a problem you've never seen before and plot your way through it using the various tools at your disposal. This is true of every programmer, from beginners right up to technical architects on huge projects. In fact, it's not just confined to programming. All engineering (and programming is certainly at least sort of engineering), involves this ability to approach a problem and find a solution in as novel or humdrum a manner as the situation dictates.

One of the first things we talk to our new students about is the idea of this "toolbox". We start with some simple commands: this is how you set the size of the window; this is how you draw a circle; this is how you draw a rectangle. We add to this as time goes on, but we never get to the point where we say "this is how you create a computer game". That, as you would expect, is instead a combination of all the little things into one big thing. 

Starting out, their most powerful tool is not really any of these things but rather the instructors. The instructors know all the answers (or at least in the narrow confines of the assigned problems we do...), and we will always be available to give an extra nugget of information when a student is truly stuck. 

After a number of weeks, however, something strange starts to happen. Bit by bit, they slowly stop needing us. 

They still have questions, of course. Even advanced programmers occasionally need a sensible eye cast over a particularly intractable problem. More and more, however, their questions are answered before they finish asking them. As an instructor, all we need to do is nod along until they work it out for themselves. We're reduced to the roll of "nodding bear".

(A software team I worked on referred to it as the Stanford Bear, but I can find no sources which credit Stanford with the original innovation).

The idea of the nodding bear is that a programmer, as part of her/his debugging efforts, explains their problem to someone or something else. This can be an instructor, a colleague, or literally a rubber duck or stuffed bear. The typical question might begin with "so I'm trying to make this box disappear here and reappear here", before trailing off with "but when I check if the position is greater than the size - wait, shouldn't that be less than..? Never mind...". As the nodding bear, all the instructor has to do is nod along until the student arrives at the solution all of their own accord. Neat, right?

We're only six weeks in, so of course there are still lots of questions coming at us, and of course there is a wide range of abilities in each of our classes. All the same, it's great to slowly start becoming closer and closer to the proverbial Nodding Bear.

This week we revisited our basic drawing tools with most of the students, before moving on to making a box fly around the screen and respond to commands. More than ever before these students are starting to see how the tools they already understand can be combined in new and interesting ways.

Meanwhile the more advanced group were pressing ahead with their block dodging game. They progressed notably on their collision detection code, and generally made good progress towards the finished game. With a bit of luck we might need to find an entirely new project for them before the end of the year!

Week 5: Movement, and the Start of a New Project

This week was exciting for both our beginner/intermediate group and our more advanced cohort. For many of the beginner group this was their first time doing anything that might be called "animation", and they were predictably excited about the prospect! For the advanced students, meanwhile, this week marked the start of their first major, multi-week assignment - more on that further down.

After a recap exercise, which involved using detecting keyboard input and changing the size of a circle in response (which is not nearly as easy as it sounds!) the first group started into their animation with an apparently simple "move the ball across the screen" task. With a bit of help most of them had managed to plough through this by the end of the class, but that's not to say there wasn't a lot going on. Quite the opposite! This task requires students to understand program flow (which means understanding which instructions will execute in what order, and why) as well as making use of variables to store numbers, and accessing those variables to modify them. On top of all that this also requires that they be very careful about their use of brackets. Every '{' must be matched by a '}', and every '(' matched by a ')'. 

All this combined means that this bunch of students, many of whom have been with us only five weeks, are now equipped with many of the skills required to produce some really amazing programs. We're all looking forward to seeing how far we can bring them in the next seven weeks!

On to the advanced crew, and their assignment was only just getting into gear this week. They've been tasked with building a "block dodging" game. The player will control a character who moves over and back across the bottom of the screen (think Space Invaders), and dodge blocks which are falling from the top of the screen (think a cross between Tetris and, well, Space Invaders). Early progress has been encouraging, with students successfully crossing some of the first hurdles, and displaying admirable breadth and depth of knowledge. Perhaps next week we will have some early demos to share.

Week 4: Keyboard Input

Like week 3, week 4 was always going to be a good one in terms of student reaction. This, of course, is one of the main reasons we use Processing. Unlike other languages (eg Java, or even Python/Ruby/etc), it's possible to very quickly progress to user input in Processing.

As a teacher it's gratifying to be able to reliably show a demo at the start of class and have students (literally!) gasping with astonishment and excitement. (At least, one hopes that gasping with boredom hasn't quietly become a thing without any of us noticing?).

That said, this week was also a tough one for many students, as they had to deal with the idea of "nesting" much more than before. Opening and closing brackets/braces isn't really a skill normally all that necessary, and when necessary it doesn't tend to be terribly difficult. In the code example below, which is perhaps on the high end in terms of number of nestings*, there are 6 separate pairs of curly brackets, all of which must be matched correctly in order for the code to function. Not all students managed to get to this level of complexity this week, but they all will!

void setup() {
  size(800,600); 
}

void draw() {
  if (mousePressed) {
    if (mouseButton == LEFT) {
      if (keyPressed) {
        if (key == 'c') {
          ellipse(mouseX, mouseY, 50, 50);
        }   
      } 
    }
  }
}

You can see in the code above much of what we covered this week, most notably if (keyPressed) and if (key == 'c'). For those students who are interested in making games (which I think probably covers most if not all of them!) this was obviously exciting, as they got to see how easy it potentially is to take a user's input and do something with it in code.

In addition to key presses we also introduced students to variables this week. Variables allow a programmer to store something (a number, letter, word, etc) and refer back to it later. For example, we might set a circleSize variable at the start of our program, and make all subsequent circles with circleSize as a diameter. If we want to change the size of all our circles we then only have to change the number in one place. This also allows us to do interesting things like incrementing or decrementing the circle size based on mouse clicks or button presses. 

As you can see, and as the students are seeing, even in the relatively small number of classes we've had so far they have built up a formidable array of tools with which to tackle programming challenges. Next week will see revision of bracket discipline, as well as a some quickfire revision of the various functions we've used to date, and more opportunities to play with the user input features introduced these past two weeks.

More advanced students (mostly those who have previously attended a course with us) will also be moving on to bigger and more complex problems, requiring higher level thinking and more complex structures. Something for us all to get our teeth into then, and plenty to look forward to for all our students!

*For those programmers in the audience: don't worry, user-defined functions are coming up soon. We won't be encouraging quadruple nested if statements as a standard programming practice!

Week 3: Mouse Input

Having introduced the students to user input in week 2, this week we started to make things a bit more interesting with the addition of left and right clicks. As usual Simon kicked things off with a quick demo of what we're building towards. As well as demoing our very simple car game again, we also took a look at a simple but extremely cool shape-shifting demo (which we will be embedding below shortly). This simply draws a box at the location of the mouse, leaving a trail behind when the mouse pointer is moved. Left-clicking switches from square to circle, while right-clicking clears the screen. All quite simple, but very visually engaging!

It's always fantastic to see the reactions of students the first time they write a program that tracks the mouse pointer. The mix this term is about 70:30 new students to returning students, so there were plenty of big grins around the room when they got a circle drawing on the location of the mouse.

In Processing we can very easily set a refresh rate of 30Hz (simply by placing code inside the draw() block), so combining what they already know about the ellipse() command (used to draw circles/ovals) with this and the newly introduced mouseX and mouseY variables (which always give us the up-to-date location of the mouse) it's actually quite a simple exercise to make a shape follow the mouse. Simple as it might be, it's still a great confidence booster. It also really shows the power of combining a few separate pieces of knowledge to make something that's much more than the sum of its parts, and is a very solid introduction to the idea of program flow.

Working hard!

Even better is when they realise what the next steps are, and there was more than one student this week who was desperately trying to make those next steps come together before the final "save everything and shut down" call came! Most managed to make some use of stroke() and noStroke() functions to remove or change the outlines of their shapes this week, but the real power of all those tools (and more, like the briefly introduced void() function) are yet to be fully revealed. 

Left and right clicks will continue to be in focus next week, as we keep up our relentless work towards mastery (or at least a decent grasp!) of coding computer graphics with Processing. Until next week, then!