Events vs er, 'normal methods'

[AJMeyer]

Thanks Sam - this is great stuff. I wish I’d seen this before using Events in some work of my own, and making a bit of a dog’s dinner of it.
I’m rather fond of the observer pattern. And my (highly limited!) understanding is that it sits ‘under the hood’ of quite a few unity methods, particular in input and UI - OnClick, animator Hit(), etc.

As a huge newb, a lot of what I ask about is trying to build a framework of what to do, when. in this case, using Events vs what, in my not-a-computer-scientist language I call ‘normal methods.’ Where I guess I’ve arrived is that Events make a lot of sense any time the class needs to react to something happening in another class, including accessing information passed as a parameter. Events make little sense within a class, when it’s just doing a thing - e.g., Fighter’s CheckDistanceAndMove() method.
At least some of our work could be done as Events. Die(), for example. This is just one of those matters of coding preference, rather than a right/wrong answer?

[Brian_Trotter]

The methods that events latch on to are really just normal methods. For example: The method Hit() is called by an Animation Event. You can call it from any other method within the Fighter script. It happens that when the Animator encounters an Animation, Unity searches every component on the GameObject with the Animator for a method with the same name, and if it exists, it executes that method.

Similarly, an an event or UnityEvent, the methods added to the event are just normal methods. The event just goes through it’s list of methods to call and executes them.

Some method names are defined as Unity Callbacks. These are methods like Awake(), Start(), Update(), OnEnable(), OnDisable(), etc. Unity looks for these methods in a component at the appropriate times and calls them if they exist.

In terms of communication between systems, a lot depends on the dependencies you’ve set up… For example: PlayerController’s Update() checks for input and makes decisions about what components to call methods on. Clicking on an enemy calls Fighter’s Attack() method, for instance. This is a dependent relationship (PlayerController depends on Fighter and Mover), so PlayerController can simply call Fighter’s Attack directly.
Now consider a UI that shows the player’s Health. We have the UI set up now to check the player’s Health every frame in Update. That’s technically ok (the UI depends on Health), but we really only want it to react when the player’s health changes. What we don’t want, however, is for Health to depend on the UI… you’d be locked in to having a UI in the first place, and the same Health component is also used for the enemies as well… that’s where the event kicks in. The UI can subscribe to an event in the Health component, and the Health component calls that method the UI supplies every time the health changes. Instead of updating the UI in the UI’s Update() method, it uses the new method…