Interface Damage
Вставка
- Опубліковано 9 лют 2023
- bit.ly/3I2JLyC - Best GameDev Course for Beginner & Intermediate Devs
prf.hn/l/dlR0JwZ - GET YOUR FREE ASSET
game.courses/beginner/ - Free GameDev Course for Beginners
bit.ly/3sKGagG - Game Architecture Course - Advanced Course
unity3d.group - Join the Group (facebook)
/ @unity3dcollege - Join the Channel
Thanks for this! While I'm already aware of interfaces, it's nice to see these kinds of quick videos to see another quick implementation and drill that information in to the brain by repetition, to help me really grok the concept and get to using it myself.
That's very useful for people who are learning programing or unity. Interfaces are awesome !! Cool video!
Super informative as usual!
Great Explanation Thank You Jason!
Great quick video! thanks!
Something I learned this weekend:
If you create a child class to a parent class that implements an interface, and create new versions of the interface functions for the child class, you will need to also declare the interface on the child. If not, when you run the interface function, it will be the base (parent) version of the function.
The correct way to implement this is to make the base method virtual and override it in the subclass. Otherwise you are going to see different behavior when interacting with the object depending on the variable's declared type.
@@Joooooooooooosh so the virtual base method gets the interface and since it’s already assumed the sun classes will implement their own functions, it already keeps that in mind?
@@pirateskeleton7828 Essentially. An overridden virtual method becomes the new target of any calls to the original virtual method. The override *can* optionally choose to call the base method at any point, but doesn't necessarily need to.
If you don't add virtual / override modifiers, what you end up creating on the subclass is a "new" method which is almost never desired, which is why C# complains about it at compile time unless you add the new modifier.
@@Joooooooooooosh Finally got around to it and turned all of the relevant functions in the parent class into virtual methods. Made the child class look a lot cleaner, and no longer need to retag it with the interface. Good stuff
I contributed to the spirit like!
Note on why the public key word can be good. You can also have internal or protected, and specifying the level will allow for better interaction with the interface.
Interface members are not allowed to have accessibility modifiers. And implementing methods must be public. What you can do is use explicit interface implementation, and in those explicit implementations, call private or protected members.
Jason, could you make a video of a system like PoE/Diablo where attacks/actions can change based in the equipment of the character and traits?
What would I be missing out off by creating seperate scripts for e.g. doing damage or having health and attaching these to my gameObjects?
Hi Jason, quick question: what font are you using in your code editor? I like spherical parenthesis.
hey jason, i've noticed you are building your project in visual studio after saving, is it for avoiding that annoying unity load scripts popUp?
or ;..
i never saw someone doing that
Would it make sense to use an abstract class instead of an interface so you can have a default implementation of taking damage? I’m thinking many enemies would take damage the same way and you’d avoid a lot of duplicate code. Then override the ones that need something different.
That is an option, yes, but it can quickly paint you into a corner since C# does not support multiple inheritance. You can get the best of both worlds by using an interface plus an abstract base class that implements the interface. But never reference the base class except when deriving from it.
I thought this video was going to be about designing user interface that looks weathered/damaged from the thumbnail/title lmao
If you needed to know who killed an enemy, how would you implement that? Carry the information of who shot the bullet inside the bullet object so it can be looked up in the collision callback?
In the interface you can make a out argument.
Damage(float damage, out ???)
That'd be my default approach with this code. Probably as a parameter for launch
That would work too
I had similar requirements so I decided to implement hits that use a "HitContext" as a parameter. It holds data about the owner of the attack, the target hit (both as interfaces), and all hit related data like damage, stun values, etc. It's important to note that the owner of the hit is not necessarily the same GameObject that deals the damage. For example, a player can shoot a fireball and take ownership of it, so when it hits an enemy it registers as being an attack made by the player, even tough the GameObject is dettached from him.
The other difference is that, instead of returning a bool, I perform a kind of "handshake". If the hit confirms, it calls a "HitConfirmed(hitContext)" in the owner of the hit. That is used to handle hit reactions that occur mostly in melee combat.
Each bullet running a script? Yikes lmao. How about you make a bullet manager script that is in charge of spawning and moving all bullets and carrying each bullets information and detecting if each bullet hit something. All done in one script just saved you hella fps now that you don't have to do obtuse OOP crap In a game. Seriously OOP in a game is an insane idea.
Thanks for your dedication to help us aspiring developers to increase our knowledge and skills
Snail is still alive...
Interesting. I already do this but I never used the term interface.
IDamageable was my implementation
Does exactly what you've done here but without the term interface.
Interesting though I was unaware I could charge everything to being assumed public using the term.
How did you manage to write an interface without using the term interface?
There's a difference in between inheriting from a class and implementing an interface in a class.
Most important one is you can only inherent from a single parent class while you can implement multiple interfaces. For example if you have a chest and you would want to be able to destroy it but also give the player the possibility to open it without destroying it but there could also be a different behaviour for some other chests (boxes, barrels that roll over, mimics anyone?, etc) you cannot inherit from two different implementations. You ca't even inherit from MonoBehaviour and a parent class (your parent class can inherent from a MonoBehaviour tho, sou you can chain) but its much much easier just to do something like class Chest : MonoBehaviour, ICanBeOpened, ITakeHits then writing a class Chest : CanBeOpenedOrTakeHits, and a class CanBeOpenedOrTakeHits : TakeHits, and a class TakeHits: MonoBehaviour. Gets even worse if you want a chest that cannot be destroyed... then you need another class UndestroyableChest : CanOnlyBeOpened and its full parenting chain...
Have you abandoned dark mode Jason? :)
nice video about interfaces of C#, but judging by the title and the thumbnail i thought "interfaces" would be as UI
but still, good video
Another excellent video. I'm fairly new to Unity, but I've been a developer for a loooong time. Most game dev videos are geared to new developers or people coming from the artistic side. I sometimes have difficulty applying the techniques I already know from desktop application design to Unity. It's great to see how good software development habits can be applied to Unity. I'd like to see a video on naming variables. I come for the old school naming conventions (m_, lpszXXXX). I'd like to see some discussion on naming conventions for Unity and WHY developers choose them. In particular, what naming conventions are good particularly for Unity. For example, exposing oddly named variables (m_) via [SerializeField] to your designer is not a good idea. I see people naming their variables the same as their class names, naming local variables exactly the same as their global variables, variables that differ only by case, and it just doesn't 'feel' right.