approaches to pass damage to enemy instances - performance concerns

dearme

Given the player is spamming projectiles from a machine gun at hundreds of swarming enemies - I would like to find an optimal solution on how to pass damage from a projectile to an enemy and not make game suffer from performance issues.

I have discovered multiple options on how to accomplish it:

Signals
Direct method invoke
Deferred method invoke
Tweener

I have prepared the code that basically shows all 4 options in action (no testing done)..

Using Godot 4.0.2, C#


public partial class MyEnemy1 : Entity
{
    [Signal]
    public delegate void HitByBulletEventHandler(int damage);

    public override void _Ready()
    {
        this.HitByBullet += OnHitByBullet;
    }

    public void HitByBullet(int damage) {  }
}

public interface IHittableByBullet
{
    void HitByBullet(int damage);
}

public partial class MyEnemy2 : Entity, IHittableByBullet
{
    public void HitByBullet(int damage) {  }
}

public partial class MyBullet : Area2D
{
    public override void _Ready()
    {
        this.BodyEntered += OnBodyEntered;
    }

    private async void OnBodyEntered(Node node)
    {
        // option 1: signal
        if (node is MyEnemy1 enemy)
        {
            enemy.EmitSignal(MyEnemy1.SignalName.HitByBullet, 1);
        }

        // option 2: direct invoke
        if (node is IHittableByBullet target)
        {
            target.HitByBullet(1);
        }

        // option 3: deferred invoke
        if (node is IHittableByBullet)
        {
            node.CallDeferred("HitByBullet", 1);
        }

        // option 4: tweener
        if (node is IHittableByBullet target2)
        {
            var tweener = CreateTween();
            tweener.TweenCallback(Callable.From(() => target2.HitByBullet(1)));
        }
    }
}

I would like to know the pros and cons of using these options.

For instance,

direct method invoke - would halt the frame right away and wait the method finishes execution
deferred method invoke - the damage to the enemy would only be done at the idle frame, after the current frame. Meaning there is going to be a slight delay before enemy receives the damage. Apart from it I am interested whether it affects the performance in any harmful way. Wouldn't this mean that there is no difference between direct invoke and this approach, if both methods freeze the game to some extent anyways. The only question is When it happens - immediately or at idle frame 🙂
then the Signal and Tweener are two options I cannot comprehend. When do they execute the code and whether it's any different than calling the deferred method
Signals are executed in the same order as they were added to the queue (FIFO)
Signals are often brought up as a manageable way of communication between objects in Godot. But I also think that interfaces just as convenient.. So I started to question myself if I want to use signals for every single case or would it be better to use deferred method invoke and the interface, for example.

If someone could correct me and provide some details on each approach - it would be very appreciated!

xyz

1-3 are basically the same. Signals are just a convenient way to centralize function callbacks. So regular call there. Deferred calls are regular calls as well. They are added to the queue and called at the end of frame. You'd typically use a deferred call if a callee depends on something that is yet to be updated in the frame (e.g. by some script that is processed after the current script in the order of execution within the frame)

Number 4 makes no sense in this context. Why would you want to create a tween simply to call a function without delay? Just call the function.

Btw. You shouldn't worry too much about performance until it actually starts affecting your application. It's called premature optimization and some say it's root of all evil 🙂

dearme

xyz perfect! I mostly wanted to hear that signals are not adding any benefits besides their convenience. Personally I see not point in using them when I can just invoke the method directly. It would have been another story if for example, they were executing the code concurrently in a non-blocking manner. On the other hand, if the result is the same then I can just as well stick with the easiest option.

You are right about the premature optimization and I can confirm that it's been a problem for me with over-engineering of projects. Thank you for the response.

xyz

dearme Yeah, always stick to the simplest option. And it can't get much simpler than a straightforward function call. Custom signals are very convenient if you have one-to-many or many-to-one communication. For one-to-one there's no much benefit except maybe it looks better in terms of system design.
Have in mind that none of your script code runs in parallel. Order of execution in strictly defined. If you want concurrency you have to be explicit about it by launching your own threads.

dearme

xyz isn't it the use-case for a tween then (apart from threads as explained here https://docs.godotengine.org/en/stable/tutorials/performance/using_multiple_threads.html)? As it has Parallel() method, i.e.

var tween = CreateTween().SetParallel();
tween.TweenCallback(..)
tween.TweenCallback(..)
tween.TweenCallback(..)

now we got 3 methods run in parallel supposedly not blocking the main thread.

xyz

dearme No. It just sets Tweener timers to count time simultaneously instead being queued to count sequentially, the next one starting after the previous finished. This has nothing to do with script code concurrency. So for example if you tween 3 callbacks, each with 1 second delay, they'll by default be called consecutively, each at the end of every second. If the parallel flag is set, all of them will be called after 1 second (but still one after another in terms of code concurrency)