Programming Contest: The Greeps Are Coming!

Yolande Poirier-Oracle

by Michael Kölling

A fun competition that teaches Java programming and computational problem-solving

I wrote a series of articles for Java Magazine that introduced Java programming with Greenfoot, a programming environment for novices that lets you create simulations and games. In those articles, I discussed aspects of Greenfoot, as well as some aspects of learning to program in Java. In this article, we will apply what was discussed in those articles to have some fun: creating a programming contest involving alien bugs.

If you have been reading Java Magazine, you are likely not a novice programmer. But many of us are in situations where we want to show others how to program, show people the excitement and enjoyment that comes with getting your code running, and teach them how to write Java. All of this works best with interesting, exciting, fun examples. This article provides an example you can use. It does not matter whether you are running a coding club, helping out with programming in your kid's school, teaching your own son or daughter to write Java—or even wanting to learn Java yourself. Whenever you have one or more kids that you want to motivate to really get into writing some code, you can use the Greeps contest. (I use the term kids in the widest possible sense: I mean kids of any age! This probably includes most of us…)

The programming experience needed to tackle this example is quite modest: you need an understanding of variables, method calls with parameters, and if statements. That's about it. However, don't let the simplicity of the constructs fool you: the task itself, while it can be started easily using some basic ideas, can be improved considerably with some intelligent strategy. It is not all simplistic!

This exercise not only teaches Java—it gives people practice in computational problem-solving. The age range for which this example can be used is from about 13 years upwards. However, it works equally well with older age groups. (And, be warned: the competition is highly addictive! Even if you are an experienced programmer, you might have some fun attempting this task. And once you start, you know how it is…)

The Story

Greeps are alien creatures, and they've come to Earth! One of the important things to know about greeps is that they like tomatoes. They have landed with their spaceship and are swarming out to find and collect tomatoes (Figure 1).

Figure 1. What greeps look like.

The challenge in this programming competition will be to program your greeps so that they find and collect tomatoes as quickly as possible. You will have limited time, and every tomato you manage to bring back to the spaceship scores a point.

The Practicalities

You can use this exercise in a competition against a friend who programs his or her own greeps. Or you can use it with a group of people in a coding club. If you are on your own, you could post your entry to the Greenfoot website to see how you compare to others who have posted there. (However, if you post to the Greenfoot site, please do not include source code. Instead, post an executable version that others can see and run to compare their score and their code's behavior. We want to keep this as a programming challenge for others and don't want to make it too easy to find solutions.)

Getting Started

To start, download the Greeps scenario file, greeps.zip, and open it in Greenfoot. Then run it.

When you run the scenario, you will see that a spaceship lands in an area with sand and water. The greeps will come out and start swarming around in search of tomatoes. By a magnificent stroke of luck, there are some piles of tomatoes in the area.

Greeps are land animals; they cannot swim. You will see that they will not go into water. If there is a lake in the way, they have to walk around it.

When you try out the program as it is, you will quickly notice that the greeps are not very smart: they swarm out of the spaceship in random directions, but when they reach the edge of the water (or the edge of the screen), they stop. They cannot go forward, so they don't know what to do.

Your task in this competition will be to program the greeps to give them more-intelligent behavior, so that they are able to walk around, explore, find tomatoes, and bring tomatoes back to the ship.

There are a few things about greeps that you should know:

• There are 20 greeps in the spaceship. They will come out after landing to start their work. You cannot get any more of them.
• Greeps can carry a tomato on their back, but they cannot load tomatoes onto their own back. They can only load a tomato onto another greep's back! This means that two of them have to be at the tomato pile at the same time to pick up a tomato.
• Greeps cannot talk or communicate verbally in any way. They can, however, spit paint onto the ground. And they can spit in three different colors (see Figure 2)! There are rumors that there once was a tribe of greeps who used this ability to convey information to each other.
• Greeps are very short-sighted. They can see only the ground at their immediate location and they cannot look any further.
• Greeps have a good memory—they never forget what they know. However, unfortunately, their memory is very limited. They can remember only a few things at a time.

Figure 2. Greeps can spit three colors of paint.

With this background knowledge, you are practically a greep expert and can get to work programming your own greep behavior.

The Rules

To modify the behavior of the greeps, you improve the code in the Greep class. There is already some (very simple) behavior present that you can look at to get started.

When you look at the scenario, you can see that Greep is a subclass of Creature. The Creature class provides some very useful methods that you can use; have a look at what is there.

There are some rules that you must follow:

• Rule 1: Only change the class Greep. No other classes may be modified or created.
• Rule 2: You cannot extend the greeps' memory. That is, you are not allowed to add fields (other than final fields) to the class. Some general-purpose memory (one int and two booleans) is provided.
• Rule 3: You cannot move more than once per "act" round.
• Rule 4: Greeps do not communicate directly. They do not call each other's methods or access each other's fields.
• Rule 5: There is no long vision. You are allowed to look at the world only in the immediate location of a greep. Greeps are almost blind and cannot look any further.
• Rule 6: There is no creation of objects. You are not allowed to create any scenario objects (instances of user-defined classes, such as Greep or Paint). Greeps have no magic powers—they cannot create things out of nothing.
• Rule 7: There is no teleporting. Methods from Actor that cheat normal movement (such as setLocation) may not be used.

It is important to follow these rules. It is technically easy to break them, but we consider that cheating. Where's the fun in that?

To program the greeps, you will work mostly in the greeps' act method (and any other private methods you choose to create).

Some Tips

• Read the documentation of class Creature. (The best way to do this is to open the class in the editor and switch to the Documentation view.) These are some of the most useful methods for your work. Know what is there.
• Work in small steps. Start making small improvements and see how it goes.
• Some first improvements could be as follows: turn around when you are at water, wait if you find a tomato pile (and try to load tomatoes), turn if you are at the edge of the world, and so on.

You will soon figure out many more improvements you could implement. It gets especially interesting once you start using the paint drops on the ground to make marks for other greeps to find.

Running the Greeps Project as a Competition

The Greeps project is great fun if you run it as a competition. To do this, it is best if there is a judge who can coordinate things. In a school, this can be the teacher. If you do this with friends, the judge can be one of your friends (but this person should then not take part in the competition).

To make the competition interesting, there should be two versions of the Greeps scenario. One gets handed out to all contestants. (This is the one that was downloaded earlier.) This scenario includes three different maps. The greeps land and forage on each of the three maps in turn. (So the challenge for contestants is to develop movement algorithms that are flexible enough to work on different maps, not just on a known map.) The judge should have a different scenario that includes more maps. I recommend running the competition with 10 different maps. Contestants do not get access to the last seven maps—they can test their code only on the first three. Then they hand in their greeps for scoring, and the judge then runs the contestants' greeps on all 10 maps (maybe on a large display screen) to reach the official score.

The competition is best run over several days (or maybe a week or two), with repeated chances for contestants to submit their work for scoring, so that they can slowly improve.

Technicalities

For submission of an entry to the judge, the easiest mechanism is that contestants submit only the Greeps.java file. The judge then copies that file into his or her full (10-map) scenario, recompiles the code, and runs it. This ensures that no other classes are modified in the process.

Some artwork (to make flyers or posters for the competition) is available at http://www.greenfoot.org/competition/greeps/.

Instructors can also find instructions there for obtaining a version of the Greeps scenario with 10 maps. Alternatively, instructors can make more maps themselves fairly easily. An image of an empty map is provided in the images folder of the Greeps scenario. Water can just be painted onto the map, and map data (for example, the location of tomato piles and so on) can be specified in the Earth class.

Conclusion

A competition—whether run against yourself or against others—is a great way to have fun when programming. This particular one will let you use some fairly simple Java constructs and hone your problem-solving skills. It's great fun; you will see when you start.

The Greeps competition is part of the Greenfoot book and is discussed in more detail there (as are many other programming projects).

See Also

• Greenfoot download page
• Greenfoot book

About the Author

Michael Kölling is a professor at the School of Computing, University of Kent, in Canterbury, England. His research interests are in the areas of object-oriented systems, software tools, programming languages, computing education, and HCI. He is the author of two Java textbooks and is the lead developer of BlueJ and Greenfoot.

Join the Conversation

Join the Java community conversation on Facebook, Twitter, and the Oracle Java Blog!

TPD-Opitz

postulating rules 1 and 2 you are teaching a lot but not good OO programming practices and therefore no good java programming.

I'd like to separate different parts of the logic in classes of their own which usually live in their own files. Also your rules do not allow for unittest, which is also a very important "best practice" in modern software development.

So thanks for the effort but I think it is heading in the wrong direction.

bye

TPD

Andy Bailey

I think the idea is that young people are meant to be motivated to get involved. Shoving Agile Development down their throats is going to be counter productive.

I have been involved in teaching young people programming and this kind of framework is ideal

- You only need to concentrate on changing one thing

- results are visible immediately

- you are testing as you go: my Greeb doesn't do what I want it to do, I change things and see what happens. Sounds like testing to me even if it isn't unit tests.

- you are being encouraged to use existing code: Duplication of existing logic is something I see all to often in "modern, best practice driven software development" because devs either don't have time to learn the codebase or are not in the habit of doing so.

The effort is well spent and is very much a start in the right direction.

TPD-Opitz

I think the idea is that young people are meant to be motivated to get involved. Shoving Agile Development down their throats is going to be counter productive.

I have been involved in teaching young people programming and this kind of framework is ideal

- You only need to concentrate on changing one thing

- results are visible immediately

- you are testing as you go: my Greeb doesn't do what I want it to do, I change things and see what happens. Sounds like testing to me even if it isn't unit tests.

- you are being encouraged to use existing code: Duplication of existing logic is something I see all to often in "modern, best practice driven software development" because devs either don't have time to learn the codebase or are not in the habit of doing so.

The effort is well spent and is very much a start in the right direction.

Andy Bailey wrote:

I think the idea is that young people are meant to be motivated to get involved. 

The OP claimed:

Even if you are an experienced programmer, you might have some fun attempting this task

And this is what my critic aims at. Experienced programmers should focus on avoiding procedural programming as it is supposed to be done by rule 1 and 2.

Andy Bailey wrote:
- you are testing as you go: my Greeb doesn't do what I want it to do, I change things and see what happens. Sounds like testing to me even if it isn't unit tests.

But the student misses to experience the value of good automated unittest.

One more time the OP and you support the much to common position: "Yes, unittest are good but first learn programming."

When do you think programmers should start working with (maybe not yet writing) unittest if not right from the start?

bye

TPD

Unknown

I think the idea is that young people are meant to be motivated to get involved. Shoving Agile Development down their throats is going to be counter productive.

I have been involved in teaching young people programming and this kind of framework is ideal

- You only need to concentrate on changing one thing

- results are visible immediately

- you are testing as you go: my Greeb doesn't do what I want it to do, I change things and see what happens. Sounds like testing to me even if it isn't unit tests.

- you are being encouraged to use existing code: Duplication of existing logic is something I see all to often in "modern, best practice driven software development" because devs either don't have time to learn the codebase or are not in the habit of doing so.

The effort is well spent and is very much a start in the right direction.

The effort is well spent and is very much a start in the right direction.

+1 - I agree with pretty much everything you said.

Kids don't learn to paint by learning about the different types of canvases, paints and brushes or the details of textures and shades.

They start by sticking their fingers in whatever paint jar/bin is closest and dragging them (hopefully) on the construction paper.

As they get older they start using crayons and drawing in coloring books that have boundaries between the sections teaching them how to compartmentalize the colors.

Many then go on to 'paint by the numbers' so they can work with more complicated images without having to know how to create the 'boundaries' themselves.

Ultimately those drawn to the arts learn how to create it all from scratch as demonstrated on many of the public television shows by artists such as Bob Ross:

https://www.youtube.com/watch?v=MghiBW3r65M

In old days people were taught Basic for EXACTLY the same reasons as what the OP is doing and what you stated.

The tools and rules are simple and you can get quick results and feedback.

Sure - people that tried to use those same techniques with Basic to create arbitrarily complex apps typically resulted in what was known as 'Spaghetti code' because it wasn't structured or object oriented. Those people chose NOT to make the transition from introductory techniques to the more advanced concepts that the more complex apps require.

TPD-Opitz

The effort is well spent and is very much a start in the right direction.

+1 - I agree with pretty much everything you said.

Kids don't learn to paint by learning about the different types of canvases, paints and brushes or the details of textures and shades.

They start by sticking their fingers in whatever paint jar/bin is closest and dragging them (hopefully) on the construction paper.

As they get older they start using crayons and drawing in coloring books that have boundaries between the sections teaching them how to compartmentalize the colors.

Many then go on to 'paint by the numbers' so they can work with more complicated images without having to know how to create the 'boundaries' themselves.

Ultimately those drawn to the arts learn how to create it all from scratch as demonstrated on many of the public television shows by artists such as Bob Ross:

https://www.youtube.com/watch?v=MghiBW3r65M

In old days people were taught Basic for EXACTLY the same reasons as what the OP is doing and what you stated.

The tools and rules are simple and you can get quick results and feedback.

Sure - people that tried to use those same techniques with Basic to create arbitrarily complex apps typically resulted in what was known as 'Spaghetti code' because it wasn't structured or object oriented. Those people chose NOT to make the transition from introductory techniques to the more advanced concepts that the more complex apps require.

rp0428 wrote:
                                                                                                                                                                                  Sure - people that tried to use those same techniques with Basic to create arbitrarily complex apps typically resulted in what was known as 'Spaghetti code' because it wasn't structured or object oriented. Those people chose NOT to make the transition from introductory techniques to the more advanced concepts that the more complex apps require.

IMHO the students will have a hard time to change from the "not so well" programming style to good programming practices if they don't have to change the language.

There are more than enough programmers out there thinking that Objects in java are some kind of a nagging obstruction, and unittest are for milquetoasts only...

bye

TPD

Andy Bailey

Andy Bailey wrote:

I think the idea is that young people are meant to be motivated to get involved. 

The OP claimed:

Even if you are an experienced programmer, you might have some fun attempting this task

And this is what my critic aims at. Experienced programmers should focus on avoiding procedural programming as it is supposed to be done by rule 1 and 2.

Andy Bailey wrote:
- you are testing as you go: my Greeb doesn't do what I want it to do, I change things and see what happens. Sounds like testing to me even if it isn't unit tests.

But the student misses to experience the value of good automated unittest.

One more time the OP and you support the much to common position: "Yes, unittest are good but first learn programming."

When do you think programmers should start working with (maybe not yet writing) unittest if not right from the start?

bye

TPD

You are still missing the point: to get young people involved in something it helps to make it interesting and attractive to them.

If you get experienced programmers involved then you are creating an environment with a Student/Mentor relationship without too many formalities involved.

Anyone who has experience with with working with young people, as I have, will tell you that things like this are far better suited to introducing young people to any potential professional discipline.

Trying to the turn them into professional developers right from the start will simply drive them away.

Once they decide to take up the profession then it is down to the further learning institutions to instil the disciplined approach to software development.

TPD-Opitz

You are still missing the point: to get young people involved in something it helps to make it interesting and attractive to them.

If you get experienced programmers involved then you are creating an environment with a Student/Mentor relationship without too many formalities involved.

Anyone who has experience with with working with young people, as I have, will tell you that things like this are far better suited to introducing young people to any potential professional discipline.

Trying to the turn them into professional developers right from the start will simply drive them away.

Once they decide to take up the profession then it is down to the further learning institutions to instil the disciplined approach to software development.

I understand your point that the "gamification" approach makes is easier for studens to dive into programming.

I don't understand why introducing Unittests and TDD sould distract students right away.

Again I'm not telling they should writ them fron the first day on, but we as the teachers should provide Unittests the requirement specifications.

The way students learn programming these days the learn that unittest are somehow additional work, but the should learn that unittests are essential. And they will only learn this when unittests are introduced as early as possible.

I'm sorry, but all answers I got here so far sound like: "I don't know how to include unittets in the classes so I'll skip them."

You're right, I'm not a teacher. But I see several ways to use unittests when teaching programming.

bye

TPD

venkatasundar

Kids love to see quick results with simple coding. Big rules, Methodology etc. they don't care. Plain old text Input/Ouput is boring for them. I tried to teach my 12 yr old, Python programming, though he liked it, he finds "Scratch" from MIT more interesting. Codes/constructs/templates can be dragged and dropped. He just needs to fill in the necessary part of the code and quick results.

Once they get involved, they can be thought about methodology, TDD, Agile and whatever industry best practice.

If i teach my kid, about a test driven approach, by writing a test case, then writing a test code, then Ant/Maven build to do all, he would be better off with his video games than to sit and develop one.
With "Scratch" the results were quick, and he developed a simple shooter game, he said, it was his version of space invaders.

I would wait for him to understand on, what complexity is and how to manage them, Then teaching these industry best of best practice would add value to him.
If one wants to write "how to teach kids", please teach one first and I am doing it.

TPD-Opitz

Kids love to see quick results with simple coding. Big rules, Methodology etc. they don't care. Plain old text Input/Ouput is boring for them. I tried to teach my 12 yr old, Python programming, though he liked it, he finds "Scratch" from MIT more interesting. Codes/constructs/templates can be dragged and dropped. He just needs to fill in the necessary part of the code and quick results.

Once they get involved, they can be thought about methodology, TDD, Agile and whatever industry best practice.

If i teach my kid, about a test driven approach, by writing a test case, then writing a test code, then Ant/Maven build to do all, he would be better off with his video games than to sit and develop one.
With "Scratch" the results were quick, and he developed a simple shooter game, he said, it was his version of space invaders.

I would wait for him to understand on, what complexity is and how to manage them, Then teaching these industry best of best practice would add value to him.
If one wants to write "how to teach kids", please teach one first and I am doing it.

venkatasundar wrote:

Kids love to see quick results with simple coding. Big rules, Methodology etc. they don't care. Plain old text Input/Ouput is boring for them. 

I agree,

But

Rule 1: Only change the class Greep. No other classes may be modified or created.
Rule 2: You cannot extend the greeps' memory. That is, you are not allowed to add fields (other than final fields) to the class. Some general-purpose memory (one int and two booleans) is provided.

Are useless restriction which lead learners into a wrong direction.

and in an earlier version it was also explicitly aimed to professionals too. But I can't find that in the text any more.

My point is that yungstern who master this challenge my think they know how to program in java whereas they don't know nothing about classes, inheritance, interfaces and polymorphism not to speak about information hiding, and other OO principles.

I really agree that this is a nice project to attract young programmers but it should not claim to teach Java...

bye

TPD

venkatasundar

venkatasundar wrote:

Kids love to see quick results with simple coding. Big rules, Methodology etc. they don't care. Plain old text Input/Ouput is boring for them. 

I agree,

But

Rule 1: Only change the class Greep. No other classes may be modified or created.
Rule 2: You cannot extend the greeps' memory. That is, you are not allowed to add fields (other than final fields) to the class. Some general-purpose memory (one int and two booleans) is provided.

Are useless restriction which lead learners into a wrong direction.

and in an earlier version it was also explicitly aimed to professionals too. But I can't find that in the text any more.

My point is that yungstern who master this challenge my think they know how to program in java whereas they don't know nothing about classes, inheritance, interfaces and polymorphism not to speak about information hiding, and other OO principles.

I really agree that this is a nice project to attract young programmers but it should not claim to teach Java...

bye

TPD

Hi TPD,

Its more about getting their hands dirty first, than the teaching part. Once they are interested, the kids will start learning.

This is what I have learned by teaching my kid.

Regards

Venkat.