Friendly Fire

By Will Fox

3/23/2023

Hey everyone! Today, I wanted to talk a little bit about our damaging system that we have in place and how we got around enemies hurting other enemies and enemies not being able to hurt the player when they possessed another enemy. So, to start off, we first found this problem when we had multiple enemies in a level, and the ranged enemies such as the Lich and the Skeleton were shooting at the player, but short ranged enemies like the Ghoul got in the way of the projectile. When this happened, the Ghoul ended up taking damage and sometimes was even killed by these projectiles. After finding this, we experimented to find if this was the case for ALL enemies, and it was. Essentially, there was a flaw in our "do damage" logic that allowed enemy projectiles to hurt other enemies.

In order to begin fixing this problem, I needed to take a look at the what the logic was that allowed things to take damage to begin with. After a quick glance, I found that there was only one logic check being made. It was making sure that the collided object wasn't the enemy that was shooting or swinging - since we don't want the enemy to damage themselves. It was very clear there were a couple of things missing here. For starters, there was no logic that checked if the object being hit was another enemy or the player.  So, to fix this, I added a branch node that checked to make sure that the collided object had the tag "player" attached to it. This worked, but caused some other bugs. Although the projectiles no longer damaged allied enemies, it made it so that if the player possessed an enemy and tried using their attacks to damage another enemy, it wouldn't work - since the damage logic only executed if the thing being collided with had the tag player attached to it.

So, after seeing this, I added some more logic that allowed the damage nodes to execute if the player was damaging and enemy or vice versa. This really wasn't too difficult, luckily. Most of the problems ended up being something related to being "out of scope" and not being able to access variables. But, these problems can be easily solved by implementing a getter and a setter. So, after all was said and done, this was how the friendly fire function worked. It starts off by getting the "damage dealer" and checking its tag. If the tag is "Enemy," it will return true. It then checks the object that is taking the damage. If the tag is "Player," it will also return true. If both of these Booleans are true - done via an "And" node - the function goes straight to the return node and returns true. If both values are not true, the logic then checks the inverse. If the damage dealer has the tag "Player," and if the damage taker has the tag "Enemy." Again, if both are true, the function returns true. The last thing that I added to the friendly fire function was, of course, a friendly fire Boolean. If the Boolean is set to true when the function executes, no matter who it is, friend or foe, they will take damage from the source.

It's nice to say that this function was not as steep of a mountain that I had originally thought. When I had began working on this issue, I thought that I might have needed to make a completely new enemy because the tags were all wonky or there was some strange issue with collision. Luckily, there is only one tag attached to the enemies and it makes this logic a lot more straight forward. Running into this problem has definitely broadened my horizons, though, as tags can be extremely useful if you're running into some strange logic issues. Sometimes, all you need to do is tag the the object/actor in question and make a logic check against it.