Unity: Is type casting every frame too expensive?

Question

I have a state machine that controls my enemy AI. Each AI has a target which may be a Player, an obstacle, a shell, or even a Vector2 position.

I'm trying to abstract my "target" member, and my first thought was to use GameObject, then downcast to whichever type I need for different enemies. Examples below:

class StateController: MonoBehavior {
    GameObject target;
    FireAction action;

    Update() {
        action.Fire(this);
    }
}

class FireAction: ScriptableObject {
    public abstract void Fire(StateController c);
}

//Examples of different fire scripts:
class FireAtPlayer: FireAction {
    public override void Fire(StateController c) {
        Player p = c.target as Player;
        //--use properties of Player object--
    }
}

class FireAtPoint: FireAction {
    public override void Fire(StateController c) {
        GameObject t = c.target as Player;
        //--use properties of GameObject object--
    }
}

As you can see, my Fire methods would cast the target object at every call to Update. Will this negatively affect my game's performance? Note that I know for a fact what type of object the target is, so I'm not guessing when I'm casting. Thank you in advance of your help!

Answer 1

What other's have said is correct. It likely won't cause issue. This is partially a problem with oop in general. The non casting solutions are not easy to maintain and work with. An alternative component based approach might be better, but since you're using oop i'll go from there. There's two alternatives that come to mind

1. Duplicate your pipeline for each subtype. For example, let's say I have BaseCharacter, and Enemy and Player which inherit BaseCharacter. I can have something like this

public class SpawnManager : Monobehaviour {
  public event Action CharacterSpawned;
  public event Action PlayerSpawned;
  public event Action EnemySpawned;

  public void SpawnCharacter(BaseCharacter char) {
    Instantiate(char)
    if (CharacterSpawned != null) CharacterSpawned.Invoke();
  }

  public void SpawnPlayer(Player player) {
    SpawnCharacter(player);
    if (PlayerSpawned != null) PlayerSpawned.Invoke();
  }

  public void SpawnEnemy(Enemy enemy) {
    SpawnCharacter(enemy);
    if (EnemySpawned != null) EnemySpawned.Invoke();
  }
}

2. Another alternative to not cast is to just have a union-like struct which as long as it's holding pointer references, is only taking up sizeof(pointer) * N where N is the number of subclasses

public struct SpawnEvent {
  public enum Type { Player, Enemy };
  public Type Type;
  public Player player; // null if enemy
  public Enemy enemy; // null if player
}

Then check the enum and get the correct field as needed. Again none of these approaches are perfect, nor is casting, but if you stick with OOP you'll find this is one of the places it falls short. You can look into component based design, if you're really not satisfied, but i'm not as well versed in that to offer much advice.

Answer 2

If you can avoid casting frequently casting then do. However if you do not find it causes a reasonable performance hit then don't worry.

Also it is not possible to cast GameObject to Player as you cannot inherit GameObject yourself. You should be using GetComponent() to get components from GameObjects.

Answer 3

I wasn’t aware that you could cast a GameObject into a component type on that GameObject and it would work. In fact I don’t think it will, will it?

Even if it did, it would be akin to calling GetComponent, which is an expensive function, every frame, which is generally accepted to be a Bad Idea.

From Unity’s documentation:

In Unity, it is common is to call GetComponent() to access components [repeatedly. ...] This code works, but it is inefficient due to the repeated GetComponent() call.

A more efficient solution would likely involve a bit more polymorphism, although it would require a bit of restructuring from your presented design, and even that has its own drawbacks. As DMGregory suggested, you won’t know if your solution is sufficient or requires some rework until you try it out. Just keep in mind that your solution is simple, but not particularly efficient.