Is it bad form to store around 800-1000 different arrays in the PlayerPrefs as a means of saving data? Each array would be changed into a string of numbers seperated by commas in order for there to be less varables.
I am still pretty new to programming, so the only way I know how to easily save data in Unity is through PlayerPrefs, that is why I would be inclined to use it for storing the said data. However, if it is really bad form to do something like that, I would prefer to use some other means of saving data, provided it is not hard to learn and would not slow my code down too much. What do you guys think?
Yes, it is bad form - PlayerPrefs simply isn’t designed for that amount of data. You’ll get performance issues, and the PlayerPrefs database isn’t necessarily reliable - it’s not so bad if your game forgets your player had it muted, it’s another story entirely to lose his entire game. As the name suggests, it’s meant for preferences and settings, not everything.
Use this instead. Setting it up requires a little more nuance than PlayerPrefs, but it’ll actually save you time in the long run, while giving you more control, better performance, and more reliable data.
I am not completely done watching the video, but the video-maker has started talking about saving to and loading from a binary file. In the game I plan on making, I would want to save to and load different bits of information from that file during and in-between scenes as the game runs. Is there a more efficient way of doing that or is the binary file way plenty efficient? I just ask because a file with binary code invokes an image in my mind of compiling a bunch of stuff for some time, although that’s probably the wrong idea in this case right?
I don’t think it’s bad form, if it works with the data sizes you are dealing with. I have a 43-game Unity app that writes 43 separate UU-encoded strings that total 920kb in size when streamed to their respective keys in PlayerPrefs.
Mac, Win32 and iOS works fine with this. I have not tried it on the Android platform yet but I suspect it will work too.
Addressing anyone’s complaint about why I chose this method, these are opaque blobs of game state tables that come back from an underlying native C/C++ game library. Nothing on the Unity side cares what is in them, they simply are produced by the native library when the game exits, and the game wants it back when I start up again, and this method works just fine for me: it is performant enough, easy to debug and requires no special-case “where is your static data directory” type code.
I think I like the way the file saving method sounds a little better now, because it seems more organized to me than using the PlayerPrefs. Plus I am eager to learn something new like this
Ok, finished the video, I have another question about good/bad form now :p. Is it bad form to create several different files called “galaxy0.dat” and “galaxy1.dat” and “galaxy2.dat”, etc for 3-8 different “galaxies” where the number varies each game? Doing something like that would make the data in my game a lot more manageable.
You might want to look into some kind of semi-structure data storage like JSON too. It can help you greatly when you are debugging if you can study the save data in a text editor and make changes to it in the text editor, which can be VERY handy for tracking down strange issues with data serialization.
Also, don’t worry too much about form. Worry about writing code you can debug and understand yourself, and then challenge yourself a week later to look at your code and explain (perhaps to your dog) what you did and why you did it. The act of explaining what you did a week later will help you improve.
As you go about making games and “things,” begin to get a feeling for issues such as performance, repeatability, testability, etc., and you will soon develop a good feeling for what is “poor form.” If you spend too much time worrying about form, you won’t finish the games.
