The Swarm - Devlog 2

Hi there,

This week I want to talk about how I'm approaching my code structure in these first stages of the project. As I've reinforced in part 1 one of the main goals of the development was to explore the idea of emergent systems and complex behaviour arising through the interaction of simple entities. So I thought it would be a good idea to try to apply those same principles to the code itself.

In order to traverse the terrain, all units have a NavMeshAgentcomponent. In order to encapsulate the actual move logic from Unity's navigation system I've created my own Move component. Its responsibilities are to direct the entity to a target position and to allow the caller to check if that position has already been reached.

public class Move : MonoBehaviour {  
    public float Speed { get }

    public float MaximumSpeed { get }

    public Vector3 TargetPosition { set, get }
    public void Stop();

    public void Resume();

    public bool DidReachTargetPosition {get, set}
}

In a level above, we have the Follow behaviour that requires the Move behaviour in order to work.

[RequireComponent(typeof(Move))]
public class Follow : MonoBehaviour  
{

    public Transform Target;
    public float StopDistance = 1.0f;
    public float moveUpdateFrequency = 1.0f;

       //updates Move.TargetPosition every 1/moveUpdateFrequency seconds to be Target.position
}

We can already see that Move looks more like a basic action while Follow is more a high-level behaviour.

Besides moving, the units can also shoot enemies with their guns. So we have the Shoot behaviour. But you need to shoot something, so let's add a Gun as well. Bu what does the Gun shoot? Bullets of course. And what do those Bullets do? Damage! All of these are mono behaviours.

But if you Shoot without Aiming, you'll get nowhere. What about trying to Aim for a Target? If all of this sounds a bit overwhelming don't worry, I've got a nice picture to illustrate one particular case of the hierarchy.

Focusing on behaviour decoupling and decentralisation makes it easier to test each one separately, to mix and match different combinations, and to reuse individual pieces in different structures.

I'm really liking this approach and it already proved itself useful when I've added a Melee Attack to the game.

This is what it looks like right now:

I hope that this way of thinking can be of any help to you during the development of your own games.

See you next week!

What do you think? Get in touch with me through email, LinkedIn or Twitter.

Menu