[FoRK] Greenfoot: Java IDE/replacement for Gamemaker
<meltsner at alum.mit.edu> on
Tue May 8 08:43:51 PDT 2007
My 11 year old survived his time with Windows and Gamemaker -- he
found GM exceptionally frustrating since the UI is sort of
inconsistent, oddly labeled, etc. The tool itself was mostly stable.
I have high hopes for the recently announced Greenfoot, a GMish IDE
for Java. It was created by the same folks that were responsible for
BlueJ, a beginner's Java IDE.
What is greenfoot?
Consider greenfoot as a combination between a framework for creating
two-dimensional grid assignments in Java and an integrated development
environment (class browser, editor, compiler, execution, etc.)
suitable for novice programmers. While greenfoot supports the full
Java language, it is especially useful for programming exercises that
has a visual element. In greenfoot object visualisation and object
interaction are the key elements.
If you know BlueJ and a microworld framework (like Karel the Robot or
the AP Marine Biology Case Study) consider greenfoot as the best from
both: object interaction (BlueJ) and object visualisation
Read on for a more detailed description, or take a look at the
screenshots to see what it looks like.
The framework can be used to create a wide range of programs that can
be visualised in a two-dimensional grid. Popular examples of such
programs often used in an educational setting includes: The 8 Queen
Puzzle, Karel the Robot, Conway's Game of Life, The AP Marine Biology
Case Study and Turtle Graphics,
The framework in greenfoot has two main responsibilities:
1. Make it easy to create graphical representations of objects.
2. Control the execution (start, stop, step) of a simulation loop.
To accomplish these things the greenfoot framework supplies a base
class GreenfootObject which should be extended by all classes that
wish to visualise themselfes. The two most important methods that must
be implemented are the getImage() method which should return the image
of the object, and the act() method which will be called in each step
of the simulation loop.
When you browse the rest of this page, you will often encounter the
term scenario. Scenarios are a set of classes typically created by the
teacher/instructor that implements the base classes for a specific
application. The idea is that the student gets an interesting
framework that can be modified and extended to create even more
interesting functionality. A scenario could for instance be one of the
programs mentioned above. Below you can see screenshots of a turtle
graphics scenario and a Karel the Robot scenario.
Turtle Graphics Scenario
Turtle Graphics Scenario
Karel the Robot scenario
The integrated development environment
The greenfoot environment contains the typical elements of a
* A source code editor
* A class browser
* Execution control
* A debugger
In addition greenfoot can visualise the objects from a greenfoot
scenario, and interact with these. It can control the execution of the
execution loop of a greenfoot scenario.
The most important feature of greenfoot that sets it apart from other
development environments is the direct interaction. The direct
interaction is available on both classes and objects as is
To instantiate a new object you select the desired method from the
context menu on a class like this:
This gives you the newly created object on the mouse cursor and you
can place somewhere in the world:
Objects can be interacted with in a similar manner. Invoke the context
menu and select the method you want to invoke:
If the method changes a state that is visualised in the graphical
representation of the object, this is imediatedly reflected:
Who should use greenfoot?
Greenfoot is aimed at high school level or below. When designing the
greenfoot system we tried to consider both the students and the
The students at high school levels might not be as commited to
programming and we have tried to create an interesting program that
should engage the student. In order to do this, we acknowledge that
students has different opinions on what might be interesting. Hence,
we sought to create a flexible environment that could be customised
for the specific group of students. Furthermore, in the design of
greenfoot we considered the different learning styles of students.
The teachers/instructors in high schools can't be expected to have a
lot of time and skill, so the customisation (creation of
scenarios/exercises) is made as easy as possible. In the future, we
hope that many different scenarios will be available, so the teachers
can just select the scenarios that best fits the students.
maintained by Poul Henriksen and Michael Kölling.
More information about the FoRK