Unity MonoBehaviour Objects vs Game Logic

Question

I originally posted this in the Unity Answer Forums yesterday, but haven't gotten any responses as of yet. So I thought I would try my luck here.

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!

Answer 1

The issue I am confused about, is everywhere I look, states that you should NOT use constructors in your classes that derive from MonoBehaviour.

Unity expects to act as a factory for all objects inheriting from UnityEngine.Object, which will include all GameObjects, components, behavior scripts, and so on.

In many cases, the .NET object you interact with is more of a shim for the underlying C++ object that's actually used by the engine. Calling one of these constructors directly will create a .NET object that's orphaned from its C++ internals.

All of this is hidden from view, so that Unity is more accessible to beginners. Instead of saying "Hey, use this factory pattern to build components", they tell you to call AddComponent. So long as you let Unity handle initialization of those objects, all of this is (mostly) transparent and seamless.

So, it sounds like you're thinking about creating some POCO classes to store configuration data. That's fine -- I do it all the time. Just make sure that you maintain a separation between your classes and those native to Unity.