estado del juego de guardar / cargar?

cuál es el método o algoritmo más utilizado para guardar el estado del juego (perfiles), archivos de texto de bases de datos, cómo funciona el cifrado y cosas relacionadas.

He visto a César IV usar mySQL.

alguna sugerencia.

Estoy bastante seguro de que con mayor frecuencia se realiza en un formato propietario (binario), simplemente escribiendo cada variable de cualquier estructura de estado del juego que use en un archivo, o leyendo ese archivo nuevamente en una instancia de la estructura. En C ++, por ejemplo, puede tratar un objeto como una matriz de bytes y simplemente fwrite () en un archivo, o fread () desde el archivo y devolverlo a su forma de objeto.

Si está utilizando Java u otro idioma, puede optar por utilizar la serialización para hacer la tarea realmente fácil. La explicación de Java está al final de esta respuesta; otros lenguajes (de nivel superior a C ++) seguramente también tienen sus propias bibliotecas de serialización o funciones integradas, que debe optar por usar. No importa cuán ineficiente pueda ser la rutina de serialización, el espacio en el disco duro hoy en día es barato, especialmente cuando el estado del juego no debería ser muy grande, y le impide escribir y mantener sus propias rutinas de serialización.

A pesar de todo debe no usar MySQL (acaba de leer la primera frase de esta revisión ). Si realmente necesita una base de datos relacional por alguna razón, use SQLite ; Es un sistema de base de datos ligero y existe en un único archivo de base de datos. Pero para la mayoría de los juegos, las bases de datos relacionales no son el camino a seguir, y las compañías que intentan usarlas generalmente terminan usándolas como una tabla de búsqueda de valor clave en lugar de una verdadera base de datos relacional.

Cualquier tipo de cifrado de archivos de disco local es solo ofuscación ; cualquier hacker solo rastreará los datos justo después de que su programa los descifre. Personalmente estoy en contra de ese tipo de cosas, ESPECIALMENTE con juegos de un jugador. Mi opinión es que los propietarios del juego (clientes que pagan, claro está) deberían poder piratear el juego si así lo desean. En algunos casos, puede crear un mayor sentido de comunidad, y se pueden desarrollar "mods" para su juego que atraigan a más clientes hacia usted. El ejemplo más reciente que viene a la mente es el mod Portal en Minecraft que se lanzó recientemente. Está publicado en sitios de noticias de jugadores en todo Internet, y puedes apostar que aumentó las ventas de Minecraft.

Si por alguna razón estás lo suficientemente loco como para usar Java para el desarrollo de juegos como yo, he aquí una explicación rápida de la serialización en Java:

Mantenga todos sus datos de estado del juego en una clase, haga que la clase sea serializable mediante la implementación Serializable, use la transientpalabra clave si combina variables instanciadas especiales en la clase (los objetos transitorios no se serializan), y simplemente use ObjectOutputStreampara escribir en el archivo y ObjectInputStreamleer desde el archivo . Eso es.

Si está escribiendo su propio código, digamos en C ++, puede usar archivos binarios. Los archivos binarios le brindan una forma de cifrado a través de la ofuscación. Pero como se documenta en todas las redes, esa es una forma de seguridad muy débil.

O bien, puede usar algo como RapidXML si desea una solución legible para humanos.

Si está utilizando algún tipo de marco, consulte sus funciones de soporte de archivos. HTH

La mayoría de los juegos que he visto solo usan código escrito a mano para leer / escribir desde archivos binarios. A menudo, el formato en disco será una réplica exacta del diseño de memoria de un objeto, por lo que la carga es solo:

1. Leer el archivo en la memoria.
2. Transmitir puntero al búfer al tipo de objeto.

Es rápido, pero es una tarea difícil de mantener, específica de la plataforma e inflexible.

Últimamente, he visto un par de juegos que usan SQLite. A la gente con la que he hablado parece gustarle.

La serialización se menciona en algunas de las otras respuestas, y estoy de acuerdo en que es una solución razonable. Sin embargo, una forma en que falla es en el versionado.

Digamos que lanzas tu juego y la gente lo juega y crea algunos juegos guardados. Luego, en un parche posterior, desea corregir un error o agregar algunas características. Si utiliza un método de serialización binario simple y agrega un miembro a sus clases, es posible que su serialización no sea compatible con los juegos guardados antiguos cuando los clientes instalan su parche.

Entonces, sea cual sea el enfoque que uses, ¡asegúrate de pensar en este problema antes de lanzar el juego por primera vez! Los clientes no estarán contentos si tienen que comenzar de nuevo después de aplicar un parche.

Una forma de evitar esto es hacer que cada tipo de datos básicos implemente los métodos Guardar (versión) y Cargar (versión) que sean lo suficientemente inteligentes como para saber qué datos guardar y cargar para cada versión del juego. De esa forma, puede admitir la compatibilidad con versiones anteriores de sus juegos guardados y fallar con gracia si un usuario intenta cargar un juego guardado desde una versión más nueva del juego de la que está ejecutando.

Si puede usar el mismo formato que usa para almacenar sus niveles, es una ventaja.

Por ejemplo, un juego como Peggle podría tener un diseño de tablero inicial, número de bolas, puntaje actual (0 para el tablero inicial), etc. Luego, un juego guardado puede usar exactamente el mismo formato.

¡Si usa el mismo formato, el juego guardado y la carga de nivel pueden compartir el código, facilitando su trabajo!

Para un juego con archivos de mapa realmente grandes, la partida guardada puede incluir el archivo de mapa por referencia. Los archivos de nivel inicial podrían hacer lo mismo, incluso, lo que hace que volver a ese mapa también sea más fácil si por alguna razón la historia hace que el personaje regrese al mismo lugar, excepto que algunos de los NPC están muertos y hay cadáveres que yacen todos terminado.