I’m trying to make a simple rpg game where the player picks up items and can use them or combine them through the inventory menu.
I’m a little stumped on how to do the combining though, or should i say which script to have the combining method in.
As it stands I have an itemdata class attached to each game item, and a inventory class attached to my player.
I’m listing all my variables in the item data class and whether it can be combined with other objects through a bool.
My inventory is basically just a List of strings (I wasn’t sure whether to use a number to reference them or a string, but a string was easier to remember);
I felt initially I should have the combineItem method I’ve made and all the add and remove from inventory methods in the itemdata class itself, but now feel this should probably be in the inventory class?
Hopefully this makes sense to someone who can help lol. I’ve thought about just making the objects children of my Inventory game object and cycling through them, this I feel would probably be easier, but I really wanted to do it via a List first.
Maybe you should use ScriptableObjects as the data instead of just strings. It lets you have a data class with no visual representation, and all sorts of information including perhaps a list of items they can be combined with. You can also have properties to store references to the prefabs used to represent them in the game world, a separate representation sprite for the inventory and name/description text.
As for where to have the functionality: I think a static class (not derived from a MonoBehaviour) with all the abstract functionality which combines/creates objects is a good way to implement it. That sort of thing generally doesn’t belong directly on a game object anyway.
A good rule of thumb for composition as in component-based engines like Unity is to make each class focused. Do one thing, and make it adaptable. One class for inventory could apply to backpacks or car trunks. One movement class could apply to AI or players equally well, and the player object would maybe have an input class in addition. And so on.
But not everything needs to be on actual objects, like the aforementioned static combination class. Sometimes you need to just have some code to call from anywhere, and that’s the way to do it. It’s just like the Unity/.NET APIs.
You’ve helped me massively again. I’ve never looked at scriptable objects but just found that unity have a full tutorial on them which will be a great starting point so thankyou!.
I thought about making my inventory class static so that would handle all these functions but your way makes more sense. I’ll look into what you’ve mentioned and get back to this thread with an update of how I went about it.
Yes, it’s usually the best way to separate functionality so you have a literal bag object on the player with an inventory component, or the inventory goes straight on the player (for games where moving bags around is a complication you’d rather avoid).
Using SOs gives you an almost automatic free inventory database editor if you only need basic attributes.
You’ll probably be a while if it goes well - the biggest jobs are making custom editors (if necessary) and adding items
