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

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.

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.

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.