I started this course a little over a year ago and stopped because of the new improvements in Unreal engine 4; but as far as courses go if you want to learn to use unreal engine you basically need to use blue prints(no thanks) or use C++ along with blue prints(massive learning curve); And the more I worked with unreal the more I missed Unity(mainly C#) so I have come back(for the time being) even with its controversy. long story short, I forgot most of the stuff I have learned in this course so I had to start over; even so it is so much easier to pick up than using blueprints and c++; anyways I found a way to bypass the need to use events and the UnitSelectedVisual script and made the code easier to read by using the following code but I am not sure how it will effect the code further down the road:(Note: first uncheck the MeshRenderer component of the UnitSelectedVisual.)
I feel you. (I actually like Unity Engine, but it’s a bit of a Resource Hog on my computer)
While this method will work for now, you’ll still need to use an event later in the course to handle updating the UI visuals. Additionally, if you change the way you indicate the selected Unit, you’ll need to make these changes here in the script as well. By isolating the display logic from the selection logic, UnitActionSystem doesn’t have to worry about how to show the selected unit, it just says “hey, the selected unit changed”.
In general, this Observer pattern is the preferred way of coding these sorts of things (and you’ll find Hugo is going to use a LOT of events). They help keep code loosely coupled, and in general far easier to maintain.
Thanks for your reply and yes for the most part I agree with what you said because if you have the broadcaster sending out a message received by multiple receivers (that may preform different tasks) it would be a nightmare to manage every single event; the broadcaster shouldn’t need to control the action of each thing it broadcast too (where each object could possibly have a completely different action) and even worse what if multiple receivers receive the same message at the exact same time the broadcaster would have to loop thought each object and handle each action individually.
But, unless the code changes drastically, for this situation I don’t think it is an issue. Because at any given point time we “only” deal with the previous object and then the next target object, and we do the exact same thing every single time: we turn off the previous mesh and turn on the new one. I know he is introducing events as a learning aid, but for the most part I understand C# so, for me, using an event for this situation just makes understanding (remembering) what is going on a lot harder.
As I said, it will work for this situation.
Oh, if the main point you were trying to make was that it will work in this situation, then I agree. I was just trying explaining why I thought it was harder and unnecessary to use an event in this situation.
I still prefer events as best practice, and as the course continues, we’ll be subscribing to this event from other places. That’s the tricky part of tutorials/courses. We don’t always know the whole story when something is being set up. Were I the instructor, I might have said “Ok, so we’re going to set up this event, which for right now we’re only handling this one thing, but as we go along…” outright in the lecture.
Some of these sorts of issues (when to use an event, engineer early vs. refactoring later, are Singletons really liars [Just for fun go into your Google Search bar and type "Singletons are " and see how high up the list of suggestions “Singletons are Pathological Liars” is], and many more) have been debated since time immemorial (or at least since the dawn of the computing age). There are not always “right” answers, only practicalities and cautions.
Yeah, that makes sense.
.