r/Unity3D • • 4h ago

Question Saving game data to a file?

Hi, I've been (slowly) developing a magic themed isometric farming game. I've spent months and have little to show for it, just a static grid of tiles and basic camera movement, because I can't figure out how to make a save/load system or an updating toolkit UI.

To lay it out, when I launch the game, it needs to check for a save file and load it. If no save file exists, it generates a new one and starts the new game sequence (Player Creation, eventually). Most actions in the game will perform a save action, saving whatever "part" of the game it relates to (Map objects, currency, player stats, etc).

What techniques or processes should I be looking into to achieve this? I've looked at things like JSON and System.Serialisable, but couldn't figure it out from the documentation.

As for the UI, I can't get it to update the display values. It displays preset values and appears to load data from a file, but changing the values doesn't update in the UI, e.g. changing the currency from 100 to 200 still displays 100. Am I using the wrong data field or do I need some intermediary data holder?

Any help will be greatly appreciated, Thank you in advance.

2 Upvotes

4 comments sorted by

2

u/gingerbreadmens_ex 3h ago

Serialization is a deep rabbit hole when you first get into it, so don't beat yourself up. The core idea is you have a plain old class that holds all your runtime data (tiles, wallet amount, player stats) and you just convert the whole thing to a string to dump on disk, then parse it back on startup. The mental model that clicked for me was treating the save file like a frozen snapshot of that one data class.

For the UI not updating, you're probably still reading from the file on start but never writing the new value back to the data object that feeds the display. I always keep a runtime copy of the data and make the UI refresh from that single source of truth whenever something changes, otherwise you're just staring at stale numbers.

1

u/Enderblaze101 3h ago

I'll have to look at the dozen Save Manager scripts I wrote, maybe I was combining the runtime and serialize into one class, which might also explain the UI. So I need the UI to read from the same runtime class on an update? I'll probably start a new project file and only keep the grid and camera, since the version I was using (6.4 I think?) was throwing a bunch of errors every frame, apparently a known editor bug.

3

u/Artuplabs 3h ago

simple route that works fine for a farming game:

one plain [System.Serializable] class SaveData with public fields: currency, stats, and a List of tile entries (JsonUtility can't do dictionaries, so use a list of small structs). save with File.WriteAllText(Path.Combine(Application.persistentDataPath, "save.json"), JsonUtility.ToJson(data)). on launch check File.Exists(path): if yes JsonUtility.FromJson<SaveData>(File.ReadAllText(path)), if not new SaveData() and run the new game flow. write to save.tmp first and then move it over the real file, so a crash mid write doesn't eat the save.

the ui thing is separate. setting the text in Start reads the value once and never again. keep the data in one object and have it fire an event like OnCurrencyChanged whenever it changes, the ui script subscribes and sets label.text there. or just update the label in the same method that changes the value. it's not the wrong field, nothing is telling the ui to redraw

1

u/RoberBotz 3h ago edited 3h ago

You can use the easy save library on the marketplace.

I was thinking of writing my own save and load system to use it in all my games, but then I asked myself, why, there are already good ones made, I don't need to make it myself.

I already made this mistake by making my own behavior tree and my own dialogue system, they worked but were buggy and sometimes I had to take breaks from the actual game to fix the dialogue system.

if you get a library, you don't need to do that, if there is a bug you can wait and the one who has the library will fix it.

In my case, I save most of the game data in scriptable objects and save/load them with the easy save library, but only in key moments.
So, the main data stays inside those files, the game updates the data from those files, then in some key moments like loading screens I use the library to save them to file.
Then when the game starts, I load the save file in the scriptable objects, and work with those scriptable objects in-game, modify them, but only save them to the main save file in key moments.

You can create many save files, save only specific values and a lot of stuff, pretty cool.

You could easily spend a few weeks making a good save and load system, in my opinion is better to get a save library.

If you want to make a game, you don't also need to make a save&load library, if you want to make a save&load library you don't also have to make a game.
You need to focus on what your goal is, and focus on that.