Unity Interfaces vs Abstract Classes - Part 1 - Interfaces 

thats a great explanation thanks mate

this is what I don't understand though. I write a class with an interface inheretance like IDamagable right next to monobehavior. And then you need to define the function below. Well if you didn't use an interface you'd have to do that anyway so the interface doesn't provide any benefit. You can just make a public function, create an instance of the class that the function belongs to in the script that attempts to call that function and it's literally the same thing.

You are lucky , because you didn't celebrate the fuckin 2020 :D

Yeah, I wouldn't have been able to do it either... ha ha... ha **looks over at mega class full of public variables***

Hi sir, I'm a newbie and have been using public variables so I can just tweak them in inspector. May I know what is the difference in using public and serializefield variables aside from making them visible in the inspector ? thanks ^^

@@blossumgames9443 public variables can be changed in other classes using GetComponent() private can't

Thanks! Adding that to my whiteboard now. I've seen a lot on lighting in 3d, but never thought about doing one on 2D, seems like a fun topic :)

it has to be one of the most scarce topics in Unity. Any decent video on it will be a top video with a lot of views.

+1

edman3d There are some great asset for 2D lighting, like SF Soft Shadow 2D (payed), Light2D (free), etc.

Yes, Jason is a Rockstar!!!

This is a great question, feel like it deserves a video of it's own. Adding that to my board now, will get it up asap

Jason Weimann Hi Jason, so did you made a video about the question above. I’m really interested in that topic as well.

For the UI problem. Summarized below. The thing I learnt from a video is that visual stuff should listen in on logic like the player's health. First you make the player's health a Scriptable Object so it never vanishes. Second the currentHealth is a get set variable. The UI is on the player's gameObject as a component hence you simply get the Health Scriptable Object regardless if the player exist or not. Thus the UI and anything is not prone to error if the player is erased or disabled and the player's Health or other components doesn't rely on the UI component or sound in any way etc. Now for the update of status part. Use a delegate in the player's Health which is triggered every time the player is hit which takes in a value. Do this by making the currentHealth's set or damage function Invoke the delegate every time the set is given a value or the function is called which is then added to the currentHealth on the Health script. You can also use an Interface that enemies or anything calls for the first time to get the player's maxHealth and currentHealth. This means anyone can get the info off the player and get updated without the player actually knowing about it and if the player is deleted or disabled then nobody throws an error as they don't directly contact the player to check their status and simply their function is unsubscribed, it doesn't even have to be, it still won't throw an error. When the UI or sound component is created it subscribes a function to the Health delegate. So every time the player is either healed or damaged, the Health Scriptable Object will call the functions automatically so no need to constantly check up on the currentHealth. The function in the UI checks if the hit value is negative or positive. If positive it will play heal particles based on the amount, if negative it will show damage particles based on the amount. This value is then applied to the health bar which goes down or up slowly to the new value. It then calls another function to see how low or high the currentHealth is. If low enough it shows flashing effects, if it's too high it shows over heal effects. Don't forget to unsubscribe the functions if the UI or sound component is removed or disabled. SO SUMMARIZED: Player's health is in a script called Health which is a Scriptable Object. The Health script has a delegate that is called every time someone damage it. The delegate function takes in a value, which is the damage the player was hit with. Anyone can subscribe to the delegate and call the Interface to get the values to setup. Now anyone can subscribe and get info from the player's Health and have any function or feature do whatever they want with it. Like an enemy whose attack rate is based on the player's missing health by taking maxHealth-currentHealth. Or a sound script which becomes deeper the more a player is damaged. All this is done separately from the player without their knowing and doesn't have anything to do with it. This means you can create, add and change out the Ui for a new one or create an entire new enemy who also changes his behavior based on the player's damage taken or their current health and you don't ever have to touch or change the player in any way at all ever. And nobody gets an error if either is suddenly deleted. Cause a Scriptable Object is separate from the game and doesn't vanish or reset in or between scenes. And because nobody depends on the other to exist and only gets their values updated when they change then there's no performance being used up on constantly updating their values by calling the player and getting the values directly.

@@magnusm4 wow awesome

I know it's been many years since the original comment but for anyone wondering, at least for me, my answer to many of those questions is just "use scriptable objects" the ui can take a floatSO and communicate with that once it updates and the player can communicate to that same floatSO when the health changes, it decouples your scripts in a really easy way plus because scriptable objects are just assets that live in your project, you can fill those references in the inspector and when you save the prefab those references will get saved, so you can just grab those prefabs and put them in a new scene and not have to worry about the references being lost or having to resolve a bunch of dependencies in awake methods, it really has changed the way I approach gamedev in unity

You're welcome!

lol thx :)

awesome, make sure to check out abstract classes too :)

Yes

That would be the better way to go - composition. Interfaces are a form of composition, but for OOP. They are not very good for game development, and you will only find rare cases where you need them (events, and Unity events specifically, for example).

ICanBeDestroyedFromCrash