HoI4 開発者日記 第209回 Mod制作と1.9のパッチログ 2020/2/21

スポンサーリンク
更新情報

Hearts of Iron IV 開発者日記 第209回目を紹介。

今回はMod制作の際に便利になった機能とVer1.9のパッチログに関するお話です。

HOI4 Bonus Diary! - Modding & 1.9 Patchlog
Hi guys! Here is the promised bonus dev diary. First up is the full changelog, and after that we will be going through a...

「第209回」について

今回の日記ですが、元タイトルがいつもの「Dev Diary」ではなく「Bonus Diary」になっています。
ですのでナンバリングで209回にするのか、それとも特別扱いなのか悩むところ…。

ただ、Paradoxの公式Wikiでは今回の日記はLa Résistanceにおける一連のDev Diaryの一つとしてカウントされています。

Developer diaries - Hearts of Iron 4 Wiki

ですのでナンバリング扱いで209回としました。

以下、パラドックスフォーラムの内容を意訳したものとなります。
正確を期すよう努めていますが詳細はパラドックスサイトの原文をお読みください。

[記事内の画像はパラドフォーラムより引用]

スポンサーリンク

Hearts of Iron IV 開発者日記 2020年2月21日分(第209回)

今回の日記担当は、HoI4″総帥”のpodcatさんです。

●お断り●
今回の日記は技術的な内容が多く、私には理解できません。
従いまして簡素な紹介とさせていただきます。

冒頭のあいさつ

皆さんこんにちは!
ここに約束されたボーナスの開発者日記があります。
まず最初は変更ログの完全版です。
その後、Mod製作者向けに用意された新しい内容全てを確認します。

1.9 ‘Husky’ のパッチログ

ここに1.9の完全なパッチログがあります。クリックして展開してください。

パッチログについての紹介はカットします。
気になる方は元サイトでご確認ください。

Mod制作

1.9.0にはたくさんのツールや改善が含まれており、Mod制作者が素晴らしい改造を開発するのに役立つことを期待しています。
バグの修正や小さな改善はここに記載するには多すぎますし、パッチログにもありますが、この開発者日記にはもっと主要なものを記載します。つまり

より多くのエフェクト、トリガー、ゲーム変数、より多くの変数のサポート

です。

新しい無料パッチで、多くの新しいエフェクト/トリガーとゲーム変数を追加しました。
完全なリストは、パッチノートまたはゲームで生成されるドキュメントファイルにあります。

これらの新しいスクリプトツールに加えて、既存のエフェクト/トリガーに対する変数サポートも追加しました。
また、Hoi4のスクリプト言語では、変数としてのトークン格納がサポートされるようになりました。
たとえば、次の操作を実行できます。

ここでは、トークンinfantry_equipmentを一時変数に格納し、後でこの格納されたトークンをadd_equipment_to_stockpileというエフェクトで使用します。

現時点では、以下のオブジェクトは変数に格納することができ、全てのエフェクト/トリガはそのような変数を受け入れることができなければなりません。

ideology/ideology groups
equipment types
operation

さらに多くのサポートを追加する計画がありますので、他の種類のトークンが役に立つと思われる場合は遠慮なく私達に提案してください。

また、スクリプト言語のドキュメントサポートも強化しています。
次のhtmlファイルは、新しいスクリプトドキュメントツールの出力です。

Effect Documentation
Trigger Documentation
Modifier Documentation
Dynamic Variables Documentation

ヒストリーロガー

“History Logger”は、AIのゲームプレイを観察するために開発したツールであり、現在では一般公開されています。
より詳細はAIの開発者日記で紹介しています。

ここでGIF画像がありますが容量の関係でカットします。元サイトで御覧ください。

以下のリンクを使用していくつかの例を見ることができます:

https://common-assets.paradoxplaza.com/hoi4-devdiary/history_viewer.html?zip=1.zip
https://common-assets.paradoxplaza.com/hoi4-devdiary/history_viewer.html?zip=2.zip

私たちは、これが改造やAI改造を作る人たちの助けになることを願っています。
これを使うには、”-hands_off” オプションを使ってゲームを実行させる必要があります。これにより、国家は定義されてNGame :: HANDS_OFF_START_TAGを観測するようになり自動的にゲームが開始されます。
(または、手動でゲームを開始し、コンソールコマンド「history_logger (履歴ロガー)」を実行することもできます)。
実行中、ゲームはデータを収集し、毎月「documents/user/Hearts of Iron IV/history_dump」フォルダにダンプします。
ゲームが十分なデータを収集したと判断したら、そのフォルダの内容を圧縮し、game\tools\history_viewer\history_viewer.htmlファイルにロードします。

-hands_offは、あなたを満足させるようなテスト条件も出力します。
必要に応じてgame\testsに条件を追加すると、User\Documents\Paradox Interactive\Hearts of Iron IV\logs\testsの下に成功または失敗としてレポートされます。

クラッシュログ

スクリプトの実行中またはセーブゲームのロード中に問題が発生してゲームがクラッシュした場合、ゲームは最後に実行されたスクリプトまたは最後にロードされたスクリプト/履歴/保存を実行します。
これにより、クラッシュの原因に関するより詳細な情報が得られ、クラッシュ自体が解決するまで問題を回避できます。

この情報を見るには”-crash_data_log”と入力します。オプションを使用してゲームを起動した場合にのみ保存されます(パフォーマンスが低下するので、通常の開発では有効にしないことをお勧めします)。

クラッシュは、user\Documents\Paradox Interactive\Hearts of Iron IV\crashes\…\meta.ymlに出力され、ファイルと行情報を表示します。

セーブゲームのロード中にゲームがクラッシュした場合は、save_as_binaryをnoに変更し、user\Documents\Paradox Interactive\Hearts of Iron IV\settings.txtで保存内容をテキスト形式で確認できるようにすることをお勧めします。

また、クラッシュに遭遇した場合はもちろんバグレポートを作成してください。
そうすれば、実際に修正することができます。

国タグのエイリアス(別名、通称)

国タグにエイリアスシステムを追加しています。
これらのエイリアス(別名、通称)は国のタグ(国タグを使用できるほとんどの場所で使用できる3文字のタグです)と同じように機能しますが、ゲーム中は異なる国にもマップできます。
例です:

SPD、VIC、およびMOTは国タグのエイリアスです。
SPDはSPR(これは本物のタグで)の元のタグを持つ国にマップされ、国フラグSPR_carlist_spain_flagを持ちます。
スクリプトが呼び出されると、

正しいSPRを見つけ、その国に政治力を加えるでしょう。

元のタグ/トリガーの組合せに加えて、国タグの別名を変数、イベント・ターゲットまたはスコアリング・システムにマップすることもできます。
前述の例では、MOTは変数generic_operation_targetにマップされる国タグの別名であり、スクリプトの別の部分で国ごとに異なるように設定されています。

国家スコア

スクリプト言語にスコアリング・システムを追加しました。
サンプルはgame\common\scorers\countryの下にあります。

ここでは、多数のトリガーと修飾子を使用して国をスコア化し、そのスコアエントリをget_sorted_scored_countriesやget_highest_scored_countryなどの効果に使用できます。

このシステムは様々なAI実装でも使用されています。
たとえば、オペレーションAIは完全にスクリプト化され、ターゲットの選択にこのスコアリングシステムを使用します。
また、復号AIはこのスコアリングシステムを用いて復号対象を見つけます。

修飾子の定義

スクリプト言語を使用してカスタム修飾子を追加できるようになりました。
これらの新しい修飾子は、game\common\modifier_definitionsに保存されます。

このような修飾子を定義すると、国/州/リーダー修飾子を付与する場面で使用できます。
修飾子のツールチップに表示され、国/州のスコープのleader_modifier/unit_modifierの下で”modifier@modifier_token”を使用して、エフェクトまたはトリガーでその修飾子の値にアクセスできます。

Control + Alt + クリックでスクリプトファイルを開く

デバッグモードでcontrol+alt+クリックとすると、フォーカス、アイデア、意思決定、イベント、研究、精神などのスクリプトファイルを開くことができます。

GIF画像は省略

これは既存のフォーカスを編集する例です。
ご覧のように、リロードも改善され、フォーカスを変更してもフォーカスツリーがデフォルトの位置にスクロールされなくなりました。

AIのさらなる戦略

私たちはAIの振る舞いを変更するために、多くの新しい戦略を追加しました。
AIが特定の戦線に対してより多くのユニットを要求したり、AIがその計画をアクティブ/非アクティブにしたり、攻撃性を変更したりするAI戦略を作成することが可能になります。
これらの戦略は、ヨーロッパにおいて連合国を枢軸国の領内へより侵入させることに大いに役立ちました。

ゲームスピードの改造

これはMP改造に取り組んでいた改造マニアたちからの要望でした。NGame::GAME_SPEED_SECONDSの値を変更することで、ゲームの速度を変更できるようになりました。

オペレーションの改造

基本レベルでは、オペレーションは3つのオペレーションフェーズで構成されます。
バニラ版の実装状態では、これらのフェーズは3つの別々のプール(それぞれ潜入、実行、撤退)からランダムに抽出されます。

しかし、あなたは決してそれらに制限されていません(例外もあります。たとえば、偽のインテルのオペレーションでは、潜入や撤退は必要ありません。)。

各フェーズには、そのフェーズが使用可能かどうか(たとえば、対象国が内陸国の場合、潜水艦潜入の方法は選択できません)を決定する固有の要件セットがあります。
各フェーズには、備蓄から自動的に抽出される設備要件もあります。
輸送機などの高価な機器の場合、オペレーションの終了時に機器を戻すように設定できます。

いくつかのフェーズでは、産業コストを使用します。
これは、数日間の工場数としてレンダリングされます。

フェーズが選択される確率は、イベントなどのai_cancesのように変更可能なベース値によって決定されます。

各フェーズには、計画、結果、オペレーションが失敗した場合の追加結果、の3つのローカライズが関連付けられています。
さらに、2つのイメージが必要です。
1つは上部の概要用のイメージで、もう1つはマップ上のフェーズアイコン用の小さいイメージです。

フェーズが完了したら、スクリプト内の操作が実際にどのように表示されるかについて説明します。

これらは実際の内容よりもずっと怖そうに見えるものです。
上から順に見ていきます。

これは主にGUI関連であり、改造マニアにとっては大きな謎ではないはずです。
iconはAgencyビューに表示される画像です。
map_iconは、オペレーションが使用可能なときにマップに表示されるアイコンです。
nameとdescは、名前と説明のローカライズ文字列です。
priorityは、使用可能なオペレーションのリストのどこにこのオペレーションが表示されるかを決定します。

daysは、オペレーションが開始されてからの期間です。
準備フェーズは、必要な資源を収集することによって完全に決定されます。

network strengthは、対象国におけるネットワークの強さです。

operativesは、オペレーションの開始に必要なoperativesの数です。
これはまた、その国に少なくともそれだけの数の工作員が揃うまでは、そのオペレーションはできないことを意味します。
これにより、3人以上のオペレーターを必要とする、より高度なオペレーションのテストが少し難しくなります。

visible={}トリガーは、意思決定やアイデアでおなじみのように機能します。
trueと評価された場合、オペレーションが表示されます。

allowed = {} やavailable = {} のトリガーが表示されていません。
allowed={}は、ある国でオペレーションを実行できるかどうかを確認するためにチェックされます。
これは、特定の国(ドイツ以外の国でしか利用できないような)のみを対象としたオペレーションを行う場合に特に便利です。
available={}は、オペレーションを実行できるかどうかをチェックします(表示されている場合)。
これは、あるオペレーションが実際に実行される前にそのオペレーションが実行可能であることをプレーヤーに認識させたい場合に便利です(visible={}トリガーをavailable={}トリガーよりも厳密にしないことで実現できます)。

selection_targetは、オペレーションの対象となる使用可能なターゲットの数を制限します(FROMは常にターゲット国、FROM.FROMはターゲット状態 (存在する場合)、ROOTはオペレーションを開始する国です)。
これは主に、ゲームがすべてのタグやマップ上のすべての状態をチェックしないようにする場合に便利です。

selection_target_stateは、オペレーションに対して選択できる状態の州(この例では、州はある程度のレジスタンスを持たなければならない)を定義するトリガーです。selection_targetと組み合わせて使用すると、この例では、ターゲット国でレジスタンスがいる州のみを選択できます。

equipment は、オペレーションに必要な機器を決定する個別のカテゴリです。
前述したように、機器はオペレーションフェーズに関連付けることもできますが、このパラメータを使用すると、ゲームでどのフェーズが選択されているかに関係なく、基準コストを設定するのに役立ちます。

required_tokensは、その国にあるトークンをチェックしています。
バニラ版では、トークンは他のオペレーションからのみ付与されますが、理論的にはフォーカス、イベント、意思決定を通じても取得できます。
これらは、それ自体では目的を果たしませんが、別のオペレーションを実行する前にプレーヤーにオペレーションを完了させ、2つを接続するのに役立ちます。

risk_chanceは、エージェントにとって問題が発生する可能性を決定します。
この例では、20%に設定されています。
RNGがエージェントにとって非常に悪い日になると判断すると、on_operative_detected_during_operationというon_actionを実行し、さまざまな結果(捕らえられ、殺され、負傷し、身を隠すことを強いられる)の相対確率を決定します。

管理人補足:ここで唐突に出てきたRNGはRandom Number Generatorの事で乱数発生のことだと思われます。

experience とは、任務に割り当てられた工作員が得る経験である。

outcome_chanceは基本的な結果のみを達成する確率を指定します。
逆説的ですが、この値が低いほどプレイヤーは追加の報酬を得る可能性が高くなります。
失敗する可能性のあるオペレーションが必要な場合は、基本的な結果の率を悪くするだけで良いです。その場合にはoutcome_chanceが失敗の可能性になります。

outcome_modifiersは、結果に影響する修飾子を指定します。
これらの修飾子は、エージェンシーのアップグレード、国家精神、アイデア、大臣などのように、別の場所に設定されます。
これらの修飾子の合計によって、基本的な結果は多かれ少なかれ可能性が発生します(オペレーションが常に結果をロールするので、ボーナス結果の可能性を順番に増減させます)。

可能な修飾子は次のとおりです。

  • Outcome_modifiers(結果チャンスの変更)
  • Risk_modifiers(リスクチャンスの変更)
  • Cost_modifiers(機器コストを変更)

特に優れた機能は、オペレーションで修飾子全体を定義できることで、このシステムを非常に柔軟なものにしています。
他の領域では、修飾子をコードで定義する必要がありますが、ここでは、オペレーションで名前を指定するだけで修飾子を定義できます。
更にその修飾子を大臣、テクノロジー、または国家精神に追加するときに、その修飾子の名前で参照できます。

ここでマジックが起こります。
Outcome_executeは基本的に、エフェクトを実行するためのフィールドです(その意味で、例えば、決定またはフォーカスとあまり変わりません)。
Outcome_extra_executeは別のエフェクトフィールドです。
Outcome_chanceは、終了時にオペレーションがoutcome_executeとoutcome_extra_executeのどちらを実行するかを決定するものです(outcome_chanceは、outcome_extra_executeの代わりにoutcome_executeを実行するチャンス設定となります)。

この例では、ゲームがボーナスをロールする場合、単純なrandom_listが代わりになり、ボーナスの大きさが決定されます。
たとえば、敵国の安定性を低下させる作戦であれば、状況によっては内戦を開始するわずかなチャンスを持つ可能性があります。

オペレーションの結果を常に同じにしたい場合は、実行すべき結果をoutcome_extra_executeに入れ、outcome_chanceを0に設定します。

Outcome_potentialは基本的に、オペレーションが実行される前に予想される結果のツールチップを生成するためのものです。
ご覧のように、オペレーションの実行によって得られると予想される最小値をプレーヤーに表示することは、outcome_executeと同様です。

こちらはフェーズをどうやって選択するかという方法を設定する部分です。
各フェーズには基本確率があり、ご覧のようにその確率は変更できます。

特別な処置として、上の画像のオペレーションにはバグが含まれていますが、これを書いているときに初めて気づきました。見つけられるかどうか試してみてください!

解決策のネタバレはこちら:

オペレーションフェーズはターゲット状態が選択される前にロールされるため、FROM.FROMでレジスタンスをチェックする基本ウェイトの修飾子は何も行いません。

以上

振り返り感想

ということで、1.9のパッチログ(全部省略したけど…)とMod制作についての紹介でした。

Modのところは変数指定してそこに値を設定して…
となんとなくやってることは分かりますが、
私自身全くModは作れないので訳がいまいちな部分が多々あると思います。
ご了承くださいm(_ _)m

来週はいよいよLa Résistance DLCがリリースされます。
そして開発者日記があるかないかも不明です(たぶん無いと思う)。

HoI4開発チームはDLC発売後は次の作業の全容が見えるまで開発者日記をお休みすることが多いので、当分日記はないかもしれませんね。