Dale un pescado a un hombre y lo alimentarás por un día. Enseña a un hombre a pescar y lo alimentarás toda la vida. - Proverbio chino
Podría preguntar qué tipo de almacenamiento de datos debería usar para mi proyecto real, pero quiero aprender a pescar , por lo que no necesito pedir un pescado cada vez que comienzo un nuevo proyecto.
Entonces, hasta que usé dos métodos para almacenar datos en mi proyecto ajeno al juego: archivos XML y bases de datos relacionales. Sé que también hay otro tipo de base de datos, del tipo NoSQL . Sin embargo, no sabría si hay más opciones disponibles para mí, o cómo elegir en primer lugar, aparte de elegir una arbitraria.
Entonces la pregunta es la siguiente: ¿Cómo debo elegir el tipo de almacenamiento de datos para un proyecto de juego?
Y estaría interesado en el siguiente criterio al elegir:
- El tamaño del proyecto.
- La plataforma objetivo del juego, así como la plataforma de desarrollo utilizada.
- La complejidad de la estructura de datos.
- Portabilidad de datos agregada entre muchos proyectos.
- Se agregó2 el uso de datos simultáneos entre diferentes proyectos. (es decir, datos de usuario)
- Se agregó con qué frecuencia se debe acceder a los datos
- Se agregaron múltiples tipos de datos para una misma aplicación
- Configuración agregada2 con almacenamiento de datos múltiples.
- Cualquier otro punto que considere interesante al decidir qué usar.
EDITAR Sé sobre ¿Sería mejor usar XML / JSON / Text o una base de datos para almacenar el contenido del juego? , pero pensé que no abordaba exactamente mi punto. Ahora, si me equivoco, me mostraría el error en mis formas.
EDIT2 Agregó algunos puntos más que consideraría relevantes. Además, me interesaría saber qué otras opciones están disponibles, aparte del almacenamiento de archivos planos y la base de datos relacional. ¿Qué pasa con la base de datos no relacional, por ejemplo? ¿Cuándo es relevante usar dicha base de datos sobre las otras opciones mencionadas anteriormente?
Respuestas:
Su pregunta es realmente amplia debido a la gran cantidad de géneros que existen, pero aquí está la perspectiva de un desarrollador de software profesional.
Proporcionó una lista de criterios que desea utilizar para determinar qué mecanismo de persistencia de datos utiliza. Esos fueron:
Primero debemos establecer qué opciones están disponibles para nosotros. Como no especificó un idioma o tecnología, es difícil decir exactamente, pero probablemente esté tratando de decidir entre XML y el almacenamiento de bases de datos relacionales .
Una distinción importante es que XML no es realmente un mecanismo de almacenamiento , sino una técnica de serialización. Es una forma de representar estructuras en memoria para tu juego. Teniendo en cuenta eso, realmente estás hablando de archivos planos versus almacenamiento de bases de datos relacionales . Estas no son las únicas opciones, pero son las más comunes, así que las voy a usar.
Para archivos planos:
Para bases de datos:
EDITAR: Usted preguntó sobre otros tipos de mecanismos además de los archivos y las bases de datos relacionales. El único otro tipo notable de base de datos que he visto utilizar regularmente son las bases de datos "estilo Berkeley", que se basan esencialmente en valores clave. Estos tienden a usar árboles B para estructurar los datos, por lo que las búsquedas son rápidas. Estos son excelentes para la búsqueda de configuración / configuración donde sabes exactamente lo que quieres (por ejemplo, dame todos los datos de telemetría para "Nivel 1").
Ahora que tenemos todo lo básico fuera del camino, veamos algunos de sus criterios.
El tamaño del proyecto.
Algunos pueden estar en desacuerdo, pero el tamaño de su proyecto no necesariamente tendrá un gran impacto en su mecanismo de persistencia de datos. Deberá crear una biblioteca reutilizable de funciones que almacene / cargue datos desde cualquier mecanismo que desee. Incluso sugeriría implementar una capa de abstracción (consulte el patrón del Adaptador ) para que pueda cambiar fácilmente su mecanismo de persistencia si lo necesita.
Dicho esto, para proyectos pequeños, el uso de XML en el sistema de archivos puede funcionar bien, pero querrá abordar algunos de sus problemas de seguridad (es decir, el cifrado) para que los jugadores no puedan cambiar los datos a voluntad.
La plataforma objetivo del juego.
La plataforma tampoco será un gran problema. Debería estar más preocupado por su plataforma de desarrollo que la plataforma de destino. La razón de esto es que algunos lenguajes manejan ciertos tipos de marcado o bases de datos mejor que otros listos para usar. Eso no quiere decir que no pueda usar ninguno de los anteriores en casi cualquier idioma, pero a veces es mejor usar las herramientas compatibles que están disponibles para usted. Cualquier plataforma admitirá archivos planos y analizará XML, pero en las plataformas móviles es posible que desee considerar la serialización binaria si es posible, o al menos optimizar su XML para el almacenamiento.
La complejidad de la estructura de datos.
Esto es algo complicado. Las bases de datos relacionales son excelentes solo para eso ... almacenar entidades y sus relaciones. Tiene una mejor capacidad para imponer la estructura utilizando un repositorio de almacenamiento relacional que con los archivos en un sistema de archivos. Considere los tipos de relaciones entre sus entidades, así como la frecuencia con la que las cambia o encuentra entidades relacionadas. Para estructuras extremadamente complejas, sugeriría ir a la ruta de la base de datos.
Portabilidad de datos entre muchos proyectos.
Cuando se trata de portabilidad, debe considerar el hecho de que las bases de datos son naturalmente más pesadas que los archivos. Hay gastos generales de instalación y configuración, habrá diferentes bases de datos disponibles para diferentes plataformas, etc. SQLite es una muy buena forma de evitar esto. Sin embargo, cuando se trata de portabilidad, es probable que tenga un tiempo más fácil con soluciones basadas en archivos como XML.
EDITAR: Hay algunas otras preocupaciones que mencionó sobre la portabilidad en uno de sus comentarios. En última instancia, no desea que sus datos se acoplen demasiado a ningún producto o tipo de archivo. En última instancia, es mejor si puede almacenar datos de stock (niveles, enemigos, etc.) en algún tipo de formato abstracto (archivos delimitados por tabulaciones, XML, etc.) que pueda analizar y almacenar fácilmente en una base de datos / sistema de archivos al compilar o cargar hora. Esto significa que puede cambiar su mecanismo de almacenamiento por un capricho y simplemente reescribir la pieza de análisis.
¿Con qué frecuencia se debe acceder a los datos?
Gran cantidad de acceso a datos significa muchas E / S a menos que tenga algún tipo de mecanismo de almacenamiento en caché. Las bases de datos mantienen estructuras en la memoria y son excelentes para la manipulación y recuperación de datos. Si realmente persiste en los datos constantemente, es posible que desee quedarse con una base de datos.
Múltiples tipos de datos para una misma aplicación
El volumen es ciertamente una consideración, pero a menos que esté hablando de la persistencia de miles o millones de objetos, el sistema de archivos seguirá siendo aceptable como solución.
Tipo de juego
El tipo de juego que estás construyendo puede tener una gran influencia en la plataforma que elijas. Sí, para la mayoría de los juegos de un solo jugador para clientes, estarás bien usando una solución basada en un sistema de archivos comprimido o encriptado. Sin embargo, si estás hablando de juegos con un componente en línea, sería una locura. Siga la ruta de la base de datos y ahórrese el dolor de cabeza. Deje que el servidor administre todos sus datos utilizando un clúster de fondo.
Espero que algunos de estos comentarios ayuden. De ninguna manera es completamente integral, y tomar la decisión depende de ti, pero mi comentario debería darte algunas cosas en que pensar.
EDITAR: Hay algunas veces en que adoptar un enfoque híbrido tiene mucho sentido. Por ejemplo, supongamos que está desarrollando un MMORPG. En el lado del cliente, puede almacenar datos en caché sobre otros jugadores en una base de datos no relacional (como se mencionó anteriormente). En el lado del servidor, está almacenando todos los datos del juego en una base de datos relacional para mantenerlos. Y, de nuevo, en el lado del cliente, probablemente esté almacenando datos de registro, datos de configuración, etc. en archivos XML / planos para facilitar la accesibilidad.
Otro póster también mencionó que a veces es bueno, incluso si está almacenando datos para la producción en una base de datos, tener una forma de usar archivos planos para el desarrollo ... puede ser más fácil eliminar otro producto de la mezcla .
fuente
Últimamente me he visto limitado por la rigidez / dificultad de agregar a bases de datos relacionales. Me encantaría explorar bases de datos basadas en documentos (por ejemplo, couchdb), ya que parecen muy adecuadas para juegos, estado y flexibilidad. Pero no es realmente práctico configurar múltiples tipos de bases de datos para un proyecto pequeño. Como resultado, he configurado un truco similar a usar un campo de blob binario en ciertos campos de la base de datos.
Lo que estoy haciendo es usar datos codificados con json en la base de datos y un contenedor que convierte los datos en json y los retira cuando sea necesario. Por lo tanto, un perfil de caracteres básico podría verse así en la base de datos:
{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}Json sigue siendo agradablemente legible en la base de datos, por lo que si está trabajando al descubierto con el sql y, a veces, también accede a la base de datos directamente, se puede modificar manualmente si lo desea.
Ahora, todo eso es un truco, y no recomiendo copiarlo, pero este es el punto general: no confíes solo en un sistema. Use una base de datos relacional y falsifique el sistema. O utilice dos tipos diferentes de sistemas de almacenamiento de datos (por ejemplo, archivos planos y bases de datos relacionales), para que pueda obtener el mayor beneficio de ambos. No importa lo que la gente sugiera, o con qué sistema vaya, más adelante encontrará circunstancias en las que otro enfoque funcionaría mejor, así que prepárese para agregar una alternativa y ver a dónde lo lleva.
fuente
En el gen RTS, los datos del juego se han almacenado en archivos.
Las unidades y atributos se han almacenado en archivos INI o XML u otros formatos basados en texto, y los modelos han sido una mezcla de formatos binarios o incluso basados en texto, y las texturas y sonidos y otros medios en formatos convencionales. A veces ha estado en un contenedor que tiene una encriptación cruda: me viene a la mente el formato mixto de Westwood. Pero esto es principalmente una ofuscación: si miras dentro de ellos, son solo archivos normales en formatos fáciles de manejar.
Con el advenimiento del juego en línea, se ha vuelto cada vez más común que los datos del juego se aprovisionen después de la instalación a través de Internet, aunque a menudo esto todavía se almacena en el sistema de archivos.
fuente
¿Por qué usar un método de almacenamiento de datos?
En la mayoría de los casos, el juego que lanzas al mundo no necesita la misma funcionalidad de almacenamiento de datos que el juego necesita durante el desarrollo.
Aquí hay una comparación de algunos requisitos de lanzamiento / desarrollo: -
Entonces, idealmente, definiría una interfaz para su módulo de carga de datos y luego crearía múltiples versiones, cada una adaptada a sus necesidades específicas.
En un proyecto en el que trabajé hace muchos años, la carga de datos de nivel del CD tomaba demasiado tiempo (tampoco el HD no era genial). Entonces se me ocurrió lo siguiente. Tenía tres métodos para cargar datos de nivel:
Esto redujo los tiempos de carga de minutos a segundos.
fuente