Let me bring the simplest example i can. GameObject “A” has the following component:
public class Life : MonoBehaviour
{
private float _currentMaxHealth;
private float _currentHealth;
[SerializeField] private LifeData _data;
private void Awake ()
{
_currentMaxHealth = _data.BaseMaxHealth;
_currentHealth = _currentMaxHealth;
}
public void Recover () {}
public void TakeDamage () {}
}
And this is the ScriptableObject referenced called LifeData:
[CreateAssetMenu (menuName = "Scriptable Objects/Life Data")]
public class LifeData : ScriptableObject
{
public float BaseMaxHealth = 0;
}
In my project i would create a folder for each GameObject and it’s “Component’s Persistent Data”, for example a folder called GameObject A contains the LifeData, a folder called GameObject B contains LifeData and AttackData and so on…
What i don’t know is if having that many instances of ScriptableObjects can be an issue on the long run, so i ask in case someone can give guidance or has tips for a better approach.
Only a potential organizational nightmare.
Thanks for answering GroZZleR, a potential organizational nightmare sounds… bad!
Would appreciate if you could elaborate it further or give some tips.
My hierarchy looks like this:
Folder PrefabsData:
Then the Prefabs Components reference that data.
You shouldn’t have any real performance implications between using one or ten different SOs to store data, so I wouldn’t worry about that just yet. I’d be more worried about how tedious managing such small chunks of data as separate files would be and how quickly it will clutter your project. If you have a hundred NPCs, you could easily reach a thousand or more SOs: 100 LifeData, 100 AttackData, 100 MovementData, 100 LootData, etc.
You’ll also need to invest heavily into editor scripting too, or even the simple act of creating an NPC would be a complete and utter nightmare: Navigate to folder → Create SO for LifeData → Navigate to a different folder → Create SO for AttackData → Navigate to a third folder → Create SO for MovementData → Navigate to a different folder → Create prefab → Add scripts → Find the right SO in the project → Link it → Oops I forgot to make a LootData for it → Back to a different folder → Create the SO → Back to the prefab → Link it → Repeat a dozen more times. You’d definitely want to automate all of that.
What’s the advantage of pushing static data onto so many SOs instead of putting it on the Life component on the prefab in the first place? What’s the goal there?
One problem I see with this is how hard it would be to change these static data for the game designer. Usually you would want to be able to change these values constantly to balance the game, so this would be a nightmare. I would just put all of them in one place, and maybe even connect them to a google sheet so that it would be possible to change them without touching Unity.
You both bringed more important hassles than the benefits i saw from my approach for sure.
This all came from “feeling the need”, which i’m not sure where it came from, of separating persistent data from dynamic data.
I appreciate the answers, thank you.
You should separate the persistent data from dynamic. But I wouldn’t worry about it early on, until you have a concrete plan on which data is actually something that needs changing and what can be just set as a constant in code. What you are doing is just over-engineering a system that will probably just work against you later on.