Multiple Save Files

Hello Everyone,
im working on a project that have saves the game and loads. I've already created the save and load system with binary formatter. But this only creating one file save file and everytime i save it rewriting in the same file. Now I want to create multiple save files. and load them individually. please help me with this.
Thanks in Advance
(sorry for my bad english)

 

Two major choices:

1. change the interior shape of the binary data to support an array of saved games in a single file

2. save the same data instead of to a single file (like savegame.dat), to a series of files (savegame1.dat, savegame2.dat)

 

This. There is no special reason to use only one file name. You can name the file whatever you like.

 

Thank you i will give it a try!!

 

Using one file for user data may help to discourage save modding, though obviously it won't stop a dedicated user from doing so. Just a thought-- enjoy those two cents.

 

So, I was wondering, do people use only one save data with Unity or multiple, cause I have the same problem where if I use only one it overwrites itself.... Using multiple might get things crowded, right?

 

It depends on how you want things to function. Save data overwriting itself is normal unless you have some way to distinguish different users using the program. If they're using different Windows accounts on the same computer, then PlayerPrefs already takes care of that for basic preferences, and if they're using the same computer/tablet on the same OS account, then there's no expectation of separation by default.

If you implement your own User Account system in your game, then you can use some identifier that corresponds to that user account- the user account name directly as the filename(s), or just a numbered folder name to distinguish one from the next, etc...

If you're less worried about users and more worried about sequential save states (checkpoints), then implementing some sort of system for managing that is important, but what kind of system you implement is completely dependent on the needs for your game. You could just overwrite a single save file and be done with it. You can increment each new save and pull all of the current save files in the directory and order them by the included datetimestamp, keeping 3 or 5 or 10 and dropping the older ones. You can allow the user to manually specify save files as "slots" that they manage for themselves, and keep a secondary save file for forced checkpoints and possibly even a third file for quicksaves.

 

It really depends on the game type. Sometimes it's best to just jump right in to the file system and let the user save as many games as they like.

 

Hi there,

I'm making a mobile game in which you go from island to island.

Right now, i'm saving every island infoformation on one big .xml but, of course, it lags crazy when I save.

My question is : If I save each 300ish island on a different file, will it cause any issues ( app too big etc... )

Thanks in advance,

Gabriel

 

Seems like a great task to move off to a background thread.

 

@Kiwasi Sorry for responding late, i wasn't notified of your post :

Now my question is, What is a background thread ?

I've done what i intended ( saving each island on a .xml file ) and there doesn't seem to be a problem. Although i'm experimenting some major crash, due to saving, that seem to appear rather randomly.

Have a great day,

Gabriel

 

A background thread is a thread other than main.

 

I see, just as a main thread is a thread other than background.

I checked it out and, sorry, it seems like a big question to answer.
I'll check it out.

 

Modern computers have multiple cores and can do multiple things at the same time. A thread is a way to run a separate task on a different core, without interrupting your main game. Its highly useful for complex tasks that don't need to happen right now. You can carry on doing regular stuff in the main game while the thread works in the background. When its done, you can bring the results back to the main thread.

I would bet on an infinite loop.

 

Thanks a lot @Kiwasi.

I don't think it could be an infinite loop, the freeze ( it's a freeze most of the time ) accurs when the xml file is written.

Looks like multithreading is the way to go, but right now, i've put the save function in a coroutine to see exactly where the freezes appears, the profiler being very vague about it.

Thank, Gabriel

 

Keep in mind there are actually separate things to think about here.

When your data structure instance (or array of instances) is saved as XML (or JSON), two things have to happen:

1. the entire data structure needs to be traversed (using reflection) and serialized into text

2. the resultant text blob needs to be written to a file.

Both of these things can take noticeable amounts of time if your data is large enough.

If instead you break your save data into lots of little pieces (however that makes best sense in your use case), then both of these steps become significantly shorter, as you are not wasting time re-serializing and re-writing the 99.9% of the world that did not change.

All of the above is true regardless of whether you use multi-threading. And multi-threading is not a panacea: certain data structure traversals require thread locking anyway, so if your dataset is large enough, you may still see the pause happen, which is another reason to break things into smaller pieces.

And now for my personal professional opinion on multi-threading: don't do it. Just DO NOT. I watch again and again as highly-trained professional software engineers struggle to get it right, and it is NOT an easy thing to do. The tighter your data is linked to your main thread, the more edge case issues you will see. It is a difficult task to get right.

Personally for what you describe I would never even consider reaching for multi-threading, but instead probably use some kind of breaking-down of the data to reduce the amount of work that has to be done to do a save/load, as long as intra-data relationships allow for it.

Good luck!

 

I've never seen Unity freeze on anything other then an infinite loop.

The profiler doesn't report data until the end of a frame. So if you encounter a freeze and the frame never ends, the profiler never gets the data.

Listen closely to this guy. Multi threading is very easy to get wrong. I wouldn't even consider it until you fix whatever bug is causing your freezes. Debugging multithreaded code is more painful then regular code.

That said, I don't think multithreading should be avoided at all costs. As long as you separate your data structures effectively, you can multi thread safety. In the Unity context, multi threading tends to be about stopping frame stutter, rather then doing the job faster.

 

@Kurt-Dekker Thanks a lot. So i guess breaking my files into multiple parts ( about 200 for me ) is a good idea ( or not completly bad ). And that's all i needed to know.
And thanks for the heads up about XMLs.

I also have a lot of work to do regarding xml optimization. I have neverending arrays of items, and character sheets taht I heard can be broken into bytes. So I'll see if I still get my freezes after that.

Thanks a lot !

 

You should only be saving the difference each time. Ie. Player is at island 1 then save that data. Don’t save the entire state each time.

In terms of save what I do to prevent the state from being corrupted is save to a single file, check it’s integrity and make sure it’s good then I use file copy to make a copy and rename they copy to a new save name. This way I can ensure they I am saving with a single data point and if the save process is interrupted for any reason it will corrupted the savegame and not the state. The state can be resaved etc