I know that you should avoid casting where possible because hard references are bad, but they’re bad because they load things in, right? As far as I know, the player, game mode, and game instance are always loaded no matter what. The player certainly is because there’d be no playing otherwise. So, can you cast to those without any concern? They are the classes that hold the crucial information other classes often need access to, so is that okay? If not, how else would you go about accessing stuff from them?
You could add in an interface to the target actor and just call the interface to do an action or retrieve an on-actor component. If the said actor has the interface the action takes place, it not it’s ignored.
No direct coupling or referencing required.
I don’t quite understand how that works though. Like if I have a function in my player class that lots of classes need to be able to call, they need to cast to the player, right? Or the interface does? Sorry, I know what interfaces are but they confuse me.
The interface acts as a wildcard. Once the blueprint / c++ implements it you can try to call it no matter if the object has the interface or not. You can have an interface that calls in internal function or returns a custom inventory component, apply damage etc.
The possibilities are limitless.
Hey @dudebat923!
Here’s a link to some documentation talking about Blueprint Interfaces, Event Dispatchers, and other ways to have actors call on other actors to do things 
And a quick video explaining Interfaces!
Disclaimer: This link is not associated with Unreal Engine, Epic Games, or their partners.
That being said, there is currently a glitch in 5.1 where “implemented interfaces” is switched with “inherited interfaces” in the class defaults. It’s ONLY the words labeling them, and it’s only in that spot. When you see these options in your class defaults when assigning an interface, if you get confused, this is probably the reason. 
The class where the cast is happening is important.
If any class Cast to the GameInstance that is okay since like you said there is only one GameInstance (note however that there can be many GameInstanceSubsystems). But if you make a Cast in the GameInstance that is not good unless you need that class in every level.
Each level can have a unique type of GameMode so you still need to be careful not to load everything by casting to a specific GameMode that might not be needed yet.
Generally you are correct though. Many Casting to a few classes is not a big issue but a few classes casting to many probably should be made into an interface.
Don’t go crazy with interfaces though. Interfaces and Casting both have their uses along with Event dispatchers.
1 Like
Yeah so like the player has currency. There’s a fuction to set a new currency value in the player. Merchants, collectables, enemies, and countless other things could affect currency, so its okay for all of them to cast to my player class to use the SetCurrency() function, correct? That’s just an example, but the player is obviously loaded anyway
Correct.
1 Like
Thank you, and thank you to everyone else for the super quick replies and helpful documentation
That is quite a few questions.
- Casting is not bad at all. You can cast a fruit to an apple to access the logic of an apple. If you need to do this a lot then you have a design flaw.
- Hard references load classes into memory. To avoid this we use soft pointers.
- There are various types of casts and not all can be used dynamic like that but with UObject derived classes you can always use Cast<ThatClass>(ThisObject) and if the result is not nullptr it was a success, else it can be ignored. So yes.