Inventory System

Learn Content
,
1

Hi, I’d like to request to take on the Inventory System ticket if it’s still available.

If you’re happy for me to work on it, could you please share with me any additional details about the scope of the feature and how it may potentially expand in the future such as:

  • Can all items be “used”?
  • Would all items require a sprite icon?
  • Are there different types of items that may have additional functions?
  • Will items be collectable in the 3D game environment or will they only act as data that’s represented in the UI?

My github profile is at: pablothedolphin (Jakir (Jak) Hussain) · GitHub

2

Hey there,

I would like to try and make an attempt at the inventory system. I see on the card for it that there’s some basic ideas for items like health potions, crafting ingredients. I’ve got an idea for a scriptable object class that could do this, and I was wondering if there was a more complete list of what item types we might need?

3

I’d love to create the Inventory system. I have lots of experience creating fully-featured ScriptableObject-based inventory systems. I also have lots of time right now so I can get it done fast.

Here’s an example of one I made:
badthankfularabianwildcat

2 Likes
4

Hi! I would like to make the inventory system ( Codecks ).
I have made an inventory system with scriptable objects before, and could alter it to fit into this project! I would need some information about if it implies an equipment system as well, and if so, what kind of items can be equipped and where. I assume it means UI too, but please let me know if it doesn’t.
Hope I can be to help :slight_smile:

5

I’ve made a fork with my rough idea for an inventory system and manager. The main code commit is here. And a couple of changes I forgot to commit the first time are here.

The InventoryItem_SO contains the basic info on the item; an enum representing its type, an int representing a value that should be increased when picked up or consumed, and a GameObject that is the prefab of the item that you are picking up which can be placed again in the world if we are allowing for items to be dropped by the player. We can also add any other fields here, for example Inventory UI Sprites as needed.

The InventoryItem script is pretty barebones, and just contains a reference to the scriptable object which has all the real data.

The InventoryManager is where most of the logic happens. It contains a List of InventoryItem_SO representing the backpack, though this could also be an array if we want to limit the backpack size. Runtime pickup of an item is handled by a trigger collider on the item being picked up, if the item we’re colliding with is tagged “InventoryItem” we add the SO for it to our backpack, and then delete the GameObject from the world. This can be refactored pretty easily if we instead want to use object pooling, and hide the item GameObjects offscreen if we don’t want to instantiate them afresh if we allow for items to be dropped.

The InventoryManager is also where consuming of consumables will be processed. I’ve not added any code for this yet, but it would be a simple matter of adding a ProcessItem function which would check the enum on the SO before adding the relevant value to the health or money, or other system. Such processing could be done immediately on pickup, or delayed until the player selects the item from their inventory to consume.

6

And of course I’m happy to take feedback here or on GitHub if anyone has any questions about why I made these choices, or if you think they may cause issues in the future :slight_smile:

7

Hey,

I noticed that you are using enum in your SO to identify an item type. I want to say that you can identify the item by SO itself.
So in the future you can create a new SO if you will need a new item type without extending enum.

If you are worry about identifying it in the code later, you can create Heal, Money… classes inherited from abstract Item class and add ItemPrefab property to the SO.

Hope it helps you and helps your code get in the project!

8

Hello,
I would like to start working on simple inventory system. I was thinking it could be build in phases, and my focus would be to make it easy to build upon. I have some experience with Unity, but actually it would be my first inventory system :wink:

I have a question though, couldn’t find it mentioned anywhere:
Have you already planned how items will drop and the way the character will be picking them up?
From concept art and the general art style, in my opinion items should drop directly on the ground (Zelda: BotW style) and picked one by one via keybind action.
Hmm now that I think about it, it might be too early to ask this, and it’s not really a necessary information to create this system.

9

Hahaha dang, i was just about to sign up for it. Already begun building one… Anyways, I’ll just pick something else.

10

I would like you give me some directives about the parameters of the scriptableobject,
otherwise I will write the scriptable object in a reasonable and exstensible way, I hope :slight_smile:

I will even implement it a few different ways, so you can choose the better one for you, or switch them during the development without effort

11

There are few other threads already and they haven’t picked anyone yet, so you might as well post your thread too, I think.
On the other hand they might as well have a look at few different implementations I guess :wink:

12

So the reason I wanted an explicit enum in the SO is so that all the information for an inventory item is in one place; the SO. This makes it simpler for the inventory manager to manage the whole inventory, as it can be represented as a List of type InventoryItem_SO. And because instances of a SO are assets, this also allows you to easily create multiple items of the same type, but with different properties; for example a small, medium, and large heal potion that heals 10, 50, and 100 hit points.

If I’m understanding your suggestion correctly, this would complicate inventory management, as instead of extending the enum in the InventoryItem_SO.cs file, you’d be creating entirely new _SO.cs files for each item type; HealItem_SO.cs, CraftingItem_SO.cs, etc. Then when it comes to inventory management, instead of maintaining a single list, you’ll have separate lists for each SO type. And every time you want to add a new item type, you’ll need to add more code to your inventory manager to handle it.

One problem with adding separate heal or money classes on the item GameObject is that, if at pickup you destroy the item from the world space, you will also delete everything attached to it. You can work around this by having a physical inventory storage area someplace else in the scene that the player can never see, however that comes with its own tradeoffs for memory usage and active objects in a scene.

If I misunderstood your suggestion, please let me know :slight_smile:

13

I know there are already 5 other topics asking to do inventory system, but this is different. I want to look at all the options for what kind of inventory systems that could be implemented and push forward my suggestions.

Constraints or goals:
What do we want our inventory system to do?
1) For specific items.
if we only have a few milestone items that need to be collected a limited sidebar inventory would suffice or a pre-listed collection inventory with ghost outlines to show how far a player has progressed though the game.
Technically speaking a milestone inventory dose not count as a standard inventory, the items cant be consumed or interacted with in any way other than viewing it. An example would be other story games where you are given a quest item thats not actually in your inventory.

a simplistic limited slot inventory is also an option, it would have <8 slots to carry quest items or other kind of items and they would not stack, this would save work and effort for it.

2) for mass items.
this would involve stacking items and many different items types with many different uses. The items can be used up in different ways and there may equipment items too.

both are viable options, 1 for milestone item collection or unlocking item collection and 1 for normal inventory described hence forth.

clarifications?
Looking at the cards in the roadmap there seems to be an energy feature, i am unsure if it applies to the player but it seems the characters can pickup something that recovers energy for them in all ways it appears to be an HP system it has no mention that attacking loses energy for them. The something that can be picked up is called an item.
Would other characters also be required to have an inventory?
would it be the same as the player or less detailed and simplistic, would the player be able to view the enemies inventory and loot them?

What items should be included in the game?
currently the only mechanic i know about from the cards is the energy mechanic. The way forward for the inventory system would describe how it interacts with energy.
Will the player consume an item to recover energy?
to prevent infinite lifespan eating, would energy items be limited in anyway such as preventing the player from quickly eating in battle to cheat death?
What would the stack size for certain items be?
what will the energy pickup (items) be and what will they look like?

and most importantly what other items are needed in the game and what will they be and what will they look like, this also includes items for other mechanics.

while the main inventory system is code based, The items, pickups, milestones and anything else will need 2D icons as well as the main inventory layout and backbone. The 3D world items will also need to be created and these can be assigned alongside this after its been decided whats being included in the game or what the inventory system will be like.

if there are other ways to do inventory systems or styles, needs, limitations and more please do say.
i dont know what kind of inventory system this game needs because the cards dont describe many mechanics.

2 Likes
14

I don’t mind if it gets tossed, it was fun to play around with, I had never built one before. I have a demo scene: Scenes/InventoryDemo

https://github.com/UnityTechnologies/open-project-1/pull/20

Let me know what y’all think.

15

Bumping my request

16

Not certainly in that way. I mean you can create extra SO per item (not .cs, exactly SO).

And then you have the “gameWorldRuntimePrefab” variable in your SO. Instead of GameObject type you can use your InventoryItem.cs:

/// <summary>
/// A reference to the prefab that can be spawned in the world if the player drops the item.
/// </summary>
public InventoryItem gameWorldRuntimePrefab;

And then you can inherit Health.cs from InventoryItem.cs and do Health’s logic there.

But basically it would be better to separate Pickup and Item logic.

1 Like
17

So I was looking at the codedeck page and saw that the Inventory system is unassigned. I’m thinking something with a with a pickable script with an overridable use/throw/etc functions kinda like in Deus Ex PC.

I’ll use some placeholder art, mostly squares lol

I think keeping inventory like in Deus Ex might be fun, a grid and you can place objects based on its size. Adds a bit of complexity to the game!

Let me know if it gets assigned to me so that I can get started!

1 Like
18

This is the official thread to discuss the Inventory System (roadmap card).

Please start with simple implementations that generally stick to what the card on the roadmap is saying. There will be time to expand the functionality.

1 Like
19

Thanks for the merge!

1 Like
20

I canceled my PR (it was a fun diversion and I was hoping to spark some conversation but I’m definitely not interested in co-opting everyone else’s fun) and prefer to discuss the design here, now that there is a single thread and not just a bunch of disparate threads.

This task seems relatively light on detail. In order to meet the requirements, I think we only need the following components:

  • A ScriptableObject that represents a type of item. This should have the bare minimum on it for now, in order to prevent expanding the scope for no reason.
  • A MonoBehaviour that represents a pickup in the world. This should have a reference to the item type.
  • A MonoBehaviour that allows a character to interact with a pickup. For now, it could just have an OnTriggerEnter.
  • A MonoBehaviour that represents the character’s current inventory. To be as simple as possible, it could just be a dictionary of item and the carried quantity.

There is a lot of talk about UI design and whatnot here. I believe these topics are outside of the scope.

I know there are a lot of parties interested. I think it would be valuable for us to agree on a design ahead of time here that doesn’t exceed the scope (remember, to meet the requirements of the card, we only need: item scriptable object, the ability to pick up an item, the ability for a character to remember what items they picked up.)

Now, before I keep rambling, I’d like to leave the floor open for people to discuss whether or not they think these 4 components meet the requirements of the ticket (without blowing up the scope of the story.) If so, we can discuss naming convention, and pseudo-code them out. Once this is done, someone can just throw it into a repo and add a comment crediting the forum members discussing it here (if desired.)

Thoughts?

2 Likes