I knew that is a way to do it, but as you know it is all tightly coupled. The shop item HAS to know about the shopmanager, the shopmanager HAS to know about shopitems. Tight coupling usually leads to breaking during refactoring, and often limits functionality later on. I’m not just interested in getting it work, i’m interested in getting it to work WELL. Also, I’m not just interested in solving this one problem, I am looking for a pattern/model to use for solving similar problems throughout my game. A generic event system seems to fit the bill.
Maybe I need to explain my situation better.
ShopItem, as the peon of the group, only knows about itself. It knows when it has been clicked. It can holler about it to anyone who is listening.
ShopList is a reusable generic scrollable control. It is a container for shopItems. It cares to listen if a shopitem is selected or unselected so it can tell other shopitems to deselect themselves.
BuyButton doesn’t care about lists or items, but it does care if something is selected (enable) or unselected (disable). It would like to listen to yells from Shop Item.
According to my implementation of Chapter 6’s example this morning it seems to me that the publishing object (ShopItem) has to maintain it’s own list of subscribers (ShopList, BuyButton) to tell them an event occurred. ExecuteEvents.Execute() requires a gameobject target. If I have to maintain a list of gameobject targets for the event, this is the least useful event system I have ever had the pleasure of programming with. Every other one I’ve used is decoupled.
I fully accept an answer “Ya, it’s not really designed for that.” Trouble is I don’t know what I don’t know, so maybe it is the right solution if I just persevere with it or had some missing piece of info.
I wrote to ask you because:
- You seem like a nice guy
- You make some good Hitchikers references
- You know more about the event system than I