No Save!

[renman3000]

Hi,
for some reason my project is not saving data // and or getting data, at start().

I’ve tried Binary and PlayerPrefs (both have been reliable for me historically). I’m wondering if anyone dealt with this? Maybe some setting in the Project Settings?

Thanks!

[lordofduct]

you mention playerprefs and binary, which leads me to believe you’re not referring to the unity serialization of assets, but rather an actual save game implementation you’ve done.

…

Since there are a bajillions ways to implement a save system, you’re going to have to share your code so we know what you did.

[Kurt-Dekker]

There is no inherent way to load / save state in Unity. It’s all on what you wrote or what you bought from the asset store, so it sounds like perhaps you just have a bug / bugs.

Here’s the skinny on load / save:

Load/Save steps:

Loading And Saving

Save system questions

Saving/Loading is never simple. There’s tons of tutorials out there on Youtube to give you an idea of the process. Basically step 1 is identify what needs to be saved. Might just be a single digit, as in “what level am I on?” Might be a lot more: GameObjects, inventories, internal states of running scripts, positions, rotations, etc. Keep in mind the more you save the more debugging and painstaking engineering you’re going to need to do. And it gets really hairy. Step 2 - design a data stru…

An excellent discussion of loading/saving in Unity3D by Xarbrough:

Save system

If you have no experience, it might be best to first use a prebuilt solution like something from the Asset Store, just to learn those concepts and see the limitations in action. Then you can always write your own. At the same time, you can follow a few tutorials. Just a random one that I remember doing: Persisting Objects But, don’t just take any single thing for an answer. Look at multiple approaches, make your own experiments and then apply what you’ve learned to your own project. Maybe at t…

And another excellent set of notes and considerations by karliss_coldwild:

Saving levels in an in-game level editor

Two advices. Keep your code modular. Just because your objects have some unique scripts and runtime behavior, it doesn’t mean that the data you need to serialize is different. For example you might have a bunch of different button like objects: a button on a wall, pressure button on floor, switch requiring a key. They might each have different scripts attached for handling the activation of them (using keyboard, stepping on, using interact button while having a key). But they all have a common…

Loading/Saving ScriptableObjects by a proxy identifier such as name:

Use the JSON serilization for ScriptableObject with asset fields in Editor and Build

We trivially work around this as follows: we recognize that ScriptableObjects cannot be serialized. we put ALL ScriptableObjects of a given type in a single directory to enforce name uniqueness we make a Repository object to retrieve these ScriptableObjects by name we modify our serializable structures so they: ----> don’t serialize the SO itself ----> they serialize the name of the SO ----> they load the SO as a reference and look it up You cannot use Unity’s “lite” JSON imple…

When loading, you can never re-create a MonoBehaviour or ScriptableObject instance directly from JSON. Save data needs to be all entirely plain C# data with no Unity objects in it.

The reason is they are hybrid C# and native engine objects, and when the JSON package calls new to make one, it cannot make the native engine portion of the object, so you end up with a defective “dead” Unity object.

Instead you must first create the MonoBehaviour using AddComponent() on a GameObject instance, or use ScriptableObject.CreateInstance() to make your SO, then use the appropriate JSON “populate object” call to fill in its public fields.

If you want to use PlayerPrefs to save your game, it’s always better to use a JSON-based wrapper such as this one I forked from a fellow named Brett M Johnson on github:

https://gist.github.com/kurtdekker/7db0500da01c3eb2a7ac8040198ce7f6

Do not use the binary formatter/serializer: it is insecure, it cannot be made secure, and it makes debugging very difficult, plus it actually will NOT prevent people from modifying your save data on their computers.

Deserialization risks in use of BinaryFormatter and related types - .NET

[Ryiah]

@Kurt-Dekker

Do not use the binary formatter/serializer: it is insecure, it cannot be made secure, and it makes debugging very difficult, plus it actually will NOT prevent people from modifying your save data on their computers.

https://docs.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide

Additionally it’s been completely removed in recent releases of .NET which Unity will eventually be using once they finally finish the upgrade to the scripting runtime. If you want binary serialization Unity provides a package with support for it.

Ideally you shouldn’t use PlayerPrefs either because for some reason they thought it was a good idea to have it store data in the system registry on Windows. On every other platform it’s fine, and in the case of WebGL likely the only approach to saving data locally (albeit it will disappear if the user clears their privacy data).

https://docs.unity3d.com/Packages/com.unity.serialization@3.1/manual/index.html

[renman3000]

@All
UPDATE: So it appears the one step I needed to take was to (at Start), force/make the Progress Binary null, and then retrieve it. My bet is it was holding onto an object which was not updated.

THANKS