Distributed Artificial Life toolkit: Specification
<<< Previous	The project	Next >>>

The project objectives

Brief overview

The main objective of the project is creating a toolkit which addresses the problems described above. The result should be provably more efficient on multiple machines than on a single machine, given the same set of data. The architecture should also have several levels of abstraction, allowing for different levels of customisation for particular experiments and should allow a relative language independence.

In order to achieve these objectives, the following main components will have to be integrated in the toolkit.

a map editor: This will provide the necessary functionality for creating and editing the 2-dimensional maps which provide the environment for the experiments.
a server: One or more instances of a program which keeps track of the current status of the map, the location of the agents and the interactions in between agents and their environment. The server should be able to supply all the 'sensory' inputs for any agent at any given time. It should also be able to decide whether actions that an agent would attempt to accomplish are valid or not (eg. an agent should not be allowed to move outside the map boundaries or in a location occupied by another solid object, etc). The server only holds the information about the agents. The agents themselves are allocated for processing purposes to one or more clients
a processing client: There will be several instances of the client program running (on one or more machines). Each client will handle the processing for one or more agents. Each agent is just the implementation of an algorithm which decides on one of the available actions based on the `sensory inputs' (for example, the map server should be able to supply the eye-sight and smell information for an agent; based on this the agent program can decide, say, to eat some food or run away from an enemy). None of the senses or available actions are to be hard-coded - this would be limiting for the scope of the toolkit. Instead a generic and flexible framework is to be provided, which should render the task of adding these features relatively easy.
an observer: This program will use data provided by the server to render a graphical display of the artificial environment. This program should also provide support for run time data extraction and hooks for adding extra functionality.
one or more examples: These will contain simple or more complex artificial life simulations using the components above

The communication in between all these components is to be done via TCP/IP. The data transferred is encapsulated in XML. Conducting all the communication over TCP/IP should provide machine independence. Using XML for encapsulating data should provide a clear and language independent format for transferring data, a feature which should prove very important in the case of a port to a new language.

The objectives

The objectives of this project can be split into three major groups:

Core objectives: The minimum of the objectives that need to be reached in order for the project to be successful
Primary objectives: Although not vital for the success of the project, these objectives are desirable. They cannot be attained without the core objectives being completed first
Secondary objectives: These objectives shall be completed depending on the available time. None of them is vital for the success of the project.

The detailed objective list is as follows:

Core objectives
1. Detailed design document.
2. Communication protocols. (specifying at least all the basic messages that can appear)
3. Artificial Life server
  1. a threaded server which can accept connection from clients
  2. Map loading
  3. Client authentication (the server should be able to accept, acknowledge and 'use' clients)
  4. Work allocation (the server should be able to dispatch processing tasks to the clients - most likely each client will receive a pack of agents which will have to process. The server will keep track of where each agent is located
  5. Observer support (server should provide data necessary for the observer)
4. Client
  1. authentication support (the client should be able to login into a server)
  2. agent framework (a generic set of classes or procedures which provide the placeholder for the decision algorithm mentioned before; this is to be extended/implemented differently for each Artificial Life experiment, according to the needs of the experimenter)
5. Observer
  1. authentication support (the observer should be able to make itself known to the server and request data)
  2. basic display and recording functionality
Primary objectives
1. map editor for AL world maps
2. Sample agent, able to demonstrate the functionality of the toolkit
3. Architecture performance testing on at least three machines (given an agent which has with fake complex processing demands, the simulation should run physically quicker when more than one machine is used, thus demonstrating the utility of this project.)
4. find processing/communication boundary (depending on the machines the program is running on, using more than one machine for a small number of simple agent can be slower, due to penalty incurred by the communication overhead). Given a sample agent and a required number of agents for the simulation, the toolkit should be able to suggest at least whether it is better to run the simulation on one or more machines.
Secondary objectives
1. Load balancing of work units in relation to processing power
2. Client improvements and fine-tuning
3. Complex (planning and memory) social agent for demonstration purposes
4. Run experiment on a large network
5. More experiments