¿Debo usar una base de datos SQL para almacenar datos en un juego de escritorio? [cerrado]

9

Desarrollando un motor de juego

Estoy planeando un juego de computadora y su motor. Habrá un mundo tridimensional con vista en primera persona y será un jugador por ahora. El lenguaje de programación es C ++ y utiliza OpenGL.

Decisión de diseño centrada en datos

Mi decisión de diseño es utilizar una arquitectura centrada en datos donde haya un administrador de eventos global y un administrador de datos global . Hay muchos componentes como física, entrada, sonido, renderizador, ai, ... Cada componente puede activar y escuchar eventos . Además, cada componente puede leer, editar, crear y eliminar datos .

La pregunta es sobre el administrador de datos.

Si se debe usar una base de datos relacional

¿Debo usar una base de datos SQL, por ejemplo, SQLite o MySQL, para almacenar los datos del juego? Contiene prácticamente todo el contenido del juego, como elementos, personajes, inventarios, ... Excepto las mallas y texturas que están aún más relacionadas con el rendimiento, por lo que las guardaré en la memoria.

¿Es una base de datos SQL lo suficientemente rápida como para usarla para leer y escribir información del juego en tiempo real, como la posición de un personaje en movimiento? También necesito preocuparme por la compatibilidad multiplataforma. Además de mantener todo en la memoria, ¿qué alternativas tengo?

Las ventajas serían

Las ventajas de usar una base de datos relacional como MySQL sería la estructura orientada a datos que permite un cálculo rápido. No necesitaría objetos para representar entidades. Podría consultar fácilmente los datos de los objetos cercanos al reproductor necesarios para la representación. Y no tengo que preocuparme por los datos de objetos lejanos. Además, no habría necesidad de juegos guardados ya que el estado del juego del hoyo se guarda en la base de datos. Por último, pero no menos importante, expandir el juego a un juego en línea sería relativamente fácil porque ya hay un lugar donde se almacena el estado del juego del hoyo.

danijar
fuente
Es posible que desee considerar bases de datos de objetos sobre bases de datos relacionales, que resuelven algunos de los problemas mencionados en la respuesta aceptada sobre el esquema frágil y tal.
ashes999
Si tiene procesos más adecuados para una base de datos relacional, puede usar Embedded SQL con acceso a memoria híbrida. Esto evitaría muchos de los problemas que hacen que las bases de datos SQL tradicionales no sean adecuadas para las demandas de rendimiento de los juegos.
rovyko

Respuestas:

11

Una base de datos SQL no es lo suficientemente rápida como para usarla en tiempo real para leer y escribir información del juego. Tales datos casi siempre se guardan en la memoria, en las estructuras de datos tradicionales.

Puede haber algún beneficio al usar una base de datos integrada como SQLite para ciertos tipos de datos, por ejemplo. Datos estáticos que no cambian durante el juego pero cambian durante el desarrollo. Esto podría implementarse como parte del juego final donde SQLite solo se usa realmente cuando se carga el juego por primera vez, o al comenzar un nuevo nivel, etc.

Sin embargo, también hay muchas desventajas: es difícil parchear partes individuales de los datos cuando se almacenan en un solo archivo de base de datos, no es ideal para muchos tipos de datos complejos que necesitan los juegos (y que usted dijo que almacenaría) afuera, pero tendrá referencias hacia y desde cosas adentro), no es muy flexible cuando necesita cambiar el esquema, no es necesariamente compatible con versiones anteriores después de cambiar el esquema, etc.

Por estas razones, la mayoría de los desarrolladores de juegos usarán su propio formato. Los desarrolladores profesionales que son conscientes del rendimiento a veces van un paso más allá y guardan la estructura de datos en memoria directamente en el disco para que pueda cargarse con un mínimo de procesamiento.

Y si realmente necesita datos tabulares basados ​​en texto que se editen fácilmente, puede usar un formato simple basado en texto, como CSV, XML, JSON, YAML, etc.

Kylotan
fuente
2
Terminé usando SQLite para guardar el estado del juego. Como estoy usando un sistema de entidades, eso tiene mucho sentido: todo lo que tengo son propiedades. Cada tipo de propiedad tiene su tabla en la base de datos y las entidades están vinculadas por su identificación (global única). Pero supongo que en las bases de datos de sistemas de herencia no tendría mucho sentido.
danijar
1
Sí, creo que usar SQLite para guardar el estado del juego es una buena idea, siempre que planees hacerlo desde el principio. Sin embargo, no me gustaría que la base de datos sea el lugar principal donde se almacenan los datos del juego durante el juego.
Kylotan
5

Una base de datos no es rápida, usar una base de datos es mucho más lento que el acceso a la memoria tradicional. La razón es simple, una base de datos es dinámica, hay un montón de sobrecarga adjunta, las consultas deben analizarse, los cálculos deben calcularse y otras cosas.

Solo hay una ventaja de usar una base de datos y es la persistencia. Puede ejecutar una o varias aplicaciones con una base de datos durante un largo período de tiempo sin tener que temer la pérdida de datos. Pero los clientes de juegos no tienen absolutamente ninguna necesidad de eso.

Entonces, ¿quieres obtener cada objeto que esté a menos de 1000 px de distancia?
Eso sería:

List<Entity> retVal;
for(entity in entities)
  if(Distance(entity.pos(), to) < 1000)
     retVal.append(entity);
return retVal;

Ahora, ¿qué pensarías que haría una base de datos si le pidieras que elimine todos los objetos a menos de 1000 px?
¡Haría exactamente lo mismo! Solo con un montón de sobrecarga, lo que haría que esta operación extremadamente simple costara aproximadamente 100 veces el tiempo del procesador (dependiendo de cuántas entidades tenga). Las bases de datos no son mágicas.

No use bases de datos para nada más que aplicaciones de servidor.

API-Bestia
fuente
2
El servidor SQL tiene índices espaciales. No recorrerá todos los registros, pero utilizará un enfoque de índice inteligente
MichaelD