Archives for : March2010

PacMan! (updated with video)

JAKE isn’t just limited to robots and beepers. Since we have Movers in JAKE, we can create all sorts of objects, not just robots. It’s entirely possible to set up your own PacMan scenario, as in the video below:

I’ve already written about Ghosts. While working on the example programs to accompany JAKE, I’ve created a KillerGhost – a subclass of ghost that kills any robots it touches. All of this was done within the JAKE editor – it’s something (albeit difficult) that a student could do themselves without having access to the underlying JAKE Java code.

So we have a ghost that can kill robots. Since Movers can use different icons (using the name of a file in the same directory), we can also create a new PacMan class. This class is a type of Mover, so we can change its icon and give it move() and turnLeft() instructions. We can create methods on the controller (buttons) to move  our PacMan character about the maze. Since it’s a type of Mover, it can’t move into walls.
If we add extra beepers to the world, the PacMan object can pick them up to use as food (as in the original game).

Reduced flicker

Up until now, JAKE has had some flickering in Java, especially when running programs with lots of on-screen objects. From now on, there’s a lot less flicker when the Java programs run, and this is reflected in the PacMan video I’ll be posting later tonight.

Two simple programs (video)

These videos show the creation of two simple Java robot programs in JAKE, based on an earlier blog entry about creating control events.

The robot/wall graphics are a little choppy, but that seems to be something to do with mixing Java and the screen-capture software.

Adding events

A big part of JAKE (Java Karel with Events) is that it adds an understandable event model to the Karel mini-paradigm. We know that there are problems with Java’s event model [1], and that’s part of what JAKE is meant to address. The idea is that the programmer, once they’ve set up their world, creates event buttons, methods of the control panel.

Adding an event is done with the “Add…” button. This adds a new button to the control panel.

When the programmer clicks on their new event button, a pop-up menu opens, giving them the option to write the method that goes with this button.

This opens the code editor (work on which is still in progress).

Now, when the programmer compiles their work, JAKE copies this method into the program, creates an appropriate JButton, and writes a Listener to connect the JButton to the control panel method. The student programmer doesn’t actually see any of the event listeners, and doesn’t have to worry about them yet. It’s not an ideal solution to have to hide away parts of the program, but hey, it is “broken”


[1] Milner, W. W. A broken metaphor in Java. ACM SIGCSE Bulletin, 41, 4 ( 2010), 76-77.

Minor updates this week

As well as the new world editor, there have been some other small updates to JAKE this week.

Firstly, the graphics have been improved slightly in the JAKE Java library, so that there’s no longer the same stretching and pixelating as before. The wall and beeper icons are now crisper. You can see this in one of the screenshots for the world editor, when compared to a scenario from a few weeks ago:

Secondly, tooltips have been added. The two screenshots below show how tooltips show up in both the world editor and the class diagram. For world editor objects, the tooltip shows the name and type of the object (e.g. “jake (robot)” or “myBeep (beeper)”). For class icons, the tooltip describes this class’s relationship to its parent:

Finally, the WorldObject class has been replaced by “Thing”. This saves any confusion from having the “World” and “WorldObject” classes next to each other in the diagram; we didn’t want it to appear that WorldObject was an instance of World. So, now, all objects in the World are “Things”.

Setting up "situations"

Karel programs are built on “situations”. Similarly, Greenfoot programs use pre-built scenarios. So JAKE programs, also, use Pattis’s situation model.

Up until now, it’s been possible to add robots, beepers and walls by clicking on the buttons down the side of the world editor. These objects were stationary and appeared, by default, in the centre of the World. As of this week’s latest version, the objects can be moved; this lets us set up complex scenarios, like the one below.

World objects can be moved around using a tool window that appears only when one is selected.

These screenshots are from the JAKE IDE. When the JAKE program is run (from the toolbar or with F5), the program represented in the world editor is transcribed into Java and compiled. The resulting program, running in Java, looks like this:

Thus, we can now create situations in JAKE, and see them running in Java.

Dynamic class diagrams in JAKE

It’s been noted [e.g. 1] that showing the static class structure is important in teaching materials and tools. BlueJ, for instance, places a lot of emphasis on this.
The JAKE IDE dynamically compiles a class diagram as classes are added to the JAKE program. Every program starts with a default class diagram that shows all the classes in the main JAKE package: World, Mover, Robot, and so on.

The diagram uses a variant UML notation, with arrows for generalisations. The classes themselves, however, don’t have methods or attributes. Instead, they’re represented by a box with an icon and caption.

The class diagram is shown alongside the main program editors in JAKE, but it can also be maximised. In later versions, the maximised diagram could be printed through the File menu. The diagram window automatically scrolls if the diagram becomes too large, but JAKE’s simple class structure makes this unlikely.

[1] Börstler, J., Hall, M. S., Nordström, M., Paterson, J., Sanders, K., Schulte, C. and Thomas, L. An Evaluation of the State-of-the-Art of Object-Oriented Example Programs in Introductory Programming Textbooks. In inroads SIGCSE Bulletin. (July 6-9 2009). ACM New York, NY, USA, , 2009, 126-143.

Debugging: Class, interface, or enum expected.

Java’s error messages aren’t always very meaningful – to novices at least. Take this, what we might imagine to be a fairly common error:

Class, interface, or enum expected.

Now, I know what it means, but would a new programmer? To understand this message, you surely need to know what an interface or an enum is – neither of which are likely to be taught in the first few lessons.

Therefore, JAKE aims to make debugging a bit easier. When a JAKE program is compiled, the IDE reads the feedback from javac and tries to translate it into simpler language. Obviously, it’s important to maintain parity with the Java error itself, so the actual error message is always shown. It’s just that JAKE also gives a short, plain-English explanation too.

Since JAKE’s being developed to research teaching programming, it’s not going to include an explanation for every possible javac error. However, the system is designed in such a way that it’s modular; the explanations are taken from text files, and JAKE just looks for a file that matches the javac error description. See below, where there’s no matching explanation for the error:

The explanations, where they do exist, are also quite short, so it’s feasible that the novice programmer might want more help. To get around either of these problems, there’s a link to Google. Yes, this might sound overly simple, but it seems like a good, quick (since this is only a demonstrator) way of providing extra help. Why duplicate help content that can be found on the web? When the user clicks on the link (either link, if there’s no explanation and a link appears instead), their default browser opens and they’re taken to a Google search page about their error: