Seria melhor usar XML / JSON / Text ou um banco de dados para armazenar o conteúdo do jogo?

Estou pensando em como implementar um jogo baseado em componentes, pois isso parece ser bom e eu gosto da ideia de um design tão flexível. Uma das características desse design é que a adição de coisas novas ao jogo pode ser feita por meio de dados, geralmente apresentados como carregamento de conteúdo por meio de arquivos de texto como XML. Isso tem a vantagem de ser legível por humanos e facilmente editável em qualquer editor de texto. O lado negativo é que o texto pode ser mais lento, e você precisa gerenciar uma grande coleção de arquivos de dados. Formatos baseados em texto semelhantes, como JSON ou arquivos de configuração, teriam benefícios semelhantes.

Por outro lado, existem bancos de dados pequenos e portáteis, como o SQLite ou o Tokyo Cabinet. Embora não sejam diretamente legíveis por humanos, esses arquivos são fáceis de interagir, e eu imagino que algum tipo de ferramenta de edição seja preferível para o design do conteúdo do jogo. O uso de um banco de dados permite um armazenamento consistente de informações de configuração e fácil recuperação. Você também pode serializar dados em um banco de dados para salvar jogos.

Em termos de desempenho, acho que geralmente o XML é mais rápido para arquivos pequenos, mas um banco de dados é dimensionado melhor para grandes quantidades de dados. Eu imagino que qualquer jogo real terá muitos objetos de jogo.

Então a pergunta: qual é a abordagem preferível? Estou inclinado para o banco de dados, mas quero saber se existem armadilhas ocultas ou vantagens muito fortes nos arquivos de texto. Ou se existem outras alternativas além destas (serializar para o formato binário, eu acho?)

Pode não aparecer tanto para um pequeno jogo pessoal, mas um problema difícil quando se trata de dados do jogo é a edição / versão para vários usuários. Usamos muitos arquivos de texto pequenos que são reduzidos a um pequeno número de blobs binários por um processo de compilação. Isso facilita a vida dos designers, pois eles têm muita flexibilidade no fluxo de trabalho. O CCP, como um exemplo contrário, usa um banco de dados de edição central ao qual todos os designers se conectam. Isso torna a etapa de construção desnecessária (ou pelo menos muito mais simples), mas significa que você precisa implementar todos os recursos de controle de versão e fluxo de trabalho, para que eles sejam mais simples do que outras ferramentas existentes. Você pode lidar com o desempenho em ambos os casos; portanto, a verdadeira questão é o que você deseja para um fluxo de trabalho de designer e como chegar lá?

JSON é muito leve e fácil de entender. Eu acho que é mais adequado para um jogo. cJSON é muito legal. Ele também será incorporado à sua fonte da mesma maneira que o SQLlite.

Os arquivos XML são mais difíceis de editar para os usuários do que você imagina. se você seguir esse caminho, convém criar um editor para as pessoas usarem para ajudá-las a evitar armadilhas comuns.

Estou atrasado para a festa aqui, mas passei muito tempo pesquisando isso.

Primeiro, por que não uso o seguinte:

XML: Excessivamente detalhado. Toneladas de redundância. Repetindo nomes de campos? BRUTO

JSON: Eu acho que o JSON é ótimo para um layout de interface do usuário, mas para um banco de dados, não. Ele terá os mesmos problemas que XML, redundância e aninhamento profundo. BRUTO.

SQL : Esta é uma ótima opção, se você gerenciar as dores de cabeça de configurá-lo. Criei jogos para celular onde armazenamos os dados do jogo online em um banco de dados SQL. O formato da tabela é bom. O problema foi que tivemos que buscar o banco de dados on-line e configurá-lo pode ser um aborrecimento. Mas o SQL é uma solução decente. O Unity não suporta isso nativamente, e os plugins que eu tentei tiveram grandes problemas (especialmente quando tentamos fazê-lo funcionar com controle de versão).

Finalmente, aqui está a solução que optei por usar (e eu adoro).

CSV : simples. Permite-me usar o formato da tabela e tenho um ponto de referência fácil quando preciso atualizá-lo. Eu posso ter uma tabela para todas as minhas armas, colunas para todos os atributos e linhas para cada tipo de arma.

Você pode usar o Microsoft Excel, mas ele lança esses avisos estúpidos toda vez que você precisa salvar. Você pode usar macros para substituí-lo, mas eu digo: salve o problema e obtenha o LibreOffice . É gratuito, suporta edição CSV e, quando você abre o arquivo, ele carrega a largura da coluna para corresponder ao nome (o Excel não faz isso e me deixa louco).

Então você só precisa analisar os arquivos CSV no seu jogo. Eu uso o Unity, então tudo que eu precisava fazer era usar esse analisador bacana de C # CSV que encontrei:

Exemplo de analisador de CSV

Você converte os arquivos CSV em seus objetos de dados do jogo e está pronto. Com o Unity, você pode transformá-los em ScriptableObjects . Portanto, meu fluxo de trabalho é: Atualizar CSV -> Analisar CSV em objetos programáveis ​​por script -> Usar dados de ScriptableObjects para o meu jogo

A resposta para isso depende do idioma que você está usando para o jogo.

Se você estiver usando C ++, é aconselhável usar uma das bibliotecas XML existentes (como TinyXml ou eXpat ).

Por outro lado, se você estivesse usando PHP, poderia facilmente usar um servidor de banco de dados como MySQL ou SQLite. (Lembre-se de que, se você seguir esta rota, precisará de mais recursos, porque o servidor de banco de dados estará sendo executado como um processo separado e aplicativos de banco de dados maiores, como o MySQL, podem consumir muita RAM durante a execução.)

O JSON está ganhando muito impulso e é certamente a melhor opção se o seu aplicativo for escrito usando mais de um idioma.

Em resumo, depende do que é facilmente utilizável no seu idioma.

Se você deseja permanecer no domínio XML, pode usar o XML Binário para ajudar a aumentar o desempenho do carregamento.

Por exemplo, o Fast Infoset é uma implementação de xml binário

Pode-se pensar no Fast Infoset como gzip para XML, embora o FI pretenda otimizar o tamanho do documento e o desempenho do processamento, enquanto o gzip otimiza apenas o tamanho. Enquanto a formatação original é perdida, nenhuma informação é perdida na conversão de XML para FI e de volta para XML.

Desenvolvo bancos de dados e brinquei com muitas idéias de jogos há anos. Meu favorito pessoal no momento, é um formato legível por humanos, baseado em texto, para configurações, mas depois analisando esses "scripts lentos" em algo mais executável. Assim como o JAVA e o .NET, são compilados no bytecode em tempo de execução.

A mesma ideia vai aqui. Eu tenho uma versão "de origem" dos componentes e, em seguida, um pré-compilador / analisador executa esses. Se eles ocupam muita memória, você pode colocá-los em uma base de dados SQL rápida de algum tipo ou salvá-los como arquivos binários. Mas o que quero dizer é que use a memória ou o banco de dados SQL como seu espaço de trabalho / cache, para que você não precise analisar os scripts repetidamente. Você pode criar o compilador, mover os arquivos analisados ​​para uma "fonte-lib" e assim permitir que o pré-compilador faça o controle de versão também (mantendo os arquivos anteriores para fins de reversão).

Se for sobre "espaço ilimitado no disco rígido", inscreva-se em algo como Dropbox ou Amazon S3 e sincronize com eles.

Portanto, o plano para mim é atualmente:

1. Config / scripts / xml (algum formato legível por humanos) como arquivos de texto (assim como código fonte)
2. Analisador / validador que executa novos scripts e verifica se estão seguindo regras
3. Compilador que cria binário ou linha SQL a partir dos arquivos originais, para que eles sejam rápidos de recuperar e rápidos de executar.

No que diz respeito à estabilidade, atualmente estou construindo o banco de dados para ser "hospedado em locais co-locais" e sincronizar automaticamente entre vários locais, para que, se houver uma falha de rede / hardware em um local, os outros sites possam lidar com o mesmo tráfego / gamestates.

Se você usar o couchdb, estará basicamente salvando tudo como uma estrutura JSON. O Couchdb cuidará de replicar os dados do seu (vários) usuários de forma mais ou menos indolor.

Você pode encontrar um procedimento no Unity Wiki com PHP, MySQL e C # / JavaScript, e funciona bem para essa finalidade.

Consiste em três etapas

1. Crie um banco de dados MySQL em branco e uma tabela.
2. Crie um script do lado do servidor PHP (Isso se conectará à tabela MySQL, receberá dados de um script do Unity (etapa 3) e consultará o banco de dados (os exemplos dados estão inserindo dados ou selecionando))
3. Crie o script do Unity Controller (isso se conectará ao script PHP criado na etapa 2)