2020/2/23 フォーラム内のやりとりを追記しました。
パラドックス社の公式フォーラムに
ステラリスの開発者日記 第170回が掲載されています。
今回は興味のある方も多いと思われる、パフォーマンス改善についてのお話です。
※画像等はフォーラムより引用。
ステラリス 開発者日記 第170回 パフォーマンスとその他の技術的問題
いつも技術的なお話の時に登場するお方。
冒頭のあいさつ
こんにちは、私のフレンド達！
ステラリスのテクニカルリードのMoahです。
ついに、皆さんが待ち望んでいたことについてお話しします。
つまり、Federations DLCには新しいカモノハシが何体導入されるのでしょうか。数週間後の…。
管理人補足:このMoahさんってのはカモノハシが好きだと前々からおっしゃってるのでそのジョークだと思われます。
スウェディッシュジョーク、ムツカシイネー(´･_･`)
さて、どうやら私は「より技術的」な事を話すべきのようです。
しかし、Stellarisのコードの謎へと飛び込む前に、まずは新しい機能の追加、パフォーマンスと安定性の改善のバランス、特にマルチプレイヤーとその恐ろしい非同期(少なくとも私は恐れていた)の観点から、少しお話ししたいと思います。
繊細なバランス
Stellarisというのは、普通のコードベースと同じように、MikadoやJengaの複雑なゲームのようなものです。
管理人補足:
Mikadoってのはヨーロッパでポピュラーな竹を使ったアナログゲームのことらしいです。日本産ゲームとのことですが私は知りませんでした…。Jengaは有名ですよね。
すべての部分が何らかの方法で他のすべての部分に接続されています。
ある機能を追加すると、それへの接続が追加されます。
気をつけて追加すればほんの数個が、急いでいる場合は少し多く追加されます。
これにより、通常は未計画のフィーチャー(つまりバグ)が作成されます。
さらに、実際のゲームでそれらが実行されると、新しく予期しない方法で機能が拡張され、より多くの予期しない機能につながる傾向があります。
何が起こっているのかがわかったら、より慎重になります。おそらく注意が必要です。
あまりにも多くのことを頻繁にチェックし、実際には起こらないはずの相互作用が実際には起きていないことを確認します。今じゃなくて、後にもない、そして一度もないということをです。
このようにして予定外の機能は削除しましたが、ゲームはちょっと慎重すぎるようです。…つまり進行が遅いと言う人もいるでしょう。
そこでこれらのチェックの一部を削除します。
銀河の周りをループする必要はなく、小さな惑星の周りをループするだけで良いことに気が付きます。
さらに一歩進んで、「3週間ごとにしかチェックしないかもしれないし、この計算はすべてのチェックで必要なので、ここに保存しておき、次に変更されるまで再利用できる。」と考えます。
そのため、ゲームはそれほど慎重ではなくなってしまい、予定外の機能領域へまた戻ってしまいました。
しかし、キャッシュ(計算の保存/再利用)が異なるマシンで異なる時間に行われると、結果は少し異なります(コーヒーを飲む前後に開発者に何かを頼むようなものです)。
どんな規格外の事が発生しているかによって少し異なる結果になります！
クライアントとサーバには0.0001のコスト差があり、時間の経過とともに悪化し、。
そのコルベットはサーバでは購入されているが、クライアントでは購入されていないというような事になります。
そこで、「賢い」アルゴリズムを削除し、正しいアルゴリズムに置き換えます。
ステップ2で得たものの半分を失い、いくつかのバグを再導入します。たぶん。
すすぎと洗浄を繰り返していきます。
でも、毎朝のルーティンはもうたくさんです！…では続きを話しましょう。。。
パフォーマンス
StellarisのファンというのはC++のプログラマーと同じで、パフォーマンスの事が常に彼らの頭の中にあります。
公平を期すために言っておくと、それは最近私たちの中にもあります。
特にゲームの終盤や大規模サイズの銀河ではパフォーマンスの問題があることを知っています。
このことを念頭に置いて、通常よりも少し深くパフォーマンスを改善するために時間をかけました。
最も時間がかかっているものついて調べましたが、それは誰もが知っていることでした…。
Popsです。
Stellarisでポップが多くの時間を消費するのには多くの理由がありますが、一番重要なのは、ゲーム終盤では非常に多くの時間を消費するということです。
非常に、非常に、非常に、非常に、非常にです。
そして、彼らは実に多くのことをします！
Popはすべてのジョブで自分がどれだけうまくいくかを計算しなければなりません(彼らは、7日ごとにそうします)。
そして彼らは、自分が最も得意とする仕事を得るために、惑星上の他のすべてのポップと競争しなければなりません。
彼らはまた、彼らが特定の倫理を持つことができるかどうかも確認しなければなりません。
もし彼らが特定の派閥に入ることができたらどれくら幸せでしょう。
どれくらい幸せになれるでしょう。あそこの惑星にいたらどんなに幸せになるでしょう。
これらすべてが変更因子の計算をトリガーするのです。
私の前回の開発者日記を覚えている人は、変更因子がStellarisのPopよりも多い唯一のものであることを知っているでしょう。
そして、それらはすべてお互いに依存しています。
それらを計算することは、糸を引いてセーター全体を手に入れるようなものなのです。
それは分かったが、実際に何をしたのか？
まず第一に、「新しいジョブがいつ追加されるか分からないので、毎日ジョブを分配する必要がある。」という私の考えは全体的に少々神経質だったかもしれないことを認めます。
私たちはこの前提を再検討し、今ではジョブの分配はオンデマンドでのみ行われています。また、繰り返し処理を行う対象がより少なくなるように書き直されました。
私たちはまた、帝国のすべてのポップを通過するいくつかのトリガーが、1人以上が奴隷化されているか退廃的であるか、または種のレベルにおいてテスト可能な他のものをチェックしていることに気づきました。
そこで私たちはこれらを種のレベルでテストする新しいきっかけを作りました。
同じような考えで、私たちは艦隊を見つけるためにすべての船に対して通過させるイベントがあったので、それに対して艦隊レベルでのトリガーを追加しました。
第二に、私たちはまたポップが倫理を変えることができるかどうか(そしてまた同じように機能するかどうか)、彼らが派閥に加わることができるかどうかをチェックするアプローチを作り直しました。
最後に、より多くのマルチスレッドを使用する機会を探しました(そして発見しました)。
話はもうたくさんだ！と思うことでしょう。
結果はどうなったのか？
もし百聞は一見にしかずだとしたら、これが毎秒3万語におよぶ答えです。
このビデオでは、コミュニティからセーブゲームを走らせたときの2.5.1″Shelley”と2.6″Verne”のパフォーマンスを比較しており、2万以上のポップがいる状態のものです。
私の仕事用のコンピュータ(Intel Core7-7900X@3.30 GHz、10コア、20スレッド、AMD R9Fury)に記録されました。
必ずしも同じ結果が得られるとは限りません。パフォーマンスの正確な違いはコンピュータによって異なります。もちろんセーブしたゲームごとに正確な状況も異なるでしょう。
平均して、ゲーム後半の状況で15％から30％の改善が見られました。
この節約は、ポップの改善の影響を示すものとして理想的です。
平均してどのくらいなのか？どうすればわかるのか？
私達には毎晩、徹夜でゲームをするシンセがいます。
朝、彼らがどこまで実行できたかをチェックします。
また、どのくらいの数のエラーが発生したのか、ゲーム終盤ではどのようなものだったのか、規格外の動作を取得したかどうかを尋ね、それらをすべて表やグラフにして、さまざまな色で表示しています。
その後シンセを一層しますので、魂やその他についての厄介な質問はしてきません。
結論として
私たちはパフォーマンスを念頭に置き、それを合理的なものにするために最善を尽くしていますが、この問題を深く掘り下げる機会を得られたことは喜ばしいことです。今回の変更が、私たちと同じくらい皆さんの喜びにつながることを願っています。
来週は、皆さんが待ち望んでいた他のことについての別の開発日記を特集します。つまり更に多くのカモノハシについてです！
PS：私たちが使用しているセーブファイルは、パフォーマンススレッドの1つであるコミュニティからのものです。
ただし、元々どこから入手したのかはわかりません。
あなたがこれを認識した場合、またはこれがあなたのものであれば、私たちに教えてください。
以上
フォーラム内のやり取り(Q&A)
回答側はステラリス・テクニカルリードのMoahさんです。
Q:現在のパッチでポップが1日ごとにジョブをシャッフルするのはなぜですか？
A:私たちは毎日、すべてのジョブでポップが適しているかを計算しますが、毎日ジョブにポップを(またはジョブをポップに)再配布します。
これが行われた理由は、ジョブの量が実際には修飾子であり、修飾子はどこからでも得られるため、何かが変更されたときにのみチェックするという方法が実際にはないからです。
しかし現実的には、これらのことが実際に起きている場所はごくわずかなものであり、それらをローカライズするのは簡単でしたので私たちはそうしました。
いくつかを見逃していたのですが、「XXXが発生してもジョブが更新されない」というバグレポートがありましたので修正しました。
これで、おそらく99%のケースでジョブの数が変更される事で、ジョブ分布が更新されるようになります。
小惑星の衝突イベントによって「ブルース・ウィリス」のジョブが追加され、それがすぐには反映されずに経済状況が更新される直前にしか反映されない―という特別なケースもあるかもしれませんが、それ以外の場合はうまく機能するでしょう。
いちおう管理人補足:映画「アルマゲドン」の事を言っとるんでしょうたぶん( -_-)
Q:現在の状態よりも15%良好であっても、まだ許容範囲から遠い状態です。
同程度にパフォーマンス改善に注力し続ける計画はありますか？
それとも「常にパフォーマンス改善に取り組んでいます」という現状に戻るのでしょうか？
A:私たちは常にパフォーマンスに取り組んでいます。常に改善できる新しいものを探しています。
今日の改善はどこからともなく出てきたものではなく、過去に行った作業から出てきたものなのです。
改善について懐疑的であっても、それは真実ではありません。
Q:マルチスレッド使用の改善について何か言及できるでしょうか？
特に、ジョブや艦隊の動きをチェックする専用のスレッドがある場合、これについて知ることは非常に興味深いでしょう。
実際パフォーマンスモニターで何度も調べましたが、スレッドの1つがピークで、他のスレッドはほとんどアイドル状態です。
あなたの知見を垣間見ることができるでしょうか？
A:残念ながら、マルチスレッドについて言えることはあまりありません。
ほとんどの人が望むほど徹底的ではありませんが、並列化を管理しているものがいくつかあり、スレッドプールをリアクティブに変更しました。
また、スレッドプール全体にタスクを分散する方法も改善しました。
私たちはまだより良い使用法を検討していますが、現時点で私たちに最大の結果をもたらせるものとしてポップに焦点を合わせました。
Q:個々のポップの量を減らすことを考えたことがありますか(つまり、ポップ成長率を下げ、住宅と人口に依存するすべてのしきい値を下げ、それに応じて雇用によって生み出される資源を増やします)。
とにかく個々のポップは抽象的なユニットであり、なぜユニットを少し大きくする方向にしないのでしょうか？
私の惑星が40～60のポップであろうと100～120であろうと、ゲームの後半に最大化されるかどうかは、提供されるリソース/必要なリソースが同じであれば気にしません。
つまり、Ver2.0より前の惑星あたりのポップユニットのハードキャップは、地表タイルの数、つまり25だったはずです。
A:それには2つの異なる答えがあります。
はい、たくさん考えました。@grekulfおよび設計チームと議論することもできます。
しかし同時に、いちプログラマーとして技術的な制限のためにゲームのデザインを変更しなければならないのは気分が悪いことなのでです。
私たち(Stellarisのプログラマー)は、むしろ技術的な問題について考えることなく、ゲームデザインが望むものを決定するシステムを持っています。
Q:私はすべてのスローダウンの解決策として、「ジョブの配布がオンデマンドでのみ行われるようになったこと」について少し混乱し、懐疑的です。
これは本当に私たちの中心的な問題を解決するのでしょうか？
パフォーマンス低下に関する(パラドフォーラムの)巨大スレッドではスローダウンの問題が、毎日新しいジョブをチェックするポップではないということを述べているはずです。
スレッドによると、それはむしろ新しい(空いている)ジョブが開かれたときにポップをチェックすることです。
つまり、新しいジョブが作成されると、現在のジョブを離れて新しいジョブを取得するかどうかを毎日チェックします。
(分析を含むGnoSISの投稿：https://forum.paradoxplaza.com/forum/index.php?threads/performance-megathread.1253705/page-22 の投稿番号427）
多くの(失業者)ポップは有益であるはずで、通常の定期的なチェックはそれに比べてはるかに問題が少なかったです。
A:これは「すべてのスローダウンの解決策」ではありません。
これは最も一般的な速度低下の解決策であり、さまざまなメカニズムを介して数回にわたって複合されたものです。
誰もが200AI、10Kの惑星の状態でゲームを3000年代までプレイできるような”魔法の弾丸”ではないのです。
今回の紹介ビデオでは確かに最良のシナリオを示しており、ポップのノイズはそれほど多くなってませんが、艦隊が多いゲーム状況ではそれほどメリットがないと思います。
今後もパフォーマンスの向上に努めていきます。
私の個人的な目標は人々がCK2(クルセイダーキングスII)のように、ゲームにより遅い最適速度の導入を求めるようになることです。
Q:ゲーム後半の状況で15%および30%の改善。
A:特定のセーブおよびマシン構成に応じて、全体的に15～30％程度です。
Q:、奴隷市場を開くとき、本当に時間がかかります。
私にとってとにかくこの遅さが奴隷市場を使わない理由になっています。
すべてのポップを表示するのではなく、市場に同じポップを蓄積する方が良いのではないでしょうか？
A:はい。改善されます。
Q:とにかく答えてくれてありがとうございます。良い仕事を続けてください！
しかし一般的な考えとして、特定のゲームタスクごとにスレッドを専用にしないのはなぜですか(もちろん、十分なスレッドが利用可能であれば)。
これにより、CPU使用率が大幅に向上(バランス化)し、遅延が減少する場合があります。
しかし、私はあなたがすでにそのアイデアを持っていたことを喜んでいます。
そして、どうしてそれを今まで行わなかったのだろうとも疑問です。
A:問題の1つは、ゲームが修飾子に基づいていることです。
ほとんどすべてが修飾子であり、修飾子は他の修飾子に依存しており、それらがどのような状態にあるのかがわからないため、修飾子の計算を簡単にスレッド化することはできません。
そして帝国に応じて惑星に依存するポップのような、依存関係のチェーンもあるため、これらを並べて並列化することはできません。
艦隊はシステム、国、そしておそらく惑星に依存しているのか？等です…。
対応は不可能ではありませんが、「了解。では私たちがすべてを処理する方法を書き直している間、6ヶ月の間ステラリスの作業をやめましょう。」となるでしょう。
結局のところ、パフォーマンスを向上させるためにこれを行う必要はないと考えています。
スレッドプールの戦術的な使用は大いに役立ちます。
私は、はるかに小さな書き換えで素晴らしい結果を得ることができる他のいくつかのポイントにすでに見当をつけています。
Q:帝国の態度の銀河マップを開くとゲームがハングアップすることを思い出しました。
fpsが60→2～3に低下することがあります。
A:私は実際にそれについて修正したことを覚えています。したがって、Ver2.6でははるかに優れているはずです。
Q:あなたがゲームデザインを維持したいがスピードも提供したい場合、半分のポップ成長率でx2のポップ生産というスライダーを作成してみてください。
そうすればシステムの速度が遅い人でもプレイできます。
A:CK2などの「ゲームルール」を採用して、それが好きな人のためにスライダーを導入するというアイデアは半分出来上がっていますが、まだ実現していません。
Q:開発者日記で非同期の問題に言及していますが、後ほどちゃんと言及してません。
それはあなたがまだその問題に取り組んでいるということですか？
あるいは非同期の問題も同様に改善されたと受け取っていいのですか？
A:動画ストリーム配信中およびこの投稿の前半で述べたように、非同期の問題に取り組んできました。
いくつかを修正しましたが、どれだけの数が残っているのかわかりません。
なぜなら、一度に膨大な数の人がプレイしなければ、確実に知るのは難しいからです。
Q:パフォーマンスの改善は有望に見えますが、特定の通知を無効にする機能を実装することをお勧めします。
A:私は、同様の通知をグループ化することを考えていましたが、それに取り組む時間はありませんでした。
※次はMoahさんの追加情報です。
ベータテスターの一人からこの写真を投稿するように頼まれました。
写真の後に彼のコメントを引用します。
これはIntel Corei5-3570KをベースにしたPCです。
古いビルドに対する改善されたビルドの比率は、2300年までは平均で約10%の減速を示し、その後速度を上げ2500年までに50%速くなりました。
これは、最初の100年でより多くのポップを持ち、機能の改善がまだ始まっていないためと思われます。
実際には経過は直線的であり、これもまたポップスの数と結びついていると思いますが、さまざまな時に起こる戦争のためにこのような奇妙な形をとっています。
したがって、ポップ数の増加を考慮すると最終的には2倍高速になります。
Q:これはすべての「フェデレーション」DLCの機能が実行された上でのパフォーマンス改善7日、それともVer2.5台に対してのものなのか？
A:全て適用させた状態でです。
今回は以上です(フォーラムの14ページまでチェック)。
Moahさんの追加情報のグラフが興味深いです。
まず、日記本文のMoahさんの環境はIntel Corei7-7900X@3.30GHzです(ターボブーストがかかると4.3GHz)。
そしてテスターの方はIntel Corei5-3570Kです。こちらはベースクロックが3.4GHzです(ターボブーストがかかると3.8GHz)。
ベースクロックはCorei5-3570Kの方が僅かに高い。
もちろん環境やセーブデータ、ゲームの進行状況等が異なればパフォーマンスはがらっと変わるのだろうと思いますが、
今回テスターの方がCorei5-3570Kの方が50%高速になって、
Core7-7900Xは30%高速というのはとても興味深いです。
というかこれってIntel のCPUなんだけど脆弱性パッチはちゃんと当てた上でのパフォーマンスなんだろうかとチラッと思ってみたり。
とりあえず、Moahさんのおま環じゃなくてテスターの方でもバッチリ効果が出てるみたいなので、期待が持てそうだと思いました(･∀･)
感想・まとめ
以上、Stellaris 開発者日記 第170回の紹介でした。
もうですね、最近とんでもない分量の日記ばかりだったので
今日はまずページを開いたら、
中身よりも真っ先にブラウザの縦スクロールバーの長さをチェックしましたよね。
ガチで(´･ω･`)
幸い今回は文章量的には少なめでしたがMoahさんのよくわからないスウェディッシュジョークが多くて訳しにくかったです( -_-)
あわせて、技術的な事は私には分からないので
あまりうまく訳せてない箇所も多いと思いますがご了承くださいm(_ _)m
とりあえずMoahさんの時はカモノハシについては「ああまた言ってるな」ぐらいで流しておけばよいかと…。
内容としてはゲームパフォーマンスが大幅改善されるとのこと。
実際どのくらい効果があるかは本文中にもあったようにPCの構成にもよると思いますが、多少なりとも改善されるようで嬉しい限りです。
個人的にはMoahさんの構成見て珍しいと思いました。
CPUはインテルでGPUはAMDのラデオンなんですね。
(もちろんダメとかそういう意味じゃないです。くれぐれも。)
あと、意外と最新の性能じゃないんだなとも。
開発者は我々のようなただのゲームユーザーとはパーツ選定の基準が違うのかもしれませんが…(･_･)
次回の日記は内容不明ですが、とりあえずまだFederations DLCのリリース日は未発表のようです。
そろそろ発表があってもよさそうですが…。
それではまた( ✧Д✧) ｶｯ!!
