The idea on ECS architecture is that you have components that are pure data, that are being added to the Entities that are pure collection of Components and then you have systems that depending on the containing component types of each entity either process the entity or not eventually completing some functionality. The benefit is that when you add or remove a component (which is just data), you change the behavior of the Entity.
In this link we see how Blueprintable components work. Those are amazing! So in Unreal things are in different way. You have predefined components for which some functionality is written in the engine. You can also define User Defined Components which contain data AND behavior. What if that behavior requires data farm multiple Components? [In pure ECS it is always like that - several components constitute a single functionality. (e.g. PositionComponent and MoveComponent together result the Entity to move and if one of them is absent, Entity will not move).] I mean I can randomly add and remove Components, and still each Component in my Actor should know if it has all the components required to accomplish the functionality. How should I achieve this in Unreal?
P.S. I need this so that if I would remove a Component some functionality will be disabled util I add it back.
You’d have to iterate through all of the Parent actors’ components, then cast them to the component you’re looking for. There’s a handy template function
AActor::FindComponent<T*>()
that will return the first component of that class it finds. Not something I would be calling every frame though.
Aside from that, splitting up your functionality across components like that isn’t really a good idea - so I would only do that if you really need to, otherwise you’ll suffer the cost of multiple actor components which aren’t necessarily “cheap” in terms of additional overhead.
Really it’s best to think of Components in Unreal as a solution to not supporting multiple Inheritance. They’re designed to add functionality to the owning actor, not necessarily change it as such.
Yes I think it can kill the performance. That is why I don’t know what to do.
But the ideas is that you have components, and you add and remove them and get some behavior or not based on the current set of components. Do you agree with my point related to Position and Move Components above?
Position and Move is a tricky example, because by default the RootComponent of an Actor is a Scene Component, which has a world transform and supports things like rendering. There is then a generic ‘MovementComponent’ in the engine already (which your movement component should inherit from, as it has roots back into all the AI pathfinding systems and suchlike) - which typically used to move actors. Not all actors need to move though, so the movement stuff is an optional component, but the interfacing is seamless because you can always guarantee that an actor will have a Scene Component at its root.
However, if I was doing a health system for example - I wouldn’t have a ‘Heath Component’ and a ‘Healing Component’, I’d have them both be the same thing and just turn the behavior on or off in that component. Modularity is great and all, but you can go too far the other way and make life difficult for yourself - which matters a lot in this realtime / performance conscious field
Once you have a list of all the behaviors you want, my advice would be to condense them down into things that relate to each other and keep the list of separate components to a minimum. This does depend on your requirements of course, but in my case, Health, Ammo, Weapon Inventory, Radar Pulses etc are all managed by a single component. I don’t want the radar to pulse when the object has no health / is dead for example - so it’s easier to keep all that code together.
I agree with majority of your points except this one:
Here you break SRP (Single Responsibility Principle) which is really evil. But I think merging as much as possible while not breaking the SRP is a very good approach.
Well not really in my case, since the Component is a ‘GameObjectComponent’ and it does all the things that I need my GameObjects to do.
If I had multiple inheritance support, all of the functionality I add to that component would be on the owning actors instead and all the data relies on each other. My advice would be just do whatever works best for your project
