Por que é ruim codificar o conteúdo?

Eu sei que a maioria dos jogos armazena texto de diálogo em arquivos, mas também vi alguns jogos baseados em texto na verdade programando o conteúdo (mapa, escolhas, possíveis comandos do jogador, texto da história) no código do jogo.

Posso pensar em algumas razões, mas qual é a principal razão pela qual até jogos de texto mantêm tudo em arquivos fora do programa?

Os detalhes da implementação diferem pouco entre manter o conteúdo em algo como o popular formato XML, analisá-lo e renderizar mapas / exibição de texto com base nas variáveis ​​criadas a partir do arquivo XML, e simplesmente renunciar completamente ao arquivo XML. Ambos terminam com strings que são exibidas na tela. A diferença não é apenas notação?

Alguns jogos mantêm os gráficos (arte ASCII?) Dentro do código. Sei que isso não está certo e posso adivinhar alguns motivos pelos quais isso é ruim, mas também não sei o principal motivo.

É muito popular ter a maior parte do conteúdo fora do programa. Mesmo o Dwarf Fortress não usa caracteres ASCII reais, mas imagens de caracteres ASCII carregadas na memória.

Peço principalmente porque é um pouco PITA criar, analisar e trabalhar com arquivos XML. Você sabe ... comparado com a alternativa preguiçosa de apenas fazer de cada masmorra (conteúdo) sua própria classe.

Há várias razões para isso. Eu só vou tocar em alguns:

1. Isso torna seu código-fonte uma bagunça. Se você tem muitas caixas de diálogo (árvores), grande parte da sua base de código é apenas um texto que não tem nada a ver com o código do jogo.
2. Você precisaria recompilar toda vez que mudar tanto quanto um único personagem.
3. A caixa de diálogo em si é difícil de navegar. Eu imagino que tentar implementar uma árvore de diálogo inteira, muito menos várias, completamente dentro da sua fonte resultará em uma bagunça aninhada de espaguete e ifs, switches e assim por diante. O que resulta em código propenso a erros, difícil de ler e mais difícil de depurar.
4. Se você deseja permitir que as pessoas modifiquem ou expandam seu jogo, é muito mais fácil se elas não precisarem lidar com o código-fonte para mudar alguma coisa.
5. O ponto acima é ainda mais importante se você trabalha em equipe. Você não quer que seu escritor tenha que mexer com o código apenas para entrar em um pedaço de diálogo.
6. É muito fácil analisar XML ou outros formatos de arquivo padrão se você usar bibliotecas existentes; portanto, o custo de implementá-lo dessa maneira é muito baixo, oferecendo muitas vantagens e evitando os problemas mencionados acima e muito mais.
7. Como o @MiloPrice apontou abaixo, também é muito mais fácil localizar o jogo se o seu texto estiver em arquivos externos. Você pode adicionar um idioma adicionando um arquivo. Sua equipe pode cuidar da tradução sem precisar tocar na fonte (o que é especialmente importante se você permitir que as pessoas traduzam que não deveriam ver todo o seu código - pense em freelancers, pessoas da comunidade que não pertence à sua equipe etc).

Colocar os dados do conteúdo do jogo no código significa que, para ver qualquer alteração ou iteração em potencial desses dados, é necessário recompilar o próprio jogo. Isso é ruim por dois motivos:

• Muitos idiomas nos quais os jogos são escritos têm tempos de compilação longos. O C ++ é particular e pode ser muito ruim nesse aspecto, e o C ++ é uma linguagem muito comum para grandes jogos comerciais. É menos um problema com linguagens como C # e Java, mas ainda não é tão rápido quanto poder armazenar dados do jogo em arquivos externos que podem ser recarregados a quente enquanto o jogo está em execução para ver as alterações.

• Muitos jogos são desenvolvidos por equipes que geralmente consistem em desenvolvedores não técnicos (designers e artistas) que produzem conteúdo. Não apenas as pessoas não técnicas não querem ter que recompilar o jogo ou lidar com "ferramentas complicadas de programador" para iterar seu conteúdo, também pode ser desejável minimizar a exposição do código-fonte somente aos programadores (porque menos pessoas que tenha acesso ao código-fonte, menos pessoas poderão vazá-lo (acidentalmente ou não).

Acho que você está superestimando a complexidade de carregar dados de arquivos de texto ou XML. Na maioria das vezes, você deve usar uma biblioteca para fazer isso, o que facilita muito o processo de análise do XML / JSON /. Sim, há um pouco de custo inicial para escrever um sistema de carregamento de nível baseado em dados, mas isso geralmente poupa muito tempo a longo prazo, contra toneladas de classes únicas para representar cada nível.

Jogos menores ou mais simples podem não ter muito a ganhar com o investimento a longo prazo de uma abordagem orientada a dados, portanto, a menos que os desenvolvedores estejam usando estruturas / mecanismos existentes que o suportam, pode ser mais eficiente para eles simplesmente codificar os dados em o código do jogo.

É claro que existem várias razões pelas quais um determinado jogo pode optar por colocar seus dados em arquivos externos (ou não); não é possível listar todos eles. Em algum nível, eles geralmente se resumem à velocidade ou flexibilidade adicional da iteração que o não ter que reconstruir o jogo pode oferecer.

Como sempre, como sempre, depende. Mas primeiro, eu gostaria de argumentar que a codificação rígida não é ruim por si só.

Eu tenho conteúdo codificado, especificamente texto de diálogo, em alguns jogos simples, e o mundo não acabou. Nós programadores adoramos abstrair coisas, mas lembre-se de que cada camada de abstração que você faz tornará seu programa mais complexo e mais difícil de entender.

Se o seu jogo é simples o suficiente para que você possa codificar algum conteúdo nele, eu certamente o consideraria por uma questão de simplicidade.

Isso, no entanto, não escala muito. Certamente, o motivo mais comum para colocar conteúdo em recursos externos é simplificar o trabalho em equipe, pois uma pessoa ou equipe pode se concentrar em escrever o jogo, enquanto outra pode se concentrar em criar e polir o conteúdo.

No entanto, traçar a linha entre o programa e o conteúdo nem sempre é realmente trivial. Pode-se dizer que as texturas são 100% de conteúdo; mas e as texturas geradas proceduralmente? O texto da caixa de diálogo pode ser considerado 100% de conteúdo; mas e quando a caixa de diálogo muda dependendo das ações anteriores? Outros elementos que se considere 100% parte do programa, como scripts ou shaders, também podem ser considerados parte do conteúdo do jogo. Eles devem ser codificados? eles devem ser carregados como um recurso externo?

Lembre-se, porém, que cada tipo de conteúdo que você suporta no seu jogo deve ter um código de carregamento e interpretação relacionado a ele; portanto, em geral, em caso de dúvida, recomendo a codificação do conteúdo e o leve a um recurso externo quando você realmente precisa dessa flexibilidade (não quando você acha que precisa, mas quando realmente precisa)

Por fim, uma vantagem de armazenar dados em arquivos de recursos é que você pode carregá-los somente quando precisar deles (portanto, possivelmente acelerar o tempo de carregamento do jogo) e descarregá-los quando não precisar mais deles (permitindo que você tenha mais conteúdo pode caber na memória). (O canto dos nitpickers: as DLLs de recursos podem ser consideradas recursos externos)

Um grande motivo para armazenar arquivos de texto é a reutilização. A criação de uma estrutura de jogo de texto que lê seus mapas, caixas de diálogo e outros recursos de um arquivo de texto permite reutilizar sua estrutura para outros jogos. Indo além dos jogos de texto, é assim que grandes títulos do orçamento, como Call of Duty, lançam um novo jogo a cada ano.

Outro motivo é a portabilidade. Você pode usar os mesmos arquivos para web, pc, Mac, Android, etc. Tudo o que você precisa fazer é simular sua estrutura para essas diferentes plataformas, e a maior parte dos dados do jogo é intocada.

Ao ir além dos jogos baseados em texto, os scripts e os dados armazenados em arquivos diminuirão o tempo de recompilação e permitirão que você crie uma interface para manipular os dados com mais facilidade.

Para acelerar as mudanças, acelera o desenvolvimento de grandes produções em toneladas.

Você não precisa ensinar todos a aprender como entrar e editar a fonte para fazer alterações simples. Ao arrastá-lo para fora do código real, mais pessoas têm a chance de brincar, é mais fácil descobrir com quais opções você pode brincar e todo o processo de ajustar várias partes do seu jogo leva muito menos tempo. Até as perguntas e respostas podem ajudar com isso.

Não acredito que ninguém tenha mencionado isso ainda, mas um grande motivo é facilitar muito a localização. Se você precisar oferecer suporte a inglês, francês, alemão, espanhol, português, italiano, russo, chinês e qualquer outro idioma para o qual você esteja buscando, o código codificado exigirá que você tenha um code-behind separado para cada idioma. Isso também significa que, se você precisar remover determinado conteúdo (leia-se: censura), precisará alterar seu próprio código para evitá-lo, em vez de dizer "apenas substitua esse minijogo de análise anal por um banner passivo-agressivo que explica graficamente o que está acontecendo" " Também é um pouco hostil para os consumidores, pois é provável que eles precisem reiniciar o jogo para alterar o idioma, pois você precisa carregar outras bibliotecas. Finalmente,

Por outro lado, se você estiver usando recursos externos, oferecer suporte a idiomas diferentes significa apenas carregar um arquivo de recurso diferente. Isso pode ser feito facilmente enquanto o jogo está rodando. significa que você pode ter uma única base de código, simplificando bastante o desenvolvimento. E também significa que você pode adicionar facilmente suporte pós-lançamento para outros idiomas. Por fim, significa que você pode deixar o usuário optar por não instalar determinados idiomas (um recurso que não acontece com tanta frequência nos jogos, mas que ainda é possível) para economizar espaço em disco e largura de banda.

Eu acho que uma frase-chave é separação de preocupações .

Se o seu código não incluir o texto, o código será menos complexo. O programador que está escrevendo o código não precisa pensar no texto específico e pode se concentrar no código.

Ele não precisa pensar em localização. A pessoa que está localizando não precisa se preocupar com o código.

Eu acho que é muito fácil ser o cara 'murcho do que branco' e recomendar calorosamente o uso de um arquivo de recurso de texto externo.

Por quê? Porque aqui há uma opção: equilibrar o custo / problemas / vantagens de cada solução.

Ao usar um arquivo externo ... Bem, acho que as outras respostas explicam os benefícios suficientemente bem. Mas e os custos? Você precisa definir um formalismo válido, criar um intérprete, concordar com um formato de arquivo e, pior ainda ... criar outro aplicativo - um editor -. O que representa um problema de 0,00% se você for membro de uma equipe de 50 programadores que está construindo um grande projeto. Mas se você estiver sozinho: você está parado.

Novamente, não subestimo os enormes benefícios de flexibilidade de um recurso externo: a programação orientada a dados me parece o caminho a seguir para os videogames. Mas não vamos esquecer o custo.

Por outro lado, fazer com que o texto contido no código permita uma prototipagem rápida, portanto, ele deve ser preferido pela primeira vez. Então, meu conselho seria, conforme o projeto amadurecesse, analisar o tipo de dados necessários para modelar os diálogos (humor / histórico-estado / ...). Então, em algum momento, você decide algumas classes / regras / formato de arquivo e segue em frente, permitindo que outras pessoas editem / separem o código do conteúdo e assim por diante. OU para um jogo com diálogos simples (Mario ...), você considera o custo muito alto e mantém as poucas seqüências / comportamentos codificados.
Sua chamada.

(Observação sobre localização: a apenas uma tabela de hash, portanto, é uma questão independente e facilmente solucionável.)

Eu acho que o licenciamento também pode ser um motivo para não incluir conteúdo no código.

Por exemplo,

• seu código pode ser FLOSS , mas você não deseja licenciar seu conteúdo (talvez você queira publicar seu código de jogo para que outros possam usá-lo para criar jogos semelhantes com conteúdo diferente)
• seu código pode ser FLOSS, mas você deseja usar uma licença Creative Commons para seu conteúdo (como licenças de software não funcionam muito bem para conteúdo e vice-versa)
• seu código pode ser proprietário , mas você está reutilizando conteúdo gratuito
• seu código pode ser proprietário, mas você deseja publicar seu próprio conteúdo sob uma licença gratuita / gratuita