This last semester I used the
Greenfoot framework as an integral part of my high school computer class. It was an experiment to see what it could do for the students compared to the way that I've taught my class in the past. Based on the results that the students achieved, I'd have to say that Greenfoot was a very good addition to our class, with only a few reservations.
In my high school computer class, I spend the fall semester on basic computer skills, background knowledge, horizontal applications, and basic networking and communications knowledge. The highlights of the semester are class-produced websites (last year's are visible
here), and a document including text, graphics, and tables which is a proposal for a video game concept. For the websites, I have each student produce a basic set of linked web pages individually while we learn rudimentary HTML and CSS, then the students are grouped into teams for the main website project. The game proposals are produced individually, and I have each student give a presentation to the class of their proposal.
The Problem: Getting GraphicsThe second semester of the class moves on to computer programming. For this we use the Java programming language. It's not perfect for our needs in class, but it works well enough,
as I've discussed before. One problem I've had with using Java as a teaching language is that while it has graphical abilities, they are so generalized that the learning curve for using them is difficult to manage in the limited class time we have. I want to provide at least a basic sense of what's happening in the computer when programming--all that stuff about data types, data structures, algorithms and so on--but still have sound and graphics available for the students since they provide a lot of motivation, as well as giving a source of feedback to students on what their program is doing that is more visceral than text. Likewise, different students respond to different stimuli. Some can perceive patterns in text, but more often they're more prepared for perceiving them in images or sounds. So this sort of program output can be critical in whether a student "gets" what a program is doing when it runs. I've discussed this in more detail
before.
With the simple, constrained systems of the past, e.g. Apple II, Commodore 64, Atari 800, etc., accessing basic sound and graphics was easy compared to present day systems. There are still BASICs available today that provide the same sort of access, but they're also more divorced from mainstream programming than was the case 20 years ago. Java, while a relatively simple language in many respects, takes a very generalized approach toward graphics and requires a substantial amount of program infrastructure for graphics which is a distraction and source of confusion to new programmers.
Greenfoot: The Answer?Enter
Greenfoot, a framework for Java with design goals directly in line with my needs, it would seem. I admit to having some
concerns and misgivings as I was preparing to use Greenfoot in class. Prior to the start of the year, I had two students
try out Greenfoot over the summer. At the end of the first semester, the class members gave their video game proposal presentations and the class selected
four games for development.
Now the semester is over and I've got time to reflect on the results of the year.
The games have been completed and posted to
the Greenfoot Gallery. You can see what the students themselves had to say in their development blogs, linked below.
Army of One: Stoner WombatsOne of my students was having trouble meshing with a working group. After trying a few different arrangements, I ended up putting him on his own to work on an individual project. Since he was working alone, and had less time on his project than the other students, his project is far less developed than the others. Still, once on his own he was able to apply himself and showed the initiative to solve some programming problems he ran into in attempting to implement his ideas in his game. Here's his game:
Stoner WombatsNever Say Die: Offroad Xtravagaanza Becomes The Art of Clay PigeonsOne of the groups started with an ambitious idea for a motorcycle simulation. They wanted something like the popular side-scrollers that simulate a motorcycle's balance and suspension while traveling over an obstacle course. I allowed the group to go ahead with the idea, and we worked hard on trying to divide the problems in implementing the simulation down to a scope that they could implement. However, the problems with learning the details of programming and debugging coupled with the difficulty they had in developing mathematical models for the simulation stymied them. They made significant progress along some paths, only to be stopped on others.
They then changed their objectives, changing the game to a top-view track racing game. Again they made substantial progress, only to run into problems with movement control and collision detection in their code that they weren't able to beat within a reasonable time.
So they stepped back once more, started with a working codebase (the ballon-popping demo scenario), and began modifying it and adding features. Even though they were weeks behind the other teams at this point, and shorthanded, they made good progress and turned out a good game.
The Art of Clay PigeonsArt of Clay Pigeons Development BlogOverall, I'd say this group had the most "educational" experience. As I mentioned, they did solve a lot of problems toward each of their prior goals. Though the process was very frustrating for them, they managed to maintain a good attitude and positively move forward from each failure.
Modularity is Our Friend: Day 3Another group started out with a very basic idea for a shooter that needed a lot of fleshing out. They also ran into development problems, with collision detection and with hitting a mental limit on data structures. They managed to maintain a central base of working code, however, so their game didn't change as much through the course of development as the Art of Clay Pigeons/Offroad Xtravagaanza team. They began development of several different sets of possible features in parallel, then used the advantages of OO programming to add each to the central codebase, experiment with it, test interactions with other features, and then decide where to go.
They followed a very iterative process and learned to be fairly conservative about connecting ideas with their ability to implement them. They managed to apply some basic data structures to their game, notably Lists. They had other ideas for which I suggested more sophisticated data structures, but they decided they'd rather "limit their risks". Some of the students who worked on this game, "Day 3", have stayed in contact, and I know at least one update has been worked on since school ended, so this game may continue to develop. I know one thing they'd like to do is put one of the lines of work they had near completion that didn't quite make it in by the end of class into the game. So Day 3 may continue to develop:
Day 3Day 3 Development BlogSuccess by Design: Farm FrenzyThe remaining project ended up looking almost exactly like its original design. It was consciously designed as a modification of a classic video game (Pac-Man), and it avoided some of the problems the other teams ran into by sticking with large cells in the playfield. The team did a great job with this, with one of the team working out many of the little details outside of class, then coming in with sheets of layout information on graph paper and pseudocode ready for implementation.
Farm Frenzy, a.k.a. The Purple Piggy GameFarm Frenzy Development BlogResults: PositiveI have to say that I'm really pleased with how things turned out. All class members were able to contribute constructively to their team projects, and all teams were able to complete a game that actually runs and get it posted on the Greenfoot Gallery. I had my doubts, especially when one team was halfway through the last class without having yet even gone through the process of exporting their game from Greenfoot, much less posting it online. They rallied, however, and managed to get in under the wire.
Greenfoot worked well for giving students visual feedback on their program work, and it made the class fun and interesting for them. Overall I'd say motivation levels were higher than in my prior classes, in that a higher proportion of students were engaged with developing new ideas and seeking to implement them in code.
Greenfoot didn't prevent me from teaching more sophisticated programming concepts in class, but it did somewhat limit the scope with which I could approach them. Students were willing to follow discussions of the use of data structure objects, but they also wanted to "get back to work", so we weren't able to dig in as deeply in these area as I have with prior classes. We did manage to cover the basics, however, and I didn't see any reluctance to open up the Java API reference, or the API reference for Greenfoot, either. Overall, I'd say that the class moved into using data Objects faster than before, but didn't go as deep or into as broad a range of data structures as in previous classes. They did show that they understood what they were doing when they used Objects and Interfaces like List, though. They were able to deal with types, iterators, and selection of elements. So I'm satisfied that the important lessons were learned.
Problems EncounteredOur problems with implementing ideas in Greenfoot were a mix of things. In part, it was through our collective inexperience with Greenfoot that we didn't always conceive of things in a way congruent with how Greenfoot handles them. In other cases, we ran into problems when trying to implement things in ways that I've used in the past, particularly collision detection, that for whatever reason didn't appear to work in Greenfoot. Greenfoot is well suited for cell-based game models, it is more difficult to implement what might be called "small cell" models with pixel-level movement and control, or something close to it. Small cell models without "terrain" effects, such as space simulations don't seem to be as much of a problem. Other than that, for new programmers it seems best to stick with large cell games, where each player or game object occupies one cell on the playfield, and all interactions are based on occupation of the same cell or adjacent cells.
I had to write a fair bit of code myself outside of class to assist students with solving problems or developing implementations. I'll be writing more code before we start again next year, so that I've got a better handle on what it takes to solve some of the problems that we ran into last year. Especially dealing with collision detection. With this I'll be better able to guide the students in understanding how much work it'll take to implement their ideas, and help them make better decisions on how they design their games.
I expect to write more on my experiences using Greenfoot in class as time goes on, and provide some of the example scenarios I've developed. For now however, I have to say that I've quite happy with how Greenfoot worked in my class and I'm looking forward to using it again next year.
You Can't Argue with the Price (or License)On top of that, thanks to the fact that Greenfoot is free, it allows me to have students create video games without using one of the commercial instructional development systems that have license fees that come out of our school's limited budget. And in this case the lower cost does not result in a reduction in the value of the product, much the opposite. The commercial systems that have been used by other instructors at our school in the past have no connection to real world programming languages, and the games require the system's runtime package to operate. My student's Greenfoot games, on the other hand, are written with their logic in Java, and are easily packaged for independent distribution as Java executables as well as web distribution.
Thumbs UpFinal word: Greenfoot's good stuff. If you're teaching introductory level computer programming, it's worth giving a try.
Posts
Webomator.com: Backward into the