InventoryManager.cs

[glass phoenix]

I have the InventoryManager.cs script on an empty game object that acts as a handler. Should I remove the component and add the Inventory.cs script to the object?

[urban pagoda]

The new inventory script should be a parent of all your slot prefabs, and each slot should have a slot script. Get that setup and work on your add function here since that's a good start

[glass phoenix]

so for parent of all slots, I just want to double check that I add this script to "content"?

[urban pagoda]

Setting the slot data can be done on the slot or the inventory, but for simplicity I'd just do a lot of the set and unset logic in the Add/Remove methods on the inventory methods themselves.

The inventory script can be anywhere honestly, even a singleton like you had it before, but making it a parent simplifies it a bit as well.

The slots however need some actual scene presence because they are the parts being shown in the scene and if you want to interact with them by clicking, you need to specify the gameobjects.

So, in this case, Inventory or Content would be fine since you'd want to lessen the searching required for GetComponentsInChildren

[glass phoenix]

Okay, (sorry I'm gonna break down these pieces a part so I can keep track of everything I need to do) so I added the Inventory script to the top of the inventory heirarchy and I'm assuming I need to place things in these two empty fields. Just to double check since I can't run and test (my code wont compile rn bc I need to change variable names) that I would drag in "content" and "item" (prefab) into these respective places?

[urban pagoda]

What script is this one

Just post the script into discord if it's not that large

[glass phoenix]

 public class Inventory : MonoBehaviour
{
    private List<ItemSlot> slots = new();

    public List<ItemSlot> Slots
    {
        get { return slots; }
        private set { slots = value; }
    }

    public void Start()
    {
        ItemSlot[] itemSlots = GetComponentsInChildren<ItemSlot>();

        foreach (ItemSlot itemSlot in itemSlots)
        {
            Slots.Add(itemSlot);
        }
    }

    public bool AddItem(Item item)
    {
        for (int i = 0; i < items.Length; i++)
        {
            if (itemSlots[i].item == null)
            {
                itemSlots[i].setNewItem(item);
               // InventoryHandler.Instance.updateInventoryUI();
                return true;
            }
        }
        return false;
    }
} ```

[urban pagoda]

Right, nothing here should be serialized, meaning when you start the game you'd have a blank slate of empty slots

so your program starts and the inventory checks all the gameobjects in the children with a slot script and adds them to the list

[glass phoenix]

so do I leave these fields empty?

[urban pagoda]

I'm not seeing any Item Content or Inventory Item variable declarations

unless they're hiding somewhere lol

[glass phoenix]

they're from the InventoryManager.cs which I got rid of, so idk why they're being pulled here

[urban pagoda]

code probably needs to compile for the editor to update

[glass phoenix]

the code won't compile rn bc of this lol

[urban pagoda]

Well, make sure you've got your slot script created

[glass phoenix]

separate from slotUI correct?

[urban pagoda]

depends on the design, but you can just make a single slot script

for more technical stuff usually you'd split the view UI logic away from the business logic but that's going the extra mile

[glass phoenix]

I'm just a beginner lol I'm just trying to get things to work at this point😭

also I want to thank you so much for taking so much time to help me and being patient with me

[urban pagoda]

Three scripts you should have -> inventory -> slot -> item

[glass phoenix]

I have the Inventory.cs , SlotUI.cs , and an Item.cs

[urban pagoda]

Right, so SlotUI then will be what's displayed and what will contain your item datas

[glass phoenix]

should slotUI inherit from Item.cs? Like "public class SlotUI : Item " instead of monobehavior?

[urban pagoda]

Basically anything that's a mono can be attached to gameobjects as a component in the scene

stuff that does need to be in a scene like I explained above must be slots for the most part

You have a few choices for both inventory and items, but since we want the inventory to be a parent of these slot gameobjects (in the scene hierarchy) then inventory must also inherit monobehavior

items are interesting and are more likely to be plain data which doesn't inherit from monobehavior, and the technical reason for that is that slots display and show what an item is on the UI.

if it doesn't inherit from monobehaviour, then it can't be attached to a gameobject like a component, but you can still insert the references into objects which inherit from monobehavior

[glass phoenix]

ahhh okay

[urban pagoda]

I see people make item data monos a lot and though it's not technically incorrect, it can become problematic the larger an inventory you make as you add an overhead cost to all items.

it depends on the game too. If you're just making some menu based game, then technically you only need your slots to do all the heavy lifting to show the item data.

if it's like a 3D game, you could make item data also inherit from monobehaviors so that this data is always loaded (cached) so there's less instantiating you need to do. Think of a 3D sword item you can put into and take out of your inventory. It has a 3D model only when outside of the inventory, but inside it doesn't render anything.

[glass phoenix]

I'm just making a 2d game where players can grab grocery items from a shelf and it shows in their inventory. I also wanna be able to have them remove it from their inventory but I haven't even been able to get the items to show yet

that's pretty much the main basis of what im making

[urban pagoda]

So in this case your items do have more of a scene presence when outside of the inventory, so somewhere this item data does need to be loaded into a monobehavior to be displayed on the scene.

so if you want to make your items derive from nothing (plain data objects), you'll need to instantiate some sort of monobehavior wrapper to represent the item's data. If you instead choose to derive your item from a mono, then when you insert these items into your inventory, you'll need to disable the visual aspect of the item when not being seen.

and vice versa when you remove these mono items

[glass phoenix]

how would I create this wrapper

[urban pagoda]

public class ItemWrapper : Monobehavior
{
Item itemData;
}

[glass phoenix]

and each item would have this script as a component?

[urban pagoda]

items don't need any references to the wrapper. Basically when you remove it from the inventory you instantiate a wrapper and insert the item you're removing into the wrapper.

Think of it as another type of slot, but in your actual game world now

rather, this wrapper is how the item is represented

sprite, size, location, ect

[glass phoenix]

ahh okay

but if each item has different things (say, price, sprite, location, etc.) how would I represent this

[urban pagoda]

the itemdata (the plain data object) should contain the primary data like the price and sprite

location meaning that coordinates of the gameobject is that of the wrapper

so when you insert the item back into your inventory, you'd discard the location and gameobject of the wrapper as the item data is now in your inventory.

the monobehavior for item idea wouldn't require instantiating any new GOs, but instead activating/deactivating the item's gameobject it's binded on

both ideas are legit, but larger games (think of infinite inventory) will use plain data when possible

[glass phoenix]

I quite like that idea

before I try and do that, can you help me fix my current errors so i can compile and see what everything currently does and how its working rn

[urban pagoda]

What errors?

[urban pagoda]

Well, you still need to make that slot script as the type isn't defined here.

[glass phoenix]

oop, I'm sorry I keep getting confused on what I need to do but I'll make it now

[urban pagoda]

Oh, right you have SlotUI here, so if you're using that one then you need to update all your variables to it

[glass phoenix]

change the variables in both? or just the variables in Inventory.cs to line up with SlotUI?

[urban pagoda]

comment out your RefreshItemIcons() method for now

Your inventory references need to be the correct type of slots

[glass phoenix]

do I reference slotUI?

[urban pagoda]

Your inventory should contain all references of your slots

so it should have a list of them for it to access

you start your game, the inventory wakes up and checks all children for slots to gather and place into its list.

[glass phoenix]

private List<?> slots = new();

[urban pagoda]

Your slot script

[glass phoenix]

Ah, need to make that

[urban pagoda]

Just rename your SlotUI to Slot

all UI events and data are going to be handled by it

[glass phoenix]

Okay, I updagted that and changed the naming. I just need to update this. Would I call any sort of updateUI in here still?

[desert sail]

Maybe invoke an event instead.

[urban pagoda]

If you're going to use a list then you'd use Count method. Either data struct is fine though.

you'll also want to set up a property for your item data inside of your slot script

because you've no way to check if it's null if the variable is completely private (with no getter)

[glass phoenix]

item data?

also it wont take Count method

[urban pagoda]

Oh, you're iterating over your item. You should be iterating over your slots ^^

[glass phoenix]

I foxed that. But I just now realized I don't have a setNewItem method so I might have to leave this empty and come back to it in the morning

[urban pagoda]

Slots[i].item means you'll be trying to access the item on the slot script, but currently you have your item Protected which is also a private variable.

so to solve this you'll need to allow the slot to give access to it, but instead of making it public, you can make a property field and set a constraint such that the inventory can get the variable to check it, but not directly set it.

Well, for simplicity you can make it public, but you may want to create a property regardless in case you want to do some validation when setting the item.

I personally like to just create independent methods for that logic, but c# is nice to allow you to do that all in a property field.

[glass phoenix]

omg I was finally able to compile and test and its working good and smooth now

Unfortunately I have to stop for the night but thank you so much! In the morning I need to keep working on getting the UI to update and show each sprite

[urban pagoda]

public class Slot
{
    public Item Item { get; private set; } //You'd actually uppercase the variable since it's publicly accessable
    
    public void Set(Item newItem)
    {
        //some validation perhaps
        Item = newItem;
    }
}```

that's one variation you can think of

and yeah no problem, you should catch up on some c# tutorials before delving too far into unity if you run into problems.

easy to get lost working in unity if you're rusty on some syntax or other c# methods

[glass phoenix]

this being in the current Slot.cs ? (previously SlotUI)

[urban pagoda]

ye

[glass phoenix]

Unfortunately this project is for a class and I'm too close to the deadline at this point to be able to take my time learning C#. I'm proficient in C and C++ but for some reason the jump to C# is really getting me (tbf I'm first working with it in this realm of unity dev). I plan on doing some C# workshops when I have a break from classes

[urban pagoda]

Oh, that's taking on a lot then lol. Though, c# is a very clean language despite it being focused on OOP.

[glass phoenix]

yeah, I was very scared of scope creep for this project and I was correct lol

Unfortunately my school doesn't offer any classes for Unity or other game engines and no one here knows Unity. So everything is self taught

[urban pagoda]

not so much just a new language but conceptionally game design is a lot to comprehend and doesn't easy mix well with general design patterns

[glass phoenix]

Yeah, I'm learning that the hard way. In my mind I can think very surface level about what needs to happen. But I'm struggling with getting lost as soon as I can the script is in front of me

[urban pagoda]

I feel ya. I kinda just stuck to smaller games like tetris and pacman for some projects. The slot stuff can be a lot lol

[glass phoenix]

This is an educational gaming class so unfortunately I couldn't just do an easy platformer game. But I have one of the less complicated designs out of my classmates and I haven't even finished half this game😭

[urban pagoda]

The UI structure seems fine. You just now need some Add/Remove methods and logic, and update the slots accordingly when accesing them. Stacking items however is a little more complicated if you want to try that.

[glass phoenix]

Thankfully the functionality I want doesn't really need stacking. And I'm trying to beat the clock rn so unfortunately I've started resorting to try and take shortcuts if I can

[urban pagoda]

Yeah goodluck, people always helpful in the coding channels if you need more help ^^

[glass phoenix]

thank you!

I'll probably be back in the morning asking for help getting the Ui to update again

[glass phoenix]

which speaking of, I added this to the script. Am I able to call some sort of UIUpdate here?

or does that have to be its own method

[urban pagoda]

Well, you've only need to update the image after setting the item (assuming you're not using the text), so you can just set the image in the same methods as the item

there's no unity method you need to call for it to redraw the UI. It'll know the image has changed the next frame if you change the reference.

[glass phoenix]

hm, okay. Right now when I click the item the controller prints out the object name but the UI doesn't update

[urban pagoda]

If there was a lot of data you were updating like along with the text then you can make another method which you can reuse. Up to your design.

[urban pagoda]

well, have you changed the image ^^

[glass phoenix]

I'm checking all the scripts right now to see if I call anything that should do that

[urban pagoda]

Setting the item data isn't enough, you need to change some other slot attributes regarding the new item data it has received.

[glass phoenix]

Is this it?

[urban pagoda]

somewhat, but that's the general idea

slot.image = newItem.image

rather, it's sprite so slot.image.sprite? I forget but you should look that up.

[glass phoenix]

is the Green slot the wrong one to be calling here?

[urban pagoda]

is this inside of the slot or the inventory?

[glass phoenix]

slot

[urban pagoda]

if you're doing it in the slot then the reference is itself so there's no need to access it but only use the member variables

[glass phoenix]

no if statement? or no "slot.item =" just the item =?

[urban pagoda]

if you're setting the data in the slot with a new item then the inventory has already made sure it's not null and is correct data

usually when working with manager type scripts you let them do all of the type checking and stuff

[glass phoenix]

did i misunderstand?

[urban pagoda]

Going to bed in a second but make sure the member variables are named correctly, and newItem data must be sent into the method because it is not a member variable.

[glass phoenix]

ah okay, no worries

thank you for all the help today!