The goal of my Honours project was to develop a software system which allowed for the simulation of a simplified ecosystem, in which different types of creature attempted to survive. The simulation was to be distributed across multiple machines using Java's Remote Method Invocation (RMI). This project specification was deliberately open-ended, allowing a good deal of exploration, reading, experimenting with ideas, and so forth.

In the finished project, simulated environments are distributed by chopping landscapes up into smaller rectangular sections. Each of these sections is sent to a remote machines ready to accept work; remote machines can each hold zero or more segments of "work". Each section of land coordinates with adjacent sections on remote machines to handle moving creatures across borders, spreading of vegetation, etc. To ease spurious network traffic, each section maintains small amounts of remote state locally (thus allowing creatures to see across borders which, to them, should be transparent).

Creatures are split into two basic categories: predators and prey. The prey eat any natural vegetation around the landscape (of which there is only one type), and the predators eat the prey. A certain level of creature configurability was catered for, allowing slightly different behaviours to be observed. For example, a creature type defines certain characteristics, such as how fast it can walk or run, how hungry it gets before it starts to look for food, etc.

The simulation, although simple, serves as an example of an application running on top of the distributed framework built for the project. Heavy use of simple object oriented design principles allowed for much of the functionality to be kept in a generic 'Core' package, with the actual simulation-specific code appearing only in a 'World' package. A generic Worker component, which has no knowledge of the type of simulation to be run, must be instantiated in machines willing to take on work. Provided components adhere to the 'Work' interface correctly, a Worker requires no further information.

Controlling the distributed simulations was an application-specific centralised server, which also dealt with splitting up user-submitted 'worlds' into smaller sections of roughly equal proportions, and then sharing those sections between connected workers.

The code design for the project allowed for a generic framework to be built, allowing for the majority of server code and for worker nodes to be generic. Thus, the work to be done and how portions of it interact, plus a UI if required, are all that's required to build an entirely new system out of the framework developed.

World Generator

The world generator is where configuration of a simulation took place before submitting it to the server. Various attributes could be altered, such as the basic dimensions of the landscape, modification of land height post-generation, population density, addition of creatures or vegetation to the landscape, etc. New creature types can also be configured via the world generator.

The terrains are generated randomly using the Diamond-square algorithm. The different land types (sea, beach, grassland, snow) being determined by their value in the generated heightmap. This is a simple, but effective, way of creating landscapes which look reasonable.

World Viewer:

A user interface (pictured here) could connect to the server, and request to view any given simulation which was currently running. This required each section of land to periodically send enough information back to the UI to draw a representation of the current state in the correct location. It is the responsibility of the viewer to stitch the pieces back together accordingly.