検証

検証はValidationFacadeを通じて自分で呼び出すもので、保存や読み込みには組み込まれていません。問題はError、Warning、Adviceに分かれ、ValidateAndFixは直せるものを修正します

どこで実行するかはゲームが決めます。エディターでレベルを開くと問題が報告されますが、プレイ時にはチェックを省きます。つまり、検証を待つのは作者で、プレイヤーが待つことはありません

レベルの作者が検証に出会うのは、レベルをサービスに提出するときです。詳細：公開プロファイル

呼び出し方

ValidationFacadeが唯一の入り口です。呼び出し側は、パスがいくつあるかを知る必要はありません：

var facade = new ValidationFacade();
var report = facade.Validate(level);

if (report.HasErrors)
    Console.WriteLine(report);

ValidationReportはRuleIssuesとGraphIssuesを持ちます：

• IsValid：問題がまったくない
• HasErrors：Errorグループの問題が少なくとも1つある

重大度

ルールはそれぞれRuleGroupに属します：

• Error：書かれたとおりにはファイルをプレイできない
• Warning：プレイはできるが、意図どおりにならない（決して現れない内容、フォールバックのある壊れた参照）。または、唯一の修正方法が破壊的
• Advice：プレイには影響しない

3つのパス

ルール

型は[RuleContainer]マーカーによってチェックの対象になります。そのプロパティにルールの属性を付けます：

• [RuleNotNull]、[RuleInRange]、[RuleMinValue]、[RuleEnumValid]、[RuleCollectionMaxCount]など
• [RuleEnumFlagsValid]：フラグのenum用
• [RuleOptional]：なくてもよいフィールド用

制限値そのものは、Rules/のテーブルにある定数です：FrameRules、ValueRules、LevelRulesなど。たとえばLevelRules.MaxObjectsは262,144です

すべてのルールコンテナーの走査は、リフレクションを使わずにBH.SDK.Roslynが生成します。大きなレベルでは、これで所要時間がおよそ半分になります

修正

ルールの属性はどれも、自分の値を修正できます（Fix）。RuleFixerは修正をトレースの逆順に適用します。修正によって、より深い場所の問題がずれることがあるからです。ValidateAndFixは、結果が変わらなくなるまでパスを繰り返します

グラフのパスは修正の後に実行されます。修正そのものがグラフに問題を生むことがあるからです。たとえば、新しいIDが既存のIDと重なる場合です

グラフの問題は決して修正されません：DuplicateObjectId、MissingParent、ParentCycle、PrefabRemapBroken、IdCounterNearExhaustionなど。こうした修正はどれも、内容についての判断（2つのオブジェクトのどちらがIDを残すか）になります。推測で直すとレベルを書き換えてしまいます