[ Jocelyn Ireson-Paine's Home Page | Publications ]

Using Java and the Web as a front-end to an agent-based Artificial Intelligence course

These are notes towards a paper.

Abstract

We describe how Java has been used to front-end a course in practical artificial intelligence previously run on VT100 terminals, and to provide a graphical interface. We also provide some motivation for our decision to use production systems.

Introduction

The course described here was taught for the Oxford University Experimental Psychology Department. (It was terminated in 1999, when they stopped all AI teaching.) It consisted of 8 half-day sessions in Trinity (Summer) Term, one or two sessions per week. Students, mostly 2nd year undergraduate psychologists, learnt some basic AI techniques and then did a little project.

The course was intended to convey the flavour of practical Artificial Intelligence, complementing the connectionist approach taken in the rest of the Department with an introduction to classical AI on the one hand and nouvelle AI and Artificial Life on the other, as well as teaching some AI history. An important point is that although some students study for an AI Finals paper, many have no knowledge of AI or even programming.

I shall refer to the latest version of the course (with Java front-end) as Eden II, and to the pre-Java version as Eden.

This replaced an older course which taught Prolog, followed by a small project such as an expert system or poetry generator. That course used a front-end, the Logic Programming Tutor, to make Prolog more student-friendly, and is described in my book The Logic Programming Tutor. Its source code is downloadable from my Prolog library. Parts of it, adapted to pure Prolog, are on-line at my practical notes page.

Reasons for changing to an agent-based course

Why did I change from the Prolog course to an agent-based one?

The Eden Microworld

A microworld is a computer-generated environment which agents inhabit. "Agents" are computer-generated creatures which are fed perceptions of the microworld and can react to them, e.g. by moving about or eating. Their "brains" may use many different AI techniques.

Eden is a two-dimensional square-grid microworld, whose design was largely imposed by the limitations of VT100 terminals. It was originally designed by Simon Perkins as part of an OU AI Society project. I worked on that project, and took Eden over for use in this course, first using it in Trinity 1992. It is implemented in Poplog.

Features: Eden can be easily configured to add new kinds of object. Agent bodies and perceptions could be configured. Agent actions can fail unpredictably, and agent perceptions can be imprecise. Such possibilities of failure are important, for example, in illustrating the shortcomings of certain planning techniques. Agents could be controlled by "brains" written in Prolog or Pop-11, and could also be controlled manually. The perception-action pairs of any agent could be saved into a file for later use, e.g. in training neural nets.

Eden ran on discrete time. The simulator calculated all agents' perceptions, and passed them to the agents' brains. It then ran the brains one by one. Each brain sent back an action specification, e.g. "move forward 1". The simulator attempted to perform this, checking for violated laws of physics, updated the agent's state if necessary (e.g. with simulated pain signals), and then repeated.

The agents' brains

These are production-system interpreters written in Poplog Prolog. Numerous sensory predicates and motor competances are provided (and, in general, chosen to be useful within the microworlds provided), so that students don't have to program them from scratch. [Borrowing from Maes networks.] Students program the brains by providing rulebases.

In this course, the actual architecture chosen for the agents was secondary. Within some limits, a wide range of architectures can be used to teach the same fundamental ideas. So I experimented with several. I chose production systems because:

Defects of production systems: lack of explicit control makes it hard to understand (or write) algorithmic processes. PS's are best suited to encoding programs expressed as state-space transitions. However, the PS interpreter was coded in Prolog, and both conditions and actions could invoke Prolog predicates (written by me or the students). These could in turn call Pop-11 routines.

Graphics, Eden, and VT100's

Course has suffered greatly from restrictions on graphics. The course couldn't be run on PC's or Macs, because there were no Poplog implementations. There were no Departmental Suns or other workstations that could be used, so we were restricted to OUCS. It was OUCS policy not to run X-windows on the VAX (even though Dec did provide a version, Dec-windows), and when we started, OUCS's Unix mainframe did not have Poplog. This restricted us to the standard terminals, VT100 clones.

Poplog did eventually become available under Unix at OUCS, but the Department had no X-emulators, many colleges had none either, and there were a limited number at CTC when we started.

What is a VT100? A text-only terminal, no graphics (although inverse video and highlighting are available), 80 characters wide by 24 deep. Only one character can be displayed in any position. A program can move the cursor to any character position.

To make Eden displayable on these, it was designed as a two-dimensional world divided up into cells. Each cell normally holds only one item, depicted as a character. Agents can move from cell to cell and pick up or drop items. Items being held won't be displayed in the appropriate cell, but will be shown on a separate status line as part of their owner's "inventory".

Incompatible terminals

We also suffered from problems with incompatible terminals, made worse by Oxford's decentralisation (the Department; OUCS; CTC; 28 undergraduate colleges). There were too many kinds of terminal: a range of terminals made by DEC, such as VT100's, and VT320's (not with identical keyboards); OUCS home-built VT100's; PC's and Macs emulating VT100's in various ways. Key layouts differ - e.g. on a real VT100, "Return" and "Enter" keys send different signals; on a PC, even when running an emulator, they act identically. [Is this always so?] The two sets of arrow keys change position between PC's and real VT100's.

This is bad for students. The Eden editor was Poplog's Ved, and uses a number of control character commands. The keys that generate them vary in position between keyboards, so students can't transfer motor skills.

A possible solution was to supply each student with software to remap the key positions to match a real VT100. This could be done either inside the editor or at the terminal end, e.g. with a Kermit initialisation file.

Reconfiguring the editor requires me to know all the kinds of terminal students may meet, and for them to know which configuration file to call up. It also can't deal with irrevocable key mappings, such as Enter=Return on PCs. Reconfiguring the terminal requires students to have permission and know how to do it; requires me to know all the kinds of terminal students may meet; may clobber sessions for subsequent users. Either may require me to go to the terminal and give advice, which is not feasible, given the number of colleges.

This would be simpler if the University had forced colleges and departments to standardise, or - at worst - had provided a list of all the terminals available in departments and colleges.

Graphical Web browsers - a solution?

The Web seemed to offer a relief from the plethora of terminals. A browser such as Netscape will run on almost any machine, is simple to use, has an interface that does not vary between machines, and does not require complex programming to generate nicely formatted text. Could we use them? Yes, if we ran Eden on a server machine, and had it send back pages to the browser.

One disadvantage is that HTML output is limited to text, unless Eden generates a graphical file depicting its state after each time step (which would be slow). So we would gain no visual advantage over a VT100.

Another is that HTML controls are limited to data-entry fields, menus, buttons, checkboxes, and imagemaps. This would make it difficult for students to change the microworld or move agents about, though not for them to step through agent runs. A possible solution here was to imitate Dec's Life game , and have each cell depicted as a text-entry field which students can type into to alter its contents.

I started trying this using a Pop-11 server under Apache, but it got messy and didn't seem worth the trouble.

Java - a better solution?

Java provides truly portable graphics, simpler to program and more widely useable than X. The idea was to run the course's front-end as a Java applet. There are various ways of doing it:

Gamelet

The first option is tempting, since it transfers load from the server to the browser. It might also make it easier to do complex graphics, linking them more closely with the simulation.

Looking through books on Java for games, I came across Gamelet: a tool for building simple shoot-'em-up games. It is a game "shell" or "framework" which provides the classes needed for sprite animation, collision detection, display optimisation, and scoring. There is a basic Actor class representing a moving sprite, and this can easily be subclassed and its behaviour modified. This behaviour could include communicating with a brain server. It is downloadable from here.

Free Java on the Web

Gamelet is one extremely useful piece of software that was available free. Others included:

Eden II's architecture

This gives us Eden II, implemented as a Java applet talking to a Poplog brain server. It consists of:

In the applet:

On the machine from which the applet was downloaded:

Note that so far, the brains are all production systems, for the reasons given earlier. All brains run the same production system interpreter (that used for Eden), but may have different rulebases.

The model-view-controller paradigm

Every displayable object may be accompanied by a View and a Controller. We use the MVC paradigm - see Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) and Observer and Observable: An introduction to the Observer interface and Observable class using the Model/View/Controller architecture as a guide . [But note inheritance problem.]

Layout is standard, with View and Controller on the same panel, View to the left of Controller. Home-built listener interface (this is Java 1.0, so we can't use the JDK1.1 Listener interface).

Applet security problems and file servers

Most browsers prohibit applets from writing to or reading files on the browser's machine, making it difficult for students to save their work or access locally-edited files. The standard solution is to run a "file server" on the machine from which the applet was downloaded. The applet talks to this via sockets, and has its own protocol for requesting and saving files and inspecting directories.

Eden II therefore also includes:

These file clients need to be able to be plugged into editors and any other means by which students access files. Java has a FileBrowser class, but that is not directly replaceable, since one can't inherit from it and override its methods. So we define an interface which can be implemented by either a FileBrowser or a remote file browser. Editors and other components need to access files through this.

State of play

I have prototyped the entire system apart from the remote file server, which is not quite finished. Still possible to run locally via appletviewer on the same machine as the files being edited. See the picture below, which shows the EdenII game window, the EdenII controller, controllers for two agents, the production-system interfaces for these agents, the text editor with its file browser, and part of the debugging output from the brain server and client (in the two windows on the right). Clicking on the image will expand it to full size.

Part of the Gamelet environment is done, but needs finishing. One problem here is finding someone to do the artwork. The file server also needs finishing.

Some problems remain:

We might also mention "link-rot". The Lava user-interface builder I mention above, no longer exists at its original URL. This is probably because the author was a student (at Nottingham University) and has now finished his course. Computing services don't have unlimited filestore; but it would greatly help the rest of us if they would realise that they are the repository for some valuable resources, and try to prevent these from getting lost once the authors leave. If nothing else, offer every departing student the opportunity to archive their software in a national archive such as Leo or Hensa, and keep on a redirection page after the user has left.

Acknowledgements

To Aaron Sloman for comments.

Conclusion

It seems possible to use Java as a front-end to make teaching some topics in AI fun and easy to use. The Web's hypertext nature helps - as many have pointed out, of course - in providing somewhere to hang course documentation. [But note that you can't easily eembed HTML inside Java controls.]

The Web helps in another way, in that there are a lot of free pieces of Java code out there, both in source and compiled form, which can be cannibalised. Java does have its limitations - for example, the applet security restrictions - but these can be circumvented.

The effort has been less successful than it should have been, owing to lack of support from the Department and from OUCS.

References

7th February 2000

[ Jocelyn Ireson-Paine's Home Page | Publications ]