A change of strategy

We’ve been plodding along for a few weeks now with Python, and a few boys in particular have amused me with the way they’ve played with the code we’ve used, particularly input and loops:

Enter password:

Wrong password, this computer will self destruct in 10..9..8..

Downloading virus…

downloading virus…

downloading virus…

We also had some fun with making the computers beep (thanks codeboom!).

But overall it felt slow, and some of the lower ability kids were finding it hard going.  Bear in mind that this cohort has done very little coding previously, if any at all, and they’ve been finding it very difficult to think in the logical way needed to build up algorithms.

So this afternoon we tried out Greenfoot.  I had originally considered it as a learning tool, but rejected it because coursework for GCSE seems console-biased, and it seemed any editor that would edit Java to run in the console seemed unnecessarily complex for our use.  However, I became interested to see what the kids would make of it.

We started with Mik’s videos, and soon we had turtles crawling and spinning merrily on screen.  The students who had previously seemed to lack motivation started experimenting and playing, and by the end of the lesson, curses over brackets and semi-colons aside, all agreed that they would like to see more Greenfoot.  Most importantly, they had experienced the wow factor that I had felt was lacking previously.

Scratch is misleading, in my opinion: it looks as though it’s designed for younger kids, and it’s very easy to click blocks together and do something, but in fact it can get very complex very quickly when they want to do something specific, and it can be frustrating when they see all the blocks there but don’t understand how to use them, especially when their perception is that it should be easy because of the child-like design.

Greenfoot can be just as complex, but it’s revealed part by part as they learn, rather than thrown at them all at once.  It feels grown-up, and produces effective, visible, entertaining results very quickly.

Python is described as easy, and on some levels it is, but Greenfoot’s way of laying out code and colouring the blocks makes it straightforward to understand and read, and the braces indicate clearly where code blocks begin and end, and the Greenfoot environment makes it much easier than standard Java to work in.

So we’ll continue with Greenfoot for a little longer, looking at the same constructs – if statements, loops etc – as we have in Python, and I’ll investigate the possibility of a simple editor that will help us create programs easily without panicking over how complex it is.

Oh, and I might investigate Processing further as well – as I understand it, that also uses Java, and is also very visual, enabling students to see and visualise the results of their code much more easily.  That, as I see it, is the most useful and efficient way for them to learn, rather than plugging in lots of text-based code.  They’re only 14/15 year olds, after all.

 

Revisiting Greenfoot

I still want to see how Greenfoot can fit in with the OCR GCSE assessment tasks, so it’s time I learnt more about it.

So far I’ve learnt about adding methods, using IF statements and code blocks and listening for key presses.  We’ve also seen how to add objects to the world and how to have those objects removed by another object (eating a lettuce, for example).  The beauty of Greenfoot is that inheritance means the classes can be exactly as complex as they need to be – in the scenario I’m working on, there are various different animal types that all inherit from Animal, which inherits from Actor.  This means they all have the behaviours that are written for Actor, but also some that are written for Animal.  This means that methods/behaviours can be preprepared and inherited from a superclass, to be used without the learner needing to create them or understand how they work, and these have been dealing with things like removing an object when it is eaten.

Turtle game with bugs and counter

Turtle game with bugs and counter

Now it starts getting much more interesting.  We’ve taken the basic game of turtles moving around and eating lettuces, while being chased by snakes, added a variable to count the number of lettuces eaten and end the game at a set number of points and now we’ve added sound.   Then comes getting objects to talk to each other.

We add a new animal class, a Bug, whose code is mostly copied from the snake as we want it to move by itself.  We add code to the turtle telling it how to eat the bug and add to the score.  Then we need to tell the turtle that when it eats a bug we want another bug to appear in the world somewhere random.  This means we have to learn how to create a new bug, obtain the reference to the world and pass the bug reference to that world to make it appear somewhere random.  This produces an interesting new ability, that of creating objects on the fly.

The next job is to add a counter.  At this point in learning the code for a counter object is given, which is another good way of protecting the learner: sometimes you want them to be able to add and use a new class without having to create it, and in this case it’s as simple as copying the code from a text file and pasting it into the new empty class.  We can then use that class by adding it to the world and calling its methods without worrying how they’re implemented, although the curious can always take a look.

The turtle needs to be able to access the counter, and so we learn about constructor methods, and how to pass the world’s counter reference to the turtle.  At this point we also see how to add objects to the world object using code rather than by placing it manually.

A few adjustments to the point scoring process leaves a complete playable game.

In this session (videos 11-16 from Mik’s blog) a lot has been covered, from the simple steps needed to add sound effects to the game to some massive concepts involving references and object interactions, and on the way we’ve seen a couple of ways that the learner can be helped to focus on the concepts they need to learn rather than getting bogged down in details they just don’t need yet.

I still don’t know how to use Greenfoot for the sort of tasks needed for OCR GCSE computing yet, but I’m left far more optimistic that there will indeed be a way, as well as admiring the way that Greenfoot helps the student understand, from easy to access code documentation through layout tools to code completion.

 

Introducing Greenfoot (Java)

I’ve looked at drag and drop code options, and I’ve looked at proper typed code options; this time I’m going to look at something that bridges the gap between the two.

Greenfoot is produced by the University of Kent, and provides a gentle introduction to Java via a system focused towards graphics – a grown up version of Scratch, almost, with its sprites.  The user is writing real Java, but in a very structured environment.

Java is an Object-Oriented language: this means that you create classes (categories) of objects, which can do certain things, and you can create sub-classes of those classes, which either extend or change the abilities of the parent class.  For example, when I first learned OOP (object-oriented programming) we learnt using frogs, little creatures who could move and jump.  We developed those into hoverfrogs (who could also hover in the air) and scared hover frogs (who could hover but only to a certain height).   So subclasses are developed from their superclasses and can do everything they can do (they inherit the ability to do these things) and can do their own special things as well.  This means that you can reuse code, instead of writing everything from scratch.

Greenfoot main screen

Greenfoot main screen

The Greenfoot site has a few tutorials to get you started with the basics, but to really get to grips with it I recommend Michael Kölling’s blog, which contains a series of videos that take you through step by step.

The Greenfoot screen has two areas: there is the world itself, and the list of classes that make up the world.  Two essential classes exist – World and Actor classes.  World classes contain the sorts of methods that a world in general needs to respond to; the world you wish to use in your program is created as a subclass of World, and has its own settings, including size and graphic.  The other important class is the Actor class.  This has its own methods, and any object you wish to place in the world inherits those methods as well as having its own.

simple greenfoot code

Simple Greenfoot code

Here we have the World, from which we have TurtleWorld, the world that we are running at the moment.  For the Actor, we have the original Actor class, then an  Animal class, then a Turtle class.  The Animal can do everything an Actor can, plus a few extra things such as tell whether it’s at the edge of the world, and the Turtle can do anything else that we design it to.

The code editor is reached by right-clicking on a class, and I found the colour coding in this editor incredibly useful: it really makes nested statements clear, and there is a code helper as well, accessed by starting to type a method then using CTRL[space] to see possibilities.

The first few lessons get as far as making the turtle move randomly onscreen and turn when it reaches an edge.  This leads on to making a simple game.

greenfoot class methods

Inherited methods can be easily found

Greenfoot is a gentle way to introduce a beginner to the idea of classes and inheritance, and writing methods for classes.  The actor class contains the method act(), which is an empty method.  This method must be defined in each class you wish to use in your world, and pressing the Run button on the scenario calls the act() method repeatedly on every single object in the world.  This leads neatly to the prospect of creating different objects, telling them how to act and putting them into the world together to see what happens.  So far in my world I have turtles who move and turn and eat any lettuces they come across and lettuces which just sit waiting to be eaten.

greenfoot code completer

Greenfoot code completer

The teaching materials for Greenfoot seem very good quality, and the projects on the website indicate that it has many possibilities and is an excellent way to introduce object-oriented programming, but after an initial session with it I still feel I need to learn a lot more before doing what I want to do with it rather than just playing with the techniques I’ve learned, and I’m not sure yet how it would fit in with the GCSE computing curriculum.

It does, of course, have the advantage that it uses a proper professional programming language that is also easily portable between platforms (you’re not tied to Windows, unlike Small Basic), and it has lots of really useful features that make it easy to understand and start using for those new to programming.

More to come, then, on Greenfoot!