Sou mais ou menos mil linhas de código para criar meu próprio jogo 2D espacial, que cria redes de sistemas estelares gerados aleatoriamente e os preenche com uma seleção aleatória de planetas, estações, navios e armas.

Potencialmente, haverá centenas de estações / navios / etc diferentes que o jogo precisará usar - então aqui está o que eu estava pensando. Devo dedicar tempo à criação de um carregador de dados 'codificado por software', que armazene todas essas informações em (por exemplo) arquivos XML e, portanto, seria um pouco mais fácil de modificar posteriormente, ou devo simplesmente seguir o que está fazendo agora - codificando todos os objetos no mecanismo principal do jogo.

Sou a única pessoa no projeto e, como eu disse, é apenas uma coisa de hobby que estou fazendo nas horas vagas fora da universidade. Mas a comunidade recomendaria investir na criação de um sistema extra inteiro de armazenamento de dados em arquivos adicionais?

Quais são os benefícios de codificar softmente os dados de uma maneira como essa, em vez de simplesmente codificá-los por meio de construtores? Existe um benefício a longo prazo em ter arquivos externos que podem ser modificados - se não estou procurando que o jogo tenha 'mods', é necessário ter arquivos externos? Se é apenas uma coisa amadora que eu poderia desistir em algumas semanas ou meses, devo perder tempo com isso?

Sim. Você deve implementar um sistema para carregar conteúdo fora do mecanismo principal.

Cabeçalhos para respostas sucintas.

Não. Não consome muito tempo.

Eu acho que a questão de saber se é uma alocação válida de seu tempo limitado é discutível; mesmo que seja apenas uma pequena parte do tempo total do projeto.

Você passará centenas (milhares) de horas em um projeto de jogo que concluirá. Talvez não em um clone de Pong, mas certamente no seu jogo espacial complexo. Compare isso com um leitor de arquivo de configuração. A implementação de um sistema para XML tubo em seu construtor principal, e posteriormente reiniciar a processo de jogo, terá talvez 10 ou 20 horas. Mesmo se você precisar de 50 ou 100, será uma pequena fração do tempo total do projeto.

Economizará tempo

Não é uma despesa de tempo; é um investimento de tempo. E vai valer a pena.

O fluxo de trabalho é importante, e ter um carregador de configuração tornará seu fluxo de trabalho melhor. Ao criar um sistema que permite editar configurações dinamicamente, você salvará inúmeras reconstruções. Você pode ver o jogo enquanto ele estiver rodando, ajustar o XML e verificar novamente em segundos. Ou você pode olhar para o código, encontrar uma linha de código (entre milhares), editar seus valores com muito cuidado (você está no seu mecanismo principal, afinal), reconstruir, executar, colocar o jogo de volta ao estado de teste, tentar lembre-se de como era antes da alteração e veja se sua alteração teve o efeito que você pretendia. Assumindo que nada quebre no seu motor, seu trem de pensamento certamente está interrompido.

De uma perspectiva mais básica da ciência da computação, tente lembrar que a parte mais demorada da criação de software não é a introdução de algumas teclas ou espaços em branco extras. É caça de insetos. E se você gastar um pouco de tempo extra para tornar as coisas mais claras escrevendo um código mais detalhado, economiza muito mais tempo depois. No seu caso, escrever um importador de conteúdo resulta em um código mais limpo que será mais fácil de ler. Em vez de milhas e milhas de valores codificados, sua fonte apresentará um simples carregamento de arquivo. Da mesma forma, você pode ler o arquivo de configuração sem percorrer o código do mecanismo do jogo. Ambas as partes se tornam mais fáceis de manter e mais fáceis de depurar.

As equipes de um membro são as que mais beneficiam

Se você contratou um artista para gerar parte desse conteúdo, seria necessário criar ferramentas para eles trabalharem. Eles precisam fazer edições de pixel e ver os efeitos rapidamente. Você não ousaria forçá-los a reconstruir o código para ver todas as alterações. O tempo deles é caro e você não quer desperdiçá-lo.

Agora imagine que o artista é muito pouco qualificado e lento (artista programador) e tem muitas outras coisas com que se preocupar, porque eles também são o principal programador e músico. Você definitivamente não quer perder esse tempo, ou o projeto nunca terminará. E esse artista ruim odiará o treinamento para ser um artista melhor, porque passa o tempo todo renomeando cadeias de ativos em código.

Não faça isso consigo mesmo. Faça as ferramentas e você terá mais tempo para fazer um jogo.

Essa é uma boa pergunta e a melhor resposta que posso dar é que apenas a experiência pode realmente lhe dizer quando é uma boa ideia seguir o caminho mais difícil / demorado. Se alguém lhe disser que você SEMPRE deve fazê-lo da maneira 'adequada', então eles estão simplesmente errados.

Você já entende que é uma troca. Por um lado, a codificação é tão tentadora porque é rápida e fácil, mas a longo prazo, adicionar recursos e depuração se tornará um pesadelo. Por outro lado, escrever um sistema excelente, flexível e expansível requer um grande investimento inicial, mas torna a vida muito mais fácil a longo prazo.

O objetivo é concluir alguma coisa e, se você se atrapalhar ao criar um ótimo sistema, o objetivo recuará ainda mais e você perderá a motivação. O código embutido é bom em algumas circunstâncias, mas você deve entender as implicações de fazê-lo. Aqui estão algumas razões pelas quais a codificação é uma má idéia:

• Você pode pensar que seu projeto é pequeno, mas é possível que ele cresça conforme você decide adicionar mais recursos. Se você começar a codificar, chegará um momento em que a energia necessária para mantê-lo (atualizando-o com coisas novas e corrigindo uma infinidade de erros inevitáveis) começará a compensar seriamente os ganhos iniciais.

• O material codificado é, por definição, específico para o projeto atual. Para o próximo projeto, você terá que começar do zero novamente, possivelmente codificando novamente as coisas (porque é com isso que você se sentirá confortável). Se você tivesse investido tempo em um sistema de carregamento decente, poderia pular esse trabalho e dores de cabeça para todos os projetos futuros.

• Você pode estar trabalhando sozinho no momento, mas pode chegar um momento em que você deseja trazer alguém para o projeto. Você vai ter tempo para explicar seu sistema paroquial nojento e escrever documentação para ele?

• A codificação embutida geralmente envolve ter que saber o que certos números mágicos significam ou dependências de classe complicadas. Você pode manter tudo em mente agora, mas espere até que você esteja longe do código por um tempo. Mesmo com comentários extensos, uma estrutura mal projetada é um inferno para o qual voltar.

Eu diria que você deve se sentir à vontade para codificar as coisas apenas nos mínimos detalhes. Se você tem a menor noção do elemento no qual está trabalhando, sendo usado por outra pessoa, ficando muito maior ou em outro projeto, reserve um tempo para fazê-lo agora.

Por outro lado, protótipo como um louco e codificar certas coisas é rápido e fácil e deixa você livre para se concentrar em experimentar. Depende do seu estilo de trabalho.

O que você está falando é sobre programação orientada a dados .

Para projetos pequenos, pode não valer o investimento de tempo, pois geralmente há recursos muito mais importantes que você pode melhorar.

No entanto, a programação orientada a dados pode ser MUITO fácil de implementar. Se você é sério, provavelmente deve usar XML, JSON ou YAML, mas também pode usar arquivos de texto sem formatação.

Programação orientada a dados

Prós

1. Permite que os designers acessem e modifiquem os dados do jogo sem conhecimento de programação
2. Você pode fazer modificações no jogo sem precisar recompilar . Isso não deve ser subestimado, pois você pode desenvolver um jogo muito mais rapidamente dessa maneira. Bons jogos vêm depois de muitas iterações.

Contras

1. Leva tempo e esforço para implementar.
2. Isso pode aumentar a complexidade do programa.