Con quale forza un motore per giocatore singolo dovrebbe rifiutare dati non validi?

In una partita a giocatore singolo, quando provi a costruire un'entità a partire da componenti specificati in script esterni, cosa pensi sia più desiderabile che accada quando uno dei componenti è mal formato:

• Il motore dovrebbe saltare quel componente e far vivere l'entità nel mondo di gioco solo con i componenti che sono stati scritti bene?
• O non dovrebbe affatto aggiungere l'entità al mondo se solo uno dei componenti è mal formato?

Nota, non sto parlando della registrazione degli errori - che dovrebbe venire senza dire - proprio di ciò che dovrebbe accadere all'entità.

Se stai parlando di un gioco modificabile, allora potresti voler seguire uno dei tuoi suggerimenti sopra. Ma se sei preoccupato di ignorare i tuoi errori, direi di non farlo. Sono diventato un sostenitore di Fail-Fast . Se questo è un errore che hai creato e che devi risolvere prima di rilasciarlo, dovresti rendere evidente l'errore. L'articolo che è collegato in fondo alla pagina della wiki è una buona lettura sull'argomento del perché il fallimento veloce è buono e quando dovrebbe e non dovrebbe essere usato.

La distinzione tra utente e sviluppatore non è sempre chiara nello sviluppo del gioco. Le tecniche di programmazione standard come "fail fast" non sono sempre vantaggiose, specialmente quando le dimensioni del team aumentano.

Ad esempio, forse il tuo artista tecnico ha rovinato lo shader per il contorno di targeting: abbiamo rotto il fallback, diciamo, quindi si sta caricando solo su sistemi SM4 e non se ne è accorto perché ha un sistema top di gamma. Ciò comporta il mancato caricamento di alcune animazioni. A quelle animazioni fa riferimento un particolare incantesimo scritto dal tuo progettista di combattimenti. Infine, la tua designer di livelli sta cercando di mettere in atto le spawn e quelle spawn sono tutte in grado di lanciare quell'incantesimo, ma ora non può posizionarne nessuno nel mondo perché i loro incantesimi non sono validi perché gli effetti non sono validi è valido perché gli shader non si caricano perché i progettisti hanno sempre i computer peggiori.

Quindi la tua demo non è pronta entro le 14:00 e i tuoi investitori si chiedono perché non puoi nemmeno avere un singolo nemico nel gioco e il tuo progetto viene chiuso.

Oppure scegli l'opzione in cui registrare l'errore ma continui a provare, e il gioco funziona bene tranne che alcuni effetti degli incantesimi dei nemici non compaiono - ma gli investitori non sanno comunque come dovrebbero apparire, quindi non lo fanno Avviso.

Per questo motivo, proporrò quasi sempre la prima opzione: generare l'entità quanto più possibile. Ci sono casi di fail-fast - come se i dati non dovessero mai essere modificati se non da persone in grado di fare build (es. Programmatori e produttori tecnici) e sono sempre controllati al 100% al carico, o se sei assolutamente sicuro della persona responsabile il problema è la persona che utilizza l'editor, ma quelli non sono i soliti casi e richiedono di per sé molte infrastrutture tecniche, sulle quali potresti non essere pronto a investire.

L'utente dovrebbe essere in grado di visualizzare in anteprima l'entità che sta per importare e sapere in anticipo se ci sono errori.

Dovresti in qualche modo decidere quali errori dovrebbero essere fatali, impedendone l'aggiunta al gioco e quali possono essere respinti come avvertimenti .

Ovviamente se per qualsiasi motivo l'entità importata fosse in qualche modo in grado di modificare irreversibilmente i dati del savegame, è meglio che sia impeccabile.

Vorrei suggerire che in fase di sviluppo, dovrebbe essere rumoroso per i dati non validi. cioè registra tutto da qualche parte che verrà letto. Tuttavia, se il tuo motore può ignorarlo e continuare, dovrebbe farlo. Puoi avere la logica come

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;
    }
}

Anche in una partita a più giocatori questo è accettabile a meno che tu non stia supponendo che un giocatore stia cercando di imbrogliare il sistema.

Dopo aver rilasciato il software, è probabile che si desideri disattivare questa registrazione per impostazione predefinita nel presupposto che i giocatori non leggeranno questi registri.