The reason we don’t just have a number associated with the stats is because then it makes it really hard to change stuff- which is the reason you’re using something that isn’t just a single float.
You still can’t change the number of stats given retroactively with that kind of system (just as the other method, you can only change the stats) without the backwards compatibility code. Especially if the number of points is random.
I’ll leave it to you to make the backwards compatibility system itself, but I’d recommend using a structure like so:
-
You have an Actor that acts as a Compatibility manager
In the actor, store a list of versions. You only really need to store the ones that have changes. You should also store the last version of the save and the current game version. -
Create an interface with an “Upgrade” function that takes two version identifiers (It should be a number in some way- or multiple numbers).
-
This function should call itself for every version change. Meaning if have version 1.25 and the current version is 1.33, you’ll call Upgrade(1.25, 1.33) from the manager to start it, and that will then call Upgrade(1.25, 1.26), Upgrade(1.26, 1.27), Upgrade(1.27, 1.28), Upgrade(1.28, 1.29) etc. You can check if this is the initial call by checking the distances. If the distance is 1, check the upgrade-to term and switch off it. You only need to implement the branches that actually need a change- maybe only 1.29 was actually changed.
-
In the manager, on load game, use the get all actors with interface node for those with the previously created interface. After that, call the upgrade function on them. Once all have been upgraded, save the game over the previously saved game- of course updating the version before doing so.