Como escolher como armazenar dados?

Dê a um homem um peixe e você o alimentará por um dia. Ensine um homem a pescar e você o alimentará por toda a vida. - Provérbio chinês

Eu poderia perguntar que tipo de armazenamento de dados eu deveria usar para o meu projeto real, mas quero aprender a pescar , para que não precise pedir um peixe cada vez que iniciar um novo projeto.

Então, até que eu usei dois métodos para armazenar dados no meu projeto que não é de jogo: arquivos XML e bancos de dados relacionais. Eu sei que também há outro tipo de banco de dados, do tipo NoSQL . No entanto, eu não saberia se há mais opções disponíveis para mim, ou como escolher, em primeiro lugar, além de escolher arbitrariamente uma.

Portanto, a pergunta é a seguinte: Como devo escolher o tipo de armazenamento de dados para um projeto de jogo?

E eu estaria interessado no seguinte critério ao escolher:

• O tamanho do projeto.
• A plataforma visada pelo jogo, bem como a plataforma de desenvolvimento usada.
• A complexidade da estrutura de dados.
• Portabilidade adicionada de dados entre muitos projetos.
• Adicionado2 Uso silencioso dos dados entre diferentes projetos. (ou seja, dados do usuário)
• Adicionado Com que frequência os dados devem ser acessados
• Adicionado vários tipos de dados para um mesmo aplicativo
• Added2 Configuração com armazenamento múltiplo de dados.
• Qualquer outro ponto que você julgue interessante ao decidir o que usar.

EDIT Eu sei sobre Seria melhor usar XML / JSON / Text ou um banco de dados para armazenar o conteúdo do jogo? , mas pensei que não tratava exatamente do meu ponto. Agora, se eu estiver errado, seria feliz em mostrar o erro em meus caminhos.

EDIT2 Adicionado mais alguns pontos que eu consideraria relevantes. Além disso, eu gostaria de saber quais outras opções estão disponíveis, além do armazenamento de arquivos simples e do banco de dados relacional. E o banco de dados não relacional, por exemplo? Quando é relevante usar esse banco de dados sobre as outras opções mencionadas anteriormente?

Sua pergunta é realmente ampla por causa do grande número de gêneros existentes, mas aqui está a perspectiva de um desenvolvedor de software profissional.

Você forneceu uma lista de critérios que deseja usar para determinar qual mecanismo de persistência de dados você usa. Esses foram:

• O tamanho do projeto.
• A plataforma alvo do jogo.
• A complexidade da estrutura de dados.
• Portabilidade de dados entre muitos projetos.
• Com que frequência os dados devem ser acessados
• Vários tipos de dados para um mesmo aplicativo
• Qualquer outro ponto que você julgue interessante ao decidir o que usar.

Primeiro, precisamos estabelecer quais opções estão disponíveis para nós. Como você não especificou um idioma ou tecnologia, é difícil dizer exatamente, mas você provavelmente está tentando decidir entre XML e armazenamento de banco de dados relacional .

Uma distinção importante a ser feita é que o XML não é realmente um mecanismo de armazenamento sim uma técnica de serialização. É uma maneira de representar estruturas na memória para o seu jogo. Dado isso, você está realmente falando sobre arquivo simples versus armazenamento de banco de dados relacional . Essas não são as únicas opções, mas são as mais comuns, então vou usá-las.

Para arquivos simples:

• XML
• JSON
• YAML
• XAML
• Texto simples

Para bancos de dados:

• servidor SQL
• MySQL
• DB2
• Oráculo
• Muito mais

EDITAR: Você perguntou sobre outros tipos de mecanismos além de arquivos e bancos de dados relacionais. O único outro tipo notável de banco de dados que eu já vi usado regularmente são os bancos de dados "no estilo Berkeley", que são essencialmente baseados em valores-chave. Eles tendem a usar árvores B para estruturar dados, para que as pesquisas sejam rápidas. Eles são ótimos para pesquisar configurações onde você sabe exatamente o que deseja (por exemplo, forneça todos os dados de telemetria do "Nível 1").

Agora que já temos todos os princípios básicos, vamos tocar em alguns dos seus critérios.

O tamanho do projeto.

Alguns podem discordar, mas o tamanho do seu projeto não terá necessariamente um enorme impacto no mecanismo de persistência de dados. Você desejará criar uma biblioteca reutilizável de funções que armazene / carregue dados de qualquer mecanismo que desejar. Eu até sugeriria a implementação de uma camada de abstração (consulte o padrão do adaptador ) para que você pudesse alterar facilmente seu mecanismo de persistência, se necessário.

Dito isto, em pequenos projetos, o uso de XML no sistema de arquivos pode potencialmente funcionar bem, mas você deseja resolver algumas de suas preocupações de segurança (ou seja, criptografia) para que os jogadores não possam alterar os dados à vontade.

A plataforma alvo do jogo.

A plataforma também não será um grande problema. Você deve estar mais preocupado com sua plataforma de desenvolvimento do que com a plataforma de destino. A razão para isso é que algumas linguagens lidam com certos tipos de marcação ou bancos de dados melhor do que outras imediatamente. Isso não quer dizer que você não possa usar nenhum dos itens acima em quase nenhum idioma, mas às vezes é melhor usar as ferramentas suportadas disponíveis. Qualquer plataforma suporta arquivos simples e analisa XML, mas em plataformas móveis você pode considerar a serialização binária, se possível, ou pelo menos otimizar seu XML para armazenamento.

A complexidade da estrutura de dados.

Isso é meio complicado. Os bancos de dados relacionais são ótimos apenas para ... armazenar entidades e seus relacionamentos. Você tem uma capacidade melhor de impor a estrutura usando um repositório de armazenamento relacional do que os arquivos em um sistema de arquivos. Considere os tipos de relacionamento entre suas entidades e a frequência com que você as altera ou encontra entidades relacionadas. Para estruturas extremamente complexas, sugiro seguir a rota do banco de dados.

Portabilidade de dados entre muitos projetos.

Quando se trata de portabilidade, você deve considerar o fato de que os bancos de dados são naturalmente mais pesados ​​que os arquivos. Há sobrecarga de instalação e configuração, bancos de dados diferentes estarão disponíveis para plataformas diferentes, etc. O SQLite é uma boa maneira de contornar isso. No entanto, quando se trata de portabilidade, você provavelmente terá mais facilidade com soluções baseadas em arquivo como XML.

EDIT: Existem outras preocupações que você mencionou sobre portabilidade em um de seus comentários. Por fim, você não deseja que seus dados sejam acoplados com muita força a qualquer produto ou tipo de arquivo. Em última análise, é melhor se você pode armazenar dados de estoque (níveis, inimigos etc.) em algum tipo de formato abstrato (arquivos delimitados por tabulação, XML etc.) que você pode analisar e armazenar facilmente em um banco de dados / sistema de arquivos durante a compilação ou carregamento. Tempo. Isso significa que você pode trocar seu mecanismo de armazenamento por um capricho e apenas reescrever a peça de análise.

Com que frequência os dados devem ser acessados

Muito acesso a dados significa muita E / S, a menos que você tenha algum tipo de mecanismo de armazenamento em cache. Os bancos de dados mantêm estruturas na memória e são ótimos para manipulação e recuperação de dados. Se você realmente persistir constantemente com os dados, convém manter um banco de dados.

Vários tipos de dados para um mesmo aplicativo

O volume é certamente uma consideração, mas, a menos que você esteja falando sobre a persistência de milhares ou milhões de objetos, o sistema de arquivos ainda será aceitável como solução.

Tipo de jogo

O tipo de jogo que você está construindo pode ter uma enorme influência na plataforma que você escolher. Sim, para a maioria dos jogos para um jogador apenas para um cliente, você ficará bem usando uma solução baseada em sistema de arquivos compactados ou criptografados. Se você está falando de jogos com um componente online, isso seria uma loucura. Siga a rota do banco de dados e salve a dor de cabeça. Deixe o servidor gerenciar todos os seus dados usando um cluster de back-end.

Espero que alguns desses comentários ajudem. Não é de forma alguma abrangente, e tomar a decisão depende de você, mas meu comentário deve lhe dar algumas considerações.

EDIT: Há momentos em que adotar uma abordagem híbrida faz muito sentido. Por exemplo, digamos que você esteja desenvolvendo um MMORPG. No lado do cliente, você pode armazenar dados em cache sobre outros players em um banco de dados não relacional (como mencionado acima). No lado do servidor, você está armazenando todos os dados do jogo em um banco de dados relacional para persistir. E, novamente, no lado do cliente, você provavelmente está armazenando dados de log, dados de configuração etc. em arquivos XML / simples para facilitar a acessibilidade.

Outro pôster também mencionou que, às vezes, é bom, mesmo se você estiver armazenando dados para produção em um banco de dados, ter uma maneira de usar arquivos simples para desenvolvimento ... pode ser mais fácil remover outro produto da mistura .

Ultimamente, tenho me sentido limitado pela rigidez / dificuldade de adicionar aos bancos de dados relacionais. Adoraria explorar bancos de dados baseados em documentos (por exemplo, couchdb), pois eles parecem muito adequados para jogos, estado e flexibilidade. Mas não é realmente prático configurar vários tipos de banco de dados para um projeto pequeno. Como resultado, configurei um hack semelhante a apenas usar um campo de blob binário em determinados campos do banco de dados.

O que estou fazendo é usar dados codificados pelo json no banco de dados e um invólucro que converte os dados em json e volta sempre que necessário. Portanto, um perfil de caractere básico pode se parecer com isso no banco de dados:

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

O Json ainda é bem legível no banco de dados; portanto, se você estiver trabalhando sem o metal com o sql e às vezes acessando o banco de dados diretamente, será modificável manualmente, se desejar.

Agora, tudo isso é um hack, e eu não aconselho a copiá-lo, mas aqui está o ponto geral: não confie apenas em um sistema. Use um banco de dados relacional e falsifique o sistema. Ou use dois tipos diferentes de sistemas de armazenamento de dados (por exemplo, arquivo simples e banco de dados relacional?), Para que você possa tirar o máximo proveito de ambos. Não importa o que as pessoas sugiram, ou com qual sistema você for, no futuro, você encontrará circunstâncias em que outra abordagem funcionaria melhor; portanto, esteja preparado para adicionar uma alternativa e ver onde isso o leva.

No gene RTS, os dados do jogo foram armazenados em arquivos.

As unidades e os atributos foram armazenados em arquivos INI ou XML ou outros formatos baseados em texto, e os modelos foram uma mistura de formatos binários ou mesmo baseados em texto, além de texturas e sons e outras mídias nos formatos principais. Às vezes, ele está em um contêiner com criptografia bruta - o formato de mix da Westwood vem à mente. Mas isso é principalmente ofuscação - se você olhar dentro deles, são apenas arquivos normais em formatos fáceis de manusear.

Com o advento do jogo online, tornou-se cada vez mais comum que os dados do jogo fossem provisionados após a instalação pela Internet, embora muitas vezes eles ainda estejam armazenados no sistema de arquivos.

Por que usar um método de armazenamento de dados?

Na maioria dos casos, o jogo lançado para o mundo não precisa da mesma funcionalidade de armazenamento de dados que o jogo precisa durante o desenvolvimento.

Aqui está uma comparação de alguns requisitos de versão / desenvolvimento: -

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

Idealmente, você definiria uma interface para seu módulo de carregamento de dados e criaria várias versões, cada uma adaptada às necessidades específicas.

Em um projeto em que trabalhei há muitos anos, o carregamento de dados em nível do CD estava demorando muito (o HD não era ótimo também). Então, eu vim com o seguinte. Eu tinha três métodos para carregar dados de nível: -

1. Carregamento normal - para o tempo de desenvolvimento em que os ativos estavam mudando
2. Pré-lançamento - efetivamente um método para converter dados normais em dados de carregamento rápido
3. Lançamento - apenas dados rápidos (não editáveis)

Isso reduziu o tempo de carregamento de minutos para segundos.