Curious Fixation: Mining for reusable code 2

This is the second in a series of postmortems where I will be evaluating my previous projects. Curious Fixation is the second (released) project I worked on as a solo programmer in Unity, and was completed as a part of a game jam in 2018 in conjunction with artist Peter Cowen. Peter and I have also worked together on The Monkey Way and Search and Rescue as a part of a larger team. You can find Peter on Artstation at this link.

Flocking

I chose to use flocking/steering behaviours (see this link) to control the actions of the enemy AI. Here are the two scripts I used to implement this system in Curious Fixation. 

Existing code

SwarmList uses a static list to manage all the members of the a flock/swarm/group, making multiple flocks impossible in a single project. This is easily remedied by transforming SwarmList into a stateless class. But the static list is the only reference to the neighbours of a given object in the flock that the methods in SwarmList had, and so they must be restructured.

I decided to structure the code based on the assumption that the members of each flock must be children of the same parent transform. 

Making changes

In the old class (SwarmList) each component of flocking motion was calculated inside a method of the SwarmList class, with a direct reference to the data structure of SwarmList that held references to the members of the flock. The methods returned the relevant component vector after completing the relevant calculations. Due to the assumption that I have made regarding the structure of flocks inside of a Unity scene, rewriting the class to use that new architecture rather than a data structure internal to the class was relatively trivial. 

For the methods calculating Cohesion and Seperation, position data was already an input parameter. By replacing the Vector3 with a reference to a Transform, there is now also a reference to neighbours of the flock via Transform.parent.GetChild as well as the position data that was required previously.

The less neatly resolvable issue is in the Alignment component which requires velocities for its calculation. For Curious Fixation, this was not a problem as each enemy gameObject used a RigidBody. This is clearly problematic for situations where simulating flocking behaviour is of interest but simulating collisions is not. My solution was to pass an array of Vector3 into the method for alignment in order to perform the calculation, and storing that data structure on the parent transform of the flock.

Flocking.cs: here. FlockParent.cs: here. SwarmMovement.cs: here.