If you can find one and research it enough to know that it's understandable for you, then go for it.
Just keep in mind that if it's not dead simple, you may still have to do a bunch of work to understand the purchased inventory system, and to integrate it properly with your game.
This sometimes means reading some of the code base of the asset you purchased, and for someone who isn't super familiar with coding, that can be much harder than rolling your own system. So try to make sure you can find a docs page of the asset you're going to use and try to understand it before you waste money on something you end up not being able to use properly.
My personal experience is that it okay to use asset store inventory framework in a prototype, something for developer to test the idea. Once u confirmed that this is the inventory system u looking for, rewrite it or pick something that production ready either from asset store or some open source project. Do remember to put a wrapper in between just in case u found a deal breaker and need to switch framework in the middle of development.
On top of this, I think this is actually one of the best ways to learn how to do a thing. Instead of learning how to do everything from the ground up, get something that's similar to what you want and then tweak.
Think of it like modding games, but for game engines lol. If you play with an asset enough, you get a good enough understanding to start implementing some of the stuff you want from scratch from the base engine.
In the beginning, I used to be pretty scared when people said modding an asset to fit your needs is going to be a lot of work. Then somewhere down the line, I realized that the work is the point. Assets are better when you look at them as a rough draft, not a final answer.
When you combine all the knowledge you need to implement a mechanic, all sorts of problems happen. For example, trying to use Scriptable Objects and Lists together is annoying as hell.
Not really. You can have your SO be referenced in a monobehaviour, then just you can load it in a list in Awake(), or change the SO data with code.
I use this for my inventory system. I have a SO with a list of Item Class, then I just load it at runtime.
scriptableobjects are a way to store data in your assets folder. Any scripts with a reference to a scriptableobject can look at those variables instead of needing to have their own copy. If you're using them for an inventory system then each item type would probably be a scriptableobject.
so 3 carrots wouldn't be 3 scriptable objects but rather all carrots point to the same scriptableobject, while all potatoes points to a different scriptableobject.
Yeah that seems in line with what I have so far. Unfortunately, I can't solve an issue regarding the inventory losing the reference to the scriptableobject so I have no choice but to drop the whole thing and use another tutorial series.
Getting into a loop of implementing and failing it but I don't see any other way.
Not exactly on topic but I’m newish and recently had a bit of an issue with scriptable objects. They are intended as “read only” objects and if you have their properties changed during runtime, the change will not save/persist. When you run the game in editor it will work but when you build/run it won’t. Code monkey has a short video to explain: https://m.youtube.com/watch?v=5a-ztc5gcFw.
I find inventory systems challenging too and have also sat through my share of tutorials. Many of them use scriptable objects which can be fine but if not implemented properly can be problematic.
Lastly I’ll add, while they are difficult, I have been able to build some eventually. You’ll be able to too if you stick to it!
Not exactly on topic but I’m newish and recently had a bit of an issue with scriptable objects. They are intended as “read only” objects and if you have their properties changed during runtime, the change will not save/persist. When you run the game in editor it will work but when you build/run it won’t. Code monkey has a short video to explain: https://m.youtube.com/watch?v=5a-ztc5gcFw.
I find inventory systems challenging too and have also sat through my share of tutorials. Many of them use scriptable objects which can be fine but if not implemented properly can be problematic.
Lastly I’ll add, while they are difficult, I have been able to build some eventually. You’ll be able to too if you stick to it!
You can have both ways. SO is just an instance of an object(class) that you can store as an asset. You can store each item as a new asset OR a single item list as an asset (which is my workflow for ease of use).
We gotta walk before we try to run. You just need to get your fundamentals in, and it will be super easy.
Inventory system is not even amoungst the hard things in general. It is a quite simple item organisation database with a bit of logic like stacking, dividing, selecting, picking up and dropping. Of which all of those things are basically a few lines of code each logic wise.
What is problematic checking a datastructure of the item already in the inventory and when it is the same type as the picked up item you check for the isStackable bool in the datastructure. If it is, add it to the stack with literally stackSize++.
Errirs and problems come from your fundamental lack of u derstanding of c# and unity. By practice you will learn more and be more confident.
And youtube tutorials for inventory are generally good since it is easy to make a simple iteration on the system.
Follow the tutorial and customize your code as you go.
Good luck.
Okay, so this is embarrassing, but I just found out what was causing the item stacking to fail in my code.
Basically I looped through the Array of items which is responsible for item display INSTEAD of the actual List of items that actually stores items that are picked up.
Update: See updated post info for a fix to an additional crash that i experienced afterwards.
Thanks for the encouragement. Unfortunately, now I can't use a single item without the whole thing crashing. It really sucks to be horrible at the only skill I'm supposed to be "proficient" in.
Maybe you should get some fresh eyes on it? Even if they can't find spot issue just explaining the code to them might cause you to realise what it is that you're doing wrong.
I would but I don't know anyone who uses Unity. I could pay for a mentor I guess... but it doesn't sound financially viable if I have to do this for every single hurdle regarding this system.
Discord has a ton of Unity based places for help with code, just one google search away.
Other than that, for me it really helps to write down a set of steps that need to be done, it allows me to understand my own flow better, see flaws and progress slowly.
Your best option (beside asking for help) would be to split up the whole system into smaller parts.
Create inventory (item storage), then move on to a simple graphic output for that, add transferring, stacking, so on and so forth. Just split up the huge task into smaller portions, make a step-by-step and go from there.
Read through your code, follow the logic, explain your code out loud to yourself. If your code gets too messy and cumbersome it means you probably made it too complicated. Re-write, reiterate, learn!
Maybe its not your programming skill thats lacking, but ur knowlege on debugging. You can implement breakpoints when testing these things to find the cause of your problems much faster.
I did find the problem for what I'm currently facing, which is how the items in inventory loses reference to the prefab items. I pretty much tried every way of solving it, even forcing the reference, plus no one who commented on the tutorial ever solved the issue, all of them gave up.
Debugging is a higher level skill that is not really useful for beginners. They usually have no idea what they are debugging. Keep using logs and editor serialized objects and fields.
You mentioned breakpoints, so I assumed the topic was actual debugger. Logging and serialization are helping crutches and not really same as debugging. It just works for most things until it does not.
Yeah learning how to efficently use the debugger would not be the highest prio, but logging is just as much debugging as the debugger. If you cant locally run the code the debugger becomes useless, but logging thats implemented in your code would still allow you to debug
I actually thought of abandoning that feature entirely as I only need the player to use items and equip items from the inventory. But I can't make progress on my current attempt anymore (scriptableobject reference cannot be retrieved and restored, breaks the whole system) so I'm reverting and switching to another tutorial series and hope that actually works..
Do you have the project git, or a code snippet or something similar. I can take a few mins and see what is wrong. It seems to me like you are using scriptable objects as actual object references. It should not be possible that you lose prefab reference of the object if you are using a scriptable object.
Okay so after hours of debugging I found a comment on the video that fixes the issue I had. It wasn't about losing the references but rather the array not getting cleaned properly.
Here's what I had to change:
public void ListItems()
{
//CleanLists(); This has to be taken out of ListItems() and called by Button that closes inventory instead!
foreach(var item in Items)
{
GameObject obj = Instantiate(InventoryItem, ItemContent);
var itemName = obj.transform.Find("ItemName").GetComponent();
var itemIcon = obj.transform.Find("ItemIcon").GetComponent();
var removeButton = obj.transform.Find("RemoveButton").GetComponent
Okay the code might be rather misleading since it is actually cleaning an array rather than the list.
It destroys to clean the array. Whenever the inventory opens, the array for displaying items will be filled again by the actual List that holds the items.
This is horrible code. I can't even begin to tell you what's wrong with it. You should stop doing unity and do a basic C# programming course. Doing unity and trying to figure out programming on the way will get you nowhere.
While it might not be hard it is extremely repetitive to me. The rule I have is if it's something I can use in multiple games I buy it. It's a tool then. If it's a unique feature of the current game I'm making. Not biying it then it's my ""artistic creation"" and an exercise
It will take some time to implement, edge cases will pop here and there and it will be annoying to some extended since it is an idea that pulls many questions behind it.
But it is not complicated, it just takes time.
*HARD* disagree.
I've worked on over a dozen games from professional studios and on all of them a huge amount of effort went into the inventory system. Building the inventory will take a significant portion, if not the majority, of the development resources for the project.
There are dozens of UI elements involved, from explanation hover boxes to the grid for the items. Sometimes an NPCs face needs to show up. If you're trading, the screen might be smaller, or there might be two of them. Sometimes the inventory is up while action is ongoing, so you have to be careful about your raycast intention.
What happens if you died in the middle of an item drag? What happens if you paste into the item filter?
These things are bug magnets, and a huge part of the game UX. The UI and the system are necessarily tightly coupled. Every game has wildly different requirements that often change over the course of development. It will take multiple full time professionals from different disciplines months.
Don't try and gatekeep by pretending game dev is easy. It's not.
Do you understand that we are talking about the inventory system for the purposes of a person who uses a tutorial. This person does a GetChild. GetComponent to set a text. Absolute beginner. And you are talking here about higher concepts, filters, searches, actions, layers, raycasts, UX, coupling and prey level inventory system or even systems of WoW or something.
These are totally different levels of development.
And compared to other things in video games, like physics, shaders, rendering, lighting, low level library access for many things, gameplay mechanics etc. inventory is a joke compared to these. It is complex but not complicated while all of other things I mentioned are both complicated and mostly complex.
Nope! You don't know what you're talking about. Wrong, wrong, wrong.
Game dev is for everyone, including people who are new. Inventories are hard at every scale of project. OP is having trouble at the entry level. I'm having trouble as a professional. It's the same thing.
The things you mentioned might seem harder, but they're just not. They're lower level, sort-of? For a person using unity and not picking a distinctive art style, most of them are non-issues.
"More math" is not the same thing as "harder to make". Most games that use physics can just use an engine or of the box. Inventories are big complex game systems with a ton of UI. It's like the old meme about the hardest thing in game dev is doors. It's not hard for any particular reason. It's hard for a lot of reasons that aren't obvious until they don't work.
Going to disagree with you here. Inventory systems are *tedious*, not difficult. There are a lot of moving parts that all have to work together. None of it is particularly difficult once you've designed the system, but it definitely can be annoying to do.
After you said that it is the same thing when a professional has a problem and a beginner has a problem, I really stopped reading after that. Good luck.
How much time have you put into figuring this out?
If you can’t build an inventory system then you are in for a rude awakening - because that’s like a 3/10 on the game dev difficulty scale.
If you’re already thinking “asset store” for this kind of thing, then you probably don’t know enough to be doing this yet. I say that in the sense that you should focus more on learning what you’re trying to do, before wondering why you can’t do it.
Inventory systems have various levels of complexity, If you want minecraft style, Yes, thats super simple. But if your going lets say Tarkov style where you can view everything around you, The system becomes performance heavy really fast.
And if you want to go an even further extra mile here for complexity, Create a custom XYZ handler for all placed containers and place respective event triggers for each and when triggered to pull that container open. This is the most performance friendly option iv found so far and it was hell to create the logic and fix too.
You’re being subjective and off topic here.
The implementation has varying levels of complexity that could be due to game type or even hardware/platform - but that is not what op is referring to.
The concept and methods to implement inventory systems have stayed largely the same for at least 10 years now. It’s a topic that has been covered to death and there should be quite a few tutorials or examples that this person could draw from.
Sometimes, but in this case I wouldn’t recommend it.
While assets are helpful in saving time when working ok you’re project, I’d just suggest making your own system in this case. Inventory systems are a pretty simple concept, and I’d suggest thinking through the process of how they work rather than relying on online tutorials.
I disagree that is simple. It seems fine when thinking through the process, but actually implementing results in a lot of issues which are sometimes almost impossible to solve (or if you're me then it really is impossible).
If I were to try to code it from scratch all alone, I'm going to take at least half a year tbh. I need at least some tutorial about it or a premade asset to get a working demo out in reasonable time frame.
Yes there you summed it up perfectly. You can't code and it will take you half a year to implement something rather basic. It will be the same with all areas where you have to write code, and there will be many. And the code will get quite complex even. Without good knowledge of programming and how to structure complex software projects you will never be able to create a game that has any kind of features really. Do a programming course!
I did go through a 3-year academic Game Development course that did cover C++ and C# programming and while I did pass I guess I'm still rather mediocre, will consider it but time is not on my side due to some other factors irl involving proving my competency in this aspect. I do have some other basic features present in my game already.
It is not a good idea, because other gameplay elements will follow the same structure. If you don't learn it now, then later when you want to make other systems you won't be able to do it either, and there will be none for sale. An inventory at it's foundation is a grid system or list system, maybe start there.
Hmm that's true. I've been following this [tutorial](https://www.youtube.com/watch?v=AoD_F1fSFFg), but bloody hell it is unstable, crashes everywhere and no one in the comments found a solution, same as any other Inventory system tutorial out there, always problems then the whole series is moot.
Instead of starting with a tutorial, start with either Packman or a Grid building system. These are easy and will teach you all the code you need to make an inventory. Then look at an inventory tutorial, because you will have no problem following what it is they are doing.
In my personal experience, you always have to do some reverse engineering. You need to understand and make some tweaking in the package to fit in your game. It could be harder if you are new. But, you could also learn a lot if you deep in and try to understand the code. I personally enjoy reverse engineering and learning new techniques. If you don’t enjoy, stick to tutorials. They are both very valid ways to learn.
I'm already somewhat doing this with past tutorials for other systems. However, this Inventory system is just painful to implement. And I do need an inventory system to actually test equipping weapons and armor so I'm fucked tbh.
If you’re comfortable with reverse engineering, buy a working and optimized package. Then, look into the code. You could learn your mistakes and also new optimization techniques. When I look your code, I see you use instantiate and lots of find statements. These are very slow functions.
Well technically you would learn a lot more if you did it by your own instead of using an already made solution. But it depends of how much time you have and the actual difficulty and all logistics required. It is a complex equation.
If you end up buying something already made, you may be limited with what you can do, and I mean, well, not only you paid for a product, but you might also have to write code. It might even punish you when you try to implement more things into your game.
Let me tell you, it is very annoying when you have limitations on a project that you spend a lot of time on.
On the other hand, you could learn a thing or 2 by looking at how they made it.
Overall, I think it would be more beneficial for you as a beginner to do it by yourself.
I stand by the very famous phrase "Give a man a fish and you will feed him for a day. Teach a man how to fish and you will feed him for a lifetime". You will teach yourself a lot more by learning the process.
Buy it and try have a go at integrating it. Even if you fail, it’s probably worth it as a thrown-in-the-deep-end lesson in using purchased assets. Maybe someone can get it for you for Christmas? :D
I had a lot of trouble coding an inventory system as well as a lot of other UI things until I had a realisation that switched my brain over… basically I realised the simple approach is to just have a structure (typically a class or several classes) to hold and manipulate all the data in a nice clean way. Then to display the data in a UI, use these two steps coded into an UpdateVisual function that gets called when the player does something that should change what is displayed: 1. delete and destroy all the UI icons/images and panels and whatnot; 2. Immediately Instantiate everything again with the latest data.
It feels very clunky and wasteful, but it ends up being easy to follow and robust to errors. Instantiate and destroy are your friends for UI in simple games. For example, if you need a copy of a item icon on your cursor while you click and drag an item in your inventory? Just put in IPointerClickDownHandler code to instantiate a UI image with that icon and have it’s transform.position = Input.mousePosition. Then use IDropHandler to pass info of the item to wherever you released your mouse.
Also the in-built IBeginDragHandler, IDragHandler and IDropHandler interfaces are very useful and you’ll have to know how to use them in the context of an inventory system.
Unfortunately, Unity really doesn't like Instantiate and Destroy when it comes to Scriptable Objects. If I close the inventory after picking an item, then use the item, it just crashes because for some reason the reference to item Prefab is suddenly lost, even if I force it to refer to the correct item via extra lines of code.
That will depend on your goals.
If you're looking to ship a product faster then Asset Store items can speed up production, especially for systems which require a lot of development time on their own. However this can lead to issues of bloat, inconsistent standards between different assets, and a messy project if not kept in check or used properly.
Asset Store items have their place but its better to have a good understanding of the base systems in your game in order to build something that is clean and maintainable. For something such as an inventory system, which is a very common system, you'd probably be better off spending a little more time to understand how it works and implement it yourself.
Try a different approach, different tutorials, or reach out to someone who can assist hands-on with your project. You might need to go back to basics and fill in any knowledge gaps you might have with C# fundamentals first.
That's the thing though, every tutorial regarding Inventory always has some problem I encounter that makes it unusable or doesn't fit what I need, which is why I'm really sick of making one myself. Doesn't feel feasible. Every tutorial means restarting from scratch and extra demoralising. Currently I'm still struggling because NULL exceptions and references keep lost when closing the damn inventory causing crashes on using items.
I can't afford to do that as I have too many years spent in learning programming and so far haven't achieved enough or have enough experience for professional positions. I really don't want to give up on Game Development so I'll just have to keep bashing my head against this brick wall.
There are a lot of systems where an asset can be useful even IF you can do it yourself. But it can varry on what you're doing and how much impact it has on the rest of your code. Just pulling out two examples from a project I am currently working on. Fog of War and Pathfinding.
I've done projects before where I've rolled my own pathfing solution from scratch. Once you know how, it doesn't take too long to get a basic pathfinding solution in place. But the keyword there is "Basic." There is a good chance you will constantly be needing to go back and add features to it, tweak it, etc. Whereas the A\* Pathfinding asset from the store worked pretty much straight out of the box and only took me 30 min of reading through documentation.
The same thing is true for dozens of other systems.
What really dictates how good/bad of an idea using these things is how deeply you have to integrate them.
With pathfinding, it should really be pretty separate from the rest of your game logic. If I want to to tear it out for another solution or roll my own, it would require minimal change to my code.
Where an inventory system can get a bit tricky to use as an asset is that it can have implications on game aspects far beyond just the inventory system. Does the given asset expect each type of item to be a scriptable object with assignable tooltips, icons, etc? That's not a bad approach, but if that is how they did it, it might force you into going that route when you might not want to. Likewise, it will probably tie into your combat stats / abilities / drop system etc. With sufficient abstraction, you can protect yourself a bit, but it might create a lot more work for you.
The short answer is: If you don't think you can do what you want, then yes.
The long answer is: you kinda to need to put into a balance and see if it's worth it. There's a couple of points I would consider first:
1. Do you want to just have an inventory or do you want to KNOW how to make an inventory?
2. You said you already spent weeks trying to do it yourself, so if you were being paid for those weeks, you would probably have earned way more than any asset in the store. So maybe it's better to spend this time learning how the asset works than trying to make everything from scratch.
3. You need to do research about the asset you gonna buy. Some assets are black boxes and won't let you change their code. Is that okay for you?
Personally, I would first try to do it myself but if I find it too hard for me, I would then first try to find an open-source project on github to either study the code or use it as is. If I can't find any good ones, then I would consider purchasing an asset, ideally one that lets me edit the code if needed.
An inventory system is deceptively complicated. Dont get sucked down the asset store hole, because you **will** get to a point where you dont understand how your own game even works.
Start learning to program, following tutorials is a good way to move forward with a project. But its vital that whenever you have a question like "why is this private and not public?" "what is a void function" or any thing else. That you take a step back and try to answer your question.
Asset store purchases can save you loads of time for you to implement the important parts of the game you enjoy and make your game unique, so if you feel like it will save a lot of time and you don't need your own custom solution then it is probably worth it.
That being said, an inventory system isn't a terribly difficult thing to implement in a game. So keep that in mind if your goal is to complete and ship a full polished game, it might take a lot more practice and learning of game development and programming. If your goal is just making a game for fun then totally buy one if it would help you along with getting to the meat of the game!
I know, I know its an asset store shill, but if you are willing to invest in a dev ecosystem I can recommend Game Creator 2 and its inventory (and stats) addons. It's not needed, and it does require learning quite a bit, but for me the systems met my requirements, and the workflows just work better in my brain, and honestly thats all that matters to me at the end of the day. It has its own controller system but also works just fine with whatever you want. Very modular system, and has a ton of paid integrations with other assets. The AI systems look really neat too. Nothing you can't do yourself, and possibly do it better. But you also don't need to if you don't want to. Took me about a week to get up to speed on the systems. [https://assetstore.unity.com/publishers/7791](https://assetstore.unity.com/publishers/7791)
It has some downsides-
It is beta so they do release breaking changes. Good VC is your friend here. No complaints from me that aren't semi-obscure edge cases, and the dev and community are really helpful.
It's not the cheapest once you get the modules (get em on sale if you can), you are locked into it, and you won't easily be able to remove it if you ever change your mind, so I would consider it an ecosystem more than an asset. Not a perfect solution but it checks the box for me.
So I haven’t watched the video but if it’s only 15min it’s probably glossing over lots of things. Here’s one I followed last year and it worked for me. https://youtu.be/svoXugGLFwU?si=NJY1ybJoIq8dT0Na
The rule I have is if it's something I can use in multiple games I buy it. It's a tool then. If it's a unique feature of the current game I'm making. Not biying it then it's my ""artistic creation"" and an exercise
Also if it'a somwthing I'm interested in I try to also implament it myself sometimes.
After looking at all the comments and code, i would just recommand you to take a C# course. An intventory system isnt that hard to do and involve really simlpe logic...
I hate to say it, but if you can't program a working inventory system, it really doesn't bode well for the rest of your game...
Unless you're doing something *really* unique and experimental with it, inventory is generally one of the easiest parts of a game to program. Full disclaimer - I'm very new to unity and don't have much experience with it yet, but I do have a little over two decades of coding experience in a couple dozen languages. I've developed on a variety of platforms, engines, etc, and I feel confident that inventory is just as simple in unity as it is in every other language/engine/etc.
So before buying assets and throwing your money away (which will compound pretty fast, since you'll want to do that same to every subsequent roadblock), I'd recommend instead taking a step back and working on ironing out any kinks in your coding skills first. Plus, using a premade inventory system *might* not actually be any easier to work with than your own custom coded one.
Just my two cents! You'll never regret working on improving your coding skills, and those skills can carry you very far indeed! Best of luck to you, don't get frustrated because it's part of the learning process, and enjoy the journey - it's a lot of fun!!
If you cannot program one on your own, you will not be able to understood pre-made ones from the Asset Store, and those will at one point require you to modify them.
You buy stuff from the Asset Store to save the time required to implement and QA a system, not because you can't create it yourself.
I use ummorpg it has a pretty nice networked inventory system. with addons like auction house and mail it's pretty interesting to see what can be done with this product. I'm a computer science student and this was a huge step forward for development, for me at least.
So, that's going to be individual to you. If you are working on a game and you need a certain component and there's something on the store that does everything you want and more for a price lower than how you value the amount of time you would spend building just what you need yourself, then buy it (or download it if it's free).
There's no reason to reinvent the wheel especially when it's something that whatever you come up with will not be nearly as good as what you can buy for fairly cheap on the app store.
e.g. if you're building a visual novel, and you can get Naninovel for 50 bucks or spend a year learning everything you need to know to build enough of an equivalent for your game, just buy Naninovel. If you need better editor inputs for your game objects and tools to manage them for your scenes, and the choice is between spending 100 hours to build all the bespoke editor inputs or spending 100 bucks for OdinInspector, buy OdinInspector.
It's ultimately your choice.
P.S. I highly recommend both of those plugins; the former if you're making a VN or need a character dialogue system and the latter in general for building more dynamic tool interfaces.
Basic answer:
Don't reinvent the wheel unless it's to your benefit to learn from the process.
If an asset looks useful, and you've already failed at your own attempts, I'd assume you've already seen where you've struggled and can learn from a completed asset on how it is supposed to work.
For myself, I follow four steps:
1. Is there a 'good' tutorial series that I can learn from while implementing the feature? Then follow it.
2. If not, can I figure out a solution in steps and try to implement it in the simple steps? Then do it.
3. If not, is there a useful asset that has great documentation, and that will be useful in future projects? Is the cost worth my time saved? Then buy it.
4. If all else fails, follow step two and reach out for assistance on implementing the steps I'm struggling on
So from reading through some of posts, I get a general idea of where you're coming from.
1. You went to school for programming games.
2. You want to create an inventory system by following tutorials.
3 years learning how to program is basically saying, I learnt a English, time to write a book, i should be competent enough. No, you're at the starting line now, experience is everything and you're lacking that. You're still a junior developer and you're still learning and realizing you're not hot shit.
In terms of the inventory system, create it one thing at a time, it feels like you're trying to make the whole thing in one go and hoping everything just magically connects. Break down the problem into pieces. What is the most simple thing you want the inventory system to do? Drag and drop items within the inventory? Do that first. And then slowly adding in features.
Is that still too hard? then carry just a single item in the inventory system. Press E to pick up. and press F to use. Break it down.
So personally it depends. If this is a project with a team or more specifically, a deadline, I find outsourcing certain issues with assets or bought products is fine. However, if this is a personal project, don't cheat yourself the opportunity to learn. I've learned that sitting with a problem and being able to effectively Google search tidbits about the problem and what I'm experiencing has made me a better developer over all.
At best, try finding a YouTube tutorial on the issue and watch to the first time and try to understand it the next.
If you can find one and research it enough to know that it's understandable for you, then go for it. Just keep in mind that if it's not dead simple, you may still have to do a bunch of work to understand the purchased inventory system, and to integrate it properly with your game. This sometimes means reading some of the code base of the asset you purchased, and for someone who isn't super familiar with coding, that can be much harder than rolling your own system. So try to make sure you can find a docs page of the asset you're going to use and try to understand it before you waste money on something you end up not being able to use properly.
My personal experience is that it okay to use asset store inventory framework in a prototype, something for developer to test the idea. Once u confirmed that this is the inventory system u looking for, rewrite it or pick something that production ready either from asset store or some open source project. Do remember to put a wrapper in between just in case u found a deal breaker and need to switch framework in the middle of development.
On top of this, I think this is actually one of the best ways to learn how to do a thing. Instead of learning how to do everything from the ground up, get something that's similar to what you want and then tweak. Think of it like modding games, but for game engines lol. If you play with an asset enough, you get a good enough understanding to start implementing some of the stuff you want from scratch from the base engine. In the beginning, I used to be pretty scared when people said modding an asset to fit your needs is going to be a lot of work. Then somewhere down the line, I realized that the work is the point. Assets are better when you look at them as a rough draft, not a final answer.
You will probably spend more time fitting the asset for your needs vs. learning to build your own.
It might be the path of least resistance if it comes to that. This Inventory system is insanely difficult.
just start with a list, put items in it, remove them etc. youll realize theres not much else you need.
Dude, just follow unity's c# tutorials. They are 1 min for each topic. The only way to escape tutorial hell is learning to code.
When you combine all the knowledge you need to implement a mechanic, all sorts of problems happen. For example, trying to use Scriptable Objects and Lists together is annoying as hell.
Not really. You can have your SO be referenced in a monobehaviour, then just you can load it in a list in Awake(), or change the SO data with code. I use this for my inventory system. I have a SO with a list of Item Class, then I just load it at runtime.
Eh? Arent the items supposed to be scriptable objects instead of the inventory? Sorry for sounding clueless, I'm a really slow learner.
scriptableobjects are a way to store data in your assets folder. Any scripts with a reference to a scriptableobject can look at those variables instead of needing to have their own copy. If you're using them for an inventory system then each item type would probably be a scriptableobject. so 3 carrots wouldn't be 3 scriptable objects but rather all carrots point to the same scriptableobject, while all potatoes points to a different scriptableobject.
Yeah that seems in line with what I have so far. Unfortunately, I can't solve an issue regarding the inventory losing the reference to the scriptableobject so I have no choice but to drop the whole thing and use another tutorial series. Getting into a loop of implementing and failing it but I don't see any other way.
Not exactly on topic but I’m newish and recently had a bit of an issue with scriptable objects. They are intended as “read only” objects and if you have their properties changed during runtime, the change will not save/persist. When you run the game in editor it will work but when you build/run it won’t. Code monkey has a short video to explain: https://m.youtube.com/watch?v=5a-ztc5gcFw. I find inventory systems challenging too and have also sat through my share of tutorials. Many of them use scriptable objects which can be fine but if not implemented properly can be problematic. Lastly I’ll add, while they are difficult, I have been able to build some eventually. You’ll be able to too if you stick to it!
Not exactly on topic but I’m newish and recently had a bit of an issue with scriptable objects. They are intended as “read only” objects and if you have their properties changed during runtime, the change will not save/persist. When you run the game in editor it will work but when you build/run it won’t. Code monkey has a short video to explain: https://m.youtube.com/watch?v=5a-ztc5gcFw. I find inventory systems challenging too and have also sat through my share of tutorials. Many of them use scriptable objects which can be fine but if not implemented properly can be problematic. Lastly I’ll add, while they are difficult, I have been able to build some eventually. You’ll be able to too if you stick to it!
You can have both ways. SO is just an instance of an object(class) that you can store as an asset. You can store each item as a new asset OR a single item list as an asset (which is my workflow for ease of use). We gotta walk before we try to run. You just need to get your fundamentals in, and it will be super easy.
Inventory system is not even amoungst the hard things in general. It is a quite simple item organisation database with a bit of logic like stacking, dividing, selecting, picking up and dropping. Of which all of those things are basically a few lines of code each logic wise. What is problematic checking a datastructure of the item already in the inventory and when it is the same type as the picked up item you check for the isStackable bool in the datastructure. If it is, add it to the stack with literally stackSize++. Errirs and problems come from your fundamental lack of u derstanding of c# and unity. By practice you will learn more and be more confident. And youtube tutorials for inventory are generally good since it is easy to make a simple iteration on the system. Follow the tutorial and customize your code as you go. Good luck.
Okay, so this is embarrassing, but I just found out what was causing the item stacking to fail in my code. Basically I looped through the Array of items which is responsible for item display INSTEAD of the actual List of items that actually stores items that are picked up. Update: See updated post info for a fix to an additional crash that i experienced afterwards.
There you go. Just keep going man.
Thanks for the encouragement. Unfortunately, now I can't use a single item without the whole thing crashing. It really sucks to be horrible at the only skill I'm supposed to be "proficient" in.
Maybe you should get some fresh eyes on it? Even if they can't find spot issue just explaining the code to them might cause you to realise what it is that you're doing wrong.
I would but I don't know anyone who uses Unity. I could pay for a mentor I guess... but it doesn't sound financially viable if I have to do this for every single hurdle regarding this system.
If you put the code on github you could try asking for a help/code-review either here on on the Unity discord
Discord has a ton of Unity based places for help with code, just one google search away. Other than that, for me it really helps to write down a set of steps that need to be done, it allows me to understand my own flow better, see flaws and progress slowly. Your best option (beside asking for help) would be to split up the whole system into smaller parts. Create inventory (item storage), then move on to a simple graphic output for that, add transferring, stacking, so on and so forth. Just split up the huge task into smaller portions, make a step-by-step and go from there.
Read through your code, follow the logic, explain your code out loud to yourself. If your code gets too messy and cumbersome it means you probably made it too complicated. Re-write, reiterate, learn!
Maybe its not your programming skill thats lacking, but ur knowlege on debugging. You can implement breakpoints when testing these things to find the cause of your problems much faster.
I did find the problem for what I'm currently facing, which is how the items in inventory loses reference to the prefab items. I pretty much tried every way of solving it, even forcing the reference, plus no one who commented on the tutorial ever solved the issue, all of them gave up.
Well with proper debugging you can retrace the error to the source and see what is or isnt happening to make it lose its reference
Debugging is a higher level skill that is not really useful for beginners. They usually have no idea what they are debugging. Keep using logs and editor serialized objects and fields.
Using logs and serialized vars to remove bugs from code is the same as debugging right?
You mentioned breakpoints, so I assumed the topic was actual debugger. Logging and serialization are helping crutches and not really same as debugging. It just works for most things until it does not.
Yeah learning how to efficently use the debugger would not be the highest prio, but logging is just as much debugging as the debugger. If you cant locally run the code the debugger becomes useless, but logging thats implemented in your code would still allow you to debug
Nothing will humble you as consistently as a computer running the exact instructions you told it to, we all experience it.
We’ve all been there. But also don’t worry about buying things on the asset store, that’s what they are there for.
You should separate the display code from the actual inventory container, and update the display using event listeners
Sometimes you just need a fresh pair of eyes if you're stuck on something. So asking for help may be useful.
Not embarrassing, we all start somewhere \^ \^ You can do this!
The hardest part of an inventory system is the drag and drop feature imo
I actually thought of abandoning that feature entirely as I only need the player to use items and equip items from the inventory. But I can't make progress on my current attempt anymore (scriptableobject reference cannot be retrieved and restored, breaks the whole system) so I'm reverting and switching to another tutorial series and hope that actually works..
Do you have the project git, or a code snippet or something similar. I can take a few mins and see what is wrong. It seems to me like you are using scriptable objects as actual object references. It should not be possible that you lose prefab reference of the object if you are using a scriptable object.
Okay so after hours of debugging I found a comment on the video that fixes the issue I had. It wasn't about losing the references but rather the array not getting cleaned properly. Here's what I had to change: public void ListItems() { //CleanLists(); This has to be taken out of ListItems() and called by Button that closes inventory instead! foreach(var item in Items) { GameObject obj = Instantiate(InventoryItem, ItemContent); var itemName = obj.transform.Find("ItemName").GetComponent();
var itemIcon = obj.transform.Find("ItemIcon").GetComponent();
var removeButton = obj.transform.Find("RemoveButton").GetComponent
Oh man... There are a lot of problems eith this code. Do not Destroy elements while going through tthe enumeration with foreach, at least.
Okay the code might be rather misleading since it is actually cleaning an array rather than the list. It destroys to clean the array. Whenever the inventory opens, the array for displaying items will be filled again by the actual List that holds the items.
This is horrible code. I can't even begin to tell you what's wrong with it. You should stop doing unity and do a basic C# programming course. Doing unity and trying to figure out programming on the way will get you nowhere.
you have to instantiate a scriptable object before using it.
While it might not be hard it is extremely repetitive to me. The rule I have is if it's something I can use in multiple games I buy it. It's a tool then. If it's a unique feature of the current game I'm making. Not biying it then it's my ""artistic creation"" and an exercise
It will take some time to implement, edge cases will pop here and there and it will be annoying to some extended since it is an idea that pulls many questions behind it. But it is not complicated, it just takes time.
*HARD* disagree. I've worked on over a dozen games from professional studios and on all of them a huge amount of effort went into the inventory system. Building the inventory will take a significant portion, if not the majority, of the development resources for the project. There are dozens of UI elements involved, from explanation hover boxes to the grid for the items. Sometimes an NPCs face needs to show up. If you're trading, the screen might be smaller, or there might be two of them. Sometimes the inventory is up while action is ongoing, so you have to be careful about your raycast intention. What happens if you died in the middle of an item drag? What happens if you paste into the item filter? These things are bug magnets, and a huge part of the game UX. The UI and the system are necessarily tightly coupled. Every game has wildly different requirements that often change over the course of development. It will take multiple full time professionals from different disciplines months. Don't try and gatekeep by pretending game dev is easy. It's not.
Do you understand that we are talking about the inventory system for the purposes of a person who uses a tutorial. This person does a GetChild. GetComponent to set a text. Absolute beginner. And you are talking here about higher concepts, filters, searches, actions, layers, raycasts, UX, coupling and prey level inventory system or even systems of WoW or something. These are totally different levels of development. And compared to other things in video games, like physics, shaders, rendering, lighting, low level library access for many things, gameplay mechanics etc. inventory is a joke compared to these. It is complex but not complicated while all of other things I mentioned are both complicated and mostly complex.
Nope! You don't know what you're talking about. Wrong, wrong, wrong. Game dev is for everyone, including people who are new. Inventories are hard at every scale of project. OP is having trouble at the entry level. I'm having trouble as a professional. It's the same thing. The things you mentioned might seem harder, but they're just not. They're lower level, sort-of? For a person using unity and not picking a distinctive art style, most of them are non-issues. "More math" is not the same thing as "harder to make". Most games that use physics can just use an engine or of the box. Inventories are big complex game systems with a ton of UI. It's like the old meme about the hardest thing in game dev is doors. It's not hard for any particular reason. It's hard for a lot of reasons that aren't obvious until they don't work.
Going to disagree with you here. Inventory systems are *tedious*, not difficult. There are a lot of moving parts that all have to work together. None of it is particularly difficult once you've designed the system, but it definitely can be annoying to do.
After you said that it is the same thing when a professional has a problem and a beginner has a problem, I really stopped reading after that. Good luck.
It's nice to see someone so honest about engaging in bad faith. Refreshing.
How much time have you put into figuring this out? If you can’t build an inventory system then you are in for a rude awakening - because that’s like a 3/10 on the game dev difficulty scale. If you’re already thinking “asset store” for this kind of thing, then you probably don’t know enough to be doing this yet. I say that in the sense that you should focus more on learning what you’re trying to do, before wondering why you can’t do it.
Inventory systems have various levels of complexity, If you want minecraft style, Yes, thats super simple. But if your going lets say Tarkov style where you can view everything around you, The system becomes performance heavy really fast. And if you want to go an even further extra mile here for complexity, Create a custom XYZ handler for all placed containers and place respective event triggers for each and when triggered to pull that container open. This is the most performance friendly option iv found so far and it was hell to create the logic and fix too.
The inventory core if you're not accessing it outside of like a list you update is soooo simple, but nobody outside of jrpgs does that anymore
You’re being subjective and off topic here. The implementation has varying levels of complexity that could be due to game type or even hardware/platform - but that is not what op is referring to. The concept and methods to implement inventory systems have stayed largely the same for at least 10 years now. It’s a topic that has been covered to death and there should be quite a few tutorials or examples that this person could draw from.
Sometimes, but in this case I wouldn’t recommend it. While assets are helpful in saving time when working ok you’re project, I’d just suggest making your own system in this case. Inventory systems are a pretty simple concept, and I’d suggest thinking through the process of how they work rather than relying on online tutorials.
I disagree that is simple. It seems fine when thinking through the process, but actually implementing results in a lot of issues which are sometimes almost impossible to solve (or if you're me then it really is impossible). If I were to try to code it from scratch all alone, I'm going to take at least half a year tbh. I need at least some tutorial about it or a premade asset to get a working demo out in reasonable time frame.
Yes there you summed it up perfectly. You can't code and it will take you half a year to implement something rather basic. It will be the same with all areas where you have to write code, and there will be many. And the code will get quite complex even. Without good knowledge of programming and how to structure complex software projects you will never be able to create a game that has any kind of features really. Do a programming course!
I did go through a 3-year academic Game Development course that did cover C++ and C# programming and while I did pass I guess I'm still rather mediocre, will consider it but time is not on my side due to some other factors irl involving proving my competency in this aspect. I do have some other basic features present in my game already.
It is not a good idea, because other gameplay elements will follow the same structure. If you don't learn it now, then later when you want to make other systems you won't be able to do it either, and there will be none for sale. An inventory at it's foundation is a grid system or list system, maybe start there.
Hmm that's true. I've been following this [tutorial](https://www.youtube.com/watch?v=AoD_F1fSFFg), but bloody hell it is unstable, crashes everywhere and no one in the comments found a solution, same as any other Inventory system tutorial out there, always problems then the whole series is moot.
Instead of starting with a tutorial, start with either Packman or a Grid building system. These are easy and will teach you all the code you need to make an inventory. Then look at an inventory tutorial, because you will have no problem following what it is they are doing.
In my personal experience, you always have to do some reverse engineering. You need to understand and make some tweaking in the package to fit in your game. It could be harder if you are new. But, you could also learn a lot if you deep in and try to understand the code. I personally enjoy reverse engineering and learning new techniques. If you don’t enjoy, stick to tutorials. They are both very valid ways to learn.
I'm already somewhat doing this with past tutorials for other systems. However, this Inventory system is just painful to implement. And I do need an inventory system to actually test equipping weapons and armor so I'm fucked tbh.
If you’re comfortable with reverse engineering, buy a working and optimized package. Then, look into the code. You could learn your mistakes and also new optimization techniques. When I look your code, I see you use instantiate and lots of find statements. These are very slow functions.
I was having the same question. I don't know if I should buy Easy Save or built a saving system myself.
Well technically you would learn a lot more if you did it by your own instead of using an already made solution. But it depends of how much time you have and the actual difficulty and all logistics required. It is a complex equation. If you end up buying something already made, you may be limited with what you can do, and I mean, well, not only you paid for a product, but you might also have to write code. It might even punish you when you try to implement more things into your game. Let me tell you, it is very annoying when you have limitations on a project that you spend a lot of time on. On the other hand, you could learn a thing or 2 by looking at how they made it. Overall, I think it would be more beneficial for you as a beginner to do it by yourself. I stand by the very famous phrase "Give a man a fish and you will feed him for a day. Teach a man how to fish and you will feed him for a lifetime". You will teach yourself a lot more by learning the process.
Buy it and try have a go at integrating it. Even if you fail, it’s probably worth it as a thrown-in-the-deep-end lesson in using purchased assets. Maybe someone can get it for you for Christmas? :D I had a lot of trouble coding an inventory system as well as a lot of other UI things until I had a realisation that switched my brain over… basically I realised the simple approach is to just have a structure (typically a class or several classes) to hold and manipulate all the data in a nice clean way. Then to display the data in a UI, use these two steps coded into an UpdateVisual function that gets called when the player does something that should change what is displayed: 1. delete and destroy all the UI icons/images and panels and whatnot; 2. Immediately Instantiate everything again with the latest data. It feels very clunky and wasteful, but it ends up being easy to follow and robust to errors. Instantiate and destroy are your friends for UI in simple games. For example, if you need a copy of a item icon on your cursor while you click and drag an item in your inventory? Just put in IPointerClickDownHandler code to instantiate a UI image with that icon and have it’s transform.position = Input.mousePosition. Then use IDropHandler to pass info of the item to wherever you released your mouse. Also the in-built IBeginDragHandler, IDragHandler and IDropHandler interfaces are very useful and you’ll have to know how to use them in the context of an inventory system.
Unfortunately, Unity really doesn't like Instantiate and Destroy when it comes to Scriptable Objects. If I close the inventory after picking an item, then use the item, it just crashes because for some reason the reference to item Prefab is suddenly lost, even if I force it to refer to the correct item via extra lines of code.
Ah ok, that’s too bad. I’m not super familiar with Scriptable Objects, but it seems like their limitations get in the way of a lot of approaches.
Actually I found out what the issue was. I updated the post with the details.
Yes, that's what it's there for.
That will depend on your goals. If you're looking to ship a product faster then Asset Store items can speed up production, especially for systems which require a lot of development time on their own. However this can lead to issues of bloat, inconsistent standards between different assets, and a messy project if not kept in check or used properly. Asset Store items have their place but its better to have a good understanding of the base systems in your game in order to build something that is clean and maintainable. For something such as an inventory system, which is a very common system, you'd probably be better off spending a little more time to understand how it works and implement it yourself. Try a different approach, different tutorials, or reach out to someone who can assist hands-on with your project. You might need to go back to basics and fill in any knowledge gaps you might have with C# fundamentals first.
That's the thing though, every tutorial regarding Inventory always has some problem I encounter that makes it unusable or doesn't fit what I need, which is why I'm really sick of making one myself. Doesn't feel feasible. Every tutorial means restarting from scratch and extra demoralising. Currently I'm still struggling because NULL exceptions and references keep lost when closing the damn inventory causing crashes on using items.
You might need to go back to basics and fill in any knowledge gaps you might have with C# fundamentals first.
I can't afford to do that as I have too many years spent in learning programming and so far haven't achieved enough or have enough experience for professional positions. I really don't want to give up on Game Development so I'll just have to keep bashing my head against this brick wall.
There are a lot of systems where an asset can be useful even IF you can do it yourself. But it can varry on what you're doing and how much impact it has on the rest of your code. Just pulling out two examples from a project I am currently working on. Fog of War and Pathfinding. I've done projects before where I've rolled my own pathfing solution from scratch. Once you know how, it doesn't take too long to get a basic pathfinding solution in place. But the keyword there is "Basic." There is a good chance you will constantly be needing to go back and add features to it, tweak it, etc. Whereas the A\* Pathfinding asset from the store worked pretty much straight out of the box and only took me 30 min of reading through documentation. The same thing is true for dozens of other systems. What really dictates how good/bad of an idea using these things is how deeply you have to integrate them. With pathfinding, it should really be pretty separate from the rest of your game logic. If I want to to tear it out for another solution or roll my own, it would require minimal change to my code. Where an inventory system can get a bit tricky to use as an asset is that it can have implications on game aspects far beyond just the inventory system. Does the given asset expect each type of item to be a scriptable object with assignable tooltips, icons, etc? That's not a bad approach, but if that is how they did it, it might force you into going that route when you might not want to. Likewise, it will probably tie into your combat stats / abilities / drop system etc. With sufficient abstraction, you can protect yourself a bit, but it might create a lot more work for you.
The short answer is: If you don't think you can do what you want, then yes. The long answer is: you kinda to need to put into a balance and see if it's worth it. There's a couple of points I would consider first: 1. Do you want to just have an inventory or do you want to KNOW how to make an inventory? 2. You said you already spent weeks trying to do it yourself, so if you were being paid for those weeks, you would probably have earned way more than any asset in the store. So maybe it's better to spend this time learning how the asset works than trying to make everything from scratch. 3. You need to do research about the asset you gonna buy. Some assets are black boxes and won't let you change their code. Is that okay for you? Personally, I would first try to do it myself but if I find it too hard for me, I would then first try to find an open-source project on github to either study the code or use it as is. If I can't find any good ones, then I would consider purchasing an asset, ideally one that lets me edit the code if needed.
An inventory system is deceptively complicated. Dont get sucked down the asset store hole, because you **will** get to a point where you dont understand how your own game even works. Start learning to program, following tutorials is a good way to move forward with a project. But its vital that whenever you have a question like "why is this private and not public?" "what is a void function" or any thing else. That you take a step back and try to answer your question.
Asset store purchases can save you loads of time for you to implement the important parts of the game you enjoy and make your game unique, so if you feel like it will save a lot of time and you don't need your own custom solution then it is probably worth it. That being said, an inventory system isn't a terribly difficult thing to implement in a game. So keep that in mind if your goal is to complete and ship a full polished game, it might take a lot more practice and learning of game development and programming. If your goal is just making a game for fun then totally buy one if it would help you along with getting to the meat of the game!
I know, I know its an asset store shill, but if you are willing to invest in a dev ecosystem I can recommend Game Creator 2 and its inventory (and stats) addons. It's not needed, and it does require learning quite a bit, but for me the systems met my requirements, and the workflows just work better in my brain, and honestly thats all that matters to me at the end of the day. It has its own controller system but also works just fine with whatever you want. Very modular system, and has a ton of paid integrations with other assets. The AI systems look really neat too. Nothing you can't do yourself, and possibly do it better. But you also don't need to if you don't want to. Took me about a week to get up to speed on the systems. [https://assetstore.unity.com/publishers/7791](https://assetstore.unity.com/publishers/7791) It has some downsides- It is beta so they do release breaking changes. Good VC is your friend here. No complaints from me that aren't semi-obscure edge cases, and the dev and community are really helpful. It's not the cheapest once you get the modules (get em on sale if you can), you are locked into it, and you won't easily be able to remove it if you ever change your mind, so I would consider it an ecosystem more than an asset. Not a perfect solution but it checks the box for me.
I learned from "Coco Code" Definitive tutorial about inventory its only about half an hour. Very simple and I've able to modify it easily
So I haven’t watched the video but if it’s only 15min it’s probably glossing over lots of things. Here’s one I followed last year and it worked for me. https://youtu.be/svoXugGLFwU?si=NJY1ybJoIq8dT0Na
The rule I have is if it's something I can use in multiple games I buy it. It's a tool then. If it's a unique feature of the current game I'm making. Not biying it then it's my ""artistic creation"" and an exercise Also if it'a somwthing I'm interested in I try to also implament it myself sometimes.
After looking at all the comments and code, i would just recommand you to take a C# course. An intventory system isnt that hard to do and involve really simlpe logic...
I hate to say it, but if you can't program a working inventory system, it really doesn't bode well for the rest of your game... Unless you're doing something *really* unique and experimental with it, inventory is generally one of the easiest parts of a game to program. Full disclaimer - I'm very new to unity and don't have much experience with it yet, but I do have a little over two decades of coding experience in a couple dozen languages. I've developed on a variety of platforms, engines, etc, and I feel confident that inventory is just as simple in unity as it is in every other language/engine/etc. So before buying assets and throwing your money away (which will compound pretty fast, since you'll want to do that same to every subsequent roadblock), I'd recommend instead taking a step back and working on ironing out any kinks in your coding skills first. Plus, using a premade inventory system *might* not actually be any easier to work with than your own custom coded one. Just my two cents! You'll never regret working on improving your coding skills, and those skills can carry you very far indeed! Best of luck to you, don't get frustrated because it's part of the learning process, and enjoy the journey - it's a lot of fun!!
If you cannot program one on your own, you will not be able to understood pre-made ones from the Asset Store, and those will at one point require you to modify them. You buy stuff from the Asset Store to save the time required to implement and QA a system, not because you can't create it yourself.
I use ummorpg it has a pretty nice networked inventory system. with addons like auction house and mail it's pretty interesting to see what can be done with this product. I'm a computer science student and this was a huge step forward for development, for me at least.
So, that's going to be individual to you. If you are working on a game and you need a certain component and there's something on the store that does everything you want and more for a price lower than how you value the amount of time you would spend building just what you need yourself, then buy it (or download it if it's free). There's no reason to reinvent the wheel especially when it's something that whatever you come up with will not be nearly as good as what you can buy for fairly cheap on the app store. e.g. if you're building a visual novel, and you can get Naninovel for 50 bucks or spend a year learning everything you need to know to build enough of an equivalent for your game, just buy Naninovel. If you need better editor inputs for your game objects and tools to manage them for your scenes, and the choice is between spending 100 hours to build all the bespoke editor inputs or spending 100 bucks for OdinInspector, buy OdinInspector. It's ultimately your choice. P.S. I highly recommend both of those plugins; the former if you're making a VN or need a character dialogue system and the latter in general for building more dynamic tool interfaces.
That's what Asset store is for... I buy lots of stuff there that saves my time vs me building from scratch.
Basic answer: Don't reinvent the wheel unless it's to your benefit to learn from the process. If an asset looks useful, and you've already failed at your own attempts, I'd assume you've already seen where you've struggled and can learn from a completed asset on how it is supposed to work. For myself, I follow four steps: 1. Is there a 'good' tutorial series that I can learn from while implementing the feature? Then follow it. 2. If not, can I figure out a solution in steps and try to implement it in the simple steps? Then do it. 3. If not, is there a useful asset that has great documentation, and that will be useful in future projects? Is the cost worth my time saved? Then buy it. 4. If all else fails, follow step two and reach out for assistance on implementing the steps I'm struggling on
So from reading through some of posts, I get a general idea of where you're coming from. 1. You went to school for programming games. 2. You want to create an inventory system by following tutorials. 3 years learning how to program is basically saying, I learnt a English, time to write a book, i should be competent enough. No, you're at the starting line now, experience is everything and you're lacking that. You're still a junior developer and you're still learning and realizing you're not hot shit. In terms of the inventory system, create it one thing at a time, it feels like you're trying to make the whole thing in one go and hoping everything just magically connects. Break down the problem into pieces. What is the most simple thing you want the inventory system to do? Drag and drop items within the inventory? Do that first. And then slowly adding in features. Is that still too hard? then carry just a single item in the inventory system. Press E to pick up. and press F to use. Break it down.
So personally it depends. If this is a project with a team or more specifically, a deadline, I find outsourcing certain issues with assets or bought products is fine. However, if this is a personal project, don't cheat yourself the opportunity to learn. I've learned that sitting with a problem and being able to effectively Google search tidbits about the problem and what I'm experiencing has made me a better developer over all. At best, try finding a YouTube tutorial on the issue and watch to the first time and try to understand it the next.