Holiday Video Game Classics

It's that time of year. The music starts playing in the stores. The decorations go up. You come home, have a look in the closet, and find your old video game systems there waiting for you.

I don't know why it is, but this time of year seems to turn our minds back to games past. Pac Man, Super Mario, Donkey Kong. Just yesterday I had a friend over, we ended up doing a tour of my old video game systems. Later my daughter came to me. She'd been going through her old Gameboy cartridges, finding old friends in a dresser drawer. (I play my Gameboy games with my GameCube adapter, which puts them up on my 55 inch TV. No squinting for me any more.)

The problem is, how do you hook up these older systems to the new TV you bought in the meanwhile?

Fortunately, I've got an entire web page on hooking up your classic video game or computer system to your TV. So you can not only hook up your old Atari or Nintendo, but also your Commodore 64, Apple II, Atari 800, Vic-20, or whatever.

If it's gathered some dust, or got put away with finger smudges on it, I've also got a page on caring for your older electronics.

I love the old stuff myself. I know I'm not alone. When we have guests over the holidays, I can't tell you how much fun we have playing fun, simple old video games like Ms Pac Man, Pong, Shadow Squadron, Space Invaders, and so on. Even Katamari Damacy is on the old-time play list now, though the PS2 hooks up to our modern TV just fine--this year. In a few years I'll probably have to create a web page on that, or a page on building a video modification to allow PS2 players to relive favorite moments with their older game system.

We gotta keep bringing our old friends along into the future with us, right? ;)

Greenfoot's Greenroom: What a Bonanza!

I finally got around to registering for The Greenroom, a support area for teachers using the Greenfoot framework for Java in their classes. All I have to say is, Wow!

If you're a teacher using Greenfoot, or thinking about it, take the time to sign up for access. Access is limited to those who can show some bona fides to show that they're teachers, not sneaky students trying to wreck the teacher's lesson plan. ;)

That's what kept me from signing up for some time, I just didn't take the time to dig up something with my name on it at my school's website to show my status. Well, I finally took the time to do it, and now I wish I'd bothered a long time ago!

The resources available include a wide selection of very well presented lessons, exercises, and information on using Greenfoot with Eclipse, etc., etc. Then there's the discussion boards. I follow the Greenfoot and BlueJ mailing lists, but the Greenroom discussions have an extra dimension to them, particularly from the teacher's perspective.

If that's not enough, that's also where to find the announcement of the forthcoming Greenfoot 2.0! My excitement about Greenfoot 2.0 is the new editor, with syntax highlighting and code completion. I can't wait to get my hands on it, I'll post about it when I do.

Class Projects: The Good, the Bad, and the Future Value

In my prior post about the student projects posted from Cornell's ECE 4760 program, I mentioned how nice it is, as a teacher, to see these reports and get a sense of how what I do with my classes compares. Class projects have their limitations, but they're tremendously valuable for the students.

The Good Parts:

• Allows students to develop and build on their own ideas.
• Lets them exercise the knowledge they've gained.
• Gives opportunities to discover gaps in their knowledge.
• Introduces time and resource constraints to practical work.
• Teaches teamwork skills.
• Opens up "teachable moments" not accessible through regular classwork.

The (sort of) Bad Parts:

• Time and resources are never sufficient.
• Substantial amounts of effort can be expended on fruitless effort.
• Non-self starters can falter easily.
• Much of the class grade rests on work patterns with which many students are unskilled.
• Teams don't always gel.

I say "sort of" bad, because these are the same sorts of problems that are encountered outside the classroom. In the classroom, the cost of failure is a less than sterling grade--and not even necessarily that. Failure in the classroom is not the same as commercial failure. A non-working project does not necessarily result in a poor grade (though one that works as planned will usually garner a better grade.) The classroom is a good place to be pushed and challenged.

The Future Value:

• Lessons learned when doing projects are often more valuable outside the classroom, in terms of time spent, than much else that is done in the classroom.
• Recognition of the value of people and communications skills alongside technical skills.
• Understanding that technical work must be accomplished to have success, even in the face of uncertainty.
• Learning to build on strengths, rather than be halted by shortcomings.
• Experiencing how great the gap is between a technically successful demonstration and a finished product.

The road to a finished product is seldom traveled to its end in a class project. There just isn't time in most class schedules, even if the students spend time outside class working on the project. However, a sense of the length of that road is obtained, I find. And a new appreciation for the effort that goes into the "second 90%" of work on a product is developed.

In my class, the teams get a chance to see what happens when actual users lay hands on the project results as well. The developers of a program have to watch silently as members of another team try to use their product. They get to learn more in 20 minutes than I could give them in hours of lecture.

The best part of class projects, in my opinion? It's a lot more fun than limiting a class to assigned classwork. I try to spend as little time on teaching the necessary material as possible before setting my students loose to discover on their own. It's something that not only do I enjoy more, but my students, so long as they keep the project in perspective, can enjoy a lot more than assigned work. It's very jarring for some to be set loose this way, but once they're helped over the hump everyone has a really good time with it.

Plus, they get to have an actual thing out there with their name on it. Something they can point to and say

"I did that."

Another Semester with Greenfoot

Greenfoot continues to be a productive tool for my high school computer classes. This year we had two students with a strong programming background in the class. This turned out to be both good and bad for the teams. In both cases, the experienced programmers tended to dominate the teams and their work. They became a bottleneck in both teams to one degree or another.

I spent more time in class on project management than I have in prior classes to help deal with this. It worked well, but it didn't relieve all the problems the teams had.

In my classes, I do as much as I can to allow the students to organize themselves and run their own projects. At the high school level, I feel the students are ready for more autonomy as well as the opportunity to struggle with their assignments. I still put up some "guard rails", but as much as possible I let them run their own project teams.

Each team had a unique set of problems to overcome. In both cases, they managed to produce a playable game in spite of the problems. I managed to get every student to spend some time hands-on with their project's code and gain confidence in their ability to code on their own. And in spite of the groups' problems, both teams managed to stick to the class schedule. I build in a small amount of slop time at the end of the project schedule, but for the first time since I've taught this class, the teams had complete working code at the end of the scheduled time.

The high school team projects for the semester are online. We had two development teams:
"Bubbles" was developed by Ryan, Keeghan, and Coleton.
Team blog at: http://anysomething.com/blog/
Finished game is online at: http://www.greenfootgallery.org/scenarios/1416

"Qake" was developed by Eva, Caroline, Ian, and Jeremiah
Team blog is at: http://qakedevelopment.blogspot.com/
Finished game is online at: http://greenfootgallery.org/scenarios/1417

These links are also available on the class web page at: http://acedev.com/education/hscomp.html

A Semester with Greenfoot

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 Graphics

The 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 Wombats

One 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 Wombats


Never Say Die: Offroad Xtravagaanza Becomes The Art of Clay Pigeons

One 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 Pigeons

Art of Clay Pigeons Development Blog

Overall, 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 3

Another 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 3

Day 3 Development Blog

Success by Design: Farm Frenzy

The 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 Game

Farm Frenzy Development Blog

Results: Positive

I 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 Encountered

Our 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 Up

Final word: Greenfoot's good stuff. If you're teaching introductory level computer programming, it's worth giving a try.

Game Development with Greenfoot: Class Projects

In my high school class we've started developing some games using the Greenfoot framework for Java. We have three teams of four students, each working on one game. We ended last semester with each student creating a proposal for a game and presenting it to the class. After the proposals were given, the class members each voted secretly on the games they would like to develop, listing all the ones proposed from the one they're most interested in working on to the one they're least interested in.

The voting itself was interesting. I was surprised by the number of students who did not vote for their own game as their top choice, or even in their top 6. Only 4 students voted for their own game first, and one other voted for their own as their #2 choice. The rest all voted themselves down below #6.

We had one game that several people liked, but the creator didn't. Otherwise, the games that drew the top votes were only ones that the creator chose as their #1 pick. When I was putting together the teams, it was pleasant that everyone got on a team developing one of their top 3 picks. In fact, 8 of the class members are working on their #1 pick.

Each team is headed by the game's creator, who takes the role of producer in the team.

The games that got selected for development are:

Day 3
Day 3 is planned to be a side-view arcade shooter with stick figure graphics.

Farm Frenzy
Also known as "The Purple Piggy Game", this is an arcade maze game.

Off-Road Xtravagaanza
A side-scrolling motorcycle simulation, this is probably the most technically challenging of the games to implement under Greenfoot.

Each of the teams has gotten off to a good start. As you can see from the links above, two of the teams have gotten development blogs started, and the third isn't far behind (they've had some team members absent, slowing their progress a bit.) We're presently interleaving our work on the games in Greenfoot with lessons on Java and Greenfoot. So far this has been working out well, though we're still at a very early stage at this point.

One of my biggest fears has been poor workload balancing among the team members. So far the teams have been managing this well on their own. Some of the class members combine a "take charge" mentality with strong skills in both programming and art, so my fear was that they'd be doing the work while the others stand around wondering what exactly they're supposed to be doing. Fortunately enough of the class members feel like they've got something to contribute to their projects that they haven't been feeling left out.

With respect to Greenfoot I've been able to largely concentrate on its mechanisms for teaching and developing objects in our class's formal lecture. With the features of the API, I've been able to simply point students in the direction of the API documentation, programming manual, tutorials and videos for Greenfoot and leave the rest up to them.

The Macs we have in the lab have been the most popular systems for development. We only have four, and they get mobbed. Then, at any given time, we have another 4 Windows XP systems in use, as well as 2-3 systems booted with a Ubuntu LiveCD (mostly for running The Gimp.)

Merry Christmas!

Here's wishing everyone a wonderful holiday. I hope you got some great computers, free OSes, preinstalled software development packages, and clean compiles with no errors and no warnings worth mentioning.

While you're preparing for the new year, you're going to need a way to keep track of the date. You could do a lot worse than to pick up a Traveller calendar. It's got great science fiction art contributed by amateurs. Not that you can tell by the quality of the art. I've seen worse--far worse--in many professional publications. I've got one hanging next to me here at my post, I'm looking at the ship Azhanti High Lightning by Andrew Boulton now.

It's been a great holiday for us, and it's not even over yet.

The last couple of classes I had my Middle School computer class playing a MUD in the classroom. We had a good time, and the kids didn't even realize they were getting educated in the process.

My high school class was finishing up their proposals for video games, it looks like we're going to have some great ideas to work with. Even some of the really simple game ideas have some interesting twists to them. When school starts up again they'll be giving their presentations (assuming they still remember what they were doing ;) and we'll be selecting the games we'll be developing once we get through some Greenfoot tutorials and some Java basics. But the high schoolers found out the middle schoolers have been playing the MUD, so I've promised them a few classes of MUD before we start programming. After we've done some Greenfoot, though, I wonder if they'll regret it. :)

Preparing for Programming (with Greenfoot)

In my high school computer class we're starting to look forward toward next semester when we begin programming. I like to have an assignment in the first semester of class where the students prepare a document with images, tables, and such. If possible I like to make it something they're actually interested in writing. And I have them tie the paper to a presentation to the class.

This year and last year I have had that paper be a design document or design proposal for a video game. This year we're going to actually use the proposals. The students will be presenting their video game concepts to the class, they'll get feedback and an opportunity to touch up their presentations then present them again. After that we'll vote to choose which games we'll actually work on developing next semester, and form small development teams to work on them (students with less of an interest in programming and more of an interest in art will be put to work producing visual resources for the programs they're interested in working on.)

In spring semester, we're going to be programming with Java, and this year I'm adding Greenfoot to the curriculum. In the past we've only managed to do a little bit of graphics in the time we have. I'm hoping that with Greenfoot we can make graphics and sound a much more integral part of our work. I've already got the students familiarizing themselves with what Greenfoot can do, so that they don't expect to develop full 3D first person shooters in one semester of introductory programming.

I've had them visit the Greenfoot Gallery to see what others have done with Greenfoot, and we've talked about how ambitious it would be for them to develop different types of programs. I've asked them to organize their design documents to have a core functionality described in the body of the document, with possible extensions described in an appendix. So hopefully the proposals will be developed enough to be interesting without being overly ambitious.

Since I first looked at Greenfoot the materials for learning how to use it have grown. There are a number of videos added to the video library they maintain. Likewise, the other documentation has grown, and the Greenfoot mailing list is quite active.

One of my middle school students has decided to take on Greenfoot on his own outside class. He saw the link on my class website, got interested and downloaded it for himself. He needed a hand getting the Java SE JDK installed on his home system, but with some basic instructions and the loan of a disk to save him the download time he's got that running now, it seems. He's worked through a few of the tutorials, it'll be interesting to see what he produces.

At this point I intend to teach only the most basic elements of running and compiling Java programs at the command line before we jump into the Greenfoot tutorials in class. It will be interesting to see how things go. Will Greenfoot drive an interest in learning how Java works to obtain desired results in the students' programs, with learning of Java smoothly interleaving with the work in Greenfoot? Or will we hit a plateau where we have to backfill with more formalized teaching of Java before we move forward? It will be interesting to see how things work out.

Either way, we'll certainly keep it fun.

Greenfoot: Further Examination

Greenfoot is a Java framework and IDE designed for introducing high school students to programming. Since I teach just such a course, it's of considerable interest to me. As I mentioned in an earlier article I have started trying it out. I have a pair of summer students who have been using it for the past 3 days, and I have been working with it myself.

I approached Greenfoot with some ambivalence. It looks like more than I could hope for, teaching OO concepts through graphics, allowing easy first-day programming, while teaching a real language and not heading the student into a dead end teaching language.

However, the concern that nagged me was whether Greenfoot was too "candy coated." Would students use it only at its lowest levels and not want to move from treating it as a game console to using it as a development system? Would there be a gap between the demo materials and further progress?

I've worked with several other systems in the past where this has been exactly the case. They do something very limited very well, then require a big jump in knowledge to advance that ends up taking more effort than learning without the system would have.

There's also the matter of how well any knowledge earned within an artificial system translates into skills outside the system. All too frequently students end up knowing the classroom system, but not able to translate that into something useful outside of class.

I work very hard to avoid this. There are a plethora of packaged systems that make the teacher's job easier, but do nothing for the students, or worse, waste their time and energy and leave them discouraged. I prefer using real world materials in class. There are seldom good classroom materials available for these, so it takes more work. Also, I have to be careful about the scope of what we do in class. It would be easy to overwhelm the students and end up doing as much harm as a poorly made pedagogical system.

But I would rather have a class of limited scope that teaches practical methods than one that just fills checkboxes.

Enter Greenfoot. It's made by the same folks who made BlueJ, an educational IDE that I really like a lot. Its mechanisms for interacting with classes, objects, and methods looks like a perfect solution for visually demonstrating these concepts in class. It provides a development framework that lets students jump right in on graphics programming. The developers have stated they want to make learning to program as fun and straightforward as it was in the days of BASIC. If I didn't know better, I'd think they got their specification by reading my mind.

Reality check. I've made mistakes before. I've gotten overenthusiastic about something, and missed obvious flaws. I've got a scar for every point I made about flawed pedagogical systems above. There are gaps between intention and result, between desire and ability. My own judgment is flawed. I'm an experienced programmer, and though I've developed an artificially-derived beginner's viewpoint as an experienced instructor, it's not an actual beginner's viewpoint.

That's where testing with real students comes in.

I've got two students, ages 13 and 16, who have spent three class sessions with Greenfoot now. I haven't been running things the way I would in a normal class. Rather, I've been seeing how much Greenfoot can do for them with the least involvement on my own part.

Both students had made a start in Java before I introduced them to Greenfoot. The younger one had done exercises from a textbook using a graphical editor and command line tools. She had also done some minor programs of her own design, but generally hadn't shown any inclination to develop her own programs even though she has expressed interest in becoming a professional programmer.

The older student has a familiarity with using command line tools, but prefers to work in a simple IDE, either BlueJ or Arachnophilia depending on what she's doing. She hasn't developed as extensive a knowledge of Java and programming, but she's done more with what she knows. She writes her own simple command line applications.

The differences are normal for different ages and dispositions.

Neither student really understood classes, objects, methods, and so on. The younger one has been introduced to them, the older one had heard of them but not studied them formally. In both cases I have been concentrating on getting them through the mechanics of programming to the point where they start having questions about larger issues before we really get deeply into OO. I mention OO concepts frequently as we go, but don't stress them. We use good OO practices right out of the gate, however.

I decided to interrupt our summer session to give Greenfoot a try. They've both been enthusiastic about it. Not only because it looks like getting class credit for playing games. They both have a real desire to write their own programs.

For our first session I let them play with Greenfoot after we watched a presentation on Greenfoot. That was as far as we had gotten as of my last post on Greenfoot. I was hopeful, but my doubts were still intact.

We've since had two more sessions, and I've had more opportunity to assess what the students have learned and get a better sense of where things are likely to go.

Both students started using Greenfoot as a sort of game system. Good enough. As a game system its simplicity invites the student to come up with their own ideas. My experience is that if you sit a student down with a Halo, Mario Carts, Zelda, or other A-grade games there's little or no desire to produce something of their own aside from a bit of daydreaming. If you set them down in front of a 1970s Pong, Pac-Man, or Space Invaders they start developing their own game ideas spontaneously. They'll grab some paper and start drawing out their ideas, or start developing involved game concepts verbally with their peers. What's interesting to me is that these concepts are not derivative ideas. They'll start with the concept of playfield and sprites and start developing ideas completely tangential to whatever games they've been exposed to.

Greenfoot possesses that same quality. Greenfoot's provided scenarios both in the original download and on the web provide the same jumping off point for creative thought as old video games. The integration of scenario downloads into Greenfoot's menus is an excellent little feature. The students don't have to leave Greenfoot to get new scenarios.

A few of the scenarios are somewhat frustrating to play as provided. At first, this can lead to frustration. It also provides an opportunity for the instructor to ask, "Why don't you change it to make it work better?"

The 16 year old began making code changes without prompting in the second session. The younger one showed some mild resistance to shifting gears from playing through the catalog of games to doing something more than changing images. Once over the hurdle, however, she did fine.

This set my mind at ease about whether Greenfoot would become a source of contention in class if I introduced it. If any student were going to turn sullen and resistant toward moving on to programming from pure play, this one would be the one. So, I think I'll be able to steer a full class into using Greenfoot as more than a video game system.

The older student's ideas soon outran her abilities, causing frustration. We reviewed the specific features she wanted to implement, and identified existing scenarios she could look at for examples. Now she has managed to implement some of her ideas, and the confidence she's gained is keeping her from getting frustrated while implementing others.

Once the younger student started modifying scenario logic, she came up with complicated ideas for reworking the ant simulation. She got hung up, then we talked. Now she is progressing with incremental changes of far less scope, and using what she learns to guide her ideas.

My doubts are beginning to be put to rest. I'm still concerned about taking things from within Greenfoot to outside of it. I'm in no hurry, but it's the next major hurdle I see. Meanwhile, I'll be using Greenfoot for more formal learning--teaching with flow control, iteration, and so on.

I'm also interested to see whether either of the students takes what we learn in Greenfoot back to their prior working environment on their own. The older student has a text game of her own she was working on, and it'll be interesting to see if she goes back to it with lessons from Greenfoot.

The students have a firmer idea of the relationships between classes, objects, methods, and fields than before. The younger one was still unclear when we started talking, but Greenfoot gave us a basis for discussion. In just a few minutes, she understood the purpose of a class versus an object, the relationship between the two, how to identify a method, and a had general idea of constructor methods. We're still working on fields.

The older student now has these pretty well down. She understands the relationship between subclasses and their parents well enough to introduce superclass and overridden methods. She said "I know how to create subclasses in Greenfoot, but I don't know how to do that in my programs I write from scratch." A few minutes later, we'd worked through two examples of subclassing using extends and she has it. Magic!

So far I'm extremely pleased with Greenfoot. I'm hoping to get a third student to give it a try. She's a friend of my two present students, and out of classes for the summer. The other two are going to show her Greenfoot and see if she's interested in trying it out outside of class. They're both already using it on their systems outside of class. Another point of view is always welcome, and this other student is very introspective and very outspoken.

I'll post more as we continue. I need to make more time to review the available materials for Greenfoot, and start planning how it'll fit into my class. At this point, I think it's safe to say I'll be using it.