Question about organizing variable data to avoid Data loss when migrating variables to an exterior source

[IllTemperedTunas]

This has haunted me for a long time now and I spend a SUBSTANTIAL amount of time setting up variable management because of it.

I have several large scripts with MANY variables within them and I have to pick my poison:

1. Have all my variables situated within these scripts causing my inspector windows to balloon to massive sizes and it becomes a total pain to find variables, or I can spend massive upkeep to organization by using OdinInspector conditions to hide and expose certain variables under specific conditions: [ShowIfGroup(“sampleGroup”)].

2. I put my variables elsewhere, but in order to access them my code becomes messier and confusing as I now have to access the outside data.

Example:
var float maxMovementSpeed;

turns into…

public class MovementValues{
public float acceleration;
public float maxMovementSpeed;
}
public MovementValues movementValues;

There are other ways to externalize or organize the variables, but to my knowledge they all require more complex and increasingly confusing setups within the code.

So the question is. Is there a solution that’s the best of both worlds? Where I can unload the variables somewhere else so that my inspector windows don’t turn into massive lists that are hard to find the darned section of variables we want to work on without having to make it harder to access those variables by remembering where they’re linked, and the naming conventions and increasing the length and complexity of code to access them?

My dream would be if #region and #endregion worked within the inspector to allow for collapsible variables, but that isn’t the case.

Edit: I should note that a lot of the values for these variables are not stored within the code, but tuned over time using Unity’s metadata for these prefab assets, so it’s of paramount importance this data not be lost.

[Patrickmol]

Scriptable Objects have several advantages in your situation:

• The inspector of the object holding them will be cleaner and easier to navigate
• The variables will be stored just once for N instances (for example MoveSpeed of enemies)
• ScriptableObjects are saved until deleted so it’s harder to lose the settings for mistake

In order to create a ScriptableObject you need a script:

using UnityEngine;
[CreateAssetMenu(fileName = "MovementValues", menuName = "ScriptableObjects/MovementValues")]
public class MovementValues : ScriptableObject
{
    public float acceleration;
    public float maxMovementSpeed;
}

Now to use the ScriptableObject in a script you just need a reference towards it:

using UnityEngine;
public class TestClass : MonoBehaviour
{
    public MovementValues movementValues;
    void Start() 
    {
        Debug.Log("Acceleration: "+movementValues.acceleration);
    }
}

This is a better solution overall due to Performance Improvement and for your requirements too because you change the settings of your Scriptable Objects using an inspector specifically for them.

[IllTemperedTunas]

So after posting this, inspiration struck while I was watching a dumb YouTube Video (funny how that happens) and I thought of a way to migrate the data without losing it.

It’s not pretty but it gets the job done, and it doesn’t require going variable to variable and changing each one individually by hand to retain the data:

So this is what a small chunk of my code looked like :

A small chunk of variables among many cluttering things up that I wanted to tuck away without excess overhead. Then I created a new class to house the old data, just copy pasted the variables in:

Took a quick video showing how once you have a class container for the old data, you create a function that transfers that data. I used Odin to create a button, but you could also transfer the data at runtime putting the function in Start() and copy the injected data (since it will be lost when you stop the player), press stop on the player and then repasted the values into the class.

Variable Transfer with no Data Loss

Then once the data is instantiated and held in the new external source I use the above mass edit technique to reference the new data location, it is a bit of overhead, but the variables are easily accessed and stored away, I think it’s better than the prior setup I was using where everything was requiring tons of bool identifiers and exposing logic:

This is just a small section of my variables, but I went from the left, to what’s on the right (collapsed and expanded). Gonna take a few days to propagate this cleanliness to the rest of my project, but looking forward to a tidier and easier kept project.

Not sure anyone will see this, but I figured what the heck, might as well share and maybe someone stumbles upon this and they can use it if they’re ever in a similar situation.

[IllTemperedTunas]

I wish I had this advice years ago! Yeah scritpable objects are awesome I need to get in the habit of using them more. Problem is I have so much data and values that i’ve been tuning over the years that aren’t easily transcribed from existing variables and references throughout my project.

Wish I could go back in time and house my important gameplay data now that I know better, but right now i’m in the process of figuring out the easiest means of transferring this data in a cleaner manner.

Also, to my knowledge if I were using scriptable objects it would still require a reference like

maxMovementSpeed => SOMovementValues.maxMovementSpeed;

Was hoping there might be a cleaner means of segmenting up variables within a script without too much extra overhead.