Damage Event

[Punchline]

Hi!
I have a question on how we deal damage; in the " ToonTanks " lecture the way we managed dealing damage was through “Multi-cast Delegate” and we needed to write the correct function ourselves

UGameplayStatics::ApplyDamage(OtherActor, Damage, OwnerInstigator, this, UDamageType::StaticClass());

and

GetOwner()->OnTakeAnyDamage.AddDynamic(this, &UHealthComponent::TakeDamage);

whereas in the following lecture "Simple Shooter " we directly used the “Damage Event structure”

FPointDamageEvent DamageEvent(DamageAmount,  L_HitResult, ShotDirection, UDamageType::StaticClass());

            HitActor->TakeDamage(DamageAmount, DamageEvent, OwnerController, this);

I didn’t quite get the difference between these two, an explanation would be most helpful.

I appreciate any help you can provide.
Also, apologize for my bad English because English is not my native language.

[tryfinsigabrt]

Both are valid techniques. Like most things in programming there are many ways to achieve the desired outcome. For the first approach, the UGameplayStatics::ApplyDamage function is just a convenience wrapper function around creating the point damage event and calling TakeDamage on the actor. You can look at the source in Visual Studio.

The choice of using the multicast delegate vs overriding the TakeDamage function in actor is whether you want to take an event driven approach and possibly listen for damage events in other components or actors in your game or if you just have some simple logic you want to code in your actor and overriding TakeDamage is all you need. Technically you could combine both approaches if you have something specific to do in your actor and then some other components want to also know about the event. If you look a the source of Super::TakeDamage you will see that it does some logic around the damage types and then broadcasts to any multicast delegate listeners.

In general, I prefer composition over inheritance and so try to keep my actors lean and push most of the logic to components on that actor to encapsulate things better. However, it does take more work to do that as you have to create more classes and manage the events. It will help as your project grows. There is also a secondary benefit of possibly being able to reuse the actor components on other actors if the logic is generic or you can use an interface on the owning actor to provide some base capabilities or subscribe to other events in your game.