Devo usar um banco de dados SQL para armazenar dados em um jogo de desktop? [fechadas]

Desenvolvendo um Game Engine

Estou planejando um jogo de computador e seu mecanismo. Haverá um mundo tridimensional com visão em primeira pessoa e será single player por enquanto. A linguagem de programação é C ++ e usa OpenGL.

Decisão de Design Centrado em Dados

Minha decisão de projeto é usar uma arquitetura centrada em dados em que haja um gerenciador de eventos global e um gerenciador de dados global . Existem muitos componentes, como física, entrada, som, renderizador, ai, ... Cada componente pode acionar e ouvir eventos . Além disso, cada componente pode ler, editar, criar e remover dados .

A questão é sobre o gerenciador de dados.

Se deve usar um banco de dados relacional

Devo usar um banco de dados SQL, por exemplo, SQLite ou MySQL, para armazenar os dados do jogo? Isso contém praticamente todo o conteúdo do jogo, como itens, personagens, inventários, ... Exceto malhas e texturas que são ainda mais relacionadas ao desempenho, por isso vou mantê-las na memória.

Um banco de dados SQL é rápido o suficiente para usá-lo para ler e escrever em tempo real informações sobre jogos, como a posição de um personagem em movimento? Também preciso me preocupar com a compatibilidade entre plataformas. Além de manter tudo na memória, que alternativas eu tenho?

As vantagens seriam

As vantagens de usar um banco de dados relacional como o MySQL seria a estrutura orientada a dados que permite o cálculo rápido. Eu não precisaria de objetos para representar entidades. Eu poderia facilmente consultar dados de objetos próximos ao player necessários para a renderização. E não preciso me preocupar com dados de objetos distantes. Além disso, não haveria necessidade de jogos salvos, pois o estado do jogo de buraco é salvo no banco de dados. Por último, mas não menos importante, expandir o jogo para um jogo online seria relativamente fácil, porque já existe um local onde o estado do jogo do buraco é armazenado.

Um banco de dados SQL não é rápido o suficiente para ser usado para leitura e gravação em tempo real de informações do jogo. Esses dados são quase sempre mantidos na memória, nas estruturas de dados tradicionais.

Pode haver algum benefício em usar um banco de dados incorporado, como o SQLite, para certos tipos de dados, por exemplo. dados estáticos que não mudam durante o jogo, mas mudam durante o desenvolvimento. Isso poderia ser implantado como parte do jogo final, onde o SQLite é realmente usado apenas ao carregar o jogo pela primeira vez ou ao iniciar um novo nível, etc.

No entanto, também existem muitas desvantagens - é difícil corrigir partes individuais dos dados quando elas são armazenadas em um único arquivo de banco de dados, não é ideal para muitos tipos de dados complexos que os jogos precisam (e que você disse que armazenaria fora - mas terá referências para e de coisas dentro), não é muito flexível quando você precisa alterar o esquema, não é necessariamente compatível com versões anteriores depois de alterar o esquema, etc.

Por esses motivos, a maioria dos desenvolvedores de jogos usa apenas seu próprio formato. Às vezes, os desenvolvedores profissionais que têm consciência do desempenho dão um passo adiante e salvam a estrutura de dados na memória diretamente no disco, para que ela possa ser carregada com um mínimo de processamento.

E se você realmente precisa de dados tabulares baseados em texto que são facilmente editados, você pode usar um formato simples, como CSV, XML, JSON, YAML, etc.

Um banco de dados não é rápido, usar um banco de dados é muito mais lento que o acesso tradicional à memória. O motivo é simples, um banco de dados é dinâmico, há um monte de sobrecarga anexada a ele, as consultas precisam ser analisadas, os hashes precisam ser computados e outras coisas.

Há apenas uma vantagem do uso de um banco de dados, que é a persistência. Você pode executar um ou vários aplicativos com um banco de dados por um longo período de tempo, sem precisar se preocupar com a falta de dados. Mas os clientes de jogos não precisam absolutamente disso.

Então, você deseja obter todos os objetos a menos de 1000 pixels de distância?
Isso seria:

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

Agora, o que você pensaria que um banco de dados faria se você pedisse para retirar todos os objetos a menos de 1000 px?
Faria exatamente o mesmo! Apenas com um monte de sobrecarga, o que tornaria essa operação extremamente simples custar cerca de 100 vezes o tempo do processador (dependendo de quantas entidades você possui). Bancos de dados não são mágicos.

Não use bancos de dados para nada além de aplicativos de servidor.