ok guys, 4.7 blueprintable introduced components and I have never missed them before…
When exactly do components make sense to use? For example in the youtube tutorial about componentsZak demonstrated how to easily put different behavior on actors.
So Zak put something like a “2DMovementComponent” on the enemy and also on the player. But the exact same thing I can achieve by just creating a blueprint actor like “Ship” which contains the movement stuff and let “enemy” and “player” both use “Ship” as parent.
Every enemy would inherit from “enemy”, and inside of enemy the score stuff is done and every enemy would have a variable like scoreAmount, so I don’t need any ScoreComponent.
Same with “TakeDamageComponent”, this stuff would be inside “Ship” since every ship can take damage, and if not I would let every ship have a boolean like “bCanTakeDamage” which would be on by default and I could set it manually in every blueprint which inherits from “Ship”.
“HurtsToTouch”, well, same! Put it into “Ship” and if necessary make it possible to disable with boolean.
In general, I can achieve everything just with parents and childs…
So where is the advantage in using components? Once having to drag 5 components on every enemy is more work than once enable/disable two or three booleans. Although both is negligible. Using components is a bit more flexible since I can remove functionality very easily, but since enemys always have to get killed and killing enemys always increases my score and so on I will never have to remove any of these components.
Reparenting a blueprint is one or two clicks more than removing a component.
I think I miss something since Epic would not have components built into the engine if there would not be a scenario where they are really useful…
Sure, you can do a deep inheritance and have completely the same functionality. But there are cases when you want to add an extra behavior without making it as a part of your main code-base. Technically you already use a lot of the components (Static Mesh, ProjectileMovement, CharacterMovement and etc.)
For example, in case of the ships he was demonstrating. Let’s imagine that the game is in 3D and when you shoot an enemy down you want them to fall down from the sky in some way. Instead of imbedding this behavior into the hierarchy of classes you just add a component on the “death” of enemy ship. Then you can use the same component to animate falling power-ups or anything else.
So in principal components won’t give you an ability to achieve something that you can’t achieve with inheritance, but they can make code management and re-usability easier.
Btw, you don’t have to drag them on to specific instances, custom components can be added to actors the same way as standard ones (Static Mesh Component, Collision Sphere Component and etc.)
For me personally, limiting factor of custom components as of now is not able to imbed other components into them. Like for example a Lifting Surface Component which would have a static mesh to represent visual geometry, physics body to have collision and etc. and blueprint code to drive behavior. We can do only code part now, which limits their usability but it’s a good start.
Almost forgot, another good place where to use them is when you want to make sure that only single instance of the functionality is present in your objects. For example, I have a FuelController class, which all of the active units can spawn and attach to themselves, I could imbed it into base class for all units but that would make unnecessary deep inheritance tree + that doesn’t eliminate potential issue with spawning more than one controller per unit or not destroying them properly. Using custom component in this case would be just easier.
Yes you can do that. And then you end up with a monolithic gigantic thing that somehow does everything and is only controlled through a few checkboxes, and then suddenly you need some functionality or changes in one part that breaks the whole system.
A very nice description of the downsides of pure inheritance is this one.
Though you should actually always think about what your really need and what makes sense, and use a combination of inheritance and components.
Regarding reparenting. I’m not sure, because I use mostly components and interfaces - but doesn’t reparenting destroy your blueprint if you ever reference variables or functions from one of your base classes?
If only your ships take damage you can do inheritance. Components are interesting if you want to introduce additional stuff with that behavior. E.g. an asteroid that can be damaged by the player.
Components would be best with loosely coupled sections of discrete functionality. But a lot of it is going to be personal taste as well, there’s nothing wrong with using inheritance as in the past. I wouldn’t go back and rewrite anything you have that’s already working unless you can point to a really good compelling reason to do so.
I was a big fan of Unity’s component system, and tried to replicate most of the functionality using interfaces in UE4 (wasn’t pretty…). I’d love a tutorial on using and creating blueprintable components in C++. Any suggestions?
And don’t forget you can use inheritance for components too. For “is a” relationship inheritance is better, for “has a” relationship components are better. Let’s say you have a Soldier class inherited from Characther class and it has a AssaultRifle component inherited from Weapon class component. It’s very viable for my “tastes” because it’'s a good example of “is a” and “has a”.
I think reparenting is under the class properties menu. It used to be called BP props. It can be dangerous and lead to data loss. If the parent had a variable and the new one doesn’t have that variable it will be lost. If you ever go back to the original parent you’ll have to repopulate the data. I’ve had a number of cases where a minor error temporarily broke the inheritance chain and then bam my world transforms were all reset back to the origin. Usually this occurs with errors, but I’ve had it happen with reparenting too.
