If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
Before we had essentially a two way street that does not close constantly sending information back and forth.
In the new structure we make the street a one way street but with the addition of a pulse switch to open and close a gate. pulse off no information, pulse on sends the information and closes the gate after.
I had a bit of trouble getting it and had to watch a couple of times but hopefully understood it correctly and explained okay (if not please correct me!)
2 Likes
So you own a theater and its 1986.
You hire someone to answer the phone to update show times as well a bunch of other important things. However, you find that your employee is ALWAYS answering the phone lines. Giving updates to anyone and everyone. They are so overloaded they can barely get anything else done!
Then one day you have a brilliant idea! Let’s make a recording of our show times and prices, etc. When things change we we just update the recording! We publish this one point of communication for EVERYONE to call ( for showtimes, prices, specials etc) … its great!
ADDITIONALLY - you find out that there is a company that has this new fangled thing ( I am making this up as I go… 
) called a “quick mailing list”. Basically, postcards are sent in the mail to anyone who wants to be notified of your theater changes (er theatre in Ben’s world).
Now our employee updates things ONCE when they happen and has our mailing company notify everyone on our list…and we can have them now free to do the million other things we hired them for! We don’t care who is on the list… whether someone added themselves or dropped off. We do things ONCE in one place and we are done. We are the Subject.
As someone who wants to SEE a movie and get the latest information… I no longer have to wait for several rings for the employee to answer my call ( or even worse, a busy signal )… as a matter of fact I don’t even NEED to check in unless I got a postcard in the mail saying something has changed! It’s brilliant! I am only calling when I know there is new information… wow, fancy. These are the Observers.
Wow that got much wordier than I was imagining at the start…hope it’s close.
5 Likes
Very cool 
I like to think of it like a electronic newsletter (think MailChimp).
When it’s time to send out some news it’ll do it. It doesn’t care how many subscribers there are to the news – be it 2 or 200 – it’s going to send to whoever is interested.
If there’s no new information to report you won’t hear from it and it won’t waste your time.
Performance wise, it seems that this way of doing things will be much less costly - as instead of checking if something has happened each and every frame (inside update), it will instead know when something has happened, only when it has happened - without having to check if it has or not.
A 'Subscriber’
You don’t know that a content creator on Youtube is actually creating content. You’re not checking, going to their channel every X amount of time. If you are, this is energy (processing power) that can be saved, as youtubes ‘subscriptions’ will notify you only if and when a new video by that person comes available.
1 Like
i do believe the best way it can be useful is simply the fact that, we can add as many parts, that require the same thing as we want, without really changing the code.
and also we can remove as many parts that use that delegate, without effecting the code at all, and have it still run peacefully.
and that helps us, actually adding certain functionality, and removing functionality without having to keep revising, changing, and adding on the code of older parts as we progress through. we simply, connect them to the delegate, and forget about the old code we’ve written peacefully.
Using on layer change, this will allow it to only run once when it is actually needed. Right now we are constantly setting even if it does not matter. Also having onLayerChange() gives us a new tool that we may be able to use in the future too, with that in place it will be super simple to implement it in other ways.
Looking ahead, it strikes me that when the player dies there will be a vast number of scripts which need to behave differently - the move controller for one. It would be a real pain for virtually every script to have to call a player function to say ‘am I still alive’ every time it wanted to do something. Instead stick a simple OnPlayerDeath routine at the end of each and let that clean things up.
The Observer pattern is all about Inversion of Control. (IOC)
Before we needed to know more inner working of the class then we really should know. All we really want is a change notification. Before we had to monitor that notification. Now what we will be moving to is a “calling tree”. Where the change will happen and the class will walk through the list and call back to everyone that is subscribing.
Instead of n^n relationship of objects looking for the event when we did it every frame, we will be doing just n calls because we will just notify everyone once instead of them bothering us every time a tick goes by.
My best analogy of delegates is to look at them as a line of dominos.
Each domino an object and the act of knocking it over is a delegate function. When you knock over the first domino, you are broadcasting a message that something happened.
If it’s just the domino by itself (no subscribers); it just falls over and nothing happens.
If there was another domino in the line (a subscriber); then that domino falls (does something; whatever it’s function was).
And like a domino line you can have multiple dominos set to receive that first domino (branching lines/ near simultaneous actions).
The dominos themselves don’t know or care about the next dominos in line and only act if acted upon.
And like the domino line, you could have delegates firing other delegates and have a whole bunch of crazy behaviour. Although that’s probably outside the scope of these lessons.
I learned most of what I know about delegates by attempting to create a modular sound synthesizer system that could be configured in just about anyway you could think of. It worked heavily on delegates and inheritance to create that modularity.
The observer pattern is a bit like… posting to Twitter…
So… you’re on Twitter, and you want to let everybody know what you’re doing, but you don’t really know or care if anybody actually reads your tweets… So… instead of your aunts and uncles calling you up and saying “Hey, what theater are you going to tonight”, you just get on Twitter and go “Checkin out Wonder Woman at #ThatOldBrokenDownTheater with @TrophyWife32”, and then everybody who actually cares knows you went to the movies…
So instead of me asking my car every single km how much gas in the tank is left, my car will be updating this information for me, so I can just look at the gas gauge every time I need to know it and decide if I need to stop by a gas station.
1 Like
Imagine writing a game like city skylines without the pattern
To be honest i’m not really sure but I’ll take a dab at it.
Before we were sending information back and forth and in that case causing performance to lower.
Now we don’t need to information of the CursorAccordance. All we need to do is send information whether it needs to or not. Thus providing information and freeing the CameraRaycaster of unnecessary information back.
In turn this allows for better performance and less bugs.
I guess it is similar to subject in micro controllers: “interrupt” and “interrupt handlers”.
The way I see it this is basically a optimization best practice. If you did not put these observers in place you would constantly be running code that doesn’t necessarily need to be called except for when things change.
In my own project that I am trying to work on little by little in tandum with this course, I think I have done something similar to what is to come in the next video (based solely on this one). I have a couple of functions being called from by update() section. However, one of the functions doesnt need to be called if the other is currently being used. So I set up a boolean that is flipped back and forth between true and false depending on which function should be called.
With the Observer pattern you only do things when they are needed to be done and only than and not every time or never. Also the subject doesn’t need to know who exactly is listening and has not to change the Observer actively.
It’s like having a doorbell.
If you don’t have one ether you have to look always if someone stands in front of the door or you’ll never know and will never open the door, even if someone stands in front of it.
Also with a doorbell, everyone can listen to the ring if they are at home and open the door. It’s not important for the bell user to know who is home. He only needs to wait if the door opens.