- Home /
MonoBehavior, ScriptableObject and Object memory usage & performance
Hi guys, I have two questions regarding performance and memory usage with the 3 categoeies of classes: - Component (and all children such as Behaviours and MonoBehaviours) - Scriptable Objects - System Objects
Question #1: Is there any gain from combining them for specific tasks or should I only use components?
I was thinking of something along the lines of this (please note that this is merely an example so don't reply with answers like "yeah what you showed there could eb done using structs or xml or whatever", just take them with a grain of salt :) ). Also this question refers only to code, I don't really care about the Editor's Inspector (so serialization shouldn't be an issue of this topic - I think) or anything of the sort. Also, this is not a cliche question on "Components vs SO", it mainly refers to performance and memory :)
Components for any Unity specific game code (either using U3D engine functions or accessing objects\states\behaviours)
(persistent) scriptable objects for asynchronous game flow (I don't mean threads, but things done on request, such as user input, notifications etc.)
System.Object classes for "static" (not keyword-wise, but flow-wise) such as properties and the likes (similar to structs, but with a lot more control)
Example:
public class MyMonoBeh : MonoBehaviour)
{
protected MyScrObj m_pMyScrObj;
protected MySysObj m_pMySysObj;
// ... variables\accessors etc.
// ... methods
}
public class MySysObj : System.Object
{
public MyMonoBeh m_pOwningBeh;
public bool bHasArmor;
public bool bCanFly;
// ... variables/methods etc.
// ... and for example I can access specific changes by calling the owning behaviour
public void AddFlyingEffects ()
{
// call the behaviour object to change to a flying state, add visual effects, sounds etc.
m_pOwningBeh->SetFlying(true)
}
}
public class MyScrObj : ScriptableObject
{
public MyMonoBeh m_pOwningBeh;
// other variables/functions similar to the system object example
}
For example, I was thinking a ScriptableObject could be a weapon; I could have a component that is used for player regulation (such as input) that could detect a "fire weapon" event in an update and call the necessary functions on the scriptable objects. An object could be used for anything that is not supposed to use engine stuff (i.e. .NET runtime) and just helps with the game, flow wise and components, of course, for engine calls or callbacks.
I notice that if I were to design the code using "unity principles" (mostly revolving around components, events and callbacks) I could end up with 30 or more components if I were to make the code 100% modular (f.e. a component handling armor, one handling weapons, one handling inventory, or even each weapon being a component etc.).
A very semi-partial answer was given in this thread, mainly hinting that SOs can handle a lot more than MBs can (but that may also be due to the overhead required or imposed on MBs).
I was wondering about the experiences you guys had by playing around with this.
Question #2 Is there a performance penalty to keeping ScriptableObjects in the scene (they are supposed to be removed once they go out of scope, but if you'd set them as members, they could persist through-out the scene). Side question to this: if I don't declare "void Update()", does this reduce change performance ? (i.e. events\messages that I don't need) or does the engine try to call them anyway and is there no real gain ? Do I hurt the performance if I were to make the event\message methods virtual ? (such as "public/protected virtual/override Update()" )
And lastly, a side question :)
I saw an article discussing readability, code (re)factoring and impact reduction using classes instead of enums (mainly removing all if/switch statements in all of your 99999999999 methods and moving all the logic in the "enum" class): Enumeration classes
Sometimes an enum is not the best idea
What are your thoughts on this ?
Thanks!