DES311 #3: Coming Together

This week I have managed to implement the cohesion behaviour in my BOID simulation as well as completing a project timeline. I’ll discuss both in this post.

The Timeline

The project will be broken up into 4 fortnightly sprints whose tasks will be taken from a project backlog. This backlog will change over the course of the project based on research, feedback and lessons learnt from implementation, but I estimate the tasks for each sprint will look like this:

Sprint 1: 1st March – 14th March

  • Implement basic functions of:
    • Obstacle Avoidance
    • Follow nearby flock mates
    • Flock cohesion  

Sprint 2: 15th March – 28th March

  • Implement advanced features of:
    • Goal seeking
    • Predator avoidance

Sprint 3: 29th March – 11th April

  • Basic sprites
  • Basic animations
  • Basic sounds that provide feedback
  • A simple UI

Sprint 4: 19th April – 2nd May

  • Tweaking based on previous sprints and polish

Tasks and progress will be tracked on a public Trello board.


The cohesion behaviour makes BOIDs group and move closer together whilst also jostling for a central position in their local group. This is the behaviour that leads to the beautiful dynamic swirling seen in real world swarms.

In the simulation I currently have BOIDs keeping a list of any nearby flock mates inside a trigger collider around them. In the alignment behaviour the velocity of surrounding flock mates is averaged and sent to the pilot module. In the cohesion behaviour the position of surrounding BOIDs is instead averaged. A vector is then drawn between the BOID’s current position and the average position. This vector is then normalised, multiplied by the magnitude of the max velocity and then sent to the pilot module.

The result looks like this…

Did you spot them? Some BOIDs are breaking the speed limit somehow. I spent the best part of this week trying to find out a reason and solution. My current hypothesis is that it has something to do with the edge warp. The edge warp is what teleports objects to the opposite side of the screen when they go outside the bounds of the camera, like in the game Asteroids. I think when a group of BOIDs approachs the edge the ones at the back are calculating the average position to beyond the edge, and then when they teleport to the opposite side of the map some value somewhere breaks and the excessive speed is it compensating. Honestly I have no idea.

But in true programming form I don’t need a reason so long as I have some sort of solution. For some reason adding a script that adds a small forward force to each BOID if its velocity is zero solves the problem. I think it pushes the BOID off the edge line before they have a chance to go weird.

        //if BOID gets stuck add forward force to keep it moving
        else if (rb2d.velocity == new Vector2(0, 0))
            rb2d.AddForce(transform.up * speed);

And hey, it works, look at this…

Separate groups of BOIDs are now attracted to each other. Already this motion is causing more interesting patterns to develop. However as you can see they aren’t really jostling for a central position. This is because I have a capsule collider on each BOID so they can’t get on top of each other. This is necessary because without it they all bunch on top of each other and look like a single BOID. To create better jostling I think they need to be able to go on top of each other briefly whilst attempting to maintain distance apart. To do this I will need to improve the separation mechanic so it isn’t just looking at a single ray in front but moves the BOID to avoid flock mates next to it too.

What’s Next?

I am happy with the outcome of this fortnight sprint and think I have quite a respectable little simulation. The improved separation behaviour is high on my list of priorates for the next sprint though. Starting on the 15th of March sprint 2 will aim to implement this improvement as well as the goal seeking and predator avoidance behaviours. But for now I’m celebrating the end of this sprint with a German Donor kebab.