Judging effectiveness is not a thing. If the code works, the code works. Otherwise fix it.
Photographs of code are also not a thing.
If you post a code snippet, ALWAYS USE CODE TAGS:
How to use code tags: https://discussions.unity.com/t/481379
Otherwise, here is how to report your problem productively in the Unity3D forums:
http://plbm.com/?p=220
This is the bare minimum of information to report:
- what you want
- what you tried
- what you expected to happen
- what actually happened, log output, variable values, and especially any errors you see
- links to documentation you used to cross-check your work (CRITICAL!!!)
If you need guidance on loading / saving, here’s some great starting points:
Load/Save steps:
https://discussions.unity.com/t/799896/4
An excellent discussion of loading/saving in Unity3D by Xarbrough:
https://discussions.unity.com/t/870022/6
Loading/Saving ScriptableObjects by a proxy identifier such as name:
https://discussions.unity.com/t/892140/8
When loading, you can never re-create a MonoBehaviour or ScriptableObject instance directly from JSON. 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.
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.
https://docs.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide