上位互換護石の検出処理の改善

[EXXXI]

イベクエ等も落ち着いてMRまで更新が空くであろう4月以降に着手予定
現状の実装方式は1つのスロットで1Lvしかスキルが増えない前提になっている
そのためMRでの拡張次第では正常に判別できなくなる可能性がある

あまりヘビーな実装にすると護石登録数によっては重くなるかもしれないので性能面も要検証
場合によっては護石が多すぎる場合には起動時に警告&ON/OFF選択させる

[willybilly981]

BY GPT 5.5

上位互換護石の検出処理 改善計画

結論

「MRなどの拡張で、1つの装飾品が1Lvを超えるスキル上昇を持つ場合に備えて判定処理を見直す」という方針は正しいです。

また、上位互換護石の検出は追加護石数に対して総当たりに近い処理になるため、登録数が多い場合に起動時警告とON/OFF選択を用意する方向も妥当です。ただし、警告のしきい値は固定値で決め打ちせず、性能検証の結果を見て設定する方針とします。

現状確認

対象処理は主に以下です。

• src/SimModel/Model/Masters.cs
  • CalcLowerCharm() で追加護石同士を比較し、下位互換または同値の護石に Upper を設定している。
• src/SimModel/Model/Equipment.cs
  • IsLeftUpper(left, right, useDecos) で、左側の護石が右側の護石の上位互換かを判定している。
• src/SimModel/Domain/FileOperation.cs
  • LoadAdditionalCharmCSV() の最後で Masters.CalcLowerCharm() を呼んでいる。
• src/SimModel/Domain/DataManagement.cs
  • 護石追加、削除時に Masters.CalcLowerCharm() を呼んでいる。
• src/SimModel/conf/LogicConfig.csv
  • 下位互換護石の検出有無 で機能ON/OFFの設定は既に存在する。

現状の課題

1. 正確性の課題

現行の IsLeftUpper() は、不足しているスキルLvを装飾品で補えるか確認する際に、該当スキルを持つ装飾品を1つ取得し、不足Lv数だけ同じスロット要求を積み上げる形になっています。

この方式では、たとえば次のようなケースで誤判定する可能性があります。

• 不足スキルが攻撃Lv2
• 実際には 攻撃珠II【2】 1つで補える
• 現行処理では 攻撃珠【1】 2つ相当として扱う可能性がある
• 2スロット1個で足りるケースを、1スロット2個が必要と見なしてしまう

現行CSVにもスキル値2の装飾品が存在するため、これは将来拡張だけでなく現在データでも潜在不具合になり得ます。

2. 性能の課題

CalcLowerCharm() は追加護石同士を二重ループで比較しています。さらに比較中に装飾品マスタを検索しているため、登録護石数が増えるほど起動時または護石追加、削除時の負荷が大きくなります。

概算では、追加護石数を N とした場合、比較回数は最大で N x (N - 1) です。500件で約25万回、1,000件で約100万回の比較になります。

改善方針

方針A: 装飾品で補えるかの判定を正確化する

不足スキルに対して「最初に見つかった装飾品を不足Lv分だけ使う」のではなく、装飾品のスキル値を考慮して、必要なスロット構成を求める方式に変更します。

実装候補は以下です。

• スキル名と必要Lvごとに、補完可能な装飾品パターンを事前計算する。
• 各パターンをスロット要求量として保持する。
• 上位互換判定時は、左護石の余剰スロットが右護石のスロット性能と不足スキル補完分を満たせるか確認する。

この方式なら、スキルLv2以上の装飾品、複合装飾品、今後のMR相当拡張にも対応しやすくなります。

方針B: 比較処理の軽量化を同時に行う

重くなりすぎないよう、以下を合わせて実施します。

• 装飾品検索結果を毎回LINQで探さず、起動時にキャッシュする。
• 護石ごとのスキル辞書とスロット情報を比較前に正規化する。
• 同一性能の護石はシグネチャでまとめ、必要以上に同じ比較をしない。
• 護石追加時は新規護石と既存護石の比較を中心にし、全件再計算を避けられるか検討する。
• 護石削除時は削除された護石を Upper に持つ護石だけ再計算する方向を検討する。

最初の実装では、正確性を優先しつつ、キャッシュ化と早期returnで体感負荷を抑えるところまでを必須範囲とします。インクリメンタル再計算は、性能検証で必要と判断した場合に実施します。

方針C: 件数過多時の警告とON/OFF選択を用意する

現状では LogicConfig.csv に 下位互換護石の検出有無 があるため、機能のOFF自体は可能です。

追加する導線は以下を想定します。

• 追加護石数がしきい値を超えた場合、重くなる可能性を起動時に警告する。
• 警告は重い計算を実行する前に出す。
• 選択肢は「今回は検出する」「今回は検出しない」を基本とする。
• 将来的に必要であれば「次回から同じ選択を使う」を追加する。
• UI表示はWPF側、判定や件数情報はSimModel側に寄せ、Model層から直接MessageBoxを出さない。

しきい値は暫定で以下を候補にします。

• 300件以上: 計測ログ対象
• 500件以上: 警告候補
• 1,000件以上: 初期表示でOFF推奨候補

最終値は実測で決めます。

実装計画

Phase 1: 現行挙動の再現テスト作成

目的は、現在の誤判定パターンを明文化してから修正することです。

確認ケース:

• スキルLv1装飾品だけで補うケースは現行と同じ判定になること。
• スキルLv2装飾品1個で補えるケースが上位互換として判定されること。
• 1スロット2個が必要なケースと、2スロット1個で足りるケースを区別できること。
• 複数スキル不足時に、要求スロットの合算が正しく判定されること。
• 同値護石はこれまで通り「同値」として表示されること。

テストプロジェクトが存在しないため、まずは小さなテストプロジェクト追加、または検証用の内部テストコード追加を検討します。

Phase 2: 装飾品スロット要求のキャッシュ追加

追加候補:

• DecoSlotRequirement
  • スロット種類、スロットサイズ、個数を表す値オブジェクト。
• DecoSkillRequirementCache
  • skillName と requiredLevel から、実現可能なスロット要求候補を返す。
• SlotProfile
  • 護石や装飾品のスロット能力を比較しやすい形に正規化する。

実装ポイント:

• 装飾品マスタ読み込み後にキャッシュを構築する。
• スキルLv2以上の装飾品を候補として扱う。
• 同じスキルを持つ複数装飾品のうち、必要スロットが明らかに劣る候補は枝刈りする。
• スロット最大サイズは LogicConfig.Instance.MaxSlotSize を使い、将来4スロット化しても追従しやすくする。

Phase 3: IsLeftUpper() の判定差し替え

差し替え内容:

• 不足スキルの抽出処理は維持する。
• 不足スキルごとに装飾品補完候補を取得する。
• 複数不足スキルがある場合は、候補を組み合わせて必要スロットを計算する。
• 左護石のスロットが「右護石のスロット性能 + 不足スキル補完分」を満たせるか判定する。
• 装飾品で補えないスキルがある場合は上位互換なしとする。

注意点:

• useDecos == false の既存挙動は維持する。
• SlotType1 などのスロット種類は既存仕様を踏襲する。
• SlotType == 2 の扱いは現行上コメント上は「両方可」なので、実装時に現行データと検索ロジックの仕様を確認する。

Phase 4: 性能検証

検証観点:

• 起動時の LoadAdditionalCharmCSV() から CalcLowerCharm() 完了までの時間。
• 護石追加時の所要時間。
• 護石削除時の所要時間。
• 登録数ごとの比較時間の増え方。

検証件数:

• 100件
• 300件
• 500件
• 1,000件
• 2,000件

記録項目:

• 追加護石数
• 比較回数
• 実行時間
• GC発生有無
• UIフリーズ感の有無

Phase 5: 件数警告とON/OFF選択の実装

性能検証の結果、起動時の体感遅延が許容範囲を超える場合に実装します。

実装方針:

• Simulator.LoadData() の中で無条件に重い計算を始める構造は避ける。
• 追加護石CSVの読み込み後、下位互換計算前に追加護石数を判定できる形へ整理する。
• UI側でユーザー選択を受け取り、今回の起動で CalcLowerCharm() を実行するか決める。
• OFF選択時は Upper をすべて空にし、護石一覧には上位互換メッセージを出さない。

受け入れ基準

• スキルLv2以上の装飾品で補えるケースを上位互換として正しく検出できる。
• 既存のスキルLv1装飾品前提ケースで判定結果が劣化しない。
• 既存の同値表示が維持される。
• 追加護石100件程度では、起動時や護石追加時に体感できる遅延が増えない。
• 追加護石500件以上のケースで、実測値に基づいた警告要否を判断できる。
• 下位互換検出OFF時に、検索機能や護石登録機能へ副作用が出ない。

リスクと対応

リスク1: 判定を正確にしすぎて処理が重くなる

対応:

• 装飾品候補を事前計算する。
• 支配されるスロット要求候補を枝刈りする。
• 必要に応じて護石性能シグネチャ単位に比較をまとめる。

リスク2: 複合装飾品の扱いで判定が複雑化する

対応:

• 初期対応では「不足スキルを満たすための必要スロット候補」として扱う。
• 複合装飾品の副次スキルをどこまで有利に見るかは、過剰判定を避けるため仕様を明文化する。
• まずは単一不足スキルとLv2以上装飾品の正確化を必須範囲にする。

リスク3: 起動時警告が頻繁で煩わしくなる

対応:

• 警告はしきい値超過時のみ表示する。
• 初期実装は「今回だけ」の選択に留める。
• 必要であれば設定保存を後続対応にする。

まとめ

現状の上位互換護石検出は、1つの装飾品で1Lvだけ補える前提が残っており、スキルLv2以上の装飾品がある場合に誤判定する可能性があります。加えて、追加護石数に対して総当たり比較を行うため、登録数が増えると起動時や護石追加、削除時の負荷が大きくなります。

対応としては、装飾品のスキル値を考慮したスロット要求キャッシュを導入し、上位互換判定を正確化します。性能面ではキャッシュ化、早期return、同一性能の集約を行い、実測結果によっては起動時に警告とON/OFF選択を追加します。

まずは誤判定ケースのテスト化と判定ロジックの差し替えを優先し、その後に100件から2,000件程度の追加護石データで性能検証を行い、警告しきい値を決定します。

[EXXXI]

不足するスキルは1つとは限らないので「スキル名と必要Lvごと」だけではうまく行きません。
簡易的なスキルシミュを行うことで解決させる予定です。
そのためにまず #98 で特殊なシミュの実行が簡単にできる形にリファクタリングする予定です。