Avec quelle force un moteur solo devrait-il rejeter des données invalides?

Dans un jeu solo, lorsque vous essayez de créer une entité à partir de composants spécifiés dans des scripts externes, que pensez-vous qu'il est plus souhaitable de se produire lorsque l'un des composants est mal formé:

• Le moteur doit-il ignorer ce composant et laisser l'entité vivre dans le monde du jeu avec uniquement les composants qui ont été bien écrits?
• Ou ne devrait-elle pas du tout ajouter l'entité au monde si un seul des composants est mal formé?

Remarque, je ne parle pas de consigner les erreurs - cela devrait venir sans dire - juste ce qui devrait arriver à l'entité.

Si vous parlez d'un jeu modifiable, vous voudrez peut-être suivre l'une de vos suggestions ci-dessus. Mais si vous êtes soucieux de reconduire vos propres erreurs, je dirais de ne pas le faire. Je suis devenu un défenseur de Fail-Fast . S'il s'agit d'une erreur que vous avez créée et que vous devez résoudre avant de la publier, vous devez rendre l'erreur évidente. L'article qui est lié au bas de la page wiki est une bonne lecture sur le sujet avec pourquoi échouer rapidement est bon, et quand il devrait et ne devrait pas être utilisé.

La distinction entre utilisateur et développeur n'est pas toujours claire dans le développement de jeux. Les techniques de programmation standard comme «échouer rapidement» ne sont pas toujours avantageuses, en particulier lorsque la taille des équipes augmente.

Par exemple, votre artiste technique a peut-être foiré le shader pour le contour de ciblage - a rompu le repli, disons, donc il ne se charge que sur les systèmes SM4, et il ne l'a pas remarqué parce qu'il a un système haut de gamme. Cela entraîne le chargement de certaines animations. Ces animations sont référencées par un sort particulier que votre concepteur de combat a écrit. Enfin, votre concepteur de niveaux essaie de mettre en place les apparitions et ces apparitions sont toutes capables de lancer ce sort - mais maintenant elle ne peut en placer aucun dans le monde parce que leurs sorts ne sont pas valides car les effets ne sont pas n'est pas valable car les shaders ne se chargent pas car les concepteurs ont toujours les pires ordinateurs.

Donc, votre démo n'est pas prête à 14 heures et vos investisseurs se demandent pourquoi vous ne pouvez même pas avoir un seul ennemi dans le jeu et votre projet est arrêté.

Ou vous choisissez l'option où vous enregistrez l'échec mais continuez à essayer, et le jeu se déroule bien sauf que certains effets de sorts ennemis n'apparaissent pas - mais les investisseurs ne savent pas à quoi ils doivent ressembler de toute façon, donc ils ne le font pas remarquer.

Pour cette raison, je préconiserai presque toujours la première option - générer autant d'entités que possible. Il existe des cas d'échec rapide - comme si les données ne devaient jamais être éditées, sauf par des personnes capables de faire des builds (c'est-à-dire des programmeurs et des producteurs techniques) et étaient toujours vérifiées à 100% à la charge, ou si vous êtes absolument sûr que la personne responsable de le problème est la personne qui utilise l'éditeur - mais ce ne sont pas les cas habituels, et nécessitent beaucoup d'infrastructure technique en soi, dans laquelle vous pourriez ne pas être prêt à investir.

L'utilisateur doit pouvoir prévisualiser l'entité qu'il va importer et savoir à l'avance s'il y a des erreurs.

Vous devez en quelque sorte décider quelles erreurs doivent être fatales, en empêchant qu'elles soient ajoutées au jeu et qui peuvent être rejetées en tant qu'avertissements .

Bien sûr, si pour une raison quelconque, l'entité importée est en mesure de modifier de manière irréversible les données de sauvegarde, vous feriez mieux de l'exiger sans défaut.

Je dirais qu'en cours de développement, cela devrait être bruyant sur les données invalides. c'est-à-dire, enregistrez tout quelque part, il sera lu. Cependant, si votre moteur peut ignorer cela et continuer, il doit le faire. Vous pouvez avoir une logique comme

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

Même dans une partie multi-joueurs, cela est acceptable à moins que vous ne supposiez qu'un seul joueur essaie de tromper le système.

Après avoir publié le logiciel, vous souhaiterez probablement désactiver cette journalisation par défaut en supposant que les joueurs ne liront pas ces journaux.