ヒント

JSONファイルはコメントをサポートしていません。テキスト内のコメントはプレゼンテーション用にのみ使用されます。直接コピーして使用しないでください。

ローグリソースの保存場所

• resource/roguelike/ には、各ローグテーマに応じての運用リソースが格納されています

  • テーマフォルダ： Phantom/ はファントム、 Mizuki/ はミヅキ、Sami/ はサーミ、Sarkaz/ はサルカズ、JieGarden/ は界園、BlackFlow/ は黒流樹海
    • autopilot/ には、各ステージの戦闘jsonが含まれます
      • ステージ名.json ステージの戦闘ロジック
    • encounter/ 思わぬ遭遇イベントロジック
      • default.json 経験値モード
      • deposit.json 源石錐モード
    • recruitment.json オペレーター招集ロジック
    • shopping.json ストア購入ロジック

• 特に、Sami/ の下の

  • foldartal.json はサーミの啓示板の使用ロジックを表す
  • collapsal_paradigms.json はサーミのパラダイムロストの種類を表す
  • autopilot/ステージ名_collapse.json ステージの戦闘ロジック（パラダイムロスト収集モード）
  • encounter/collapse.json パラダイムロスト収集モードの思わぬ遭遇ロジック

• Sarkaz/ の下の

  • fragments.json はサルカズの思案の基本情報を保存
  • map.json はサルカズの位置測定分隊のルーティング用テンプレート画像情報を保存

• JieGarden/ の下の

  • coppers.json は通宝の基本情報と拾取・交換ロジック
  • map.json は界園ローグのマップノードのテンプレート画像情報を保存

• BlackFlow/ の下の

  • strategy.json は黒流樹海ローグの高レベルルーティング戦略設定
  • node_execution.json は黒流樹海ローグのノードタイプ処理ルーティング設定
  • map_perception/ は黒流樹海ローグのマップ認識ビジュアルリソース
  • scrap_market.json は黒流樹海ローグの秘境行商データ（自然物の価格、更新費用、育成保留上限）
  • map_templates.json は黒流樹海ローグのマップレイアウトテンプレート

ローグの始め--オペレーター招集

resource/roguelike/テーマ名/recruitment.json にオペレーター招集ロジックを記述しました

{
    "theme": "Phantom",              // ローグテーマ（ここはファントム）
    "priority": [                    // グループの優先度、順序
             ...
        ],
    "team_complete_condition": [     // ラインアップの完備度チェック
             ...
        ]
}

オペレーターの分類

ゲーム理解に基づいて、オペレーターを異なる groups （グループ、関連概念は自動戦闘フロープロトコルを参照）に分類します

注意

1. 同じグループ内のオペレーターと召喚物は、配置方法が同じである必要があります（つまり、両方が近接か、両方が高所に配置されている）

2. 同じオペレーターや召喚物でも、使用方法に応じて異なるグループに分類されることがあります

3. 既存のグループ名を変更しないでください。 MAA の更新時に以前のバージョンの作業が使用できなくなる可能性があります

4. 新しいグループを追加しないようにし、新しく追加されたユニットを使用法に基づいて既存のグループに組み込むようにしてください

ヒント

デフォルトでは、エリート1以上のレベル55のオペレーターのみを募集します

{
    "theme": "Phantom",
    "priority": [                     // グループ、順序付け
        {
            "name": "棘刺",           // グループ名（このグループ名は "棘刺"/ソーンズ ）
            "opers": [                // グループに含まれるオペレーター、順序付け、このグループのオペレーターを配置する際の優先度を表します，
                                      // （このグループのオペレーターを配置する必要がある場合、まずスパインを配置し、スパインがない場合はホーンがあるかどうかを確認した後、ホーンがない場合は他のグループを確認します）
                {
                    "name": "棘刺",   // オペレーター名
                    ...
                },
                {
                    "name": "号角",
                    ...
                }
            ]
        },
       "team_complete_condition": [
             ...
        ]
    ]
}

1. 既存のグループの紹介

   サーミのテーマを例に取ると：主にオペレーターを以下のように分類しています

   グループ	主な考慮事項	主に職種を含む	オペレーターの例
   地面阻挡	場に立つことと雑魚を清掃	重装、前衛	庇護衛士、基石、ラ・プルマ、マウンテン、M3、リィンとシーンの召喚ユニット、スポット、重装予備隊員
   地面单切/執行者	一人でエリート敵と戦う	執行者-特殊	スルト、血掟テキサス、キリンRヤトウ、M3、レッド
   高台C	常態と決戦DPS	狙撃、術師	ウィシャデル、ロゴス、遊龍チェン、ゴールデングロー
   高台输出	対空および通常DPS	狙撃、術師	アルケット、エクシア、クルース、スチュワード
   速狙	物理DPS、標準射程	狙撃	Ela、エクシア、ケイパー、クルース
   術師	術DPS、標準射程	単体術師	エイヤフィヤトラ、ロゴス、スチュワード
   辅助	後方1マスを攻撃可能	補助	ヴィルトゥオーサ、スズラン、ケイパー、オーキッド
   狙撃	射程が長い高台	投擲手、破城射手	ウィシャデル、ティフォン、ロサ
   奶	治療能力	医療、補助	ケルシー、濁心スカジ、ハイビスカス、アンセル
   単奶	攻撃範囲縦深>=4	医療	ケルシー、焔影リード、純燼エイヤフィヤトラ、ハイビスカス、アンセル
   群奶	攻撃範囲縦深<4、後方を治療可能	医療、補助	ナイチンゲール、フィリオプシス、濁心スカジ
   回费	COST 回復	先鋒	テンニンカ、イネス、フェン、バニラ
   地刺	ブロックなし、盾の前でDPSまたは減速を提供	潜伏者	帰溟スペクター、アスカロン、マンティコア
   地面遠程	地上長射程、盾の後ろでDPS可能	教官、領主	ホルン、パラス、ソーンズ、シルバーアッシュ
   領主	地上攻撃範囲縦深>4、対空可能	要塞、領主	ソーンズ、シルバーアッシュ、チューバイ
   盾法	攻撃範囲が短く、ある程度の耐久力がある	法陣術師	リン、カーネリアン
   炮灰	砲弾吸収、再配置	特殊、召喚ユニット	M3、レッド、テンニンカ、予備隊員
   大龍	盾の前で耐久、近接ブロックで合体しやすい	召喚ユニット	リィンの小龍、ジェシカの盾
   補給站	メインDPS オペレーターの回転を加速	召喚ユニット	支援補給ステーション、工匠系オペレーターの召喚ユニット
   無人機	高台地上を無視する治療召喚ユニット	召喚ユニット	スカジのシーボーン、サイレンスのドローン
   支援陷阱	地上に配置する爆発物	召喚ユニット	壊れたスモークマシン、ミスターランブル
   障碍物	配置枠を使わず敵視を集めるかブロック	召喚ユニット	鳥籠、障害物
   其他地面	優先使用したくない地上	押引、ブロック1先鋒、剣豪	バグパイプ、クロワッサン
   高台预备/其他高台	優先使用したくない高台	拡散術師、連鎖術師、戦術家	オーキッド、予備隊員

   ヒント

   地面阻挡は主にオペレーターの防御総合能力を考慮します（時には全滅させることも防御力が強い表現ですね）、地面遠程と領主グループを含みます

   奶は主に総合治療能力を考慮し、単奶と群奶を含みます。攻撃範囲カバーを考慮する必要がある場合は、単奶（4マス治療）または群奶（後方治療）を単独で使用します

   高台输出は出力能力のみを考慮し、主に狙撃と術師職業の混合順序です。出力タイプ、攻撃範囲などの制限条件を考慮する必要がある場合は、速狙、術師、辅助、盾法を単独で使用します

   罠タイプの召喚ユニットは数が多いため、支援陷阱グループに入れず、MAAに自動配置させた方が効果的です

2. 特別な操作が必要なグループ

   上記のような一般的なグループ以外に、時折、特定のオペレーターやオペレーターの種類に対して細かいカスタマイズが必要な場合があります。例えば

   グループ	含まれるオペレーター	主な特徴
   益达	ウィシャデル	高台DPS、優先配置でプレッシャーを軽減できます
   棘刺	ソーンズ、ホルン	地上遠隔攻撃、ファントムテーマでは特定の位置に非常に適したマップがあります
   召唤类	ケルシ、リィン、シーン	地上ブロックを持ち、一部のマップでは優先的に配置する必要があり、召喚物はブロックまたは死体として使用できます
   情报官	カンタービレ、イネス	コスト回収やサイドアウトプット、シングルカットが可能
   浊心斯卡蒂	濁心スカジ	低圧時の回復量はまあまあですが、範囲が特殊で、一部のマップには特に適しています
   焰苇	焔影リード	サーミローグでよく使う開局オペレーター、治療と輸出を兼ねており、一部のマップには比較的適切な位置があります
   玛恩纳	ムリナール、シルバーアッシュ	地上の大規模な決戦DPS、ボスに対して配置できます
   史尔特尔	スルト	精二後、3スキルを固定搭載するため、この時点での場持ち能力はほぼゼロで、ブロック位置の配置優先度は非常に低いです
   骰子	ダイス	ミヅキテーマの中のダイスは個別に操作する必要があります

注意

現在、識別されていない近距離オペレーターは最後から2番目のグループ（其他地面）に分類され、識別されていない遠距離オペレーターは最後から1番目のグループ（其他高台）に分類されます

ヒント

新しく実装されたオペレーターは、それぞれのローグライクの recruitment.json に手動で追加する必要があります。開発者が対応を忘れることもあります。
もし気づいた場合は、issue を送って開発者に知らせることもできますし、直接 PR を送ることもできます。

預設陣容--陣容完備檢測

あなたがクリアできるか、高層まで進むことが期待されるチームの中で、どのオペレーターが基本的なコアメンバーに属していますか？欠かせないものは何ですか？

注意

現在のスクリプトの招集ロジックは、陣容が完全でない限り、0希望とkeyオペレーターだけを招集し、希望を高星のkeyオペレーターに渡します
（現在の実装方法は、高レア度オペレーターと★3オペレーターを手動でキーオペレーターとしてマークし、募集時にはキーオペレーターのみを募集する）（TODO: 0希望のオペレーターを識別する）

したがって、完全度の数字を高く設定しないようにし、必要なすべてのオペレーターの数（基本的なコアメンバー）を合計して、4〜8人にしてください

チームが陣容の完全度テストをクリアした後、招集券を入手するたびにオペレーターの募集と昇進優先度に基づいて採用されるため、希望を無駄にしないために、採用を望まないオペレーターは評価を設定したり、同じ職業の★3と予備隊員の評価を下回ったりする
（絶対に必要でないオペレーターには特別な高得点と低得点が与えられます。 Sami の 止颂 を参照）

戦闘陣容を形成する際、オペレーター選択画面のデフォルトソート（上から下、左から右へ）が読み取られ、秩序正しく保存されます
この順序に基づき、最初に陣容完全性を満たすオペレーターは、すべての陣容完全性を満たすか、陣容完全性を満たすオペレーターがいないまで相対的な順序で言及されます
次に予備隊員を一番最後に移動させ、新しい順序を形成し、新しい順序で選択します
特に、六つ星の臨時招集オペレーターはデフォルトで編成の先頭に配置されているため、実際の編成に六つ星の臨時招集オペレーターを簡単に組み込むことができます（TODO：使いならないE1臨時招集オペレーターは除外）

新しいアカウントについて：キーオペレーターの半チームの要件を満たさない10件の招集の場合、完全性テストは中止され、スコアに応じて使用されます。つまり、3つ星を育成していない新しい人数は2つか3つの6つ星のみを得られ、残りは多くの予備オペレーターを使います

{
    "theme": "Phantom",              //ローグテーマ
    "priority": [                    //グループ
             ...
        ],
    "team_complete_condition": [     //陣容完備度検査
             {
            "groups": [              //必要なグループ
                "高台C"
            ],
            "threshold": 1           //これらのオペレーターのうちいくつが必要か
        },                           //（つまり、高台Cグループから1名のオペレーターが必要）
        {
            "groups": [
                "棘刺",              //（つまり、以下のグループには最低2人のオペレーターが必要です）
                "地面阻挡",
                "地面单切",
                "炮灰"
            ],
            "threshold": 2
        },
        {
            "groups": [
                "奶"                 //（ここでは、回復役が1名必要であることを示しています）
            ],
            "threshold": 1
        }
        ...
        ]
}

警告

あるオペレーターが複数のオペレーターグループに所属している場合、カウントは一度だけ行われます。
例えば、オペレーター 棘刺 はオペレーターグループ 棘刺 と 地面阻挡 の両方に所属している可能性がありますが、この戦略グループ内ではオペレーター 棘刺 は一度だけカウントされます。

しかし、それぞれの戦略グループでは別々にカウントされます。
例えば、オペレーター 焰影苇草 はオペレーターグループ 高台输出 と 奶 の両方に所属している可能性があり、この場合、両方の戦略グループでオペレーター 焰影苇草 がカウントされます。

オペレーター募集パラメータの調整

1. グループ内の順序は配置検出の優先度を表します

2. 臨時募集オペレーターは、既存の優先度に600ポイントが加算されます

3. ランダム昇進オペレーターの評価は、募集優先度と精二優先度を合計して計算されます

4. グループ内のオペレーターの各フィールドの意味とスクリプト関連のロジック

   {
       "theme": "Phantom",
       "priority": [
           "name": "地面阻挡",                              // グループ名（ここは近距離ブロックグループ）
           "doc": "標準ラインは1ギア(雑魚を除去する能力または戦場に立て能力がマウンテンよりも強い)、>マウンテン>2ギア(ブロック>2、自身回復力持て)>スポットであり、戦場に立て能力はスポットよりも少なく、单切または炮灰グループに入れます",
                                                           // "doc" フィールドを持つものは、プログラムの実行に影響を与えません
           "opers": [                                      // これにはどのオペレーターが含まれ、順序があり、配置の優先度を表します
               {
                   "name": "百炼嘉维尔",                    // オペレーター名（ここでは百錬ガヴィル、グループ内で1番目、地上阻止グループを配置する際に、最初に百錬ガヴィルかどうかを確認します）
                   "role": "Warrior",                       // オペレーターの職業、オプション。同名オペレーターが存在する場合に職業を区別するために使用。英語の職業名を記入、大文字小文字は不問
                   "skill": 3,                             // 何技能を使用するか（ここでは3技能を使用する例）
                   "skill_usage": 2,                       // スキル使用モード、自動戦闘プロトコルを参照してください、空白または1は自動、2はX回だけ使用（Xは"skill_times" フィールドで設定）、3は現在サポートされていません
                   "skill_times": 2,                       // スキルの使用回数、デフォルトは1、"skill_usage" フィールドが2の場合に有効
                   "alternate_skill": 2,                   // 指定されたスキルがない場合に使用される代替スキル、通常は6星オペレーターがE2になってから3技能を使用する場合に指定する必要があります（ここでは3技能がない場合に2技能を使用する）
                   "alternate_skill_usage": 1,             // 代替スキルのスキル使用モード（このフィールドはまだ実装されていません）
                   "alternate_skill_times": 1,             // 代替スキルのスキル使用回数（このフィールドはまだ実装されていません）
                   "recruit_priority": 900,                // 募集優先度、数字が大きいほど優先度が高くなり、900以上は必ず募集することを示し、400以下は一部の重要なオペレーターのE2優先度よりも低い
                                                           // 臨時オペレーターの募集優先度は自動的に+800
                   "promote_priority": 600,                // 昇進優先度、数字が大きいほど優先度が高くなり、900以上はE2を取得する可能性があり、400以下は普通の3星オペレーターの募集優先度よりも低い
                                                           // Tips: 募集優先度を下げたり書かないで精英度を高めると、実際にはこれらのオペレーターのE2優先度を高めています
                   "is_key": true,                         // true はキーオペレーター、false または省略すると非キーオペレーターです。陣形完全性チェックに合格しない場合、キーオペレーターおよび0希望オペレーターのみを募集し、希望を保存します。
                   "is_start": true,                       // true は開幕選択オペレーター、false または省略すると非開幕選択オペレーターです。チームに start オペレーターがいない場合、start オペレーターおよび0希望オペレーターのみを募集し、ユーザーが入力したオペレーターは強制的に start オペレーターになります
                   "is_alternate": false,                  // true はバックアップオペレーター（重複募集を許可、バックアップオペレーターにスワイプされた場合はそれ以上右へスワイプしない）、false または省略で通常オペレーター
                   "auto_retreat": 0,                      // 配置後何秒で自動撤退するか、整数で、0 より大きい場合に有効です、主に特殊オペレーターや投錨に使用されます、肉鳩は通常2倍速ですので、スキルの持続時間/2 に設定することをお勧めします
                   "recruit_priority_when_team_full": 850,   // 個別に設定する必要はなく、編成が整ったときの募集の優先度は、デフォルトで-100となります
                   "promote_priority_when_team_full": 850,   // 個別に設定する必要はなく、編成が整った時、昇進の優先度はデフォルトで精二優先度300
                   "recruit_priority_offsets": [           // 現在の陣形に応じた募集優先度の調整
                       {
                           "groups": [                     // 条件を満たすためにどのグループが必要か。これらのグループには同じオペレーターが重複して出ないようにしてください。そうしないと、重複してカウントされます。
                               "凯尔希",
                               "地面阻挡",
                               "棘刺"
                           ],
                           "is_less": false,               // 条件は大きいか小さいか、false または省略した場合は大きいです、true の場合は小さいです
                           "threshold": 2,                 // 条件を満たす数
                           "offset": -300                  // 条件を満たした後の募集優先度の調整
                                                           // （ここでは、凯尔希、地面阻挡、棘刺の3つのグループに2人以上のオペレーターがいる場合、バイランカジュビールの募集優先度が300減少します）
                       }
                   ],
                   "collection_priority_offsets": [         // 現在所持しているコレクションに応じた募集優先度の調整
                       {
                           "collection": "古旧的钱币",       // コレクション名
                           "offset": 100                    // そのコレクションを所持した後の募集優先度の調整、省略でデフォルト 0
                       }
                   ]
               },
               ...
           ],
       ],
       "team_complete_condition": [
           ...
       ]
   }

   注意

   recruit_priority_offsetsのgroup内のグループに重複するオペレーターがいないようにしてください。

   auto_retreatを設定した場合、通常は作戦計画で改めてretreat_planを設定する必要はありません。

5. あなたの理解に基づいて新しいグループとオペレーターを追加してください

   新しいグループを追加すると、既存のグループからオペレーターをコピーして、エキスパートの評価を参考にして、それを基に変更できます

ローグ第2ステップ--戦闘ロジック

resource/roguelike/テーマ名/autopilot/ステージ名.json には各ステージの戦略が記述されています。

MAA ローグの基本戦闘ロジック--パラスちゃんの高血圧の源

1. マップ上のタイルの種類に基づいた基本的な戦闘操作

   • MAA はマップ上のタイルが青い扉か赤い扉か、高台か地面か、配置可能かどうかに基づいて基本的な戦闘操作を行います。

   • MAA はマップの名前や番号に基づいてどの作業を使用するかを決定し、マップの一般、緊急、ルートネット、暗号板使用などの状況を判断しません。

   • MAA は戦闘中に確定できないマスの状況を判断しません。例：猛獣小屋の祭壇の位置、パブリック・エネミーが左から出るか右から出るか

   したがって、後で、すべての異なる状況（上記で言及した状況）に対処できる戦闘ロジックを設計する必要があります。皆に ｢このマップの操作は高血圧だ！｣ とissueで言われないように気をつけてください（笑）

2. MAA の基本的な作戦戦略--青い扉を封鎖

   1. 地面オペレーターは青い扉のタイルに優先して配置されます（なぜタイル上なのかは後で説明）、またはその周囲に配置され、方向は赤い扉に向けられます（自動計算）。

   2. 地面を優先して配置し、その後治療オペレーターや高台オペレーターを配置し、青い扉から周囲に向かって一周ずつ配置します。

   3. 上記のロジックに従って配置可能なもの（オペレーター、召喚物、支援アイテムなど）を連続して配置します。

基本戦闘戦略の最適化

1. 青い扉の代替案

   オペレーターを単に青い扉の前に集めるのは明らかに賢明ではありません。いくつかのステージには、1人で立ちはだかることができるタイルがあるため、ここでの防御は非常に効果的です。

   また、複数の青い扉があるステージでは、MAA はどの青い扉がどの赤い扉に対応するかわからず、乱雑に配置します。

   この場合、地図ウィキを開いて、地図を見ながら脳内で指示を出す必要があります。

   まず、設定で座標表示をMAAに切り替えます。

   次に、優先的に防御するポイントの座標と方向を経験に基づいて見つけ、json の"replacement_home"に記入します。

   {
   "stage_name": "蓄水池",        // ステージ名、必須（CN版準拠での入力）
   "replacement_home": [         // 重要なディフェンスポイント（青い扉の交代ポイント）、少なくとも1つを埋める必要があります
       {
           "location": [         // 地図ウィキから取得したグリッド座標
               6,
               4
           ],
           "direction_Doc1": "優先方向ですが、絶対にこの方向であるという意味ではありません（アルゴリズムが独自の裁量を決定します）",
           "direction_Doc2": "デフォルトのnoneを入力しない場合、つまり、推奨される方向はなく、アルゴリズム自体が判断するのは完全にアルゴリズム次第です",
           "direction_Doc3": "none / left / right / up / down / 无 / 上 / 下 / 左 / 右",
           "direction": "left"   // （これは、オペレーターが最初に座標 6,4 に配置され、グリッドが左を向いていることを示しています）
       }
   ],

2. 配置タイルのブラックリスト

   優先的に防御するポイントがあれば、それ以外にオペレーターを配置しないポイントも存在します。例：大きな火が通る場所、ボスの足元、出力が難しい位置

   この時、"blacklist_location"を導入し、配置したくないタイルをブラックリストに追加します。

   注意

   ここに追加されたタイルは、後続の配置戦略に記述されていても配置できません

       ...
       "blacklist_location_Doc": "これは使用例であり、貯水池でこれら 2 つのポイントを禁止する必要はありません",
       "blacklist_location": [  // プログラムの展開が禁止されている場所
           [
               0,
               0
           ],
           [
               1,
               1
           ]
       ],

3. 他のマップ戦略

   例えば、ミヅキテーマでは青い扉から敵が出る場合にダイスを使う必要があるか、敵のプレッシャーを和らげる

       "not_use_dice_Doc": "青い扉のオペレーターが撤退時にダイスを使う必要があるかどうかにかかわらず、デフォルトはfalse",
       "not_use_dice": false,

まだ高血圧？本当の技術を見せる時が来ました--カスタム作戦戦略！

"deploy_plan" と "retreat_plan" を使用してカスタマイズ操作を実現します。

カスタム戦略は基本戦闘戦略よりも優先されます。カスタム戦略のすべてのステップを試行した後、残ったオペレーターまたは倒れた後に再度配置されるオペレーターは、基本戦闘戦略に従って継続的に配置されます。

多くの場合、多くのカスタム戦略を設定する必要はありません。重要なステップが完了した後、MAA に任せると良い結果が得られるかもしれません。

1. グループを使用してオペレーターを配置する

   "deploy_plan": [ // 上から下、左から右の順序で取得するロジックを配置し、最初に見つかったオペレーターの配置を試み、そうでない場合はスキップします
       {
           "groups": [ "百嘉", "基石", "地面C", "号角", "挡人先锋" ],//これらのグループからオペレーターを検索します
           "location": [ 6, 4 ],             //これらのグループを巡回する
           "direction": "left"               //見つかった最初のオペレーターを 6,4 という座標上に配置し、左を向く
       },                                    //見つからない場合は次の配置操作に進みます
       {
           "groups": [ "召唤" ],
           "location": [ 6, 3 ],
           "direction": "left"
       },
       {
           "groups": [ "单奶", "群奶" ],
           "location": [ 6, 2 ],
           "direction": "down"
       }
   ]

   注意

   MAAは、すべてのデプロイ命令をフラット化し、最優先のデプロイ操作を実行します。
   例：[6,4]に[ "百嘉", "基石", "地面 C"]を配置し、[6,3]に[ "基石", "地面 C"]を配置する場合、MAAはデプロイ命令を[ "百嘉", "基石", "地面 C"，"基石", "地面 C"]としてフラット化します。
   戦闘中に[6,4]の位置にある"百嘉"が倒れ、配置可能な"基石"が手元にある場合、MAAは[6,4]ではなく[6,3]に優先的に配置します。

2. 特定の時間にオペレーターを配置する

   ヒント

   これは、シングルカットオペレーターまたは大砲の飼料が必要な一部のユースケースに適しています

   "deploy_plan": [
           {
               "groups": [ "异德", "刺客", "挡人先锋", "其他地面" ],
               "location": [ 5, 3 ],
               "direction": "left",
               "condition": [ 0, 3 ]       // この操作は、キル数が0〜3の場合にのみ実行されます
           },
           {
               "groups": [ "异德", "刺客", "挡人先锋", "其他地面" ],
               "location": [ 5, 3 ],
               "direction": "left",
               "condition": [ 6, 10 ]
           },
           ...
       ]

3. 特定の時間にオペレーターを撤退させる

   ヒント

   肉壁が強すぎてスタンドに留まりたい場合や、配置スペースを移動したい場合は、撤退します！

    "retreat_plan": [  // 特定の時間に対象のオペレーターを撤退させます
           {
               "location": [ 4, 1 ],
               "condition": [ 7, 8 ] // キル数が7〜8の場合、位置[4,1]のオペレーターを撤去します。存在しない場合はスキップします
           }
       ]

4. 特定の時間にスキルを発動する（to do）

5. その他のフィールド（おすすめではありません）

       "role_order_Doc": "オペレーターのタイプデプロイ順序。未記入の部分は前衛、先鋒、医療、重装、狙撃、術師、補助、特殊、召喚ユニットの順で補完されます。英語で入力してください。",
       "role_order": [ // おすすめしません。deploy_plan フィールドを設定してください
           "warrior",
           "pioneer",
           "medic",
           "tank",
           "sniper",
           "caster",
           "support",
           "special",
           "drone"
       ],
       "force_air_defense_when_deploy_blocking_num_Doc": "フィールド上に10000個のブロックユニットがある場合、合計1つの対空ユニットを強制的にデプロイします（記入の有無は正常なデプロイロジックに影響しません）。この期間中、医療ユニットのデプロイは禁止されません（指定しない場合はデフォルトでfalse）",
       "force_air_defense_when_deploy_blocking_num": { // おすすめしません。deploy_plan フィールドを設定してください
           "melee_num": 10000,
           "air_defense_num": 1,
           "ban_medic": false
       },
       "force_deploy_direction_Doc": "これらのポイントは、特定の職業に対して強制的にデプロイする方向です",
       "force_deploy_direction": [ // おすすめしません。deploy_plan フィールドを設定してください
           {
               "location": [
                   1,
                   1
               ],
               "role_Doc": "指定された職業は強制的な方向に適用されます",
               "role": [
                   "warrior",
                   "pioneer"
               ],
               "direction": "up"
           },
           {
               "location": [
                   3,
                   1
               ],
               "role": [
                   "sniper"
               ],
               "direction": "left"
           }
       ],

注意

maaが現在のステージに対応するカスタム作戦を見つけられない場合、自動的に汎用作戦を実行します。

maaが現在のステージ名を認識できない場合、作戦のロジックは一切実行されません。

特定のオペレーターの戦術に特別な理解がありますか？- 特定のオペレーターに対する高度な操作

このオペレーターを単独でグループ化してください。

作業を記述する際に、このオペレーターと既存の作戦の優先順位を考慮してください。

また、このオペレーターに対して個別に作戦ロジックを記述することもできます。

1人のオペレーターだけを使用することも可能です！MAAを使用して個別のクリアを目指しましょう（他のロジックが不完全なため、確率は低いです）。

参考例：1. ファントムテーマのソーンズ 2. ミヅキテーマの血掟テキサス 3. サーミテーマの焔影リード

ローグ第3ステップ--思わぬ遭遇イベントのノードロジック

resource/roguelike/テーマ名/encounter/default.json は、経験値モードの思わぬ遭遇イベントの選択戦略を記述しています

resource/roguelike/テーマ名/encounter/deposit.json は、源石錐モードの思わぬ遭遇イベントの選択戦略を記述しています

MAAの現在の思わぬ遭遇判定方法

OCRで思わぬ遭遇イベントを認識しますが、選択肢は固定された位置を操作します

事件が認識されない場合、最も下の選択肢を選択します

よくあるフリーズの原因の一つは、オプションタイプのアイコンは存在するのにオプションが選択できないことです（TODO）

通常、微調整するか調整しないことが必要です（高手はすでに書いているでしょう）

思わぬ遭遇オプションの優先度を最適化する

prts.wiki を参照して、各イベントのオプション効果を確認してください。ただし、選択肢は必ずしも固定ではありません

思わぬ遭遇イベントオプションを変更して、MAAを特定のマップの特殊エンディングに向かわせることもできます

{
    "theme": "Sami",                              //ローグテーマ
    "mode": [1, 4],                               //このファイルがどのモードで有効になるかを限定します、オプション。省略時はすべてのモードで有効
    "stage": [                                    //思わぬ遭遇イベント
        {
            "name": "低地市集",                    //思わぬ遭遇イベント名
            "option_num": 3,                      //全部でいくつかのオプションがあります（ここでは3つあります）
            "choose": 3,                          //最初のいくつかのオプション（ここでは3番目のオプション）に優先順位を付け、できない場合は逃げるオプション（基本的に最後のオプション）を選択します
            "choices": [                          //特定のオプションに対する追加要件
                {
                    "name": "选择碎草药",          //オプションの名
                    "choose": 1,                  //下記の条件を満たす場合に優先的に選択するオプションの番号、オプション。省略時はこの項目は無効
                    "requirements": [             //発効条件、オプション
                        {
                            "name": "Vision",     //条件タイプ、現在は Vision（灯火値）のみサポート
                            "value": "3",         //必要な数値
                            "type": ">"           //より大きいか小さいか（= も可。ここでは、灯火が3より大きいときにこの項目の choose が有効になることを意味します）
                        }
                    ]
                },
                {
                    "name": "选择好看的织物",
                    "choose": 1,
                    "requirements": [
                        {
                            "name": "Vision",
                            "value": "3",
                            "type": ">"
                        }
                    ]
                },
                ...

イベントではさらに以下のオプションフィールドをサポートしています：

• option_text：文字列の配列。イベントの各選択肢のテキスト。認識マッチングの補助に使用
• next_event：文字列。このイベントの処理完了後にジャンプする次のイベント名
• fallback_choices：[[実際の選択肢数, 優先選択], ...] 形式の配列。実際に認識された選択肢数が option_num と一致しない場合、実際の選択肢数に応じて対応する選択肢を選択

BlackFlow のイベント戦略と選択結果

この節は機械翻訳です。もし可能であれば、中国語の文書を読んでください。もし誤りや修正の提案があれば、大変ありがたく思います。

BlackFlow の戦略モジュールは encounter_rules をサポートしています。ルールはイベントのタイトル event_name でイベントに一致させ、when は既存の戦略条件構文を使用します。 例えば、一足先に（先行一步）に対応するイベントのタイトルは ｢未涉足之树｣ です。複数のルールが同時に一致する場合、まず rank を比較し、小さい値を優先します。 rank が同じ場合はルールの id の辞書順で決めます。一致するルールがない場合はイベントの既定設定を使用します。

選択肢は option_text に並べた文字の順で一致させることも、option_num と choose を同時に指定することもできます。後者は実際の選択肢数が option_num と等しいときに、1 から数えた choose 番目を選びます。2 つの書き方は併用できません。allow_fallback の既定値は true で、目標が選べない場合や選択に失敗した場合は下から上へ選択可能な選択肢を試します。false にすると、目標の選択に失敗した時点で今回の選択を終了します。

イベントの判断では、以下の組み込みページ事実を facts で再宣言せずに読み取れます：

事実	型	意味
encounter.name	string	現在認識しているイベントのタイトル。
encounter.option_count	int	実際に認識した選択肢の数。
encounter.available_options	string_list	今回の判断時に選択可能な選択肢の文字。
encounter.route_known	bool	イベントに入った時点で、有効で完全な単一の残り経路を保持しているか。
encounter.remaining_battles	int	その経路で現在のイベント以降にある戦闘数。経路が明確な場合のみ判断に提供されます。
encounter.selected_option	int	実際に選択した選択肢の番号（1 から開始）。
encounter.selected_text	string	実際に選択した選択肢の文字。
encounter.used_fallback	bool	実際の選択で代替の選択肢を使ったか。
encounter.rule_id	string	今回の選択要求で一致したルール。一致しない場合は空。

available_options、route_known、remaining_battles はイベントの判断に使用します。戦闘なしと判断するには、 route_known が true かつ remaining_battles が 0 であることを同時に要求する必要があります。経路が空、着地点が複数、または後続ノードの種類が不明な場合は、 いずれも戦闘なしとはみなせません。ここではイベントに入った時点の計画を読み取り、その後の再計画は制約しません。

選択に成功すると、共通のイベントプラグインが RoguelikeEventSelected コールバックを発行します。内容は name、option_num、 choose_option、option_text、rule_id、rule_description、used_fallback です。画面のログには実際に選んだ 文字を表示し、ルールに一致して代替の選択肢を使わなかった場合はルールの description を理由として添えます。そのため、異なる戦略が同じ選択肢を選んでも それぞれの理由を示せます。BlackFlow のセッションは実際の選択をページ事実に書き込み、 その後マイルストーンを更新します。rule_id は元の選択要求を表すため、代替の選択肢を使った場合はそれを根拠に目標の選択肢が選ばれたとはみなせません。マイルストーンでは 実際の選択事実を確認してください。選択結果はオペレーターが派遣されたことを意味しません。選択を確定すれば必ず入手できるアイテムについては、ルールの on_selected で 対応する事実を明示的に更新できます。

on_selected は探索全体の事実名から値への対応表で、宣言済みかつ型が一致する run 事実のみ指定でき、 milestone.* には書き込めません。実際に選んだ文字がそのルールの option_text に含まれる場合のみ代入を適用し、代替の選択肢で別の文字を選んだ場合は適用しません。 これらの代入は今回の選択記録とまとめて書き込んだ後にマイルストーンを更新し、失敗した場合は一部だけ更新された状態を残しません。第二エンディングの ｢线人｣（情報屋）では ｢我受雇于梅兰德｣ を選択した時点で sandtable_a を true にし、ノードの終了は引き続き報酬と後処理の流れに従います。

ページのタスク結果も同様に、事実一式とページの変更を検証してからまとめて書き込みます。完了済みのページは再び完了結果を受け取れないため、 同じ秘宝の結果が重複して加算されることはありません。マイルストーンの変化は既存のコールバックを使用し、発生元の記録は追加しません。マイルストーンを逃したことによる終了判定は引き続き マップ観測時に行います。

BlackFlow のイベント既定設定は option_tasks をサポートしており、実際に選んだ選択肢の完全な文字をキー、既存のタスク名を値とします。 一致すると JustReturn エントリ経由で対応するタスクチェーンに転送され、目標のタスクは自身の名前で実行されるため、テンプレート設定、タスク名のコールバック、 実行回数の統計がそのまま保たれます。以降のページはそのタスクチェーンが処理し、今回はイベント単位の next_event を実行しません。対応する項目がない場合は従来の 報酬処理とイベントの後処理を続けます。設定したタスクはすべて選択前に解決できる必要があり、タスクが欠けている場合は選択肢をクリックしません。

単一選択肢が連続するイベント

BlackFlow のイベント既定設定にある continue_single_option の既定値は false で、現在は ｢安眠一隅｣ でのみ有効です。 有効にすると、ページごとに選択肢を認識し直し、選択可能な選択肢がちょうど 1 つの場合のみそれを選びます。固定の文字、番号、逆順による代替の選択は行いません。 選択可能な選択肢が 0 個または複数ある場合や、選択の確定に失敗した場合は、いずれも選択失敗として扱います。

各選択では引き続き確定ボタンと LoadingText の待機チェーンを使用します。その後、報酬とイベントの会話を処理し、選択肢が出たらイベントのタイトルを確認します。 タイトルが現在のイベントのままの場合のみ次のページを認識し直し、マップをはっきり認識してからイベント全体を終了します。隣り合うページで同じ選択肢の文字を使っても構いません。 読み込み、認識失敗、ユーザーによる停止はいずれもイベント完了とはみなしません。この項目は BlackFlow 専用で、next_event や option_tasks と 同時に有効にはできません。成功した選択ごとに実際の選択肢を個別に通知し、ページの完了はイベント全体が終わった後にのみ報告します。

チームの状況に応じて特定の選択肢の優先度を動的に調整する(TODO)

ローグ第4ステップ--商店の秘宝の優先度

resource/roguelike/テーマ名/shopping.json は、秘宝を商店に購入する(戦闘後に秘宝を選択する)の戦略を表します。

{
    "theme": "Phantom",                                     //ローグテーマ名（ここはファントム）
    "priority": [                                           //優先度、有序、順序はすべて優先度を表し、前にあるほど優先的に購入されます
                                                            //ただし、優先度の判定はchars、rolesの選択よりも前に行われるため、高い優先度の商品が除外され、何も買わない状況が発生する可能性があります
        {
            "name": "金酒之杯",                              //秘宝名（ここは金酒の杯）
            "no_longer_buy": true,                          //trueは、この秘宝を手に入れた後、もうお金を使って秘宝を買わないことを示します。falseまたは省略された場合、引き続きお金を使って秘宝を買います
            "ignore_no_longer_buy": true,                   //trueは、店にこの秘宝がある場合、"no_longer_buy"を無視してそれを買うことを示します。falseまたは省略された場合、"no_longer_buy"の秘宝が手に入った後、その秘宝を購入しなくなります
            "effect": "每有5源石锭，所有我方单位的攻击速度+7", //秘宝の效果（プログラムの実行に影響しません。並べ替えるのに便利です）
            "No": 167                                       //秘宝番号（wikiで確認できます。プログラムの実行に影響しません。並べ替えるのに便利です）
        },

        ...
        {
            "name": "扩散之手",
            "chars": [                                      //これらのオペレーターがチームにいるとき、この秘宝を購入します
                "异客"                                      //（ここでは、チームにパッセンジャーがいる場合、拡散の手と出会えた場合、購入を試みます）
            ],
            "effect": "【扩散术师】、【链术师】和【轰击术师】每对一个单位造成伤害就回复2点技力值",
            "No": 136
        },
        ...

        {
            "name": "折戟-破釜沉舟",
            "roles": [                                      //これらの職業がチームにいるとき、この秘宝を購入します
                "WARRIOR"                                   //（ここでは、チームに前衛干員がいる場合、折戟-破釜沉舟に遭遇した場合、購入を試みます）
            ],                                              //大文字の英語職業名のみサポート
            "effect": "所有【近卫】干员的防御力-40%，但攻击力+40%，攻击速度+30",
            "No": 16
        },
        ...

        {
            "name": "Miss.Christine摸摸券",
            "promotion": 2,                                 //0 でない場合、昇進待ちのオペレーターがチームにいるときにのみ購入します。デフォルトは 0 で、要件なし
            "promotion_rarity": 6,                          //昇進待ちオペレーターを統計するレアリティの上限。この値より低いレアリティのオペレーターのみ統計します。オプション、デフォルトは 6（制限なし）
            "effect": "立即进阶两个干员（不消耗希望）",
            "No": 15
        },
        ...

        {
            "name": "警戒篱木",
            "effect": "坍缩值-2，目标生命上限+2",
            "No": 198,
            "decrease_collapse": true                          // trueは、このコレクションを入手すると崩壊値が下がることを示します。modeが5の場合は購入されません。
        },
        ...

priority のほかに、shopping.json では戦略に応じて表を選ぶテーマ向けに、名前付きの購入表と売却表を宣言できます：

{
    "theme": "BlackFlow",
    "priority": [ ... ],                     // 既定の購入表、名前は default
    "buy_tables": {                          // 任意、名前付きの購入表。商品の書き方は priority と同じで、default は priority 用に予約
        "表の名前": [ { "name": "..." } ]
    },
    "sell_tables": {                         // 任意、名前付きの売却表。売却を許可する名前を並べ、並び順は売却順を決めない
        "cultivation_final": [ "血蕈", "雾滚草", ... ]
    }
}

名前付きの表、price、購入時の残高による事前の絞り込みは現在BlackFlowでのみ有効です。ほかのテーマは引き続き priority を読み取り、従来の解析規則に従います。

roles はどのテーマでも上記の大文字の職分名のみ受け付けます。BlackFlowではさらに、商品名は空にできず、roles と chars は文字列の配列である必要があります。 いずれかが不正な場合、ファイル全体の解析が失敗します。 空の購入表は購入候補なし、空の売却表は売却しないことを表します。

BlackFlowの商品には正の整数 price を指定できます。商店の残高を読み取れた場合、残高が足りない商品は飛ばして次の商品を確認します。指定しない場合の動作は変わりません。

BlackFlowの戦略に応じた購入表・売却表の選択

BlackFlowの戦略モジュールは shopping_rules をサポートしています。ページの処理を振り分ける際に、現在のページ意図と事実に基づいて購入表と売却表の組を選択します：

"shopping_rules": [
    {
        "id": "cultivation_final",                           // 同じ戦略内で一意
        "description": "第三层培育后结束，加工品卖出换种子",   // 任意
        "page_intent": "scrap_shop.cultivate",               // 任意、省略するとこの戦略のすべてのページに適用
        "rank": 0,                                           // 任意、既定値は0、小さい値を優先
        "when": { "fact": "current_floor", "op": "eq", "value": 3 }, // 任意、既存の戦略条件構文を使用
        "buy_table": "default",                              // 任意、既定値はdefault
        "sell_table": "cultivation_final"                    // 任意、省略または空の場合は売却しない
    }
]

複数のルールが一致する場合、rank が小さいものを優先し、同じ場合は encounter_rules と同様に id の辞書順で選びます。購入表と売却表は同じルールから選び、異なるルールのフィールドを組み合わせません。一致するルールがない場合は default 購入表を使い、売却は行いません。ページの処理を振り分けるたびに表を選び直すため、前のページの選択は引き継ぎません。

when は候補経路の事実を参照できません。参照する表名はBlackFlowの shopping.json に存在する必要があり、存在しない場合は戦略設定の解析が失敗します。購入処理は選択した購入表を使用し、秘境行商の育成では選択した売却表で売却対象を絞り込みます。

個別のローグテーマ カスタムロジック

サーミテーマ--啓示板

resource/roguelike/Sami/foldartal.json はサーミテーマの啓示板の戦術を記述しています。

{
    "theme": "Sami",                                         //ローグテーマ名（ここはサーミ）
    "groups": [                                              //使用状況と用法のグループ化
        {
            "usage": "SkipBattle",                           //用法（ここでは戦闘をスキップして、源石錐ためや電気ケトルための作戦ノードに使用します。板を使用して戦闘をスキップして時間を節約します）
            "doc": "跳过战斗,刷钱和烧开水模式",
            "pairs": [                                       //板のペア（対応するノードに遭遇した場合、以下の板のペアが一致するかどうかを判断し、一致する場合は使用可能なものをすべて使用し、一致しない場合は直接ポイントに進みます）
                {                                            //（ここでは、"伤痕"と"空无"のみが連結できます）
                    "up": [                                  //上板
                        "伤痕"
                    ],
                    "down": [                                //下板
                        "空无"
                    ]
                },
                {                                            //（ここでは、順番に "黜人"+"惊讶","黜人"+ "疑惑","黜人"+...,"猎手"+"惊讶","猎手"+ "疑惑","猎手"+... , ... などを検索します）
                    "up": [
                        "黜人",
                        "猎手",
                        ...
                    ],
                    "down": [
                        "惊讶",
                        "疑惑",
                        ...
                    ]
                }
            ]
        },
        {
            "usage": "Boss",                                 //（ここでは、ボスポイントに遭遇した場合に使用される板のペアを示します）
            "doc": "あるものは全部使った",
            ...
        }
    ],
    "foldartal": [                                          //啓示板の効果の注釈（ここでは、板の効果を参照用に記述し、プログラムの実行には影響しません）
        {
            "name": "布局",                                  //啓示板の種類（上板か下板か）
            "foldartal": [
                {
                    "name": "黜人",                           //啓示板の名前
                    "effect": "选择所有右侧邻近的战斗节点"       //啓示板の効果
                },

サーミテーマ--パラダイムロスト

check_collapsal_paradigmsがtrueの場合、MAAは2つの異なる方法でパラダイムロストをチェックします：

• ステージ選択画面で画面上中央をクリックして崩壊状態バーを展開する、以下Panel Checkと呼ぶ
• 画面右側にパラダイムロスト通知があるかどうかを観察する、以下Banner Checkと呼ぶ

崩壊値を取得する方法は多様で、以下の状況を考慮しています：

1. 戦闘後、完璧な戦闘でないため崩壊値が増加し、Banner Checkを実行
2. 戦闘後、秘宝を獲得したため崩壊値が変動し、Banner Checkを実行
3. 思わぬ遭遇などのノードで選択肢を選んだため崩壊値が変動し、Banner Checkを実行
4. 怪しい旅商人ノードで秘宝を購入したため崩壊値が変動し、Banner Checkを実行
5. 啓示板を使用したため崩壊値が減少し、Banner Checkを実行
6. 新しい層に入ったため崩壊値が増加し、Panel Checkを実行
7. Banner Check時にパラダイムロストが消退したことを発見した場合、一度に2層消退するかどうか不明なため（可能性は極めて低い）、次回ステージ選択画面に戻った時に追加でPanel Checkを実行
8. double_check_collapsal_paradigmsがtrueの場合、ステージ選択画面に戻るたびに追加でPanel Checkを実行し、パラダイムロストの記録漏れや記録過剰がないか検証

以下は隠しパラダイムロストを収集するタスク設定例です：

{
    "theme": "Sami",
    "mode": 5,
    "investment_enabled": false,
    "squad": "远程战术分队",
    "roles": "稳扎稳打",
    "core_char_list": [
        { "name": "维什戴尔", "use_support": false },
        { "name": "斑点", "use_support": false },
        { "name": "史都华德", "use_support": false }
    ],
    "expected_collapsal_paradigms": ["目空一些", "睁眼瞎", "图像损坏", "一抹黑"]
}

modeが5の場合：

• stage_nameがステージ名_collapseの作戦戦略を優先使用、例：resource/roguelike/Sami/autopilot/事不过四_collapse.json
• resource/roguelike/Sami/encounter/collapse.jsonに記述された思わぬ遭遇イベント選択の戦略を使用
• decrease_collapseがtrueの秘宝は購入しません

modeが5でないがcheck_collapsal_paradigmsがtrueの場合、パラダイムロストを検出し、expected_collapsal_paradigmsリストにあるパラダイムロストに遭遇した時にタスクを停止しますが、他のパラダイムロストに遭遇した時は再開しません。

隠しパラダイムロストを収集する場合、N10難易度を推奨し、以下のチームの使用を推奨します：

• ウィシャデル + スポット + スチュワード
• 焔影リード + オーキッド + ポプカル
• ティフォン + スポット + スチュワード

界園テーマ--通宝

resource/roguelike/JieGarden/coppers.json は界園テーマの通宝の設定と交換戦略を記述しています

{
    "theme": "JieGarden",                                    // テーマ名（ここは界園）
    "addons": {                                              // 通宝の追加属性説明（備考のみ、プログラム実行に影響なし）
        "锈色": "投出时，每经过一个节点，获得源石锭+1",
        "存护": "加入钱盒时，获得护盾值+2",
        "入幻": "加入钱盒时，获得希望+1",
        "引光": "加入钱盒时，获得烛火+1",
        "巡游": "投出时，每完成一场战斗，获得票券+1"
    },
    "coppers": [                                             // 通宝リスト
        {
            "name": "大炎通宝",                              // 通宝名
            "desc": "普通又空白，什么也没有",                // 通宝効果説明（備考のみ、プログラム実行に影響なし）
            "rarity": "NORMAL",                             // レアリティ：NONE/NORMAL/RARE/SUPER_RARE（備考のみ、プログラム実行に影響なし）
            "pickup_priority": 0,                           // 拾取優先度、ドロップ選択時に使用、数値が大きいほど優先的に拾取
            "discard_priority": 1000                        // 廃棄優先度、交換時に使用、数値が大きいほど優先的に廃棄
        },
        {
            "name": "衡-奇土生金",
            "desc": "投出时，立即获得源石锭+4（下次投钱前变化为-大炎通宝）",
            "rarity": "NORMAL",
            "pickup_priority": 200,
            "discard_priority": 800,
            "cast_discard_priority": 999                    // オプションフィールド、投出時の廃棄優先度、投出済みかつ値>=0の場合のみdiscard_priorityを置換
                                                            // 通常、投出後に効果が変化する通宝に適用（大炎通宝に変化する通宝など）
        },
        {
            "name": "厉-西廉贞",
            "desc": "投出时，精英及领袖敌人的生命值、攻击力+10%，在险路恶敌及岁兽残识中攻击力、生命值额外+20％",
            "rarity": "NORMAL",
            "pickup_priority": 0,
            "discard_priority": 1998,
            "cast_discard_priority": 2098                   // 同上、投出後にマイナス効果をもたらす通宝にも使用されることがあります
        },
        ...
    ]
}

通宝交換ロジック

MAAは界園テーマで通宝の拾取と交換を自動処理します：

1. ドロップ通宝の拾取：戦闘終了後、通宝ドロップ選択画面が表示された場合、MAAは pickup_priority に基づいて最も優先度の高い通宝を選択

2. 銭匣通宝の交換：新しく拾った通宝を銭匣内の通宝と交換する必要がある場合：

   • 銭匣内のすべての通宝の種類、名前、投出済み状態を認識
   • 銭匣内で discard_priority が最も高い（最も重要度が低い）通宝を見つける
   • 新しい通宝の discard_priority が既存の最も重要度が低い通宝より低い場合、交換を放棄
   • それ以外の場合、最も重要度が低い通宝を新しい通宝に置換

3. 投出済み通宝の特殊処理：

   • cast_discard_priority が指定された通宝の場合、投出済み状態では discard_priority ではなくこの優先度を使用
   • 通常、投出後に効果が変化する通宝に適用（大炎通宝に変化する通宝など）

通宝認識メカニズム

MAAは以下の方法で通宝を認識・処理します：

1. テンプレートマッチングで通宝の種類アイコン（厲/衡/花）を認識
2. 種類アイコンの位置に基づき、ROIオフセットを使用してOCRで通宝名を認識
3. 通宝が ｢投出済み｣ 状態かどうかを認識
4. 通宝交換画面でリストを自動スクロールし、すべての通宝をスキャンして比較

認識フロー図解

注意

• OCR認識した通宝名が設定ファイルに見つからない場合、MAAはデバッグ画像をdebug/roguelike/coppers/unknownディレクトリに保存し、トラブルシューティングに使用します

実現したいロジック（todo）

自動編成ロジック

1. 異なるマップに応じて、異なるマップ配置の完全性検査とスキル優先度の設定が可能です

2. 現在の配置に基づいて、いくつかの難しい戦闘を避けることができます。

経路探索アルゴリズムの最適化（初期実装済み）

例えば、最初の3層で多くの戦闘を行い、後ろの層では少ない戦闘を行うようにすると、成長がより良くなります。

スキル保持

特定の位置に配置されたオペレータのスキルが準備できた後、x秒待ってから使用します。これは軸に対して便利です。Deploy_plan の下に Skill_hold を記述することもできます。

スキル停止

弾薬消費系のオペレータに便利です。

このページを編集