This week I continued with the task of implementing the prototype simulation. This began with attempting to adapt the Barnes-Hut algorithm for a SpatialOS application. After failing to get the simulation to run on SpatialOS I decided to try a fresh unity project with an implementation of the algorithm with no attempt to incorporate SpatialOS. As a result I was able to fine tune the numbers and parameters of the algorithm so that it produced a simulation that behaved in an expected manner.

Alongside the creation of this initial prototype I looked into ways that the SpatialOS documentation suggested I could carry out neighbour searching. A suggested technique for local queries is using Unity’s ‘FindGameObject’ functions which is the method that was used in this prototype. This negated the need for an overarching simulation manager and allowed all of the functionality of the simulation to be split into the Planet script which is attached to each body. Therefore when the prototype is implemented in SpatialOS the bodies can be under the authority of different workers and the simulation can still run.

Using this prototype an initial SpatialOS implementation was produced which operated as a local deployment, all running on my computer. Using this prototype I was able to fully understand the concept of SpatialOS components and the need to use them for any persistent data controlled by the bodies. In particular their coordinates in world space as well as their velocity.

I also experimented with client-side functionality implementing a script which is attached to all bodies but is only run on the client. This script queries the SpatialOS components of Velocity and Position and manipulates this data to produce a colour for the body on the client. The purpose of this was to understand how the client can interact with the simulation without any authority over the bodies. This will lead the way to having an interactive simulation.

Research was carried out into the setup of the launch configuration .json as well as the worker configuration .json to control the load balancing of the simulation. The information procured here was used to adjust the project’s parameters so that the area the simulation occurs in could be split between the domains of different workers. Also by limiting the numbers of bodies the workers can interact with, the number of workers which manage the the simulation can be controlled. It is also possible to define the number of workers, however they are unlikely to share their load if they are still controlling less bodies than possible.

After a cloud deployment using the initial parameters (and therefore one worker) was created a multi-worker implementation was attempted locally and in the cloud. The simulation did run, but it did not behave in the expected manner as the neighbour searching method used only found bodies attached to the same worker. This resulted in the simulation fragmenting according to worker domains. The next stage of work will be creating a neighbour search which looks to other workers, as well as locally, so that the simulation behaves as if it is managed by one machine.

Below is a video which demonstrates these prototypes: