Valider la forme et les plages autorisées
Définissez la structure d’un niveau avec ses champs obligatoires, par exemple id, width, height, tiles, spawn, exits et entities. Vérifiez que les dimensions sont des entiers positifs compris dans les limites prises en charge par le jeu, que le tableau de tiles contient exactement width × height éléments et que chaque tile utilise un type connu. Validez les coordonnées des entités par rapport à la grille et exigez des identifiants uniques pour les portes, clés, interrupteurs et objectifs. Vérifier uniquement qu’une valeur est numérique ne suffit pas : rejetez explicitement les valeurs similaires à NaN ou hors limites.
Séparez les champs facultatifs des champs obligatoires. Attribuez une valeur par défaut à une palette décorative omise, mais n’inventez pas silencieusement un point d’apparition ou une sortie manquants si cela risque de changer le puzzle. Renvoyez les erreurs avec un chemin tel que levels[2].entities[4].x afin que la personne qui rédige le contenu trouve rapidement le champ défectueux.
Vérifier les relations et les invariants jouables
Après validation structurelle, vérifiez les règles inter-champs. Chaque porte verrouillée doit faire référence à une clé existante ; chaque clé obligatoire doit être accessible devant sa porte ; une sortie ne doit pas se trouver à l’intérieur d’une tuile solide. Lancez une recherche de chemin depuis le point d'apparition et confirmez que les objectifs requis peuvent être atteints selon les règles de mouvement du jeu. Si des ennemis ou des plates-formes en mouvement affectent l'accès, utilisez un validateur plus spécifique ou un test de jeu plutôt que de prétendre qu'un simple chemin de grille prouve que l'ensemble du niveau peut être résolu.
Échouez en toute sécurité et testez le validateur lui-même
MDN indique que JSON.parse lève une SyntaxError lorsque le JSON n’est pas valide : traitez donc les erreurs d’analyse séparément des erreurs de schéma. En développement, indiquez le fichier exact et la règle non respectée. Dans la version destinée aux joueurs, chargez une solution de repli connue ou affichez clairement que le niveau est indisponible, plutôt que de démarrer avec des données partielles. Gardez des cas de test pour les champs manquants, les références incorrectes, les chemins bloqués et un petit niveau valide ; ce dernier évite qu’un validateur rejette tout.
Questions sur validation des données au niveau du jeu
Un JSON.parse réussi est-il suffisant pour faire confiance à un fichier de niveau ?
Non. L'analyse confirme la syntaxe, et non la forme, les plages, les références ou les règles de solvabilité spécifiques au jeu. Validez chacun d’eux avant de passer le niveau au code de gameplay.
Le jeu doit-il réparer automatiquement les niveaux invalides ?
Uniquement pour des valeurs par défaut sûres et sans ambiguïté. Si la réparation d'un objectif ou d'un itinéraire manquant modifie la conception, rejetez le niveau et utilisez une solution de repli connue au lieu de masquer le défaut.
Pour aller plus loin
Vous avez repéré une information dépassée ? Signaler une correction