Qual é um bom formato de arquivo para salvar dados do jogo? [fechadas]

Preciso salvar alguns dados personalizados do jogo. Mapa, jogador, etc.

Todos eles terão "subobjetos". Por exemplo, um mapa e um mapa terão uma "matriz" de blocos. isto é, dados hierárquicos. Esperemos que nada de binário.

Qual seria um bom formato para isso?

Até agora eu considerei:

Serailization: Isso é RÁPIDO e fácil, mas tende a quebrar quando eu altero as classes subjacentes :(

XML: Eu realmente odeio analisar isso. Meu caso de teste tinha mais de 100 linhas de código e parecia ter toneladas de "trabalho ocupado", mesmo para um formato muito simples.

INI: seria realmente desajeitado para dados hierárquicos.

Protobuf: Nunca usei, mas leia que você precisa fazer muitas manobras manuais e quebras se mudar de classe.

Outras opções? É por isso que estou aqui!

Edit: este é o Java btw.

Edição 2:

Eu decidi pela "Serialização binária controlada" (veja abaixo).

Prós:

• É rápido

• é pequeno (no disco) e pode ser facilmente compactado / descomprimido durante a leitura / gravação.

• é super fácil de ler / escrever no jogo e no conjunto de ferramentas.

• Eu posso decidir o que incluir / excluir do objeto.

• Objetos / dados podem ser aninhados.

Contras:

• Não é possível editá-lo manualmente (como XML, YAML etc.)

• Não é possível ler / modificar facilmente com scripts

• A serialização Java por padrão é bastante lenta / inchada em comparação com outras implantações, mas é estável e funciona

Para exibir dados hierárquicos, YAML ou JSON seriam boas opções. Eles são muito mais simples e fáceis de analisar do que XML.

Outra opção seria um processo de serialização binária "controlado". Todo objeto escreve seu estado de maneira controlada, ou seja,

void player::save(savegame &sgm)
{
    sgm.write(this->position);
    sgm.write(other properties);
    inventory.save(sgm);
}

A id Tech 4 (mecanismo Quake 4 / Doom 3) usa essa abordagem.

Um formato binário bem feito realmente tem todas as vantagens, é rápido, razoavelmente pequeno e tão flexível quanto você.

Ao criar um formato binário, você não tem regras, o que é uma grande vantagem, mas, ironicamente, é em grande parte o que deu às estruturas de arquivos binários um nome ruim. XML, JSON e similares tomam muitas decisões para você, elas estão longe de ser sempre ótimas, mas são opções razoavelmente seguras que geralmente o ajudarão a evitar alguns problemas comuns.

Identifique esses problemas, projete seu formato com isso em mente e você poderá criar um ótimo formato binário.

Se você não tiver experiência / confiança suficiente para criar um formato binário e a quantidade de dados for pequena o suficiente para que o impacto na velocidade seja insignificante, sugiro que você use JSON, é simples, mas faz o trabalho.

Sua escolha do formato do arquivo depende enormemente do seu conjunto de ferramentas atual e do jogo que você pretende fazer. Com isso dito ...

O conjunto de ferramentas é um dos fatores mais importantes na decisão de um formato de arquivo do jogo. Se você criar um formato binário , precisará sempre garantir que possui as ferramentas para inserir os dados do jogo. Isso pode ser tão simples quanto um editor hexadecimal ou tão complexo quanto o Unreal Editor.

Eu acho que a principal vantagem do XML, YAML ou de qualquer outro arquivo de idioma é que você pode editá-lo facilmente através de um editor de texto. E usando um padrão existente, garante que você não pode dar errado . Mas, isso é extremamente tedioso quando você tem milhares de arquivos, o que me leva ao meu próximo ponto.

Jogos. Que tipo de jogo você está fazendo? Por que digo que isso afetará o formato do arquivo? Porque, se você estiver criando algo como 2D bomberman, poderá se livrar de um arquivo de texto simples como:

*********
*1     2*    1,2,3,4  - start point of players 1, 2, 3, 4
* + + + *    *        - walls
*       *    +        - crates
* + + + *
*3     4*
*********

Em outras palavras, sempre escolha o formato mais óbvio para seus dados específicos . RPGs são o gênero de jogo mais complexo a se fazer. Eles exigem muitos dados. Mas isso não significa que você precise definir um formato específico , seja ele binário ou baseado em texto para todos os dados do jogo.

• Mapas, partículas e outras coisas gráficas tendem a usar um formato binário personalizado. Porque é a maneira mais simples de implementá- lo. Não é humanamente sensato descrever mapas textualmente. Geralmente editado pelos editores de mapa / nível / partícula.
• Jogadores, itens, inimigos, habilidades e missões são estatísticas que afetam o equilíbrio do jogo . Eles geralmente exigem muitas e muitas informações e ajustes. Eu gosto de fazer isso colocando-o em um arquivo XML para facilitar a implementação, mas ainda tendo um editor de objetos para os designers brincarem. Melhor dos dois mundos .

Geralmente, você deseja descrever texto com um formato de texto e gráficos com um formato binário. A seguir, um exemplo:

<Skill>
    <Name>Fireball</Name>
    <Animation>fireball.dat</Animation> <!-- Graphics described in another file -->
    <Attack>1.3</Attack>
    <Cooldown>15</Cooldown>
</Skill>

Para resumir, é a minha recomendação mais completa que, se possível, você não script seus dados, a menos que seja absolutamente necessário . O usuário final não se importa com o quão impressionante é o formato, desde que o jogo seja jogável, isso é tudo o que importa.

Saúde, Roy =)

BSON é bem legal. http://bsonspec.org/ . É mais fácil analisar o JSON e melhor para conter dados binários, mas ainda possui uma estrutura agradável. É um pouco semelhante aos buffers de protocolo. A desvantagem é que parece que existe um grande suporte de ferramentas fora do mongodb.

EDIT: MsgPack ( http://msgpack.org/ ) também é semelhante ao BSON e parece estar ganhando mais força.

O que aconteceu com seu formato de dados binários personalizado? Se você tem medo de serialização bruta, escreva seu próprio sistema que grava os campos conforme necessário e os lê novamente. Não há necessidade de xml, que é realmente excessivamente volumoso e complexo para situações em que você não precisa da transparência que o formato fornece. Apenas defina um formato de arquivo bem especificado e cumpra-o, deixando talvez algum espaço para expansão do seu conjunto de dados em cada registro preenchendo-os com valores nulos (digamos que você tenha um registro de 100 bytes agora, coloque-o em 150 para uso futuro.
Adicione um número de versão e talvez uma soma de verificação para saber quais campos devem ser preenchidos e ter uma verificação de integridade, e você estará pronto.

Você pode misturar XML ou algum outro formato com inserções Base64 para alguns dados específicos e, para os campos em que você precisa de legibilidade, pode usar o TEXT usual