We use the delegate in CamRayCaster, but to me it would be neater and safer to have all game events coded into an empty gameObject called Log, or something like that. Then in Log, I add a totally different script for each event. Does this make sense? Or was there a special reason to use the camera raycasting script?
Let’s say you have 1000 events across your entire application. For neatness/safety (?) you put them all into one script. You now have the ability to look in just one location when you need to modify your code in order to make changes.
You add your script to a GameObject in your first scene. We’ll assume this is a main menu. The only event in this scene is a button click event.
We have just loaded in 999 unnnecessary events and bloated a GameObject in one scene for little to no benefit, other than, one day, you can make a modification to a piece of code and find it easily. 
I would suggest placing your events on the objects which are going to be raising them.
If I had a clock object and each hour, on the hour, I wanted to send a chime message, it makes sense that this comes from the clock.
If I had a counter that was awaiting a specific threshold before sending an alert message, it makes sense that comes from the counter.
My clock doesn’t really care who or what receives the chime message, it just sends it. My counter is oblivious to the receiver(s) if it’s message, it just has a job to do, keep counting and send a message when you hit the threshold.
1 Like
That helps a bit but I’m still a little confused, maybe just because I haven’t built a large game yet so haven’t seen how it should fit together neatly. But my idea was that in Log, we have all event-scripts (public Classes of course) that I would have disabled by default, and then we enable those components whenever we want to trigger an event?
My problem might be in understanding what “event” means in the context of an application or C# script, because I’m struggling to disinguish my intuitive idea of event [anything that happens, or a representation of present information that is publically available] from the computer game semantics of it.
My idea so far has been that: each event, if enabled, would run in Update (or FixedUpdate or LateUpdate) but start with a very cheap if (bool) statement, to see if the code needs to be run at all. Since simple conditions such as comparing two integers, or testing whether some gameObject exists, is very cheap, it it harmless to run the code in each and every frame.
But I’ll try and carefully go-over the lectures again and reread your helpful answer! Thanks.
Hi Gregory,
You’re welcome.
But my idea was that in Log, we have all event-scripts (public Classes of course) that I would have disabled by default, and then we enable those components whenever we want to trigger an event?
I’m assuming Log is a GameObject as you mention about adding components to it and then enable/disabling them. What does Log actually represent? For example;
public class Unicorn : MonoBehaviour
{
public void FireRainbowFromHorn()
{
// ... magic happens here
}
}
If you popped the above onto a GameObject and named the GameObject Unicorn, I would know exactly what it was supposed to be representing. What does Log represent in your example? What are the components you are enabling/disabling in this scenario? Using the above, would they be whether my Unicorn was able to fire another rainbow until a certain re-charge time had occured? Or something else?
and then we enable those components whenever we want to trigger an event?
Wouldn’t you be needing an event to have occured in order to know which component to enable/disable though?
If we think of an event as something has happened, one of the easiest scenarios is a button with its click event. A GameObject in a scene with the button component will be able to have this type of event. When a player clicks on the button, the button can announce “my click event has been triggered”. It may even send some event arguments with it, perhaps the thing which triggered the click event, perhaps the exact point where the click occurred etc.
Taking the clock analogy I gave originally, you might consider the number of chimes the clock performs event arguments. The clock chiming on the hour is the event, it saying “hey, its a new hour”. Some things might care about this, some things might not, but some things might say “ok that’s great, but I need to know which hour it is”… the number of chimes the clock announces could be the event arguments which this thing can then say “ah, its four o’clock”.
Every comparison will have a cost. Sometimes you need to also consider looking at a scenario from the other way around. For example;
Instead of checking every single frame to see if a GameObject exists, why not have a GameObject report that it exists and then have it report when it no longer exists, “I’m alive now”, “I’m dead now”. Now all of those checks you were performing every single frame are no longer needed. Those “I’m alive” and “I’m dead” reports would be perhaps its events.
See also;