Com que força um mecanismo para um jogador rejeita dados inválidos?
Em um jogo para um jogador, ao tentar criar uma entidade a partir dos componentes especificados em scripts externos, o que você acha mais desejável que ocorra quando um dos componentes está mal formado:
O mecanismo deve pular esse componente e deixar a entidade viver no mundo do jogo apenas com os componentes que foram bem escritos?
Ou não deveria adicionar a entidade ao mundo se apenas um dos componentes estiver mal formado?
Note, eu não estou falando sobre registrar os erros - que devem vir sem dizer - apenas sobre o que deve acontecer com a entidade.
Estamos falando de single-player ou multi-player?
@Lohoris Um jogador.
Como a maioria das respostas já mencionou, quem é seu público? Você está criando um jogo modável ou está falando para fins de desenvolvimento interno?
@Tetrad Eu gostaria que o jogo fosse o mais amigável possível aos modders.
Se você está falando de um jogo modável, siga uma de suas sugestões acima. Mas se você estiver preocupado em reverter seus próprios erros, eu diria que não faça isso. Eu me tornei um defensor do Fail-Fast . Se este é um erro que você criou e deve ser resolvido antes da liberação, você deve tornar o erro óbvio. O artigo ao qual está vinculado na parte inferior da página da wiki é uma boa leitura sobre o assunto com o porquê falhar rápido é bom e quando e como deve e não deve ser usado.
Eu acho que essa é uma grande dicotomia, diferenciando entre erros de usuário e erros de desenvolvedor. Faz sentido exatamente pela mesma razão que os erros do compilador geralmente são fáceis de corrigir, mas os erros de tempo de execução / semânticos são o diabo.
Se o mecanismo incluir uma maneira de modificar as entidades após o início do jogo, você deve pelo menos ter a chance de corrigir o erro antes de falhar.
— Blecki 12/09/11
A distinção entre usuário e desenvolvedor nem sempre é clara no desenvolvimento de jogos. Técnicas de programação padrão como "falha rápida" nem sempre são vantajosas, especialmente à medida que os tamanhos das equipes aumentam.
Por exemplo, talvez o seu artista técnico tenha estragado o sombreador do esquema de segmentação - quebrou o fallback, digamos, por isso está apenas carregando nos sistemas SM4, e ele não percebeu porque ele tem um sistema de primeira linha. Isso resulta em algumas animações que não são carregadas. Essas animações são referenciadas por um feitiço específico que seu designer de combate escreveu. Por fim, seu designer de níveis está tentando colocar os spawns no lugar e todos eles podem lançar esse feitiço - mas agora ela não pode colocar nenhum deles no mundo porque seus feitiços não são válidos porque os efeitos não são é válido porque os shaders não carregam porque os designers sempre têm os piores computadores.
Portanto, sua demonstração não está pronta às 14h e seus investidores se perguntam por que você não consegue nem um único inimigo no jogo e seu projeto é encerrado.
Ou você escolhe a opção em que registra a falha, mas continua tentando, e o jogo funciona bem, exceto que alguns efeitos de feitiço de inimigos não aparecem - mas os investidores não sabem como devem ser, de qualquer maneira, para que não aviso prévio.
Por esse motivo, quase sempre defenderei a primeira opção - gerar o máximo possível da entidade. Existem casos de fail-fast - como se os dados nunca fossem editados, exceto por pessoas capazes de fazer builds (ou seja, programadores e produtores técnicos) e sempre são verificados 100% em carga, ou se você tem certeza absoluta de que a pessoa responsável por o problema é a pessoa que usa o editor - mas esses não são os casos usuais e exigem muita infraestrutura técnica em si, na qual você pode não estar pronto para investir.
Gostaria de pensar que o cenário que você propõe pode ser evitado com bons sistemas de controle de origem. No seu cenário, o artista "quebrou a compilação". Qualquer pessoa que trabalhe com o shader quebrado deve poder reverter o shader para uma revisão anterior até que o problema seja resolvido.
@John Embora seja necessário um bom controle de origem e, às vezes, uma reversão seja necessária para restaurar o restante do projeto para um estado de trabalho até que uma falha seja resolvida localmente, raramente é útil como mecanismo de prevenção e não deve ser considerado como tal. .
@ John: Em projetos grandes, as compilações podem levar horas (ou um dia inteiro). Então, você realmente precisa de uma abordagem em duas frentes - você não precisa apenas de controle de origem, mas de controle binário, para que um não programador possa reverter para compilações anteriores inteiras. Mas é claro, isso tem seus próprios riscos e custos, porque agora você está desenvolvendo um novo conteúdo em relação a outro conteúdo desatualizado, com executáveis ​​que podem ter outros erros ruins. E até encontrar a construção certa para reverter pode levar mais de 30 minutos - se todos os seus designers tiverem que parar por meia hora e mexer nas construções, isso é desperdiçar muito dinheiro.
@ Joe Wreschnig: Isso faz sentido. Então, acho que deve haver um ponto em que a falha rápida não é mais um ativo. Seja no tipo de pessoa que o utiliza, seja em projetos de um determinado tamanho. Suponho que cabe às pessoas da equipe decidir o que funciona para elas.
Não tenho certeza se a falha rápida e difícil , que é realmente a questão, é sempre um trunfo. Mesmo em uma "equipe" de uma única pessoa, talvez eu não queira lidar com o código de sombreador, porque realmente preciso fazer esse nível. Certamente escrevo um bom tratamento de erros e registro todos os erros, mas quase sempre tenho uma idéia melhor do que é importante agora no momento do que quando escrevi o código de erro seis meses atrás.
O usuário deve poder visualizar a entidade que ele vai importar e saber com antecedência se há erros.
De alguma forma, você deve decidir quais erros devem ser fatais, impedindo que sejam adicionados ao jogo e quais podem ser descartados como avisos .
Obviamente, se por algum motivo a entidade importada puder alterar de alguma maneira irreversivelmente os dados do jogo de salvamento, é melhor exigir que eles sejam impecáveis.
Eu sugeriria que, no desenvolvimento, deveria ser barulhento sobre dados inválidos. ou seja, registre tudo em algum lugar que será lido. No entanto, se seu mecanismo puder ignorar isso e continuar, deve fazê-lo. Você pode ter uma lógica como
Mesmo em um jogo com vários jogadores, isso é aceitável, a menos que você esteja assumindo que um jogador está tentando enganar o sistema.
Após o lançamento do software, é provável que você queira desativar esse registro por padrão, supondo que os jogadores não vão ler esses registros.
Supondo que os logs não apresentem problemas de desempenho, você deve continuar fazendo logon nas versões de lançamento e enviar os relatórios de volta à equipe de desenvolvimento. (Apropriadamente informando jogadores, é claro.)
Você deve poder registrar logs mais concisos para liberação. No desenvolvimento, você pode tender a ser mais detalhado.