Over the last couple of nights I have been trying to resurrect my old Uni AI Assignment (Rar copy of files). The main problem I’ve had is just getting the thing to run! It’s been at least 4 years since I’ve use javac to compile a Java program and classpaths were my first hurdle. After figuring that out I could then attempt to compile which wasn’t pretty.
I had to make some changes, as the code was written for Java 1.1 and a lot has changed since then. After trawling through the latest API I found all the changes I needed.
The last thing to change for it to run (still a lot of code deprecated left) was the event handling for key strokes. This doesn’t sound like it would be too much trouble considering I was dealing with Threading issues before this.
Boy was I wrong, it took me about 5 hours last night to figure out the new structure of the java.awt.event.KeyEvent class. In the end I could not get any key events to fire when running the KeyListener on the Applet. I had to attached the KeyListener to a useless TextField and the events could then get passed on to the EventManager class which passes on the event to each object of interest.
Because there are more then one type of Agent in this system the EventManager object and EventHandler interface are a very good way of spreading out the workload of event handling between multiple objects (i.e fish and shark).
I didn’t write this code (or the majority of the game). When I first started to look at the code again it seemed very confusing. But once I start adding more agents with different abilities these classes should help me sort everything out in terms of events.
Its a good concept which involves objects registering to a central handler object all the events it would like to be told about. In the current version of the game these events are restricted to keyboard events.
But I was thinking of expanding this into a multiagent system where if an agent comes across something interesting, it could fire an event to a central control object which could inform other agents near by about it. The good thing about this is that each agent implements a EventHandler interface which has a method called handleEvent(Event e).
Therefore each agent can handle the event in different ways. The practical application of this would be a multiagent system in which there are 4 types of simliar robots exploring terrain let say….on Mars!
Each type of robot has different sensors in it. For example each robot has one function which might go something like this.
- Camera vision
- Chemical Analyzes
- Rock/Soil Sample Collecting
- Power Hub (A robot who’s main purpose is to refuel other robots)
So if a robot that analyzed some rock found something interesting it could inform (using a wireless LAN) other robots around it to have a look. After this has happened the original robot could then move on while others came over to inspect the site using there own instruments.The inspiration for this idea came from Dr. Steven Dubowsky who has been doing research for NASA in this area. By splitting up each ability for different robots you can build much smaller robots that can complete a task as a group. This is much more robust (IMO) and closely follows how nature has done this. For example how ant colonies have different types of ants for different jobs.
Most of my thinking in robotics comes from nature. AI through evolution of best practices for rewards is another area I think nature should be looked at.
So what is the next step in my “vision” for this program. The first thing is to implement a part of the program which I thought I had done but turned out not to be there. I thought I had got the remaining fish left to “mate” with each other and share attributes to create another fish. The other thing I plan to do is to make the “player” (or shark) autonomous as well. By getting it to see when a fish is on its own and to go and get it. Then I can run the program with “eating” as a positive outcome and see if the shark learns to do this on its own.
Posted by midge 