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!  

Week 2: User input and conditions

This week we introduced students to the concept of "user input". This allows us to write programs with which they and other people can actually interact, and is a vital early stepping stone in our curriculum.

After a quick refresh of our existing programming tools (ellipse, rect, fill), we started into the three main topics of week two.

1. User input: This is a big subject so we started off with mouse button clicks. Once students had this part figured out we moved on to distinguishing between left and right button clicks, and using each one to do different things.
2. If conditions: 'if' statements core to all programming logic. They allow the programmer to test if a 'condition' is true or false, and act in different ways depending on which it is. 
3. We also introduced the "pointer base", a simple programming tool (programmed in-house by the Academy of Code team) that helps show the position of the mouse on the app window, allowing easier identification and placement of shapes on-screen. Most students find this useful, but especially those who might be struggling slightly with the co-ordinate system, or those younger students who simply hadn't come across it before attending the Academy of Code.

Eammon and the Tuesday class coding up Pumpkins

Other things we learnt:

Another basic function, background - similar to the fill command (and similarly allows students apply their knowledge of RGB colours from week 1!), this function lets us set the colour of the background of the window.

We also took the opportunity to get seasonal (if perhaps several weeks early), and students practiced their use of functions and co-ordinates by drawing pumpkins and ghosts!

Week 1: Shapes and Colours

One of the great things about Processing is how you can write just two lines of code and immediately have a shape appear on your screen. If you've never studied programming this might not seem like a big deal, but trust us when we tell you that this is a radical departure from how coding is taught to computer science students in Universities and Colleges. 

When I was in University (which is not really all that long ago, and I'm told not much has changed) we had to slog through literally dozens of lectures, tutorials and labs where all we did was input and output text. Only then did anyone even acknowledge the fact that actually, yes, it is possible to write programs which do more than this.

The merits of this approach are a whole post unto themselves, but suffice to say text adventures stopped being exciting in the early 90s, and we like to use a slightly bigger and more colourful hook with which to grab their attention. To start with they are given code to type in that looks something like this:

Week One, Step One: The journey begins!

Then they hit the play button (that's the little triangle near the top left - no prizes for guessing what the square does). All going well, another window pops up that looks like this:

A circle! How exciting!

And that's a computer program!

There is quite a bit to talk about, even in those two lines, but when the students have gotten their heads around that much we add another element: colour. 

Colour is interesting because most students won't ever have needed to describe a colour in numbers (why would they, after all?). Moreover, what colour mixing they have done will have mostly been in art class in school, where they will have mixed paint. Computer colours obviously aren't composed of paint though, and in fact they mix in almost the opposite way.

Paint mixes subtractively, which means that if you keep adding different colours you'll end up with black. (My memory of art lessons is that inevitably any colours mixed indiscriminately ended up more of a gloopy brown, but probably I just gave up too easily).

Computers use light to make up colour, which mixes additively. Keep adding more colour and you get to (or near) white. The image below neatly sums up the difference:

How light mixes (on the left) versus how paint or ink mixes (on the right). © Athabasca University / Wikimedia Commons / CC-BY-SA-3.0

We describe each of the component parts - Red, Green and Blue - with a number between 0 and 255. (The images above only show the 0 and 255 values, of course, but all shades in between are possible too. A total of around 16.7 million, if you were wondering, albeit a lot of them quite hard to tell apart). By using the fill command we can make subsequent shapes change colour. A very simple example, typical of what the students wrote in class this week, might look like this:

Note the lovingly precise comments - students are encouraged to comment their code from day one!

And it would output the beautifully simple:

This face doesn't look all that happy - possibly because describing curves is one of those things that's inexplicably hard. We don't start drawing curves for quite some time!

All this means that by the of the lesson students are making coloured shapes and positioning them on screen using co-ordinates (younger students might be using co-ordinates for the first time). They've grasped the idea of parameters, and of functions. They understand the basic idea that computers execute instructions in the order given. They've also, almost certainly, had the experience of drawing a second circle in the exact same position as the first, wondering why they're only seeing one, and then laughing when they realise what's happened. Little do they realise that they've just successfully completed their first exercise in debugging!*

On top of this they've learned about how computers actually understand colours, and (somewhat unbeknownst to themselves) they've started internalising 255 as an important number (it's the biggest number you can store in a single byte, since you asked, and one which crops up almost constantly in computer programming).

All that, and 11 of our 12 classes still to go. Welcome to The Academy of Code!

*A lecturer of mine once made the observation that if "debugging" is the process of removing bugs from code then the process of writing the code should surely be known as "bugging". Not that it's ever likely to catch on, but I guess you could make the argument that the students were introduced to both debugging and bugging this week, which is really quite a lot to take in all at once. Thus far they seem better at the latter than the former, although the same could no doubt be said of plenty of professional developers.