Saving and Loading - The Current Plan

[Oafkad]

Outside of naming classes and folders, the next most complicated part of coding for me is the process of saving and loading. This is not because the idea itself is necessarily complicated. You are just saving some information as text (or whatever format you desire) onto your device. The major challenge for me comes in the most convenient way to have data that can be saved and also easily parsed within Unity.

There are also some constraints when saving with Unity. Natively you can't save json strings that feature any content that won't naturally display in the editor. This means that things like dictionaries or multi-dimensional arrays are out. You can, however, create classes that contain the "internal" data of your 2D array and then have a 1D array containing multiple instances of that object. Each featuring unique data. You can think of something like the Moosecats falling into that category. Each index in the array is an object containing all the data of your Moosecat.

And indeed this is likely how it'll work here but with some caveats. The first is that we are not saving to JSON, instead I am taking discrete units of data and converting them into bytes, saving those bytes to the player preferences, and then later gathering them back and converting it directly into the original objects.

  How are we accomplishing this? Well, the more detailed description will be available once I actually finish some of the more complicated collections. But for now we can talk a little bit about the player saving and loading.

  I'm going to use a bit of jargon here and I apologize, I'll do some write ups later on things like interfaces and classes to make it a bit more clear what I'm talking about. But here we go, I've created an interface called IOdinSerializeable, I name all of my interfaces with a leading I and then I try to make it obvious what they are for. In this case, these are classes that implement an interface that allows me to serialize it trivially with Odin Inspector, one of my favorite Unity tools that I recommend you get if you are interested in Unity at all.

  This interface requires you to inform it what "kind" of data you are saving. And with that it can actually handle the IO calls to and from the disk without any additional work on my part. Yay! This means that a line like the following

public class HandlerPlayer : MonoBehaviour, IOdinSerializeable<DatumPlayer>

  Is literally all I need to do to make my player behavior saveable (which I'm noticing is MonoBehavior at the moment, I need to update that to my NotatedMonoBehavior). This will require the implementation of two very simple functions within the class.

public void Load(DatumPlayer data)

and

public DatumPlayer GetSaveData()

You can likely guess what each of these needs to do. But if it is non obvious, the first is how we load our data from disk back into the player. The second is how we get the data off the player for saving to disk. This will scale for any particular asset going forward. When we get to the Moosecats we will likely have a collection of all the kitties. Then I will save and load that entire collection to and from the disk in the same manner.

In this way we've solved the core functionality of saving and loading for all systems going forward. When it saves and loads, and indeed what operations happen as a result of that loading and state update, are not as clearly defined. We will talk about those in a future scratch note, or perhaps something more detailed will end up in another section.