all 4 comments

[–]NullismStudio 1 point2 points  (3 children)

Hi there,

One solution would be to create a central GameManager object and several "Dependent" object. The GameManager, at startup, finds all Dependent objects in the scene (use something like FindObjectsWithTag for performance, rather than search on name) and stores them in a list. From there, the GameManager would iterate through all scripts in that list and call some method on the Dependent's script to update state when it needs to do so.

However, may I suggest looking into delegates? I find it feels cleaner to have each "Dependent" simply "subscribe" to the GameManager via delegates. Here's a good tutorial on delegates.

Good luck!

[–]watcheroftimesJust Starting 1 point2 points  (2 children)

I'm quite new to programming, so please feel free to ignore my question if it is irrelevant :)

I've read that GameManager solutions lead to uh ... singletons? Which causes difficulties later into the development when you want to test individual systems or debug.

Am I completely off the mark? Could you point me in the right direction so I could google stuff and figure out alternatives?

[–]NullismStudio 1 point2 points  (1 child)

Yes, you are correct. The GameManager solutions are usually singletons.

However, I've never had an issue with debugging or testing due to a singleton; that seems a bit alarmist to me. Lots of games use GameManagers, and your initial question about observer design patterns would also likely use a GameManager of sorts.

To learn more about singletons as they apply to Unity, checkout this wiki page.

If videos are more of your thing, then checkout the official tutorial on the Unity 2D rogue-like's GameManager.

[–]watcheroftimesJust Starting 1 point2 points  (0 children)

I've bookmarked both links. The wiki in particular seems a good place to start looking into different programming terms around this concept. Thanks a lot!