I created a Unity project based on the SpatialOS starter project, which has a small amount of the core SpatialOS-Unity already implemented and within this project converted the java algorithm which I found into c# scripts.
My reasoning behind jumping straight into implementation before doing any documented planning of the software architecture was that I would be more likely to identify areas which would help make a solid groundwork to include in the plan. I personally find that it can be quite difficult to make a useful plan without a good understanding of the problem space and part of the understanding can be gained by having an initial attempt at implementation.
Straight away this proved to be the case as I came across an issue I had not considered: how I would structure the parallelisation of the algorithm. Most of my work this week was based around the research of threading and parallelisation within the contexts of Unity and SpatialOS. Unity is not a threadsafe api and neither is SpatialOS and so only limited calculations can be performed using the System.Thread namespace. The simulation to be performed is not an ’embarrassingly parallel’ problem as there is a lot of shared data access which does not help with the complexity of the task. The main issue arises from the need for each body to receive data about every other body each frame. The algorithm I had researched uses a controller class which stores all of the bodies and performs all body-body communication. This would not really work within the context of SpatialOS as a virtual machine or ‘worker’ should not need to have that kind of information about all other workers… the core way in which SpatialOS is constructed is broken.
A solution really needs to be found which utilises bodies as reasonably self contained units which perform their own neighbour searching and data acquisition (as well as their calculations) without reliance on a manger. This would mean their method of neighbour acquisition could be modified in a sequence as described in my proposal.