Wayback Machinekoobas.hobune.stream
May JUN Jul
Previous capture 13 Next capture
2021 2022 2023
1 capture
13 Jun 22 - 13 Jun 22
sparklines
Close Help
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
  • Asset Store
  • Get Unity

UNITY ACCOUNT

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account
  • Blog
  • Forums
  • Answers
  • Evangelists
  • User Groups
  • Beta Program
  • Advisory Panel

Navigation

  • Home
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
    • Blog
    • Forums
    • Answers
    • Evangelists
    • User Groups
    • Beta Program
    • Advisory Panel

Unity account

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account

Language

  • Chinese
  • Spanish
  • Japanese
  • Korean
  • Portuguese
  • Ask a question
  • Spaces
    • Default
    • Help Room
    • META
    • Moderators
    • Topics
    • Questions
    • Users
    • Badges
  • Home /
avatar image
0
Question by darksider2000 · May 12, 2013 at 08:42 PM · performanceoptimizationinventorysysteminventory system

Inventory System (Specific question)

This is a very specific question on the topic, and can not be found by searching, so bear with me on this one.

What I have taken for granted in so many games so many times has now come to haunt me in my sleep - Inventory. I've been working on the logic behind my own inventory system for a few days now, and I've come up with a solution that doesn't appeal much. When it's down to the technicalities, it seems like it will do the job fine, but I don't have enough knowledge about Unity to determine whether it's a good solution, that's where you guys come in.

The Goal: Picking up objects from the ground and adding them into an inventory. The objects are essentially spawned from a prefab at one point or another in time, but they all have dynamic variables that change, either over time or by various other ways. The objects that I add to the inventory need to maintain their dynamic variables so that when I take them out they come out the way they should. Ex: If I use a tool a couple of times, it degrades a bit and when I add it to the inventory I want to keep it's current durability rating so that when I take it out, it doesn't magically gets fixed. These variables are not consistent throughout the project's scope and so storing them in the code might not be a good idea.

My Solution: Any object that is added to the inventory is moved to any set position on the scene, doesn't really matter where so long as they're all in one spot. The objects are completely turned off (Renderer + Scripts + Anything else) and a reference to them is added in a GameObject array, which will be the primary inventory array. Whenever an item is taken out, it can be turned on through that reference and placed wherever desired on the scene. Using this method I accomplish a few tasks: I keep the dynamic vars, I essentially remove the objects from the game and at any point I can access the objects' scripts and run functions even while they're in the inventory. (For items that can degrade even while in inventory, so on).

There are a couple of downfalls that I can see straight ahead with this method, but nothing too major and nothing that can't be worked around to fit this method.

So my questions are: Can this method do the job well, provided the coding is well optimized? Will the objects in the inventory still have any impact on performance when, for instance, I have 105 objects all in one place in my scene? Is an array a non efficient way to store inventory items? Does the action of turning off an object have any impact on performance?

Any kind of feedback is greatly appreciated, and if you have any other pointers or perhaps a method of your own that might fit my goal feel free to share!

Thank you for reading this far, and for generally being a helpful community ;)

Comment
Add comment · Show 3
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Negagames · May 12, 2013 at 10:19 PM 0
Share

Well I skimmed your idea. Like I always say this isn't a build your code place. BUT, I do have somethings for you. 1) How good are you at scripting? If you're not great I will help you. 2) When you can make this a forum post, this is a great collaboration project!

avatar image whydoidoit · May 12, 2013 at 11:09 PM 0
Share

So your biggest problem with your approach will be saving and loading these instances between runs of the game. You should consider using a normal class to hold the details of the objects so that this can be easily saved and reloaded.

I'm not sure what language you are using, let me know so I can think of examples.

Do not use a GameObject array, use a List of something actually useful - the only reason to hold GameObject arrays is so you have something to call AddComponent on, otherwise you are just blowing CPU cycles doing .transform or .GetComponent(). Use a List so you can dynamically add and remove things.

avatar image darksider2000 · May 13, 2013 at 02:10 PM 0
Share

@ Negagames: 1) I can't really say how good I am, I wouldn't know. I have faced things that were much more complex in terms of designing the code and bulletproofing it, but I'm always looking for help and advice. 2) I'm not sure I know where to post this on the forums, a little help maybe? ;)

@ whydoidoit: I didn't even think about loading, and you raise a good point there. I'm using strictly C#. I have thought of using a List, but all in all I think I'd still have to use GameObject variables. The project is massive in scale and all the scripts and variables on the items are subject to change throughout the project. I want to create an inventory system that will be "Fire and Forget", so that whenever I make a change to an item's code I don't have to adjust the inventory system accordingly. Also, using GetComponent() on a gameobject allows me to run functions on that object without having to redefine them in the inventory system, that's for items that can change even while in the inventory. (Food spoilage, Devices running out of power, etc.) So I guess it all comes down to how difficult will it be to save my scene if I do go ahead with this method. Unfortunately I know close to nothing about saving & loading, so if you have any pointers, that'd be nice :P

0 Replies

· Add your reply
  • Sort: 

Your answer

Hint: You can notify a user about this post by typing @username

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this Question

Answers Answers and Comments

15 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Related Questions

Crafting system NOT like minecraft 1 Answer

Are there any performance differences between a timer and using Invoke? 1 Answer

Reasonable heap alloc. per second and total ? 0 Answers

inventory for FPS game 0 Answers

Saving My Inventory 4 Answers


Enterprise
Social Q&A

Social
Subscribe on YouTube social-youtube Follow on LinkedIn social-linkedin Follow on Twitter social-twitter Follow on Facebook social-facebook Follow on Instagram social-instagram

Footer

  • Purchase
    • Products
    • Subscription
    • Asset Store
    • Unity Gear
    • Resellers
  • Education
    • Students
    • Educators
    • Certification
    • Learn
    • Center of Excellence
  • Download
    • Unity
    • Beta Program
  • Unity Labs
    • Labs
    • Publications
  • Resources
    • Learn platform
    • Community
    • Documentation
    • Unity QA
    • FAQ
    • Services Status
    • Connect
  • About Unity
    • About Us
    • Blog
    • Events
    • Careers
    • Contact
    • Press
    • Partners
    • Affiliates
    • Security
Copyright © 2020 Unity Technologies
  • Legal
  • Privacy Policy
  • Cookies
  • Do Not Sell My Personal Information
  • Cookies Settings
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Default
  • Help Room
  • META
  • Moderators
  • Explore
  • Topics
  • Questions
  • Users
  • Badges