Hi everyone! I wanted to get a feel for some other C++ programmers out there on how they go about programming in UE4. More specifically how you’re suppose to go about creating your own C++ classes in a logical way. For example, say I wanted to created my own C++ cameraActor class so I go and inherit from UE4’s cameraActor and create my own camera. A camera normally has a camera component, which is responsible for the camera’s view, and I want to create my own camera component to attach to my camera in order to keep any custom camera view logic separate from the actual camera itself. So I inherit from UE4’s cameraComponent class and begin creating my logic. However, when I’m done and I go to create a blueprint of my C++ cameraActor class I see that this camera blueprint already comes with a cameraComponent class attached and I can’t delete it.
My question is am I still suppose to attach my own cameraComponent class with it’s own custom logic to this blueprint (which might makes things a little confusing or over bloat the class)? or am I suppose to create my custom functions and logic inside the actual cameraComponent class within UE4 in blueprints or something? It seems as though, for the moment, UE4 pushes you more towards creating bigger classes with multiple responsibilities instead of smaller separate classes with fewer responsibilities. I could be completely wrong on this though, considering I’m still pretty new to UE4, which is way I’m asking the community :-). Thanks for any insight!
CameraActor is a special thing that only serves as a standalone camera to be placed in the level. If you have some character or vehicle or whatever it’s more common to put a camera component and all the logic pertaining to camera movement in there as well. Indeed if you look in CameraActor.h you can see that CameraComponent is private and so unless there is some RegisterCameraComponent method or somesuch, you won’t be able to use a custom one with a CameraActor.
I guess the question is, what exactly are you trying to do? My understanding is (and I might be wrong) that a CameraComponent just serves as a container for the various camera properties like FOV etc. and shouldn’t really have any logic to control its own movement. You would do this from outside of it, wherever you are using the component. Since CameraActor has a predefined CameraComponent, it would seem that this was Epic’s idea too. Put any logic to manipulate the CameraComponent inside the CameraActor.
Ahh is see what your saying. Thanks for clearing that up. So would you say then a majority of the time if a blueprint already comes with components installed then it’s probably because you don’t need to touch those classes with custom code at all? And if you think you need to it’s probably because your need to rethink your logic (in terms of who is in control of what)?
At least that might be a sign of how Epic imagined these classes should be used like, sure. Btw if you really did want your own CameraComponent for some reason, instead of inheriting from CameraActor just use Actor instead and add your CameraComponent to that? Don’t think CameraActor is really much more than just that, an actor with a camera in it.
Alright thanks so much man. Really appreciate all the suggestions. I think having the right mindset and game plan for software development is extremely important and often glossed over when learning so figuring out how to think in UE4 is very helpful.
The source code encourages inheriting from actor classes and component classes however you see fit. More often than not, actor and component functions are overridable allowing you to replace big portions of the default behavior. If you look at an actor class like Character, which comes with some components like CharacterMovementComponent out of the box, you can even change the type of that component to a subclass (of CharacterMovementComponent in this case).
Any code that you place in actor, could be placed in an actor component as well (and vice versa). So you have complete control over whether you place more code in the actor class or component classes. When placing code in components, the main advantage is reusability on other actors. When placing code in actors, the main advantage is that the actor has the overview of all his variables and components, whereas if a component requires other components (siblings) he needs to find those via the actor first.
