形状と許容範囲を検証する
id、width、height、tiles、spawn、exits、entitiesなど、レベルに必要なフィールドを定義します。寸法がゲームの対応範囲内にある正の整数であること、タイル配列の要素数がwidth × heightと一致すること、各タイルが既知の種類であることを確認します。エンティティの座標がグリッド内にあるか検証し、ドア、鍵、スイッチ、目標には重複しないIDを要求します。数値かどうかだけの確認では不十分です。NaNのような値や範囲外の値は明示的に拒否します。
任意フィールドと必須フィールドを分けて扱います。省略可能な装飾用パレットには既定値を使えますが、パズルの設計が変わるおそれがある場合は、欠けているスポーン地点や出口を黙って補わないでください。levels[2].entities[4].xのようなパスを付けてエラーを返せば、コンテンツの作成者が問題のあるフィールドをすぐに見つけられます。
関係と再生可能な不変条件を確認する
構造検証後、クロスフィールドルールをチェックします。施錠されたすべてのドアは既存のキーを参照する必要があります。すべての必須キーはドアの前で到達できる必要があります。出口は固体タイルの内側にあってはなりません。スポーンからパス検索を実行し、ゲームの移動ルールに従って必要な目標に到達できることを確認します。敵や移動するプラットフォームがアクセスに影響を与える場合は、単純なグリッド パスがレベル全体が解決可能であることを証明すると主張するのではなく、より具体的なバリデーターまたはプレイスルー テストを使用してください。
安全に失敗してバリデータ自体をテストする
MDN によると、JSON が無効な場合、JSON.parse は SyntaxError をスローします。そのため、解析エラーとスキーマエラーは分けて処理します。開発中は、該当するファイルと違反した条件を正確に報告します。プレイヤー向けのビルドでは、不完全なデータで開始せず、既知の代替レベルを読み込むか、レベルを利用できないことを明確に表示します。フィールド欠落、誤った参照、通行不能な経路、小さな有効レベルのテストケースを用意します。有効なケースを含めることで、バリデーターがすべてを拒否する問題を防げます。
ゲームレベルのデータ検証についての質問
JSON.parse が成功すれば、レベル ファイルを信頼するのに十分ですか?
いいえ。解析では、ゲーム固有の形状、範囲、参照、または可解決ルールではなく、構文が確認されます。レベルをゲームプレイ コードに渡す前に、それぞれを検証してください。
ゲームは無効なレベルを自動的に修復する必要がありますか?
安全で明確なデフォルトの場合のみ。欠落している目標またはルートを修復することで設計が変更される場合は、レベルを拒否し、欠陥を隠す代わりに既知のフォールバックを使用します。
関連情報
古い情報を見つけましたか？ 訂正を連絡