¿Sería mejor usar XML / JSON / Text o una base de datos para almacenar el contenido del juego?

Estoy considerando cómo implementar un juego basado en componentes, ya que parece ser lo mejor y me gusta la idea de un diseño tan flexible. Una de las características de dicho diseño es que agregar cosas nuevas al juego puede hacerse a través de datos, a menudo presentados como carga de contenido a través de archivos de texto como XML. Esto tiene la ventaja de ser legible y fácilmente editable en cualquier editor de texto. En el lado negativo, el texto puede ser más lento de manejar y debe administrar una gran colección de archivos de datos. Formatos similares basados ​​en texto como JSON o archivos de configuración tendrían beneficios similares.

Por otro lado, hay pequeñas bases de datos portátiles como SQLite o Tokyo Cabinet. Si bien no son directamente legibles para los humanos, estos archivos son fáciles de interactuar, e imagino que de todos modos sería preferible algún tipo de herramienta de edición para el diseño de contenido del juego. El uso de una base de datos permite un almacenamiento consistente de información de configuración y una recuperación fácil. También puede serializar datos en una base de datos para guardar juegos.

En cuanto al rendimiento, creo que generalmente XML es más rápido para archivos pequeños, pero una base de datos escala mejor a grandes cantidades de datos. Me imagino que cualquier juego real tendrá muchos objetos de juego.

Entonces la pregunta: ¿Cuál es el enfoque preferible? Me estoy inclinando hacia la base de datos, pero quiero saber si hay errores ocultos o ventajas realmente fuertes para los archivos de texto. O si hay otras alternativas además de estas (¿serializar a formato binario, supongo?)

Es posible que no surja tanto para un juego personal pequeño, pero un problema difícil cuando se trata de datos del juego es la edición / versionamiento multiusuario. Usamos una gran cantidad de pequeños archivos de texto que se reducen a una pequeña cantidad de blobs binarios mediante un proceso de compilación. Esto hace la vida más fácil para los diseñadores, ya que tienen mucha flexibilidad en su flujo de trabajo. CCP, como ejemplo contrario, utiliza una base de datos de edición central a la que se conectan todos los diseñadores. Esto hace que el paso de compilación sea innecesario (o al menos mucho más simple), pero significa que debe implementar todas las funciones de versiones y flujo de trabajo usted mismo, por lo que seguramente serán más simples que otras herramientas. En cualquier caso, puede lidiar con el rendimiento, por lo que la verdadera pregunta es qué desea para un flujo de trabajo de diseñador y cómo puede llegar allí.

JSON es muy ligero y fácil de entender. Creo que es más adecuado para un juego. cJSON es realmente agradable. también se incorporará a su fuente de la misma manera que lo hace SQLlite.

Los archivos XML son más difíciles de editar para los usuarios de lo que piensas. si va por esa ruta, es posible que desee crear un editor para que la gente lo use para ayudarlos a evitar las trampas comunes.

Llegué tarde a la fiesta aquí, pero pasé MUCHO tiempo investigando esto.

Primero, por qué no uso lo siguiente:

XML: excesivamente detallado. Toneladas de redundancia. Repetir nombres de campo? BRUTO

JSON Creo que JSON es excelente para un diseño de interfaz de usuario, pero para una base de datos, demonios no. Tendrá los mismos problemas que XML, redundancia y anidamiento profundo. BRUTO.

SQL : esta es una gran opción, si manejas los dolores de cabeza de configurarlo. He creado juegos móviles donde almacenamos los datos del juego en línea en una base de datos SQL. El formato de la tabla es agradable. El problema era que teníamos que buscar la base de datos en línea y configurarlo puede ser una molestia. Pero SQL es una solución decente. Unity no admite esto de forma nativa, y los complementos que probé tenían problemas importantes (especialmente cuando intentaba que funcionara con el control de versiones).

Finalmente, aquí está la solución que opté por usar (y me encanta).

CSV : simple. Me permite usar el formato de tabla, y tengo un punto de referencia fácil cuando necesito actualizarlo. Puedo tener una tabla para todas mis armas, columnas para todos los atributos y filas para cada tipo de arma.

Puede usar Microsoft Excel pero escupe estas estúpidas advertencias cada vez que necesita guardar. Puede usar macros para anularlo, pero le digo ahórrese el problema y obtenga LibreOffice . Es gratis, admite la edición CSV, y cuando abre el archivo carga el ancho de la columna para que coincida con el nombre (Excel no hace esto y me volvió loco).

Entonces solo necesitas analizar los archivos CSV en tu juego. Uso Unity, así que todo lo que tenía que hacer era usar este ingenioso analizador C # CSV que encontré:

Ejemplo de analizador CSV

Convierte los archivos CSV en tus objetos de datos del juego y listo. Con Unity puede convertirlos en ScriptableObjects . Entonces, mi flujo de trabajo es: Actualizar CSV -> Analizar CSV en Objetos con secuencias de comandos -> Usar datos de ScriptableObjects para mi juego

La respuesta a esto depende del idioma que esté utilizando para el juego.

Si está utilizando C ++, le recomendamos que use una de las bibliotecas XML existentes (como TinyXml o eXpat ).

Por otro lado, si estaba usando PHP, podría usar fácilmente un servidor de base de datos como MySQL o SQLite. (Tenga en cuenta que si sigue esta ruta, necesitará más recursos porque el servidor de la base de datos se ejecutará como un proceso separado y las aplicaciones de bases de datos más grandes como MySQL pueden consumir mucha RAM cuando se ejecutan).

JSON está ganando mucho impulso y sin duda es la mejor opción si su aplicación está escrita en más de un idioma.

En resumen, depende de lo que se pueda usar fácilmente en su idioma.

Si desea permanecer en el ámbito XML de las cosas, puede usar XML binario para ayudar a aumentar el rendimiento de la carga.

Por ejemplo, Fast Infoset es una implementación de xml binario

Uno puede pensar en Fast Infoset como gzip para XML, aunque FI tiene como objetivo optimizar tanto el tamaño del documento como el rendimiento del procesamiento, mientras que gzip optimiza solo el tamaño. Mientras se pierde el formato original, no se pierde información en la conversión de XML a FI y de regreso a XML.

Llevo años diseñando bases de datos y jugando con muchas ideas de juegos. Mi favorito personal en este momento es un formato para configuraciones, basado en texto y legible para humanos, pero luego analiza estos "scripts lentos" en algo más manejable. Al igual que JAVA y .NET se compila en código de bytes en tiempo de ejecución.

La misma idea va aquí. Tengo una versión "fuente" de componentes y luego un precompilador / analizador los ejecuta. Si ocupan demasiada memoria, puede colocarlos en una base de datos SQL rápida de algún tipo o guardarlos como archivos binarios. Pero mi punto es, usar la memoria o la base de datos SQL como su espacio de trabajo / caché para que no tenga que analizar los scripts una y otra vez. Puede hacer el compilador, mover los archivos analizados a una "fuente-lib" y de esta manera dejar que el precompilador también realice el control de versiones (manteniendo los archivos anteriores para deshacerlos).

Si se trata de "espacio ilimitado en el disco duro", regístrese en algo como Dropbox o Amazon S3 y sincronícelos con ellos.

Entonces el plan para mí es actualmente:

1. Config / scripts / xml (algún formato legible por humanos) como archivos de texto (al igual que el código fuente)
2. Analizador / validador que se ejecuta a través de nuevos scripts y comprueba que están siguiendo las reglas
3. Compilador que hace fila binaria o SQL de los archivos originales, por lo que estos son rápidos para recuperar + rápido para ejecutar.

Con respecto a la estabilidad, actualmente estoy construyendo la base de datos para que esté "alojada en una ubicación conjunta" y también se sincronice automáticamente entre varias ubicaciones, de modo que si hay una falla de red / hardware en una ubicación, los otros sitios deberían poder manejar el mismo tráfico / estados de juego.

Si usa couchdb , esencialmente guardará todo como una estructura JSON. Couchdb se encargará de replicar los datos de sus (múltiples) usuarios de manera más o menos sencilla.

Puede encontrar un procedimiento en Unity Wiki con PHP, MySQL y C # / JavaScript, y funciona bien para su propósito.

Consta de tres pasos

1. Cree una base de datos MySQL en blanco y una tabla.
2. Cree una secuencia de comandos del lado del servidor PHP (Esto se conectará a la tabla MySQL, recibirá datos de una secuencia de comandos de Unity (paso 3) y consultará la base de datos (los ejemplos dados son insertar datos o seleccionar)
3. Cree el script de Unity Controller (Esto se conectará al script PHP creado en el paso 2)