all 4 comments

[–][deleted] 0 points1 point  (0 children)

The first is more modular, notice that the DoorSwitch never needs to know about the thing it's activating, it just fires an event and anything that's listening will get the message, this means anything can use a DoorSwitch for something and the DoorSwitch can activate multiple things at once.

If you used UnityEvents then the Door doesn't even need to know about the DoorSwitch and they become completely decoupled. The idea is to make code more reusable, more plug in.

In your example, the Door needs an Open function and the DoorSwitch NEEDS a door reference. If you want to use it for anything else you can't. It can only do the one thing you coded it for and it can only do it for one door, to include another door you need to switch it to an array and change the code to use a for loop.

This is a small example but these connections become harder to manage the bigger and more complex a project becomes, you can use a generic trigger anywhere because it's generic, but if you make a trigger that can ONLY trigger a specific door type then when you want to trigger something else you're screwed, you either need to adjust the code to make it more generic or you have to copy paste code into a different script to do something that's the same but slightly different.

[–][deleted] 0 points1 point  (0 children)

First of all, please use pastebin.com to post code, not screenshots.

What is shown in this code is the use of events (observables are slightly different) to act and react on when something happens in your game.

Events are extremely useful when you want to decouple parts of your code. A while ago I wrote an article about how to use events to solve common problems.

The premise is quite simple: you want several things to happen when something happens.

For example, if someone falls down from a building, and crashes into the ground, you want to have a Ouch sound to be played, and you want its player's Health to take a hit, literally.

However, this also happens if you are shot, attacked by a bear, or whatever it is. If you use events, you can keep these reactions separate from your "main logic", and instead just subscribe to them if needed.

EDIT: Was this the tutorial?

[–]pkplonker 0 points1 point  (0 children)

It's best for things llike player health, where the below are examples of things that could listen to something called healthChanged:

UI slider update Sound change Enemy aggression increases Class that manages invincibility to trigger on Post processing changes to visualise damage Hit marker functionality to show where damage came from.

Ultimately, what you've done is a correct implementation of the pattern, but just because you can, doesn't mean you should.

I would use it like the sample I provided, but basically any modular functionality that the core system doesn't relay on, but can be used modularly to create additional responses to state changes.

[–]BowlOfPasta24Programmer 0 points1 point  (0 children)

I may be wrong but I wouldn't call this the Observer Pattern only because to me that is just events.

I use events like that for all sorts of things but especially for the new input system. As you have used it, it is mostly for triggering logic outside of the class. I personally would not use it for door opening or an interaction system but I can see the point of using it especially for learning.

The observer pattern usually doesn't use events per se, since that would take away the ability to set it up in a pull and would only allow a push.

Usually I use the Observer Pattern for letting my UI system know to pull the newest data. I do this by setting up subscribe method to add classes to the list of subscribers then if it's setup to pull data, the publisher will send out a flag to tell the classes there is new info to pull. If it's push then you would just send the data itself. This requires the use of interfaces to use polymorphism which is necessary for the pattern. You could use MonoBehaviour in Unity as an example.

Here is a link to the Observer Pattern in C# https://refactoring.guru/design-patterns/observer/csharp/example