So I have a blueprint actor, I want to add components to it and then edit instances of that blueprint placed in the world. Having to create variables and route everything into the components from the construction script is a joke.
Why would you put so much effort into removing boilerplate from scripting and c++ only to enforce this bizarre boilerplate in your high level systems?
Why is an actor defined in c++ special in that I can edit actor component instances?
Why do I have to define new actor classes at all, shouldn’t Actors really be an opaque component containers?
More aggregation, more composition, less class inheritance!
In short because of the lifecycle of a component defined by a blueprint component and one from c++. The blueprint components are destroyed and recreated everytime the construction script is rerun (so a property changes, it is moved, etc.), and at the same time, any changes made to the properties of those components in the blueprint need to be reapplied. Tracking what instance properties come from the templates in the component tree, what properties are modified by the user construction script, and what has been set by a user on a per-instance basis turns out to be rather non-trivial and it took quite a lot of work to work out the edge cases.
You don’t, you can create component blueprints as well. Using an Actor class allows you to provide higher level logic and reasoning about known collections of components.
Thanks Marc, I’m looking forward to seeing how this works in 4.8.
As for inheriting from Actor, Pawn and Character both mess with composability a lot. In my opinion, these special case actors need to go away. Or at least possess no data other than the component pointers. If I want any actor to be possessable, give me a PawnComponent and a ControllerComponent, and if I want it to move, let the CharacterMovementComponent stand on it’s own.
I appreciate that this system design has been used in battle for a long time. That said I think if you’re not going to go with something totally new and exotic, then the more puritan Component/Entity design of something like Unity is the way to go. It seems like that is the direction we’re heading but I obviously don’t know what the roadmap is.
Thanks for hearing me out, you guys have been doing a great job!
I see it the same as the OP. I first couldn’t believe it when I saw how complicated it is to compose blueprints right know (4.7). Why is it so extremely difficult to add a blueprint to another blueprint? I thought, that’s the whole thing about them?
EDIT: So 4.8 will let me finally add all blueprints (derived from actor or scene) as components and configure them right in the editor? I will not have to derive a special preconfigured blueprint and add this as a child actor anymore?