Você preenche todos os dados do seu jogo em grandes tabelas do Excel? Existe algum método melhor?

Eu realmente quero saber quantos designers de jogos preferem trabalhar com uma mesa enorme para todos os itens, outra mesa para todas as habilidades e até outra mesa para todos os mobs em um MMORPG. E essas tabelas podem crescer para várias centenas de MBs com milhares de registros, mas a maioria dos registros usa apenas alguns campos em uma tabela.
Eu sei que alguns designers de jogos funcionam dessa maneira. Existe algum método melhor?

Eu não queria responder aqui, mas quando vi outra resposta / comentários, mudei de idéia. SQL não é uma solução muito boa disso. O SQL define tabelas e insere muitos dados nessas tabelas. Não é esse o caso. Ao criar / testar o design do jogo, você deseja verificar principalmente se o enorme sistema está equilibrado. Isso significa muitas tabelas que se afetam. Nada de bom para o SQL atualmente - ou é, mas não é fácil de manusear, porque você precisa fazer uma programação que não é necessária. E o designer de jogos não precisa saber disso.

Como programadores / desenvolvedores de jogos, podemos desprezar o excel e seu uso por qualquer coisa, mas é uma ferramenta muito boa para esse caso, especialmente quando o designer de jogos pode usá-lo bem e o documento é bem criado.

Não posso recomendar nenhuma outra ferramenta, mas posso dizer que conheço designers de jogos profissionais que também usam o Excel. Então, eu assumo que é uma ferramenta comum.

Concordo com a maioria dos respondentes que às vezes as planilhas podem criar ferramentas de desenvolvimento decentes, especialmente para designers.

Se você estiver interessado em levar essa abordagem adiante, o programa de planilhas do Resolver One usa python para criação de scripts, facilitando a configuração de uma planilha para designers que faz modelagem complexa e exporta para um formato de dados otimizado para jogos. Acho muito mais fácil trabalhar com o VBScript do Excel.

O Excel é uma excelente solução. Fiquei me perguntando como isso deveria ser feito. Mas, pensando bem, o Excel é uma ferramenta muito popular e bastante adequada para essa tarefa. Eu não recomendaria essa prática. Além disso, banco de dados real, como @notabene sugere, traz um monte de sobrecarga extra que você realmente não precisa. Vejo algumas opções, uma das quais é semelhante ao uso do Excel:

• Abra o Office Calc: grátis. Há também um download do conector MySql (de código aberto, acredito) para o Calc.
• dados serializados: XML ou binários (criptografados)

... de qualquer maneira, livre e você tem controle total.

Pessoalmente, eu estaria inclinado a usar dados binários serializados e criptografados . Duas razões:

• os dados do jogo não podem ser facilmente alterados
• Eu posso trabalhar com tabelas de dados em vez de serialização XML de conjuntos de dados, ou seja , tenho a opção

Existe uma necessidade de uma biblioteca de dados dedicada e verdadeira orientada para jogos ? Talvez ... a menos que alguém já conheça essa biblioteca.

Ao ponto da pergunta do OP, observe cada arquivo CSV da página como uma única tabela de dados - semelhante a uma tabela em um banco de dados. Cada arquivo de página deve conter dados relacionados:

• Habilidades, ou
• Gear, ou
• Estatísticas de NPC

Isso ajuda a manter um alto nível de organização que será muito importante à medida que o conteúdo dos dados cresce, o conteúdo do jogo se expande etc.

Editar
Depois de realmente tentar usar o .ODS (arquivo do OpenOffice Calc) e conectar-se a partir de um aplicativo, na verdade não é possível, pois as postagens iniciais no site do OO implicavam. Não consegui encontrar nada especificamente mostrando o codez na implementação.

Além disso, o uso de arquivos do Excel pode ser bom durante o desenvolvimento de um jogo, para que os dados possam ser ajustados sem sobrecarga de um banco de dados. No entanto, e isso é importante, se você planeja fazer isso, é necessário ter o MS Office instalado para poder fazer referência ao Microsoft Excel Interop COM. Isso pode ser benéfico no começo, mas eu não gostaria de remover ou alterar um monte de código para preparar um aplicativo para Alpha, Beta ou RC. Uma biblioteca muito simplificada exigiria mais esforço do que eu poderia considerar útil.

Vou usar arquivos .CSV para armazenamento de dados em estágio inicial. Existem algumas desvantagens, mas no geral acho que essa é uma opção muito melhor. Tudo está contido em minhas bibliotecas. O .net possui classes muito úteis para ler esses arquivos de texto. Além disso, como arquivos .CSV, os dados são facilmente manipulados; e, para estágios posteriores de desenvolvimento, tudo o que preciso fazer é ter meus arquivos de dados serializados em XML e, posteriormente, em binários criptografados serializados.

Desde que a natureza dos seus dados permita que eles sejam armazenados em uma planilha sem passar por muitos obstáculos, cria um formato muito bom, especialmente para o trabalho de desenvolvimento. No final, você pode querer armazená-lo em outros formatos para uso, mas a planilha fornece um editor muito poderoso que pode ser MUITO legal se você decidir mudar a forma como lida com algo!

Se você estiver usando o Excel, obtenha uma cópia dos utilitários o mais rápido possível - transforma a planilha em um editor ainda melhor.

Bem, para mim, os programas da folha de lança não conseguem lidar com essas coisas de maneira correta e eficaz. O RDB foi projetado, na verdade, para lidar com grandes dados e tabelas. Os RDB modernos foram projetados para lidar com o tipo "Enorme" de coisas e eles estão fazendo isso muito bem.

O ponto é que, para obter a melhor saída do RDB, é necessário projetar seu banco de dados da maneira correta. Se o seu esquema de dados estiver ruim ou não cobrir todos os dados do seu projeto, você terminará com resultados, desempenho e saída muito ruins.

A idéia do RDB é dividir tabelas enormes em tabelas menores, para que você possa melhorar o desempenho e a legibilidade. Se você possui uma tabela muito grande (atributos sábios ou até mesmo registros) ou muitas reparticionações, e você não usa a maioria delas, isso significa que seu design do banco de dados tem alguns erros.

Na sua pergunta Huang F. Lei, se me pedissem para criar um banco de dados do MMORPG, não adicionarei todas as habilidades em uma tabela e todos os monstros em uma tabela. Dividirei as habilidades de acordo com suas classes e uso em várias tabelas. Cada tipo de habilidade terá sua própria mesa ou até mesas. Para os mobs, eu os dividirei de acordo com seus tipos ou de acordo com sua localização em mundos diferentes. E assim por diante.

Dessa forma, posso reduzir o tamanho da tabela, facilitar o rastreamento dos dados e melhorar o desempenho do banco de dados.

No Excel, por outro lado, todos os dados serão 'fragmentados' em um só lugar. e encontrar um dado é quase intransitável, epicamente quando você tem dados repetidos. Além disso, à medida que os dados aumentam de tamanho, o tempo de abertura do arquivo aumenta.

No final, o Excel - na minha opinião - é uma maneira muito ruim de lidar com grandes dados relacionados.