Good tutorial, but I wouldn't do that kind of logic in GameMode/GameState/GameInstace. You should avoid too much unnecessary code in these classess as it becomes too hard to manage as your game grows and trust me they can become "Godlike classess" with 10k lines of code or spaghetti blueprint, so new features are harder and harder to implement. I would move the logic to a new component of a GameState or even to another actor(maybe even to the crystal ball bp). With component - it works the same but the code is in another class With new actor - you could use GetAllActors -> Yes it is bad like you said, but if it's not in tick and you don't have too many calls to it on the start of the game it is good enough. Or -> make the actor(CrystalBall for example) register to a GameState so it's easy to access by the ladies, who can then register to a crystal ball as well.
Absolutely agree, and thank you for the helpful comment. We tried to keep it simple for the example's sake, but anyone who's making an actual game should compartmentalize the code like you said. I've pinned so others can see :)
Why not just make a function in the Blueprint interface. When u interact with the Ball, it shoots an event like getAllCharacterInfo. That way all newly spawned actors while playing respond too. Each character implements that interface uses the event to add themselves to the array like before and the ball just gets the info & displays
I like the style of video, it's a really nice introduction to the concept. However in your description, you claim that Get Actor Of Class iterates through all the actors in the level. This statement is only true if you get all actors of class . In reality if you specify a class it will only give you the actors of that specific class. The function itself only transfer an already existing array of actors (because all actors in unreal already register themselves). It would have been better to compare your solution to functions like Get All Actors With Tags or Get All Actors Using Interface which DO iterate through all actors to check if they fit the predicate to generate the list.
Thank you for the correction. I actually wasn't aware of the smart handling of Get All Actors of Class method, always nice to learn something new! I updated the description accordingly.
Is there a specific reason for not using Interfaces as getter and setter? With those you wouldn't need to cast to actors, which can be performance heavy.
Casting may drag down performance if you're doing it on tick. What we did is cast on BeginPlay and then cache the results for future results. The performance difference here is negligible.
