Wanted some opinions on ways to set up triggering “on-kill” effects. In short: The player can have abilities that trigger effects whenever they shoot and kill an enemy. I’m also looking to extend abilities to enemies as well, so can’t just hardcode a player reference.

Currently I’m doing it like this:

  • Enemy signals that it died -> the bullet receives this and signals that it killed Enemy -> the player’s weapon receives this and signals that it’s bullet killed Enemy -> the player receives this and triggers it’s on-kill abilities.

It simultaneously feels like a good way to go about it but also a long mess. The other option I’ve considered is:

  • Each bullet has a reference to it’s owner (eg. player). When an enemy dies to a bullet, it looks to the bullet’s owner reference and tells it to trigger it’s on-kill effects.

This way is a lot simpler to write, but is error prone eg. In cases where the bullet’s owner is killed while their attack is mid-air.

Thank you all!

  • rtxn@lemmy.worldEnglish
    0·
    8 months ago

    I have little experience with Godot, so I’ll just write the general concept and you’ll have to translate.

    I’d go with #2, but also have the bullet subscribe to an event that is triggered when the shooter player dies. When that happens, set a private variable that tells the bullet that it shouldn’t trigger any on-kill effects (or you could do other things like detonate or remove the bullet).

    Something like that in C# (or close to C#, it’s been a while):

    class Bullet {
    private bool _player = null;
    private bool _enableOnDeathEffect = true;

    private void OnPlayerDeath(object sender, EventArgs e) {
        _enableOnDeathEffect = false;
    }

    public void OnKill(){
        if (_enableOnDeathEffect) {
            //trigger effect
        }
    }

    public Bullet(player) {
        _player = player;
        player.OnDeath += OnPlayerDeath;
    }
}
  • Melmi@lemmy.blahaj.zoneEnglish
    0·
    8 months ago

    I tend to prefer the latter, but I totally get that feeling where signals seem like they “should” be better. I just find in practice that references are a little easier to work with in some cases.

    You can easily solve the owner dying issue by just using is_instance_valid() before attempting to call anything on the owner reference.

    That said, you can probably simplify your signal code if you connected the bullet killed_enemy signal directly to the player’s on-hit handler. It seems like the weapon on-kill handler is redundant? But I don’t know the details of your implementation, I just know that there’s often ways to simplify chains like this.

    I find that signals are great in some use cases, and less good in other use cases.

    • Jozzo@lemmy.worldOP
      0·
      8 months ago

      The longer I’m using the signal chain the more I’m wanting to rework it to just be a reference lol. Good point with checking if the instance is valid, if any other errors come up I could just patch around them in a similar fashion.

      That said, you can probably simplify your signal code if you connected the bullet killed_enemy signal directly to the player’s on-hit handler. It seems like the weapon on-kill handler is redundant?

      Ah I see what you mean, killed_enemy(enemy-object) signals directly to the player which can then pass that enemy to it’s abilities if needed. You’re correct that the weapon signal is mostly redundant, it was just the easiest node to connect to the bullet’s signals, as it’s responsible for spawning them.

      I think I’ll change the whole system to just use a reference. Thanks for your input!

  • Bezier@suppo.fi
    0·
    8 months ago

    Definitely the latter. Rube goldberg machines will become much more error prone. The more steps you can simplify out, the better.

    You can write a simple guard in case player has died:

    if !is_instance_valid(player):
    return

player.onkill()