Quando devo codificar os dados em vez de carregar dados externos?

36

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?

Singular1ty
fonte
10
O termo que você procura é "Data Driven" e, sim, é muito mais rápido a longo prazo criar novas estações e navios com arquivos XML (ou qualquer formato como o JSON) do que o que você está fazendo em um projeto menor . Além disso, mais tarde você pode remover e editar sem precisar tocar no código e recompilar, para economizar uma segunda vez.
Patrick Hughes
@PatrickHughes Ao digitar minha resposta, você já a comenta!
MartinTeeVarga
1
Se estamos tentando legitimar "codificação flexível" como um termo real, proponho a codificação firme como "usando uma entrada codificada para uma matriz de dados codificada".
precisa
1
@ Singular1ty, este site perdoa mais as discussões do que alguns outros SEs. Acho que sua pergunta se qualifica para o status "boa discussão".
amigos estão dizendo sobre seth battin
2
@ Singular1ty Ah, aqui está. Não foi possível encontrá-lo quando publiquei meu primeiro comentário. blog.stackoverflow.com/2010/09/good-subjective-bad-subjective
Seth Battin

Respostas:

62

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.

Seth Battin
fonte
3
Uau, outra resposta fantástica! Muito obrigado. Definitivamente, concordo com a capacidade de alterar valores rapidamente - e também na busca de bugs. Esquecer uma ou duas coisinhas está rapidamente se transformando em um pesadelo, e eu quero fazer o que for necessário para reduzir a repetição das mesmas linhas de código sem parar, com apenas pequenas alterações entre alianças, nomes e valores de casco / arma.
precisa
Seth, seja bem-vindo ao seu novo nível de privilégio. Use seus votos próximos e reabra bem!
MichaelHouse
Eu agradeço, obrigado. Vou esperar um pouco para usá-los. Tenho recebido algumas flutuações de rep em contas com votação antecipada que são excluídas.
Seth Battin
10

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.

DaleyPaley
fonte
Obrigado pela resposta. Já estou descobrindo que meu sistema está ficando fora de controle. Por causa da extensão de coisas em java, minhas classes geralmente têm de dez a quinze argumentos construtores, e eu sempre esqueço em que ordem elas entram. Estou acostumado a fazer coisas 'rápidas e sujas', porque minha atenção é muito curta, mas Eu gostaria de terminar um projeto pela primeira vez. Além disso, se eu sinto a necessidade de ajustar estatísticas para as coisas mais tarde, eu não quero ficar preso com arrasto através de milhares de linhas de objetos codificados ...
Singular1ty
@ Singular1ty Nesse caso, pare o que está fazendo agora. É hora de refatorar como um louco. Esqueça qualquer novo conteúdo e concentre-se em melhorar a estrutura geral existente. Eu trabalho em uma empresa de jogos e estou sempre pressionando por um período de folga e refatoração. Mas, é claro, cai em ouvidos surdos e sempre acabamos triturando como loucos, percorrendo pedregulhos infestados de insetos / hack. Ho hum
DaleyPaley
8

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.
Nick Caplinger
fonte
Estes são apenas alguns dos prós e contras em que consigo pensar agora; deixe-me saber se você pensa em mais!
perfil completo de Nick Caplinger
1
Eu aprovei sua edição para o meu título.
precisa