Simon (darkside) Jackson
I’ve not forgotten you, just been pulled this way and the other. Desperately trying to put a sample together for you, but this is what is in my head.
There is no truly disconnected way (yet) with the event system to raise alerts and have them captured by components listening for them. It would cause too much of a performance hit with each component searching for events.
So the only solution right now is to have a single manager who manages events and can notify subscribers. I did something similar with the Conversation manager singleton in book one, the premise simply is:
- Have a Singleton manager registered in the scene (either adding it’self on first call or placed)
- The manager would be the target by any class wanting to “raise” an event (The Game object in the EventSystem.Execute(<manager>, etc
- Items wishing to be notified of a certain event would subscribe to the manager on Awake, being populated in to a subscriber list
- When an event occurs, the manager walks through the subscriber list and notifies everyone.
With the event system, you can build your own interface and event type so as not to interfere with other Unity events, further specialising (or generalising depending on your needs and data)
This loosely couple system wouldn’t have the same drawbacks as the tightly coupled Group -> Item linkage I described earlier and allows ANY object to subscribe for “Selected Inventory item” events
(also make sure there is an unsubscribe option as well :D)
How does that sound?
Simon (Darkside) Jackson