There is a lot of confusion about the Blueprint Cast node, that it makes the game perform badly or things like that. Mostly none of that is true and for cases where it is true, the issue is less the “Cast” node, but a missing knowledge or understanding or adherence to larger programming concepts.

Why do we need the Cast node at all?

In C++ there are more reasons, but for Blueprint I want to focus on this one:

• If you need a more concrete type than the type system provides.

So a functions provides you with an Actor, but you need to ensure it is a Character, because you need to call a function that only Characters have.

Why is the Cast node supposed to be bad?

One thing about the Cast node, that is also true for many other nodes, variables and parameters is, that they have to load the Blueprint that they target.

• A SkeletalMesh Component has a Variable/Property of type TSubclassOf<UAnimInstance> that allows to assign an AnimationBlueprint. When assigning an AnimationBlueprint type to this Variable it creates a hard reference to this AnimationBlueprint type. Which itself has a lot of hard references to Animation Assets that are used within the AnimationBlueprint
• A Cast to a BP_RabbitCharacter will require the BP_RabbitCharacter to be loaded. This in itself is not really an issue, but the RabbitCharacter probably has a Mesh to load → an animation blueprint → a ton of animations, maybe sound effects and so on.

So, we don’t fear the Cast itself, but the chain of Dependencies we get.

When is the Cast node not bad?

Understanding this already gives us a lot of places where Casting is obviously not worse than any other function call:

• Casting to a Blueprint that you know is always loaded anyway.
  • E.g. Casting to your GameMode that is used for every Level.
  • E.g. Casting to any C++ type (e.g. Actor, Character , …) as they are compiled and loaded anyways and usually don’t have hard references to any concrete asset.
  • E.g. Casting to your Player Character Blueprint, as you know it will be loaded at least most of the time anyway
  • E.g. Casting inside AnimationBlueprint to the type that loads the AnimationBlueprint.

When is the Cast node actually bad?

So we have to wonder, what lead to the bad reputation of the Cast node? And the answer is: bad coding skills. Blueprints are more approachable and look more appealing to a lot of non coders. That lead to a lot of projects finding the Cast node and utilize it to reach their goals not thinking ahead.

A programmers job is to think ahead, to have the project maintainable while it scales up. We learn things like “DRY” and “SOLID” to prepare for the future of a project.