The potential scope for the BOTS Project is huge. There is far more work to be done than can be completed by one Software Engineering group in a one year part-time project. This section contains some of our ideas for the future of the BOTS Project. We have limited this section to technical issues only--there is also potential to add lots of "cute" GUI features as well.
The template editor code has not so much been designed as evolved over time to meet our needs. As you'd expect, the lack of a design has meant the code is not as maintainable as it should be. It should be reworked or redesigned from scratch so as to be maintainable by future Software Engineering groups.
The Brain currently uses global variables for data passing between modules. We wanted to make minimal modifications to the genetic programming code we inherited from John Koza in order to keep things simple and be able to get on with the job quickly. The modularity is pretty good on the whole, but it is not perfect. It is also inflexible, which is the main thing that should be fixed.
There are quite a few things that can be done to optimise the code. First up, there is a lot of object type checking that can be avoided by sorting the object array into several arrays, one for each type. The entire environment component could be converted to C or assembly language, but this will probably involve reorganising the rest of the project as well.
There are a couple of advantages to this. Common LISP is a fine language, but the version we were using doesn't integrate terribly well with other languages, which required us to develop the CBEP protocol in order to get various parts of the BOTS system communicating with one another via TCP/IP sockets. Using a language like Delphi or C++ to implement the Genetic Programming system would eliminate the need for a CBEP protocol, and allow the system to more easily access all data about Genetic Programming.
Switching to another language has another major advantage: speed. By using a foreign function call interface between Delphi and C++, or just Delphi to Delphi, we could pass pointer to rule set trees around the system rather then having to send entire rule sets. This would cut execution time by ten or twenty per cent--perhaps more.
Another major advantage is memory utilisation. At present, two copies of each rule set are stored while the program is running, one in the BOTSsim executable and one in the Brain image. By having a rule set representation that was easily accessible from the Delphi code, and useable from within the GP component, we could cut memory usage of rule sets (the major user of memory within our project) in half. This would allow us to have twice as many rule sets in the population at once on the same machine, allowing greater things to be achieved with Genetic Programming.
Due to the large amount of I/O and intensive processing performed by BOTSsim, screen updates are often slow or delayed for a number of seconds. To remedy this problem, it may be worthwhile to make BOTSsim a multithreaded application.
Threads would be spun off for all sorts of tasks. Primarily we would have threads for background processing, CBEP communications, and user interfaces. Specifically, threads would be allocated for every GUI window and dialogue, the CBEP communications and all of the background tasks.
This would of course end up being a mammoth task, and one would probably need some sort of coordinator thread. However, the benefits of this task would be well worth the amount of effort that would have to be put in to it.
Genetic Programming lends itself very well to parallel processing. Performance should improve proportionately with the number of processors used. The University of Maryland had great success using 40 Alpha processors in parallel to do evaluation.
It's important to realise that converting the BOTS system to allow parallel evaluation would be a fairly major undertaking. For a start, one would need to find a way to graphically display environments which are evaluating on other machines. Other challenges include synchronisation between the controlling machine and the environment machines. This could possibly be done by extending the CBEP protocol.
One suggestion has been to port the evaluation code to UNIX using C++ or Common LISP, so that BOTS could use UWS's large number of Alpha-based workstations for evaluations, and use NT for the GUI front-end to the system.
Dave developed Perl scripts to convert the log file that BOTSsim generates into raw statistical data, which could then be used to make graphs. We started writing a program called BOTSstat, to function as a graphical front-end for this task. This would allow users to select the type of statistics they wish to generate, select the input file, and select the format of the output file. We abandoned this idea due to time constraints, and because it was not part of the user's wishes. However, we believe it would be a worthwhile addition, because it would make BOTSsim easier to use for GP research.
Collisions could use some work, eg: bumping into something could make the Bot "slide" along it, providing the angle is steep enough. Momentum, friction and the like could be implemented.
Some group members have the opinion that the sensors played a big part in the project's lack of performance. Implementing something that gives the Bots a lot more "sight" could help a lot. This would need a lot of shuffling of project code, too.
There are a number of improvements that could be made to the GUI given, enough time. One area for improvement is the dynamic resizing of windows. That is, when windows are resized, they should scale their contents to the overall size of the window. Another idea is allowing users to name bots, and assigning specific pictures to them. For example, we could name one bot George and give it a beard.
The trend in the Windows marketplace today is for applications to be integrated with HTML-style Context-Sensitive Help. At the time of writing, not enough research has been done in this area, and the tools available were designed to integrate HTML Help with Windows applications. However, we believe it worth considering in future.