Say you have a car composed of multiple actors for each part (like a door actor, wheel actor, radio actor etc.), all attach to the body of the car, for example. I have timelines in some of these actors that I need to wait for before I run code in a different actor.
What’s the best way to approach something like this?
lots of solutions to this but an easy one would be to use GameplayTags on the root actor and listen for Tag events. So each component can add a Tag when its ready and when any tag is added check if all required tags are on
“Tag events“?
So create a GameplayTagContainer
Create functions that Add/Remove Tags to that container which also calls an EventDispatcher with the GameplayTagContainer as an output.
Then anything can bind to that EventDispatcher, check if the Container has AllMatchingTags and if true execute an event.
Thanks. What do you thing about state trees? Could that be a better option?
havent tried them extensively yet, i dont think they suit this task but could of course be made to work
My advice is to communicate directly.
First those parts (door, wheel, radio) sound like components instead of actors. Actors create an overhead and assume independent movement. You won’t be moving the radio or the wheels independently of the car right?
The car is a car because it has 4 wheels and 2 doors etc. Not only that but there are probably no wheels running around without a car. The car already has the pare references (regardless if they are actors or components) and the part can get the car reference on begin play.
From that point on just call methods on the parts and the car directly - they are one entity. Parts can even have references to other parts if they communicate too often. This will make your code faster and more readable but you won’t be able to separate the parts. To be honest, I don’t think you would want to separate them anyway.
Event Dispatchers. When your timeline animation is done, you trigger an event dispatcher. Any BP listening then knows the action is complete.
The reason I want to use actors instead of components is because I need to save the state of each of those “car parts“. Of course I could save the state of the whole car, but if I decide to add/remove components, I need to re-adjust the “saving“ part of the code accordingly.
It’s a lot easier instead, to have one actor per part, and each actor can take care of it’s own saving, and just slap them on top of each other in a hierarchy in the level Outliner, to form the whole car.
Unless I’m missing some big downside.
Child actor components are not designed to be used like that. This approach will lead to slow loading and even instability.
(Check “Don’t use ChildActorComponent?”)
They didn’t say they were using child actor components. That said, like most programming tasks, there’s many ways to accomplish things, and any one of them that works is the “right” way, even if there are better ways… as long as it works, it’s the “right” way.
I.e. there are reasons child actor components exist, and not everybody is experiencing the same problem domain. A lightweight game is vastly different than a AAA, massive world, multiple player game, which is vastly different than people using UE for non-game purposes.
Thanks for the link. I’ll have a look.
But I’m not using child actor components. Just actors that attach to one another.
My mistake then.
I really have no clue of how you actually compose your objects but I still advice you to communicate directly with your sub parts and only go for event dispatchers if you really, really need dependency reversal and decoupling.
I would also encourage you to use components instead of whatever it is you are doing with the actors but it is your decision after all.