0
\$\begingroup\$

I'm building an inventory system with different items classes deriving from a 'Item' base class.

When an inventory slot runs out of the item it holds I want the item to be destroyed. I cannot null the inventory slots reference to it, and I cannot destroy it. How are non-monobehaviour classes supposed to be handled in Unity? Any tips on how I can get rid of the used up item?

Improve this question
\$\endgroup\$
  • \$\begingroup\$ If there's no reference to the object, it will be removed. Why can't you null the reference to it? \$\endgroup\$ – MichaelHouse♦ Feb 12 '14 at 22:04
  • \$\begingroup\$ Sorry my bad. I got some error message about it being non-nullable, but now i dont get it anymore. It should not be a problem since its just a reference. Thanks anyway! \$\endgroup\$ – Daarwin Feb 12 '14 at 22:08
  • 2
    \$\begingroup\$ I guess you can delete the question then. \$\endgroup\$ – MichaelHouse♦ Feb 12 '14 at 22:09
  • \$\begingroup\$ Non-nullable objects may be structs, not classes. They behave differently (non-nullable, pass-by-value instead of pass-by-reference) and may be the source of your trouble. \$\endgroup\$ – PixelArtDragon Feb 12 '14 at 22:20
1
\$\begingroup\$

If you do not wish to subclass MonoBehavior and still wish to Destroy the objects, you should use ScriptableObjects:

http://docs.unity3d.com/Documentation/ScriptReference/ScriptableObject.html

ScriptableObject

A class you can derive from if you want to create objects that don't need to be attached to game objects.

This is most useful for assets which are only meant to store data.

You can call Destroy on them.

If you do not do this, then anything else gets managed by the GC in the same way as any other object in a non-Unity project. Just remove all references to that particular object.

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ Can you explain the point of ScriptableObject? Because the script reference entry doesn't explain why I would bother with ScriptableObject. \$\endgroup\$ – jhocking Feb 13 '14 at 0:52
  • 2
    \$\begingroup\$ "This is most useful for assets which are only meant to store data." - You can call DontDestroyOnLoad on ScriptableObjects to make sure the data they store persists across scenes. The alternative (w/o Unity's objects) would have been to use static data (e.g. via singletons). \$\endgroup\$ – user15805 Feb 13 '14 at 0:55
  • \$\begingroup\$ I suppose that makes sense, although at some point there must have been a MonoBehavior that instantiated the ScriptableObject, so you could just as easily call DontDestroyOnLoad on that originating MonoBehavior and keep a reference to the data object in there (indeed, this is what I do). Is this just another way of accomplishing the same thing, or is there a substantive difference between these two approaches? \$\endgroup\$ – jhocking Feb 13 '14 at 2:28
  • \$\begingroup\$ Unless the original MonoBehavior has relevant behavior that needs to be kept across scenes, it would just sit on top of the data for no reason whatsoever. I'd say using a ScriptableObject in that case is more intuitive. \$\endgroup\$ – user15805 Feb 13 '14 at 2:55
  • \$\begingroup\$ Interesting. Since I'd never heard of ScriptableObject before, I'm just trying to get a handle on whether or not I should start using that in my code. It sounds like it's mostly a stylistic preference, so I'll just keep doing what I've been doing. Thanks though! \$\endgroup\$ – jhocking Feb 13 '14 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.