Architectural Advice / Feedback for multiuse UI Components

[sasuchi]

Hi guys,

I need an architectural advice / help with the implementation of “reuseable” / “multiuse” UI Components. First of what do I mean with reuseable / multiuse:
I want UI components to be useable in several places/ui compositions. For example the player inventory, which is shown at the equipment screen or at a npc shop screen. Obviously, when the player transfers an item from his inventory different behaviour is needed, in the equipment screen we want to equip the transfered item (Player->Equip(item)) and in the shop we want to sell the item (Player->SellItem(NPC,item)).

My current Implementation looks like this:

Per UIComponent a seperate script (e.g. UIPlayerInventory, UICharacterEquipment, UIReadiedItem) with neccessary references (to the player/equipment/etc). Furthermore, Components that contain items/have slots implement the interface IItemSlotHolder.

Abstract class UIItemSlot that extends explicit ItemSlot Classes (UIInventoryItemSlot, UIEquipmentItemSlot, UIReadiedItemSlot). Those concrete Implementations are attached to corresponding prefabs. The ItemSlot has a reference to its parent ui component as a IItemSlotHolder.

A class for an Item (ItemStack), also attached to a prefab. OnEnabling/Moving the item prefab, it saves a reference to its parent slot as a GameObject.

Now for the interaction between those components, i made the item drag’n’droppable, meaning the class UIItemStack implements the interfaces IPointerDownHandler, IDragHandler, IBeginDragHandler, IEndDragHandler and the UIItemSlot implements the interface OnDropHandler with virtual (probably could/should be abstract) OnDrop implementation, where the extended classes (UIInventoryItemSlot/…) have their specific OnDrop implementation (e.g. Player->Equip(itemRecieved), Player->Unequip(itemReceived)).

Now the (rising) problem I see with this implementation:
There is a sender, the one where the ItemStack is dragged from, and a receiver, where the ItemStack is dropped on a ItemSlot.
The receiver knows explicitly what his UIComponent is, e.g. UIInventoryItemSlot’s UIComponent is the UIPlayerInventory. And the receiver can also get the type of the senders UIComponent (the eventData holds the ItemStack, which has a reference to its originating slot//concrete class for UIItemSlot, which has a reference to the parent IItemSlotHolder), however how would I implement different behaviour based on the senders type.

Of course i could go the route of if/switch statements based on the senders type, but having watched the jason weimann videos about the solid principle multiple times, i understood this could cause poor maintainability. For each new Composition where a UI is needed, i need to add a new branch to that statement.

A different solution i thought of was to have a seperate class, as a kind of processor, that determines the correct behaviour… this would prevent the need to edit every existing ui component if a new one is created. however its not truly prevented but rather shifted to a seperate class…so this seems to be a suboptimal solution aswell…

Any advices on archtecture are appreciated…
I hope I could explain my problem clearly, as I am not a native speaker, if there are any questions or need of concrete code let me know.

Thanks everyone in advance.

[GroZZleR]

I don’t think you’ve created anything generic or multi-use at all, if I’m being honest. Every element on your UI is highly specialized and specific to the system using it. I personally don’t like the idea of the UI having so much knowledge of what it’s representing and how to handle it.

I would only have your UIItemSlot and that’s it. Every time an item is placed in a slot, broadcast an event. Every time an item is removed from the slot, broadcast an event. Put a layer between that, like InventoryWindow, which re-broadcasts the event for every item slot it’s managing. Then your actual game systems only need to worry about listening for specific events from specific windows.

[sasuchi]

Hi GroZZleR,

thanks for the input.

@GroZZleR

I don’t think you’ve created anything generic or multi-use at all, if I’m being honest. Every element on your UI is highly specialized and specific to the system using it. I personally don’t like the idea of the UI having so much knowledge of what it’s representing and how to handle it.

I agree, i dont want the UI to have knowledge about what it should represents, it should only trigger the corresponding action caused by the usage. In that regard my system is probably as you mentioned poorly designed.

@GroZZleR

I would only have your UIItemSlot and that’s it. Every time an item is placed in a slot, broadcast an event. Every time an item is removed from the slot, broadcast an event. Put a layer between that, like InventoryWindow, which re-broadcasts the event for every item slot it’s managing. Then your actual game systems only need to worry about listening for specific events from specific windows.

I am not sure if I fully understood you suggestion here, so ill try to rephrase it and point out my uncertainty.
-The Item fires an Event when it gets dragged (something like RemoveItemFromSlotX)
-The ItemSlot fires an Event when something gets dropped on (something like AddItemToSlotY)
-InventoryWindow is class, which represents a window like PlayerInventory/Equipment, that manages an array of ItemSlots and listens to the events (RemoveItemFromSlotX/AddItemToSlotY). The underlying system, listens to forwarded events from the InventoryWindow and does processes the logic behind.
E.g.

1. I begin dragging an Item from an ItemSlot in the InventoryWindow (PlayerInventory) → ItemSlot in InventoryWindow (PlayerInventory) fires the event RemoveItemFromSlot(x) → InventoryWindow (PlayerInventory) fires the event that the underlying gamelogic process removing the item from the slot x.
2. I drop the dragged item on an ItemSlot in the InventoryWindow (Equipment) → ItemSlot in InventoryWindow (Equipment) fires the event AddItemToSlot(y) → InventoryWindow (Equipment) fires the event that the underlying gamelogic process adding the item to the slot y.

As mentioned before, i probably did not fully understand your suggestion, however if my rephrasing is correct, how could i ensure process safety ? The process of removing an item from inventory A is decoupled from adding it to inventory B.
As an example what if the player trys to unequip an item into an full inventory, on the equipment side removing is no problem, on the player inventory side now i face the problem i dont know the origin. Or would i pass the origin of the transaction within the event, that i could reverse the process?

sorry im a bit lost

[GroZZleR]

Sure, you’ve mostly got it. I’ll demonstrate with regular C# events but you can also use UnityEvents and then rig things up in the inspector.

class UI_ItemSlot : MonoBehaviour, all the callback events
{
   // call these events when an item is dragged in or out of the slots successfully
   // you already have that logic with dragging and I don't know it off-hand
   // you invoke events like functions: itemAdded(item);
   public event Action<Item> itemAdded;
   public event Action<Item> itemRemoved;
}

class UI_EquipmentWindow : MonoBehaviour
{
   // create all your slots
   UI_ItemSlot headSlot;
   UI_ItemSlot leftHandSlot;
   // etc etc

   // now define the rebroadcast messages
   public event Action<Item> helmetEquipped;
   public Event Action<Item> helmetUnequipped;
   // etc etc

   void Start()
   {
       headSlot.itemAdded += OnHelmetEquipped;
       headSlot.itemRemoved += OnHelmetUnequipped;
   }

   void OnHelmetEquipped(Item item)
   {
       if(helmetEquipped != null)
           helmetEquipped(item);
   }

   void OnHelmetUnequipped(Item item)
   {
       if(helmetUnequipped != null)
           helmetUnequipped(item);
   }
}

// I don't know the specifics of this part of your game, you may not want to register
// directly to the UI events in the Player itself, but you get the idea
class Player : MonoBehaviour
{
   void Start()
   {
       UI_EquipmentWindow equipmentWindow = // find it
       equipmentWindow.helmetEquipped += OnHelmetEquipped;
       equipmentWindow.helmetUnequipped += OnHelmetUnequipped;
   }

   void OnHelmetEquipped(Item item)
   {
       // gain stats
       // change visuals
   }

   void OnHelmetUnequipped(Item item)
   {
       // lose stats
       // change visuals
   }   
}

UnityEvent docs if you want to use them instead: Unity - Scripting API: UnityEvent