#Alternatives to if else
1 messages · Page 1 of 1 (latest)
oh okay! yeah i'm still pretty new with this, this is the first game I've fully developed.
i'll look more into interfaces
public interface IAttacker
{
public int DMG { get; }
}
...
// Implement IAttacker on your enemies, or use inheritance.
// It will require DMG to be a property that has a getter.
...
if (AttackedBy.TryGetComponent(out IAttacker attacker))
{
// You can now use attacker.DMG
}
out keyword may needed
oooh, okay yeah this seems like a much better way
Practically, if you find yourself using the same code over and over there may be a root shared interface to implement, and your code just operates on the subset of functionality that the interface is saying these objects implement
okay yeah, perfect, thank you so much for taking the time to reply
there are definitely more efficient methods of doing a lot of what I'm trying to do i know for sure lmao, but currently I'm just trying to make things actually work xD, but this is a good time to familiarize myself with better ways of doing things
Hey there, I'm sorry to bother you again, I just had a few questions now that I've looked up a bit more about Interfaces, and am having a tough time wrapping my head around how exactly to implement this. In your example, is the AttackedBy variable meant to be the transform attached to the hit Collider of the enemy? Also, with an interface, say, that would be used by all enemies, would I put every variable that an enemy has in it? such as HP, DMG, DEF, etc...? I've watched a few tutorials now and it seems like, as an example, maybe there would be an interface for anything that can take damage called like IDamageable, including enemies and players that have similar things that would happen if attacked, like, reducing HP? Also, in your example, would you maybe use the IAttacker interface on enemies and players alike, or anything that can do damage?
Again, I apologize for bugging you, and by no means is this urgent so, if/when you have time to get to this, i would be super appreciative! Thanks!
AttackedBy is just the object that has the component you care about, same as your original example
oh okay gotcha. right, right, i'm an idiot lmao, in the case of my janky code it is a transform, but it doesn't have to be
And yes, if all your enemies had common properties that you wanted to access, then maybe you would add them all to an interface. How you break it down is up to you, it's just a contract that says these objects have these things, and you can use it in Unity's methods instead
okay i see, ultimately it would make it easier for me to detect specifically which game object is triggering the player's hitbox collider because I could find what object it is based on the interface attached to it?
well, thanks again for the help! i really appreciate it
You'll be getting the object that is triggering it if it has the interface, yes. The main point will be that you don't care what object it is any more, just that it's one that implements the contract
So you can have one implementation that only uses the things you care about, and doesn't need to know anything extra