パラドックス社の公式フォーラムに
ステラリスの開発者日記 第232回が掲載されています。
今回はゲームバージョン3.2でのバランス調整とパフォーマンス改善についてのお話です。
※画像等はフォーラムより引用。
ステラリス 開発者日記 第232回 Ver3.2のバランス変更とパフォーマンス改善
冒頭のあいさつ
みなさんこんにちは。今日はSF作家Frank Herbertにちなんで名付けられた近日公開予定のVer3.2″Herbert”パッチに関するいくつかの変更点について紹介します。
このパッチはAquatic Species Packとともにリリースされます。
バランス調整
バランス調整については以下の変更があります。
- Functional ArchitectureおよびConstructobot:無料の建築スロットを2から1に減少
- Agrarian Idyll(農業牧歌)帝国は4つの農業地区が建設されるごとに惑星に1つの建築スロットを獲得する
- 決定システムを使うことで、クローン軍提督の艦隊維持コストを5/10/20減らすようにできる
- Ruins of Shallashの遺跡から終盤の危機を打ち破った時と同じぐらいの統合力は得られないように変更
- 原始種族に対する適切な干渉ポリシーがない場合には境界内の原始種族がいる惑星に対して惑星破壊兵器を使えないように変更
- 家畜の世話をしているポップは政治権力を10%減少
- 多くのアノマリーが3つの科学調査値を得るようになっていたが、より多様性を持たせた
- 覚醒した没落帝国が伝統を使用するようにした(アセンションパークは使用しない)
- 生産性を向上させるいくつかのテクノロジーは、その維持費(および生産量)の効果が実際に主に資源を生産するジョブにのみ適用されるようになったため、もはや疑わしい利益ではなくなった
- ハイブマインドの神経ステープルのポップは複雑なドローンのジョブを実行できなくなった
- レジャー・アーコロジー地区が増やすジョブの量を減らし、他のエキュメノポリス地区と同じにした
- イオンキャノンを無料で維持することはできず、8エネルギー維持費がかかる
- ネクロハイブについて:
- ネクロファージポップのアセンブリ・ペナルティを75％から50％に削減
- ポップを生み出すための修正(Mod？)はプラス方向もマイナス方向もハイブマインドには適用されなくなった
- -50％の有機的な維持が、光合成におけるエネルギーにも適用されるようになった
- 貪欲なスワームのネクロファージは、エレベーションチャンバーが無いことの代替として追加のインフラストラクチャで発生するようになった
ここで注目すべきは、Functional Architecture(機能アーキテクチャ)についての変更です。
この市民の主な魅力は追加の建物スロットであったことは認識していますが、リリース初期の評判でさえ、これはあまりにも過剰だと言われていたのです。
これらはLemパッチの時に行ったような事前に計画されたバランス調整ではありませんが、調整する場所はいくつか見つかっており今後のパッチでも調整を継続します。
…ここでCaligula Caesar氏にパフォーマンスの改善とMod製作の可能性について話題を渡します。
スクリプトのパフォーマンスを見よ！
こんにちは！おそらく皆さんは私が新しいMod製作可能性やスクリプト言語の機能について長文を書くことには慣れていると思います。
今回はそのような点ではお見せできるものが少ししかありませんが、それでもいくつかのクールで技術的なことをお話しできます。
スクリプト言語をよく理解している私は、スクリプトがパフォーマンスへ与える影響は自分にはまったくわからないといつも思っていました。
私が追加しようとしていたものはパフォーマンスに影響するのでしょうか？
どうすれば最も効率的にスクリプトを作成できるかは十分に推測できましたし、アーリーアウトなどのプログラミングの一般的な概念も適用できました。
しかしその差はどのくらいだったのでしょうか？
また効率の悪いスクリプトを見つけ改善することで、どれだけの節約ができるのでしょうか？
Moah氏は以前、EU4のスクリプトプロファイラをペットプロジェクトとしてStellarisに移植する作業を進めていました。
唯一の問題はその情報が非常に不完全であることでした(コードの多くの場所に多くのタグを追加する必要があるため。基本的にエフェクトやトリガーが呼び出される場所すべてにタグが必要です。)。
また提示された情報を読むのもかなり困難でした。
しかし今回のカストディアン・イニシアチブの取り組みで、これを使って何ができるのかを確認する時がやって来ました。
情報をすべて網羅し、体系的で読みやすいものにするための(非常に面倒な)作業の後、AIにいくつかの追加ブースト(研究費0.75、居住可能な惑星1.25)を加えた巨大銀河の設定でゲームを走らせ、スクリプトプロファイラを有効にして1年間実行してみました。そうすることで問題が見つかるかもしれません。
この出力の2つのバージョンを添付します(管理人注:添付ファイルは元サイトで御覧ください):
一つは初期の実行の時のものですーカバー範囲は包括的です(特筆すべきはトリガーされたMod可能性と経済表がないこと)が、最適化作業が行われる前のものです。
そしてもう一つは3.2ベータ版です。
(各オブジェクトに費やした時間の数値はプロファイラーをオンにして最適化されていないデバッグモードでゲームを実行したため、大幅に増加していることに注意してください)。
先に断っておきますが技術的な理由から、3.2アップデートでスクリプトプロファイラを公開することはできません。
スクリプトプロファイラを使用してゲームを実行すると、ゲームの動作が約50％遅くなるため、スクリプトプロファイラとそのパフォーマンスへの影響を自由にオン・オフできる方法を開発する必要があります。
(今のところ、この機能は一般には公開されていないコンパイラフラグに隠されています)。
しかし将来的にはMod製作者の方々に公開できるようにしたいと考えています。
初期の成果
最初の大きな発見はゲームが特定のゲームルールの再計算をポップごとに毎日大量に繰り返しており、それがパフォーマンスに不均衡な影響を与えているということでした。
最大の原因は”can_vote_in_democratic_election”で、各派閥のポップが支持率を計算する際に、国中のすべてのポップを毎日チェックしていることがわかりました。
これは以下のように理解してもらえば良いです:帝国主義派閥が全国のポップに投票権があるかどうかを確認し、次に繁栄派閥が同じことをして、さらに帝国主義派閥が…という具合です。
これらのケースは、デイリーキャッシュを利用することで修正されました。
ポップは1日に1回(species_has_happinessの場合は、1日に1つの国の種ごとに1回)結果を計算するようになり、コードの他の場所ではその結果を参照するだけでよくなりました。
さらに、ポップの派閥支持率の計算は、派閥ごとではなく国ごとに一度だけ計算できるように最適化されました。
スクリプトの面ではトップヒットした様々なスクリプトを解析することで、簡単に最適化できるスクリプトがいくつか見つかりました。
まずはgraygooについてです。
Gray Gooが活動しているときにのみ発生するはずのイベント(実際には活動していない)に対して、555回という驚くほど多くの回数を実行しようとしていました。
これは “is_triggered_only “が欠けていたためで、毎日すべての惑星で発生しようとしていたのです。
同様に、多くのテストイベントも同じの方法でスクリプト化されていますが、トリガーとして「always=no」を使用しているため、イベントが発生することはありません。
これらは小さな事ですが、それにもかかわらずパフォーマンスに顕著な影響を与えました。
意見に関するMod要素 triggered_opinion_galactic_community_in_breach は、他の意見に関するものよりも圧倒的に多くのパフォーマンスを消費しており、少し奇妙に思えました。
この問題はトリガの順番を少し変えるだけで解決できることがわかりました。
銀河共同体のメンバーシップを確認する前にis_in_breach_of_anyをチェックしていたのです。
これは大きな問題ではないように聞こえますが、このトリガーは、通過したすべての決議の違反条件のトリガーをチェックするので、実質的には1つの中にたくさんのトリガーがあることになります。
この順序を入れ替えるだけで非常に良い結果が得られました。
最後にイベントcrime.1(初期バージョンではなぜか2番目にコストのかかるイベント)も似たようなケースでしたがもっと複雑でした。
ここでの主な問題は次のようなスクリプトでした。
これは非常に非効率的であり、アーリーアウトの原則を適用することで大きなメリットが得られます。
Count_owned_popは、スクリプトをコードに変換してその結果を計算する際に多くの効率が失われるため、比較的高価な計算方法です。
つまり80人のポップがいる惑星では、それぞれのポップをループさせ、それぞれのトリガーをチェックしています。
残念なことに順序があるので、失業者が3人もいない惑星では1日に2回これを行うことになっていました。
- このイベントでは居住している各惑星のトリガーを毎日チェックしています。あるいは少なくとも頻繁に。正確には年に44,000回です。
- どのような種類の失業者ポップがいるのかを明らかにする前に、惑星上に失業者ポップがいることを確認していません。
これは両方のcount_owned_popセクションでORがfalseを返すことを意味し、その結果両方をチェックしていることを意味します。スタート時にnum_unemployed>3 を追加すると大きなメリットがあります。 - これは非ゲシュタルトに関連する失業者のポップの数をチェックし、その後でのみその国がゲシュタルトではないことをチェックすることになります。
ゲシュタルトのチェックを最初に入れ替えることで、count_owned_popループのうち1つだけを試行することになります。
したがってトリガーのより効率的な新しいバージョンは次のようになりました:
さらなる分析からの利益
これはこれで修正すべきクールな機能ったのですが、これ以上は単純にリストを見るだけで大幅な節約につなげるのは少し難しいです。
そこでスプレッドシートの登場です！
われわれは結果をスプレッドシートに貼り付けいくつかの数式を入力し、素敵なピボットテーブルを作成して「すべてのジョブの全体的な影響は何か」や「ポップ派閥の潜在的なトリガーの影響は何か」 といった内訳を表示しました。
画像はパフォーマンス向上後の値を示しています。
これによりさらにいくつかのことを特定することができました。
第一にai_resource_productionは比較的少数のヒットによって、とんでもなく高いパフォーマンス・コストを引き起こしていました。
犯人はplanet_resource_compareトリガー (主にここで使われています)が信じられないほど高価だったことです。
問題は基本的に惑星上のすべての資源の出力を再計算していたことです(各ポップの出力を見ることも含めて！)。
関連する資源の生産量を選択的に再計算することでこの問題を多少(約75％)軽減できることがわかりましたが、それでもトリガーとしてはかなり高価なので使用量を少し減らしました。
Mod製作者の方たちも使いすぎないことをお勧めします。
もう一つ分かったことは予想外ではなかったですが、ジョブについてはかなり高コストということです。
具体的には重み付けと”possible”のチェックです。
重み付けにかかる時間を短縮するためのアイデアはいくつかありますが、まだお話しできる段階ではありません(それらは、いくつかのイテレーションを必要とする可能性が比較的高いので3.2の開発段階では、パッチの対象とするには遅すぎました)。
しかし、possibleトリガーを安価にする方法を見つけました。
基本的に7日ごとにポップのジョブキャッシュを再計算し、その時点で各ジョブの作業が許可されているかどうかをチェックし、許可されている場合はその重みを計算します。
しかしほとんどのジョブには、最初の部分をチェックするかなり標準的なpossibleトリガーがあります。
具体的には、ワーカー、スペシャリスト、ルーラー、ドローンの各ジョブの間で、トリガーのセットが共有されています。
popにこれらの4つのトリガーを最初に計算させてから、ジョブをループして結果を適切なジョブに単純に一致させることで、非常に大幅な改善(約2/3程度)が可能であることが判明しました。
(Mod製作者への注意:フォーマットが少し変わっています。スクリプト化されたトリガworker/specialist/complex_specialist/ruler/drone_job_check_triggerを使用した場合は、ここで”possible_precalc=can_fill_ruler_job”などを定義する必要があります。これらを変更した場合は、game_rulesの新しいバージョンを変更する必要があります。)
最後に、ゲームルールの最適化によってポップ派閥のパフォーマンスに関するいくつかの問題はすでに修正されていましたが、さらに改善できる点がいくつかありました。
スクリプトとコードの両方が派閥に参加できる5人のポップがいるかどうかをチェックしていましたが、派閥が形成された後はコードがこれをチェックしていないことがわかりました。
明らかにこれは理想的ではないので、スクリプトのチェック(遅い方)を削除し、コードのチェックは、ポップが減少すると派閥が無効になることを考慮して修正しました。
2つ目はポップが派閥に属するべきかどうかの判断です。
ほとんどすべての派閥は、その派閥の気風に合致するポップしか参加を許可しないにもかかわらず、気風によるフィルタリングはかなり遅れて行われます。
このフィルターを、スクリプトがチェックされる前にコード上に設置することで、この特殊な計算のコストを大幅に削減することができました(技術者のロボットなど、このフィルターが不要な場合はオーバーライドすることができます)。
最後に、派閥ごとに毎日チェックされる要求の中にはかなり法外なものもありました。
そこで順序を変更し、同等で安価なチェックを使用することにしました(例：any_owned_popの代わりにany_owned_speciesを使用)。
これも大きな効果があり、ポップ派閥のスクリプトの専有領域(使用しているゲーム・ルールを除く)は約3分の2になりました。
その他のパフォーマンスに関するトピック
この作業が、ゲーム後半のスローダウンを少しでも軽減するという形で実感できることを願っています。
私のテストでは成功したと言えますが、どの程度かを数値化するのは非常に難しいです。
しかし、この作業はスクリプトのパフォーマンスフットプリントにのみ焦点を当てたもので他にも検討すべき点がたくさんあります。
パフォーマンスに関して言えば仕事は決して終わっていないので、3.3ではさらに改良を加える時間があることを期待しています。
例えばゲーム後半のUIのラグに関する不満をいくつか耳にしましたが、これはパフォーマンス作業の結果いくつかのインターフェースで若干改善されるかもしれませんがこの作業はUIに焦点を当てたものではありません。
確かにいくつかのUIは我々が望むほど高速ではありません。
特に惑星ビュー、種族ビュー、入植地選択メニューなどがそうで、これらを高速化するオプションを検討しています。
(他にも思い当たることがあれば、ご指摘いただけると助かります！)。
改造性(Mod化)の改善点
開発日記といえば改造性の向上について語らずにはいられないので、ここではそれを紹介します。
先に述べたように今回はそれほど多くのことはできませんが、皆さんに試していただきたいことがいくつかあります。
- create_nebulaエフェクトができました。
銀河マップ上の視覚効果はゲーム中には更新されないので、銀河生成時に使用するのがベストです。 - 決定にon_queuedとon_unqueuedの効果を設定できるようになりました
- テラフォーミングがメガコープエコノミーシステムを使用するようになっています。つまりコストが構成可能なリソーステーブルとなり、economic_unitの改造を作成して適用できます。
- 種族のリーダーの性別をチェックするspecies_genderトリガーがあります。
- 銀河マップ上で星系にマウスオーバーしたときに表示されるツールチップを定義できるようになりました。
- on_capital_changedとon_planet_class_changedにon_actionsが追加されました。
(管理人補足:首都の変更と惑星クラスの変更に関するトリガー要素です) - 伝統について、その採用伝統のpossibleトリガーが失敗した場合、採用するためのツールチップに表示されるようになりました。
伝統のカテゴリーにグリッドボックスを追加するコンテナを持たせることもできるようになったと聞いています。
またMod製作者がアップデートしなければならないことがいくつかあります(前述のテラフォーミング以外です):
- any/count/every/random_planet_armyは、惑星の所有者が所有する軍だけでなく、その惑星に存在するすべての軍を参照するようになりました。
- Set_starbase_building/moduleおよびremoveのバリエーションはスロット1から始まるようになりました。これまでのように”set”が0から、”remove”が1からではありません。
- component_templatesにおいて、valid_for_countryがweightsフィールドではなくトリガーになりました。
- Fire_on_actionで、スコープを”prev “と”from”で定義した場合に問題がありましたが、これらが解消されました。
最終的な改造可能性の注意点として、大幅な改造可能性の変更を伴う充実した開発日記を見逃している人も心配する必要はありません。
われわれの新しいゲームのスクリプトをいじったことのある人なら、われわれのスクリプト言語にはもっと多くの可能性があることを知っていることでしょう。
現在いくつかのクールな機能が開発されていますが、具体的にどのようなものになるのか、どのようなパッチになるのかについては現段階では言えません。
また、前回と同じようにスクリプトのドキュメントを開発者日記にに添付しています。
また、3.2 Updateへの早期アクセスに関心のあるMod製作者は、改造をアップデートするため、https://pdxint.at/3bZbVJNからサインアップできます。
以上
フォーラム内のやり取り(Q&A)
※引き続き管理人多忙のため休止中です。再開まで今しばらくお待ち下さい😥
感想・まとめ
以上、Stellaris 開発者日記 第232回の紹介でした。
今回は技術的な内容が多くうまく紹介できたかは微妙な感じなので参考程度でお願いします。
また日記の掲載がいつもより遅かったことと、体調不良で記事を作るのに時間がかかり紹介が遅くなってしまいました。
皆様も風邪等お気をつけくださいm(_ _)m
