I recently started working with Unreal Engine 4 and am still in a phase where I am trying to figure out how things can or should be done in UE4. To get started, I am creating a top down space shooter (learning by doing ).
I already created something similar in C# (a space invaders clone) and used a component-based architecture (yeah I know, thatās overkill for such a simple game. It was about the learning experience ). I really like the benefit of being able to freely compose components on game entities to add behavior (like a health system/combat behavior, an RPG system with XP, etc.). I am at the point of implementing weapons and a health/shield system into my game and took a look at the Shooter Game example how itās done there: They put everything into the Character class itself.
Would it be possible to create something like a custom Combat Component and add this component to my PlayerCharacter (and to enemies) to handle this stuff? I saw thereās an ActorComponent for logic stuff, would this be the right one?
I saw thereās a recent feature request hinting that all the possibilites arenāt quite there yet here: Feature suggestion: Complete Entity-Component-System for UE4. Though I have to admit I donāt know what the entity component-system in Unity looks like. I also saw a reddit post where someone asked a very similar thing, pointing out that Blueprintable Components seem to allow such a component-based architecture.
Or would you suggest sticking to the inheritance-based design the UE seems to advocate in the Shooter Game example?
Looking forward to hear some opinions and advice about the pros and cons of these approaches. Or if you think a fully component-based approach is even possible?
If you want to stick to the style of existing actor classes, you can do the health system in a component class and make the component itself a retrievable field. Take for example the character movement: logic in UCharacterMovementComponent, you can get a ACharacterās reference to the component using ACharacter::GetCharacterMovement(). If you donāt want to put restrictions on what actor class has the health system, there are two ideas that I can think of:
Use AActor::GetComponentsByClass to find attached components by class. I wouldnāt use this one except for preprocessing (locating a component once and then storing the reference).
Make a āHasHealthSystemā interface (UInterface) that any actor with a health system can implement, where the interface has a function to return the health system component (I prefer this idea over the previous)
The only pro/con I can think of for inheritance vs. component based is that:
With inheritance you never need to test whether the component exists or implements the interface, also slightly easier when you have systems that work together
With components you have plug-and-play functionality
Thereās already some ādamageā type functionality in the base Actor classes I think. Iām not a huge fan of inheritance for games, so Iām using it, but iām holding my nose while i do it
Seriously, all of this should come from composition. But UE is simply not ready for that quite yet. So i guess the question is, if you want to extend the component system or not? You COULD do these things with blueprint based components. They also have interfaces you can query for implementation etc.
Basically, the C++ code is a fair bit behind the blueprint code in that sense.
After reconsidering it, I came to the conclusion I donāt need the absolute flexibility to add and remove components during run-time. That would be nice to have, but is not really mandatory for my game.
So I think I will go with something like your second approach, NisshokuZK, since I like it better as well. I want to use components mainly for reusability and structural reasons, so I will be adding the components directly to my actors.
@zoombapup: I agree, composition is the way to go in modern complex software architectures. I will take a look into whatās possible with Blueprints and components, thanks for the tip! I guess thatās the best solution anyway, since Iām working with a friend who is an artist and that allows him to try and contribute stuff for these parts as well. Do you know any resources on whatās possible with components in Blueprints? Never heard of interfaces in Blueprints before.
My few cents, which I have leanred when I have been implementing (and still work on it for that matter), advanced effect system (buffs/debuffs/attributes).
tl;dr version is I would put health/damage handling/etc in Component. Componenets can be easily added/removed from actors, who said that all actors must have health and take damage ?
The long story is, my implementation is pretty complex, and you probabaly wonāt need such thing, for simpler system, but there are few things you can do:
Create AttributeComponent. Make base class, which will handle Damage or attribute changes, orā¦ you get the idea. How exactly you will implement it is up to you. Simple system will just call function like TakeDamage or ApplyDamageToTarget(), where you simply implement what happen, when damage have been dealt.
Ok you have component. Now, how do we make sure that actor which is attacked have this component ? There are two ways. One you can simply call FindComponentByClass(), and check if there is component, and then call functions on it.
Other way (proffered by me), is to creater Interface, which class must implement, if it have specific component (well, it doesnāt really need it, but itās convenient). This interface contains exactly one function. GetYourComponentName(). You can add more functions, to interact with component systems if you wish.
Donāt overdo this though. If get to the point where interface mirrors component functionality, you could just as well implement everything using interface.
The rule of thumb is that, Interface should make interacting with component easier, and less painful for end users.
Then you can implement some static functions, to interact with this system trough blueprints.
Ok guys, so I created a UCombatSystem component that inherits from AActorComponent to handle health, shields, taking damage and dying. I took a look at the First Person sample to see how health and damage is handled there and some questions popped up:
In the sample, the ShooterCharacter has a Health property of type float. Why do they use float and not int (uint16 or something like that)? Negative health isnāt really needed, or is it? Is it just because of the higher precision to have decimal damage values? Why does the GetMaxHealth method return an int32 then?
Am I right in the assumption that this code retrieves the max health value by querying whatās set in the archetype (default) object?
So I can set the max health for all actors of the same kind in the defaults pane of the editor?
As far as I can tell by the samples, itās common practice to work with public members in the UE. For example, health is a public float variable of the ShooterCharacter. I feel kind of uneasy to publicly expose member variables like this (data encapsulation, I learned to make everything private unless I have a good reason not to). On the other hand, I see the advantages of simply being able to set the variable in the editor (like in the archetype for a default value on all actors of the same type). How do you work with this? Is there a way to achieve the same while having setters/getters and a private variable for something like this? Or am I being overzealous with best practices here?
Would be nice to hear some advice and about your experience.
).
). I really like the benefit of being able to freely compose components on game entities to add behavior (like a health system/combat behavior, an RPG system with XP, etc.). I am at the point of implementing weapons and a health/shield system into my game and took a look at the Shooter Game example how itās done there: They put everything into the Character class itself.