Add a Score Counter to Greenfoot

A few people have been asking me how to create a score counter in Greenfoot.  So…

Click here for a PDF tutorial – to complete the tutotial you need certain files that are used in Greenfoot.

To get those, as a big Zip file, click here.  Decompress it and read README.TXT

In essence, it builds a really simple game (a turtle eating flowers) and counts the flowers eaten.  The counter is a rip-off of a counter I used elsewhere and students need to use the old counter, which refers to Lobsters and ‘rewire’ it slightly so that it talks to Turtles.  This borrows from some of Michael Kolling’s great work (Google for The Joy of Code).

Happy hacking!

Showing off Greenfoot to Year 9

My A-level ICT class are expected to get user-feedback for the systems they build.  For some systems, this is easier than others.  I am currently walking round with two Android Apps on my phone, as a result of my own testing of students’ project work.  Finding people who are happy to exhaustively test a website is not a problem.  Getting people to exhaustively test an Access database is more of a challenge.  Nonetheless, it has to be done.

Any time we create something, we are unlikely to spot the flaws straight away.  We need someone else to look at it and spot the problems.  Someone else will see what we have done, impartially.  When I look at my own work, I see what I think I have written/built – not what I have really done.

The A-level students who were using Greenfoot had scenarios where the client wanted some sort of interactive game or simulation, for training purposes.  The problem with Greenfoot, or any similar tool, is it produces applications with a million different possible states.  There is no way a single student can exhaustively test it on their own.  However, putting their work before an audience ensures realistic feedback.

I also have a bunch of juniors who I want to see something with a “wow” factor.  When I was in Year 8/9, I got excited about Chemistry because I saw A-level students making smelly things.  I got excited about Biology when I saw a room-full of people dissecting rats.  I got excited about Computing because a saw a pile of mumbo-jumbo (my name at the time for Pascal), that someone compiled, to make something really clever.  Ten years of MS Office has told me that there is no “wow” factor there for students who are beginning to wonder about GCSE choices.

So, I brought the Year 14s along to some Year 9 classes – to test their work!  The idea was simple – “Hello class, this is John, he wants you to test some games he has made.  Here’s a pile of mumbo-jumbo on the screen, called Java, written via Greenfoot”.  The blank faces said it all, at this stage.  “Then  we press compile to turn it into a running program and… look, there’s a real game.  Now, open your browser and click on the link for a few  games that were made with this Java stuff”.

And they played a bit.  And the sixth former walked round and chatted with them, getting feedback, telling how he built the game.  The feedback was really helpful and good, and helped uncover little niggly things that had hidden away. The more they played, the more it dawned on them that a human being standing not far from them had hacked it together in a month.  Some started to ask if they could see the Java mumbo-jumbo stuff that he wrote.

Twenty minutes later, the faces that had been blank all wanted to know more about writing their own mumbo-jumbo Java stuff.  Result.

Two days later and it was another Year 9 class and Alice showed off here game.  It was the same as before.  Result, again.

I have ran out of fingers to count the number of Year 9s who have stopped me to ask, in the corridor, about learning programming.

Greenfoot (11) – CCEA have their say…

It’s GCSE results day, and the ultimate day of reckoning for my GCSE ICT experiment with Greenfoot.

Keep in mind, the CCEA GCSE ICT Unit 2 ‘Game’ task was written with MS Office apps in mind.  Indeed, the CCEA-endorsed book takes this approach.  I’m sure an enthusiastic teacher can get their students enjoying quiz games created in PowerPoint or Excel, but, well….. I have difficulty getting myself really excited about PowerPoint, never mind other people.  It does its job fine, but there are other things out there.  Excel would do for one of those kill-time-on-Friday-afternoon quizzes you get e-mailed to you, but after Unit 1 my class were ready to move on from Excel.

So, a long time ago, I looked very carefully at the CCEA specification.  Not a word there about MS Office, or any other software, being mandatory.  All it asks for is a game with several ways through it, instructions, user feedback and scores.  So, conceivably anything that meets these requirements would do.  From what they have written, GameMaker, Scratch or even Android App Inventor could be used.  I know of schools where GameMaker and Scratch went down well with the students.  Actually, C++, BASIC on a ZX Spectrum or even x86 Assembly Language would meet the requirements.  Though I doubt if I’d complete something with x86 Assembly Language in the time allocation!

Before we started, I had a chat with the coursework people at CCEA, just to be sure….  They said “Go for it”.  So we did.   Yes, it was difficult at times but for many students, it was their best piece of work.  Yes, Java programming is more difficult than using Excel – but I remain convinced that doing something hard forced the students to think an awful lot, and they were the better for it.  Getting away from the mundane clicking next-next-next of office apps and assuming Excel always produced correct results, regardless of your formulae, was undoubtedly more engaging.  Being faced with a compiler that has a stroppy moment when you leave a semi-colon in the wrong place forces you to organise your thoughts and properly understand when you are doing.  Marks aside, I have no doubt of the educational value of this.

So, what did CCEA say in the end….. they were happy.  Last time I was talking to someone at CCEA, they said  they were glad to see schools being creative and not feeling they had to go down the Excel/PowerPoint route.  From the moderator’s report, it’s clear they were happy to see technically challenging Java being used.

What will we do in 2012/13.  More Greenfoot, but better (I hope!).  Will you use Java too?  Tweet to @computing_teach if you are interested in a repeat of my one-day course for teachers.

 

Greenfoot (10) – teaching the teachers

Over the course of the year, a few teachers in other schools had told me they liked the idea of Greenfoot, but would really like someone to hold their hand to get them started.  I have a lot of sympathy with them – after all, I had to go off on a course last August to get properly started.  Some people are great at learning from books and videos.  Others need a human being standing in front of them to get them started.  Whichever works for you, I say.

So, I sent a few messages out via Twitter (@computing_teach) and emailed teachers.  I piggybacked on Computing At School’s (@cas_ni) contact with schools in NI to raise awareness and used the CAS online booking system (a great idea – if anyone else in CAS is organising an event, I recommend it).  Looking back, it sounds a bit like overselling it! However, I knew it was going to happen in the middle of exam season and a few people had told me they’d be crying off for that reason.  If I had 300 A-level papers to mark, I’d have cried off too!  In the end, there were more teachers wanting to be there than we could accommodate.  This was good, though it also made me nervous.  I had a classroom of teachers, all expecting to be taught – eek!

Was I nervous?  Yes!  There was lots of potential for it to all go wrong – hardware and software failure; a confused me; the general shambles that sometimes happens to the best-planned lessons.  Even with several run-throughs of the excellent course material that Neil Brown (@twistedsq) of the University of Kent had sent my way.

Once we got going though, nerves calmed.  Everyone got logged on and everyone seemed to understand what we were doing.  I started off by explaining the idea of objects, instances and inheritance (because people do need to understand it!).  Something like this: primate is an extension of mammal and inherits all the properties of mammals.  Whether primates like it or not, they have spines and hair because they are mammals.  Humans are an extension of primate and inherit the qualities of primate (and therefore all the qualities of a generic mammal), whether they like it or not.  Humans also have some qualities of their own (walking upright, big brains, talking).  So, whether Joe Bloggs likes it or not he can walk upright, has a big brain and can talk because he is human.  He is hairy because he is a mammal.  Joe Bloggs, John Smith, etc., are all instances of human.  For that reason, they have a lot in common but they all have certain variables that are particular to them, like hair colour, favourite song, whether they can drive.  A lizard, on the other hand, does not have hair or a big brain, because it is unrelated to the mammal class.

Why do I use animals instead of programming ideas?  Because the important idea is instances and classes, not programming (yet).  With these ideas explained, I demoed Greenfoot with a few pieces of Year 12 work, talking about inheritance and classes.  Once teachers had an “eek, am I supposed to be able to do that?” look on their faces, we started – nice and simple.  A crab on screen doing nothing.  Then we made it walk to the edge.  Then we made it turn at the edge.  Then we made it do some random staggering, instead of a straight line.  Someone asked about keyboard control – good idea, it’s coming after tea, once we’ve practiced the first part.  .Okay class, now create your own lobster class to do the same thing.  Okay, let’s have a cup of tea.  Now let’s get lobsters eating crabs.  “Keyboard control”, you asked?  Okay, here’s how to get the left key doing stuff, see if you can figure out the rest and code it (and they did).  “What about a scoreboard?”  Great idea – but it’s almost lunchtime…. after lunch, I show them a scoreboard, they code it up, then they make their own version of it and rename it ‘speedometer’ for the crab.  We look at exporting to HTML, adding a user guide and…

…after five hours (plus tea and lunch), we have a GCSE-standard game.  We take a look at The Joy of Code videos.  Evaluation sheets are all positive.  People go off and tell their friends and say they’ll be using it in-class.  There’s potential to do it all again,

Greenfoot (9) – Controlled Assessment

All the preparation was done and off they went.  Outline designs, build the thing, then do the design properly (and don’t let on in the write-up that your ‘design’ was after the event).  “Sir, are you supposed to do your design that way?” they ask…. Well, put it like this – they are all going to deviate from their design anyway and have to rehash it.  Why waste 4 hours of controlled assessment time on a design that is never fulfilled?  The reality is, 16 year-olds are probably not skilled enough programmers to fully design the thing, and the specification does allow for this.  Does anyone who is learning know what they are  going to build, until they build it?

Did I have to help them?  CA rules are fairly strict.  I can give advice to the class as-a-whole but one-to-one feedback is restricted.  They all knew scoreboards would be fiddly and I always intended to stop the CA clock after a couple of weeks and remind them how to do that (using a dummy scenario).  Apart from that, and a couple of little technical issues, things went really well.  The technical issues were largely down to this being the first class to run through it.  One person’s work wouldn’t export to a webpage – solution – the Greenfoot installation on that machine was fouled up, go to another machine.

Ah yes, exporting to a webpage… Once students are done, they tell Greenfoot to export it to a JAR file that is built into a webpage.  They can open that webpage in Frontpage (that’s a piece of retro default software, for anyone unfamiliar with it) and put on links to the design and the user guide, to keep CCEA’s moderator’s happy.

So what did they do… well, I’m reluctant to put them here ‘live’, simply because I never asked the students, and because moderation is still on-going!  However, a few screenshots might help.

Avoid the back-and-forth cops and collect the loot:

Cops and Robbers game

 

Little Mermaid, avoiding randomly running things and collecting stuff:

Little Mermaid

And we had several variations on the run-round-collecting-objects idea.  And why not?  It’s straightforward, gets the marks and build on skills developed in the lobster-chases-crabs tutorial.  It’s maybe not as shiny as Scratch would do it, with its lovely drag-and-drop code editor.  But, in terms of the effort students have to put in, it’s great.

We had a Frogger-type game

Greenfoot (8) – The coursework begins…

I was confident about starting Greenfoot.

I was a little nervous about the prospect of every student in the class fully ‘getting it’.  I always had the ‘Plan B’ of Scratch, or the ‘Plan C’ of Excel, if it went horribly wrong.  Excel does not an exciting game make: but, it would get students who were struggling with Greenfoot or Scratch a decent mark.

I was very nervous about all students meeting the controlled assessment criteria with Greenfoot.  Now we have a strict time-limit, I would have issues if I had to switch someone to Excel after 3 weeks as they would over-run their time allocation.  However, they had not let me down so far and most of them had started experimenting with something that would pass as a GCSE-level game.  They had all looked round the Greenfoot gallery by this stage and gotten ideas.  They had downloaded other user’s source code and studied it.  Something pretty cool was happening inside my classroom.  I had accidentally created a bunch of open-source hackers, who were all enjoying it.

Time for the Controlled Assessment then.  The rules are simple: give me an outline design, build it, test it.  Don’t plagiarise anything you have been studying.  Don’t plagiarise the tutorials.  Yes, they can look similar but I’ll check the code to make sure you came up with the innards yourself.  Once you have it working, we’ll talk about the paperwork CCEA want – design document, final review, etc.  Do as much preparation as you can at home – artwork, documentation, etc. – use this room for coding only.

Two levels, scoreboard, with instructions…. go!

I thought to myself, it would be four weeks of class-time before anyone had a completed game.  I thought some might have issues completing on-time.

Two weeks later I had the first, “My game’s finished, what do I do now?”

“Extend it”, I said.  Oh boy did some of them extend it…

Next day: Frogger clones and Justin Beiber.

 

Greenfoot (7) – videos for lazy teachers

I had done the intros, we had scurrying crabs, and then….

…Michael Kölling of the University of Kent started posting brilliant tutorial videos, each around 10 mins long.  Michael invented Greenfoot and is still project lead.  His video blogs are at: http://blogs.kent.ac.uk/mik/category/joy-of-code/

Just watching up to Episode 10 will cover CCEA GCSE ICT requirements, assuming you add a scoreboard (more on that later).

The first tutorial exercises feature a lettuce-eating turtle, trying to avoid snakes.  We watched an episode per-period and did what it said.  Some of it repeated what we had previously done – though repetition and more hands-on aids understanding.  Some of it introduced new ideas.  Some of it explained things better than me.

Something that struck me, was the class listened and watched in rapt attention.  They didn’t just want to understand – they really wanted to ‘grok‘ it.  They asked me to replay parts they missed.  They asked for access to the videos at breaktime. You just don’t get this with end-of-year videos!

Watch them yourself.  Episode 1 is an intro, Episode 2 discusses Greenfoot installation.  Episode 3 tells you what Java ‘objects’ are and the coding starts in Episode 4.

Greenfoot (6) – some reflections

This is probably a good point to break from the how-we-did-it, to a few reflections on what I was noticing as a teacher.  These are the sort of things I should maybe work on for next-time-round.

The big thing I was noticing was student engagement.  It was fantastic.  This was undoubtedly more difficult than anything we had done before.  Most of GCSE ICT coursework centres round applications and any reasonable student can get pretty far simply through clicking next-next-next a lot.  Once it goes off the next-next script, MS Office is intuitive enough that most students can normally figure things out.  This is fairly commonplace end-user ICT – a million miles away from Computer Science.

With Greenfoot, we are going into Computer Science territory.  There’s no next-next-next here.  It’s all about proper problem-solving and learning to think.  Most students realised this early on when they got messages from the compiler, such as “; expected” and “reached end of file while parsing”.  Bafflement followed.  I (yet again) reminded them of the rules of syntax – end a line with a semi-colon, make sure your brackets match up.  It’s not like English where grammar sloppy and miss-takes in spell donut always stop the other person under standing of you.  Java compilers are not forgiving to the foreigner who is learning the language.  You need your syntax to be perfect.

I was aware, from the outset, that this could become a brick wall for people.  I have too often seen the “Sod this, it doesn’t work” response when Word doesn’t format things the way you think it should, or when Excel doesn’t produce the graph you think you have told it to produce.  I’m guilty of such responses myself.  I did everything I could to avoid the “Sod this” reaction happening with Greenfoot.  As a teacher, I am acutely aware that one student ‘not getting it’ and giving up can spread round the class with alarming speed.  So I went really gently.  I went really easily.  I put my own mistake-ridden, not-compiling code up on the big screen and did code walk-throughs of 10-line programs to get them used to spotting mistakes.  I purposely goofed up when putting my own code in ‘live, on-screen’, for them to all shout out “Sir, the semi-colon!”.  I had them break their own code to see what messages the compiler gives.  I treated them so kindly.

And yet….

…not a single one had the “Sod this” reaction.  Not one.  Zero.  They would be damned before they let a computer beat them.  Okay, they asked me to help find where the missing punctuation went.  They helped each other find mistakes.  Oh boy, did they help each other.  This turned into a fantastic piece of teamwork (at the learning stage, later, the controlled assessment rules were followed!).  I have seen copied spreadsheets, copied Word docs and copied PowerPoint files over the years.  I saw students – even the ones who I thought might really struggle – put commendable effort into making the thing work, so they didn’t have to copy.  I was delighted.

So, observation 1 is that they responded to the challenge fantastically well.

Observation 2 is, that it’s addictive.  They want more.  If you are thinking of Greenfoot (or anything proper-programmy) at GCSE, you have to think about what happens at A-level.  If you follow the Access-is-king model at A-level ICT, you might want to reconsider that.  If A-level Computing is a scary thought, there are A-level ICT courses that allow proper-programming for A2.  I say this because you will have students asking for programming and wanting to get away from the applications-driven stuff.  Programming is addictive, they will want more.

Observation 3: they all said they enjoyed it far more than the Access/Excel/PowerPoint stuff.  In fairness to them, I didn’t see the point of spreadsheets when I was their age – simply because I didn’t see any real purpose to the spreadsheet exercises we did.  It was only when I started teaching and had a bit spreadsheet with linked pages for class admin, that I really saw the point.  So, I wonder did they not like Excel because spreadsheets are pointless?  Or, did they not like Excel because the work we were doing simply did not grab their attention?  Likewise for Access and PowerPoint – perfectly fine packages in their own way, but not something that excites a 15 year-old.

Making a Crab wander like it is drunk, does grab their mind.

Greenfoot (5) – A hungry Lobster

One of the nice things about Greenfoot is, once a student has got their head round the basic idea of an object that is walking about, they can make their own new objects or make changes to existing objects fairly easily.  A scurrying crab can be given new artwork to become a scurrying rat.  It can be made to do different turns at the side, or different random staggers.  Very quickly, a student can fill the screen with a dozen objects that look different but have awfully similar internal code.

And that’s okay.  Because at this stage, we are doing a lot of learning-by-repetition to reinforce key ideas.  If a student is working quickly and gets bored waiting for the rest of the class to catch up with him, he can easily recreate CrabWorld as FishWorld and have randomly moving fish on a blue background.  If he’s really ambitious and wants to have the fish pout occasionally, that’s great.  If he wants a basic ‘fish’ with extensions of that model (shark, goldfish, etc), great.  To a random person walking into the room, it may look like some kid who has gone off on a tangent and who is ignoring the purpose of the class.  To me, he’s very much on-track with my objectives – making things move randomly round the screen.

Of course a game that has no interaction, just moving things, gets boring very quickly.  We need some sort of interaction.  “So, class, back to the crab and create a new object called lobster.  Get him moving randomly, just like the crab.  I’ll give you five minutes and then we’ll make the Lobster eat crabs.”

“Oooooohhhhhhh”…… they are already letting me know they like this idea.

Five minutes later, we have introduced this to the Lobster:

if (canSee(Crab.class) )
        {
            eat(Turtle.class);
        }

“Ooooh, the lobster eats the turtle…” and pennies begin to drop.  They are starting to figure out how objects in Playstation and X-box games interact.  They are moving from being end-users of stuff to becoming understanders and creators of stuff.

Back to Greenfoot-  it’s a randomly moving bunch of crabs being chased by a lobster.  Actually, nothing’s being chased – the lobster is totally blind and just stumbles on a crab now and then.  It looks like this.

But a lobster chasing crabs is, on its own, not as much fun as it could be.

So we take out all the code that makes the lobster walk about at random.  In its place, we start with:

        if ( Greenfoot.isKeyDown("up") )
        {
           move();
        }

This checks if the ‘up’ key is pressed and if it is, the Lobster moved forward.

“OK class, make it turn left, right, go forward, go backward, etc.”

…and they did.  Some even tinkered with random numbers to make a drunkLobster that responded to what you wanted, but only sometimes.  Some even had the lobster randomly to the reverse of what you wanted.  They played and played and played.  They created little challenges for themselves overcome them.  They shared ideas and it was great.  This never happens with PowerPoint, I tell you!

At this point, though, most of them had very messy code that they understood but might be confusing to other people.  Some were taking the initiative to re-write and tidy their mess.  We had no methods.  For the uninitiated, methods let us turn a very long program into a lot of smaller, easier-to-maintain programs.  Twenty lines inside the lobster’s act() method, dealing with keyboard control, should really be a single line: checkKeys(), which goes off and talks to a checkKeys() method.  Just take my word for it, it’s a lot easier to maintain and read.

So, our next challenge: tidy it up, have some procedures.  And then, like manna, did arrive Dr Michael Kölling and his fantastic Joy of Code videos.  More of that later.


Greenfoot – how did we do it? (4)

After the first few classes, we had a crab running round the screen in a predictable way.  It reaches the edge of the screen, turns, keeps going, and so on, for ever.

The next step was to give the crab a mind of its own.  Actually, we didn’t do that.  Artificial intelligence is really tricky stuff, so we faked it by making it look like the robot had a mind of its own.  If the end-product looks genuine enough, we don’t normally cares how we got there.  All we want is a crab that looks like it is out for a dander, randomly walking about all over the place.

Greenfoot gives us a method called getRandomNumber(n) – it’s basically a big multi-sided dice.  It returns a random number >= 0 and < n.  So, getRandomNumber(10) returns 0 to 9.

We start simple: a line after move(); that does a random turn.

move();
turn(Greenfoot.getRandomNumber (20) );
if (atWorldEdge())
  turn(15); 

So, each time we move the crab does a random turn, with 20 possible values (0-19).  So, it might turn 0 degrees clockwise, it might turn 19 degrees clockwise.  Not anti-clockwise, because getRandomNumber does not give us a negative value.

More important than the random movement, is the fact that the class experimented with high numbers for the movement, fractions, negative numbers and so on.  Some broke their code, but that’s okay because they immediately wanted to fix it.  Some put their hand up before trying to fix it and I told them to “Pretend I’m not here”.  By only getting involved if they made a complete hash of it, there was far more chance of them learning from their mistakes.  By letting them plough on and add functionality of they wanted, they were too busy playing and having fun to realise how much they were learning.

“OK class, we can do a random clockwise turn.  That’s good, but I’d like a random turn that can be clockwise or anti-clockwise.  Sort of like the crab is staggering all over the place.  What do you think?”

They had a think.  Some tried things like Greenfoot.getRandomNumber(-20) or Greenfoot,getRandomNumber(-20:20).  Credit for innovation, but it does not compile.  getRandomNumber deals with a single positive number only.

Then a couple of people had the same idea, together.

“Sir, suppose getRandomNumber sends back a number between 0 and 19… could we take 10 off each time.  So, instead of a range of 0-19 it is shifted down to become a range of -10 to 9.”

Bingo.

move();
 turn(Greenfoot.getRandomNumber (20)-10 );
 if (atWorldEdge())
   turn(15); 

We now have a crab doing proper random turns.  Some went further and had the if (atWorldEdge()) turn using a random number.  Some even had the crab walking left and right, back and forth, walking like he was very, very drunk.

More pleasing than the drunken crab, was the mutterings of “Cool”, “This is fun”, “Let me see how you did that- I want mine to do that too.”  Or, “Motivated learning” and “Peer review” to use the official terminology.

Next time: a hunger Lobster.  With keyboard control.