Para guardar datos para mas tarde cargarlos, partidas guardadas, preferencias del usuario, etc. Cual es la diferencia entre usar playprefs y serializar un archivo.

Hola Siam, hay mucha info y preguntas de esto incluso aca mismo en el foro.
 
PlayerPrefs:
 
- Usado u orientado a.... adiviná ... "preferencias de Usuario", de ahi el nombre:  brillo, contraste, fullscreen, window mode, nombres, ambient occlusion, etc
 
- No orientado a Datos personalizados (Custom Data)
 
- Funciona como una base de datos manejada por llaves, cada conjunto de datos tendra su llave para poder accederlos. Entiendo que los tipos de datos son limitados,( int float strings ?)
 
- Se guardan en un lugar relativo al registro (me parece), entonces depende del SO, no me crees? mira:
 
-----
 
On macOS PlayerPrefs are stored in ~/Library/Preferences folder, in a file named unity.[company name].[product name].plist, where company and product names are the names set up in Project Settings. The same .plist file is used for both Projects run in the Editor and standalone players.


On Windows, PlayerPrefs are stored in the registry under HKCU\Software\[company name]\[product name] key, where company and product names are the names set up in Project Settings.


On Linux, PlayerPrefs can be found in ~/.config/unity3d/[CompanyName]/[ProductName] again using the company and product names specified in the Project Settings.


On Windows Store Apps, Player Prefs can be found in %userprofile%\AppData\Local\Packages\[ProductPackageId]>\LocalState\playerprefs.dat


On Windows Phone 8, Player Prefs can be found in application's local folder, See Also: Directory.localFolder


On Android data is stored (persisted) on the device. The data is saved in SharedPreferences. C#/JavaScript, Android Java and Native code can all access the PlayerPrefs data. The PlayerPrefs data is physically stored in /data/data/pkg-name/shared_prefs/pkg-name.xml.


On WebGL, PlayerPrefs are stored using the browser's IndexedDB API.
 
----
 
 
 
Serializacion en general:
 
- serializas lo que quieras es decir armas cadenas de 0's y 1's, formadas por lo tipos de datos que los elegis vos, habrá algunos que podras serializar otros que no. El serializador en general no es algo de Unity, es algo de mono C#, "System.Runtime.Serialization.Formatters.Binary" entonces no hay definiciones a serializar como "GameObject". Un ejemplo podria ser una escena de Unity, que serializa el mismo motor Unity(no mono C#), todos esos datos Serializados que "van y vienen" cada vez que se actualizan los assemblies, para eso Unity serializa todo lo que debe y cuando vienen los tenes guardados, con la escena ocurre lo mismo. Es decir que todo eso que ves cargado, datos,componenetes, valores, objetos, posiciones, todo eso fue serializado y deserializado.
 
- Se usa generalmente esto para guardar "Custom Data" de tu juego en un archivo. Los juegos comerciales usan este metodo para guardar los datos, revisa en tus juegos seguro en mis documentos (windows), los perfiles y fijate los archivos que hay.
 
EJ: Fallout 4, "..../MyGames/Fallout4" --> "xxxxx".FOS (un Archivo "Save"), si lo abris con un editor de texto te sale algo asi :
 
"ÿÿÿýÿÿÿýÿÿÿýÿÿÿýÿÿÿýÿÿÿýÿÿÿýÿÿÿýÿÿÿýÿÿÿýÿÿÿýÿÿÿ ......"  , (es un binario codificado)
 
- La clase/s a serializar la podes armar vos (de ahi el Custom)
 
- Vos elegis donde guardarlo, no depende (necesariamente) del SO.
 
Otra alternativa entre medio es usar un formato basado en texto, por ejemplo un Xml o JSON, que no tiene nada de seguridad (es modificable) pero si esto no te preocupa con JSONUtility (nativo de Unity) podes guardar tus clases de toda la vida directamente en JSON y cargarlas muy facilmente.
 
Es decir si vas a guardar datos de tu juego no te dejes llevar por el tutorial ese que el tipo lo guardo con playerprefs, tiene limitaciones y nunca deberia usarse para mas de lo que fue creado,
 
Se puede hacer malabares y arreglartelas de alguna forma para el caso especifico tuyo en PlayerPrefs? "posiblemente" si ... pero tambien para que arrancar con una base que no se usa, que es super limitada, y  que fue creada para otros propositos?...Ademas serializacion es bien facil hoy en dia, el serializar/deserializar son 4 a 8 lineas locas (si es que ya tenes tu clase a serializar configurada).
 
Saludos

La otra opción que yo utilizo es la de guardar los datos en un documento XML o incluso los he visto creados en TXT. Lo malo de esto es que la información no estará cifrada, pero puedes cifrarla antes de guardarla y luego leerla con la clave de cifrado.

Cita de: leocub58 date=1503943385La otra opción que yo utilizo es la de guardar los datos en un documento XML o incluso los he visto creados en TXT. Lo malo de esto es que la información no estará cifrada, pero puedes cifrarla antes de guardarla y luego leerla con la clave de cifrado.
   

Lo bueno de eso es que vos te podes hacer tu propio formato de escritura y por ende tu parser para leerlo, entonces no solo si lo queres leer necesitas el cifrado sino el parser, que no responde a ningun formato conocido por que lo investaste vos. Yo tenia mi "level editor" con esto y era muy divertido el proceso, recuerdo que eran 0 y 1 (0 = no hay bloque , 1 = hay bloque), y lo escribia algo asi: "0..1..0..1..0" entonces si no sabes lo de los dos puntos fuiste

Cita de: lightbug date=1503944126Lo bueno de eso es que vos te podes hacer tu propio formato de escritura y por ende tu parser para leerlo, entonces no solo si lo queres leer necesitas el cifrado sino el parser, que no responde a ningun formato conocido por que lo investaste vos. Yo tenia mi "level editor" con esto y era muy divertido el proceso, recuerdo que eran 0 y 1 (0 = no hay bloque , 1 = hay bloque), y lo escribia algo asi: "0..1..0..1..0" entonces si no sabes lo de los dos puntos fuiste

Yo igual, lo hice cuando estaba aprendiendo para hacer un minecraft 2D con generador de mundo automatico jajaja

@lightbug ya me ha quedado claro. Muchas gracias