Pour un moteur de jeu personnalisé, que dois-je faire si mes données de base sont malformées ou manquantes?

J'écris un moteur personnalisé pour un jeu. J'ai commencé ce jeu bien avant de comprendre pourquoi je devrais utiliser un middleware à la place, et c'est trop loin pour être réécrit.

La grande majorité de mes données provient de fichiers externes, et je ne me réfère pas seulement aux actifs; Je définis tous mes objets de jeu via .JSON. Mais, hélas, je suis humain; parfois mes fichiers de données ne sont pas valides, ou je change le format mais oublie de mettre à jour le fichier, ou le chargeur lui-même est un buggy à plat.

Si, pour une raison quelconque, une tentative de chargement d'une forme d'actif dans un moteur personnalisé échoue, quelles options ai-je?

Ce n'est pas un doublon de Comment dois-je gérer les ressources manquantes? , car cette question concerne les ressources destinées aux utilisateurs telles que les modèles ou les textures. Les mauvaises textures peuvent être remplacées par un damier, les mauvais sons avec silence et les mauvais textes avec "ERREUR". Mon problème réside dans les données qui sont essentielles au jeu même en cours d'exécution, telles que les niveaux, les définitions d'objets de jeu et les dispositions d'interface graphique.

Enregistrez une erreur et quittez gracieusement.

Idéalement, affichez également une erreur lisible par l'homme à l'écran. Il devrait y avoir un pipeline de base de fonctionnalités codées en dur qui fonctionne sans ces fichiers de données. C'est le même pipeline qui charge les fichiers de données en premier lieu. Il devrait être capable de détecter le moment où ces fichiers de données de base sont corrompus ou autrement défectueux et de fermer l'application. Si les utilisateurs ont l'intention de modifier ces fichiers, il n'y a pas grand-chose d'autre à faire. Sinon, vous devez mettre en œuvre une stratégie de test pour vous assurer que ce type de corruption ne se produit pas. Ensuite, vous pouvez vous assurer que vous ne publiez que des fichiers de données valides.

Byte56 a mentionné une option. Il y en a au moins un autre:

Supposez les valeurs par défaut et affichez un avertissement.

Selon la nature de vos données, il peut être parfaitement acceptable de supposer certaines valeurs par défaut et d'avertir l'utilisateur que «puisque le fichier xxx n'a pas pu être chargé, nous utilisons un objet générique yyy».

Cela dépend si cela se produit pendant le développement ou la version.

Pendant le développement, vous aurez toutes sortes de choses manquantes, d'erreurs et de bugs, constamment et tout le temps, et vous voudrez peut-être même charger à chaud des ressources à la demande ou remplacer une ressource pendant le jeu. Vous pouvez éditer des scripts avec le jeu en cours d'exécution pour tester une IA plus performante, ou quelque chose de similaire.

Il est très ennuyeux si le programme affiche une boîte de dialogue d'erreur et se ferme à chaque fois, et vous devez le redémarrer, ce qui prend 2-3 minutes. L'objectif en développement est de vous caler (dont le temps est le bien le plus précieux) le moins possible.
Donc, si par exemple, une texture manque, vous voudriez voir quelque chose comme un damier rouge-blanc, peut-être avec le mot "manquant" orthographié dessus comme texture de remplacement, il est donc immédiatement évident que quelque chose est étrange . Mais vous ne voulez pas que le jeu se termine correctement, ni même qu'il plante. Des informations détaillées sur ce qui manque dans votre fichier journal sont extrêmement utiles.

D'un autre côté, dans une version, l'ensemble complet des fichiers de ressources devrait idéalement ^[1] être passé par votre pipeline de ressources automatisé. Cela ne doit pas être beaucoup plus qu'un simple analyseur qui lit tous vos JSON et vérifie ensuite que chaque module est cohérent en soi, et vérifie que chaque actif que vous référencez est réellement là, puis zippe tout le tas de fichiers d'une manière connue (mais pas nécessairement standard) qui est facile à lire pour votre moteur, en ajoutant éventuellement quelques sommes de contrôle.

Vous savez qu'il ne peut y avoir d'échec car votre pipeline a vérifié que tout était là avant de publier le package à l'utilisateur final. Donc, si un échec se produit, soit il y a eu une erreur de transmission, soit il est plus probable que l'utilisateur essaie de tricher. Dans les deux cas, le programme devrait afficher un message indiquant que les fichiers de ressources sont endommagés et quitter.

Alternativement, vous pouvez offrir la possibilité de télécharger une copie vierge des actifs à partir d'Internet (si vous avez un serveur de téléchargement). Mais afin d'éviter un cauchemar de support client, assurez-vous de demander avant de télécharger des gigaoctets de données.

^{[1] La} réalité peut sembler différente, vous pouvez même trouver des actifs manquants sur des titres AAA dont les créateurs "devraient savoir", mais ils ont généralement des délais irréalistes et de grandes équipes changeantes aussi. Idéalement, tout ce que vous expédiez est passé par le pipeline automatisé et est garanti d'être complet.