Progress Saving System

Hey,

Starting a thread about the saving and loading system.

I guess things I would think to think about for this would be:

  1. What aspects of the game are persistent

  2. at which times is the player able to save.

  3. Code basis for implementation

I have some experience writing scripts that control and use binary readers and writers that save wanted data to files.

Thoughts?

Would'nt this come much later when we have most of the systems in place so that we know what to save what to leave to the systems in place?

1 Like

Yeah you are right. I think I was just excited and thought I saw this on one of the cards...

I would want to write that package later too.
Simple as PlayerPrefs, but generic, feature rich and with visual inspector :slight_smile:

Yeah, It also doesn't hurt to think about this now as it might require lots of components to be adjusted later on depending on how this works. I try to avoid using player prefs because they are easily editable by users, which could cause game breaking bugs. Much safer to save necessary data into binaries so that most users wouldn't be able to edit.

I always imagine this as a bit of a stretch goal, since I don't know yet how long will the game be. Do we need a progress saving system?

But it would be fun to make. No harm in starting to talk about it!

(PS: I took the liberty to edit the title so it doesn't get confused with the Game Settings)

I have recently made one on github. Here is a link: GitHub - STARasGAMES/Save-System: Save system for Unity game engine. Inspired by Component Save System: https://github.com/AlexMeesters/Component-Save-System

But for this game it’s an overkill.

I could easily develop a lightweight version featuring:

  • Singleton pattern (it’s for beginners as I understand)
  • C# events (or UnityEvents?)
  • JSON serialization (cuz it’s simpler than Binary and easy to understand)
  • Custom inspector editors for saveable components

This is what I use in my prototypes/small games.
It’s a really simple class which takes an object and serializes it (as @Feral_Pug suggested) to the persistent data path.

A trivial example of a save file would be:
6372828--709452--saveExample.PNG

The Serializer would be used by a hypothetical PlayerDataManager to load player’s data when the game boots for the first time and to save data on the disk on OnApplicationQuit or OnApplicationPause.

A trivial example would be:


Why did you make it a generic class?
You can just make a static generic method like this:

public static class SaveUtility
{
    public static void Save<T>(string fileName, T value) where T : new()
    {
        // code
    }

    public static T Load<T>(string fileName) where T : new()
    {
        // code
    }
}
1 Like

Yes you are right.

i suggest using .dat files

and player prefs

Yes, the solution I had in mind was similar to what @kcastagnini laid out. I typically would make classes that are responsible for creating writers and readers and initialize the saving or loading function. And then all classes that have data that need to either be saved or loaded inherit from a class that has functionality for saving and loading. The classes that create the readers and writers then go through an array or list of gameobjects that belong to the parent class of saveable objects and runs calls to the method on them that has the instructions for how to save that class. I have examples of this but nitty gritty is different for every game depending on what you are saving.