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.

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.

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.

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

void setValue(int value) {
    if (value < MIN_VALUE) {
       log(value + " is too low, using " + MIN_VALUE);
       value = MIN_VALUE;
    }
    if (value > MAX_VALUE) {
       log(value + " is too high, using " + MAX_VALUE);
       value = MAX_VALUE;
    }
}

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.