Kismet? Going rogue? Hi!

Unreal Courses Talk
,
#1

So, as per usual I went rogue at the beginning of the lesson. I thought I knew exactly what to do and… What a wild ride! This lesson threw me off a bit.

Firstly I didn’t add HealthComponent in blueprints, I added it in c++ (Health = CreateDefaultSubobject<UHealthComponent>(TEXT("Health"));). Secondly, I implemented damage using:

UHealthComponent* OtherHealth = Other->FindComponentByClass<UHealthComponent>();

if (OtherHealth) OtherHealth->TakeDamage(20);

My questions are:

  • What’s Kismet?
  • Why do we use it here? Google tells me it’s something for visual scripting. I don’t understand fully.
  • Is what I did proper? Or is it considered silly? Or is this something that’ll come back further down the course?

I am digging this chapter so far. There’s a lot going on.

#2

I’m not sure which lecture you’re on (it’s hard to tell from the tag alone), but Kismet is basically the precursor to Blueprints; it was the visual scripting system in the Unreal Development Kit (UDK) that shipped with UE3.

Code looks fine but again I can’t say for sure without looking at the lecture itself.

1 Like
#3

Yeah the categories are only really helpful when following the course and seeing the topics at the lesson itself.

It’s the " Applying Damage" lesson where we end up using UGameplayStatics::ApplyDamage. I like the ApplyDamage way, I also like the DamageType system. I’m just curious about it since I come from unity, where any sort of gameplay logic is not part of the engine itself. Now all of a sudden I’m dealing with damage systems and projectile movement components that are awesome, but also make me wonder if it’s what should be used.

It probably is. I started my unity journey on gamedev.tv as well and I like the quality of the lessons. It just feels like I’m using some old library that I shouldn’t be touching.

My base-mode when learning is doubt and so I ask a lot of questions. :grinning_face_with_smiling_eyes:

1 Like
#4

[A bit late to the party, but for other future readers…]

Regarding that code:

UHealthComponent* OtherHealth = Other->FindComponentByClass<UHealthComponent>();
if (OtherHealth) OtherHealth->TakeDamage(20);

This was implemented in the projectile’s OnHit right? The problem with it that you’re making a lot of assumption about what happens and how:

  1. it assumes the damaged actor implements its health based on UHealthComponent.
    Potentially, some actors could choose to handle the damage directly, because they would need to first redirect it to some armor/energy shield components, that need to be depleted before the health could be affected.
  2. it assumes that the only effect of the damage is on the health or that all the other effects are applied by that HealthComponent.
    Maybe some other components are used to show some visual effects each time damage is taken (e.g. make the actor blink red for a short time), or maybe to trigger a short invincibility period.
  3. it assumes that there is only one HealthComponent. Maybe the actor needs localized damages and have one HeathComponent for each damageable area (turret, base, …).
  4. it assumes that only the damaged actor/component is interested. Maybe there is a “PawnManager” somewhere that monitors all the pawns and wants to do/show something when they take damage.
  5. …

Now, there is such a thing as “over-engineering”. One needs to choose the right balance between “generic-but-usually-complicated” and “simple-but-specific/limited”. In this case though, the ApplyDamage/OnTakeAnyDamage is easy to use and all the complications are managed by Epic, so it’s very likely to be better than something like your FindComponentByClass/TakeDamage.

Privacy & Terms