koobas.hobune.stream
Unity MonoBehaviour Objects vs Game Logic
So I'm somewhat of a noobie to Unity. I've dabbled in it since Unity 3, but never actually made anything constructive or worth mentioning. I've been a C#, ASP.NET, and JAVA programmer by career for more than 5 years after graduating with my degree in Computer Science. So I want to throw out there that I do understand OOP. So hit me what the hard-truths here.
My question is such that I want to know standard practice when creating a hierarchy of classes and how they should extend or tie into MonoBehaviour classes.
Here is my particular situation in a hierarchy:
IPickupable (interface) > Item : Monobehaviour, IPickupable > Weapon : Item, IEquipable (interface) > Sword : Weapon
This is what I have now. I am putting MonoBehaviour at the bottom most layer in my class structure, such that when I create a new Sword() object, I must use Start().
The issue I am confused about, is everywhere I look, states that you should NOT use constructors in your classes that derive from MonoBehaviour. Well, when I create my dictionary of items from my database, I want to create a bunch of instances of swords for example, and store them in a collection. This is all happening in code and nothing is actually being rendered on screen or happening in the game yet.
Would it be more beneficial to build my class structure such that all game logic is contained within normal classes--then have a top level class which uses my top most logic class. For example, my example above would change to something like this:
SwordObject : Monobehaviour private Sword sword;
In this way, my actual script that would be attached to a GameObject would still have access to all of the sword methods and data members, but my classes can be instantiated whenever and however I want.
I'm currently fighting with demons on how to go about this, and thought I would see if more experienced programmers with Game Logic and Unity could help me out with some best practices. I am a business logic programmer and only deal on a daily with accounting issues, APIs, mobile development, and web design, so game logic is all new to me. Thanks for your help, insight, suggestions, and feedback in advance!
An old question, but it sounds like what you're looking for is ScriptableObject, a built-in Unity class purposely designed for shared/data/model objects, like inventory items. In the hierarchy you've described, ScriptableObject would be Item's superclass, not MonoBehaviour.
In that scenario, MonoBehaviour would likely be some kind of Item Controller, attached to say, a player-character GameObject (or inventory shop, scene controller, etc.), and holding a reference to that collection of items you mention. Your game logic then could either be placed in the Sword/Weapon/Item hierarchy, or in the Item Controller/MonoBehaviour, your choice.
Besides support for "smart" serialization by Unity, ScriptableObject also plays nicely with the AssetDatabase and with the Editor/Inspector. There's a good live-training session covering it's use - https://unity3d.com/learn/tutorials/modules/beginner/live-training-archive/scriptable-objects
