2019/5/26
フォーラム内のやりとりを更新しました。
パラドックス社の公式フォーラムに
ステラリスの開発者日記 第149回が掲載されています。
今回はなんと、ステラリスが64bit対応になるというお話です。
ステラリス 開発者日記 第149回 技術的な改善 2019/5/23
冒頭のあいさつ
こんにちは皆さん、Moahと言います。
私はStellarisのテクニカルリーダーで、今日はAncient Relics DLCと一緒にやってくる無料の2.3 “Wolfe”アップデートと、それが技術面でもたらすものについて話すためにここにいます。
Stellarisは64ビット対応になる
人々はこれまでの間この対応を求めていました。
そしてさまざまな要因により、私たちはついにこのパッチでこれを行いました。
ただ、私は皆さんの期待を少し落ち着かせることになります。
ー つまり多くの人が、64Bit対応がStellarisに関するすべての問題に奇跡的な治療法になると主張しているのですが、現実はいくぶん面倒なのです。
どういう意味なのか?
64ビット対応の確かな利点の1つは、Stellarisが4GBのメモリ使用制限から解除され、その限界に達している状況でもクラッシュしなくなることです。
多くの帝国、多くのMod、あるいは3000年代までの巨大銀河で遊ぶ人々にとって、これは恩恵となるでしょう。
パフォーマンスの面は、64ビット対応ではあまり変わりません。
技術的な詳細はともかく、一度に多くのデータを処理するために速く処理されるものと、処理するデータが多いために遅く処理されるものがあります。
結局のところ、私たちの測定では目に見える違いはありませんでした。
最後に64ビットへの切り替えの最後の効果としては、ゲームが32ビットのコンピューターまたはOS上で再生できなくなることです。
これが多くの人々に影響を与えるとは思いませんが、32ビット版を使用している方には影響があります。
パフォーマンスはどうなのか?
私はこの事が皆さんのお気に入りの質問であることは理解しています。
それでその疑問について話すために最善を尽くしましょう。
まず、フォーラム内の様々な投稿で浮かんでいるいくつかの概念について払拭させてください。
Stellarisはマルチスレッドを使用しています。そして私たちは常に新しいことをスレッド化することに注目しています。
実際、Ver2.2.0と2.2.7の間では、ジョブとポップのスレッド化に多大な努力が払われ、それが結果としてこれらのバージョン間でのパフォーマンスが向上した主な要因の1つです。
ポップスとジョブは確かに今日の私達のCPU処理時間の大部分を消費しているものです。
それぞれのポップが評価する仕事の量を減らすことでそれを改善しました。
私達は私達があまりにも多くの作業をしていた他の分野も見つけ、例えば次のような箇所を切り詰めました。
- 船体値が完全な健康状態にあるときにもそれらの日々の再生を計算すること
- オフスクリーンのアイコンが更新中の処理
- 居住不可能な惑星に対しても人口の多い惑星と同じ評価を行う
なぜこのような無意味なことが起こるのでしょうか?
まあ私たちは一般的に、ゲームをプレイし素早く作業することに集中しているので、コンテンツ・デザイナーは素早く繰り返し作業をすることで、ときには何かが欠けてしまうこともあるのです。
これらのシステムの中には非常に複雑なものもあり、新しいコードの規模はそれほど簡単にはわかりません。
多くの作業を行っていないため、ターゲットの数を制限しなくても十分な場合もありますが、数か月後に別の人が計算を追加したり、無関係な理由でオブジェクトの数が爆発的に増えたりすると、突然パフォーマンスの問題が発生します。
Mod(改造)
Stellarisが他のパラドックス社のタイトルと一線を画すものの1つは、Modの使用(あるいは乱用)です。
すべては変更なのです。
Modは他のMod製作者によって変更され、場合によっては他のModがModを変更する場合もあります。
これを理解するのは非常に難しく、気づかないうちにいつでもあらゆる価値を変えることにさえ繋がります。
「新しいジョブが表示されたときに、なぜジョブを計算しないのですか」とよく言われるのはこれらの部分です。
それに対する簡単な答えは、新しいジョブがいつ現れるのかを知るのは本当に難しいということです。
国、惑星、ポップスなど、どのModからでもジョブを得ることができます。
これらのそれぞれは、倫理、伝統、アセンションパーク、イベント、建物、仕事、国、惑星、ポップ、テクノロジーなどから改造を得ることができます。
これまではMod(改造)を手動で計算しようとしていたため、連鎖する全体を追跡する必要がありました。
国のModを再計算するときに、その惑星のModを計算すると、各惑星でポップModについて再計算されます。
フリーズしたものの中には、糸の塊が絡み合っているだけのものもありました。
これがModのフロー・チャートです。
最新ではありませんが、システムの複雑さがわかります(開発ツールであり、記事のために作られたものではないため、洗練されていません)。
もうやだ
2.3 “Wolfe”では、Modをノード・システムに切り替えました。
各ノードはそれらが従うノードを登録し、使用されるとチェーン自体に従って再計算されます。
より最新のModがあり必要なときにのみ計算されます。
これにより、無意味な再計算の回数も減ります。
このシステムは非常に有望で、ゲームの周りで起こる「大きなフリーズ」の数を減らした(例えば、特にロード後など)。
いくつかの問題がありますが作業を続けるうちに改善され、パフォーマンスとプログラマーの健全性の両方に役立ちます。
で、結果的にどうなのか?
我々のテストでは、2.3 “Wolfe”は現在の2.2.7よりも10%から30%速くなっています。
リリースされるまではこのままでいてほしいのですが、このような最適化は物事を壊し、問題を修正することで帳消しにしてしまうので何も約束はできません。
AI
もう一つのフォーラムのお気に入りであるAIについても私達はいくつかの改良をしました。
まず@Gravius(※)の許可を得て、一般的なAIの職務分配を改善するために彼の職務分担の重み分けを使用しました。
私達はまたブラッシュアップと改良に関して通常のやり方を行い、そしてもちろん私達のすべての新しい機能を使用する方法をAIに教えました。
※管理人注:この@GraviusさんというのはAI調整Mod、Glavius’s Ultimate AI Megamodの製作者様のことだと思われます。
ほかになにか新しいことは?
次回にゲームを開始するときではなく、発生したらすぐにクラッシュレポートを送信する新しいクラッシュレポーターもあります。
私たちは接続問題などのために私たちのnon-steamネットワークスタックを改良しました。
わかりました。もうたくさんでしょう。
GRRM並の長編小説のようになりました。さらに多くの分野をカバーすることができますが今回は参考に程度にしてください。
以上
フォーラム内のやり取り
今回の回答者はいつもステラリスのバージョンアップをお知らせしてくれるJamorさんと、今回の日記担当のMoahさんです。
以下A(回答)はJamorさんと記載がある以外はMoahさんの回答です。
Q:(64ビットになり32ビットの人を切り捨てることは)あなたが思う以上に多くの人々に影響を与えるでしょう。
A(Jamorさん):私たちの統計によると、1%未満のユーザーがまだ32ビットシステムにアクセスしています。
今回の目的は決してだれかを放棄することではありませんが、最終的にはさらなる開発を可能にするために技術的に進める必要があり、もしそうしなければ私たちの他の選択肢としてはすべてのMacユーザーを放棄することになります。
それを行うわけにはいかないでしょう。
Q:このアップデートでオーバーフローのバグが自動的に解決されますか?
A:一般的な答えとして、64ビット化は私たちが持っているオーバーフロー問題を魔法のように解決するわけではありません。しかし、それらの多くはチームによって個別に解決されています。
Q:64ビット化は短整数から長整数へ、そして単精度から倍精度への浮動小数点数の移動を容易にするのでしょうか。
64ビットレジスタを使用してもオーバーフロー自体は修正されませんが、変数を32ビットから64ビットに移動することで修正されるはずです。
64bビットの実行可能ファイルが最初のステップとなるでしょう。
A:そうでもありません。一つの問題は、我々は浮動小数点(をあまり多く)使わずに、様々な理由で独自の「10進固定小数点」を持っていることです。
これらを64ビットに切り替えることは可能で、これは開発中のプロジェクトで行われているが、大きな影響を伴う小さな変更になるだろう。
つまり目に見える3つのバグがすぐには見つからないかもしれない何百ものバグに置き換えてしまいます。
また、パフォーマンスへの影響も不明です。
つまりこれらの浮動小数点処置を行う予定はありません。代わりにオーバーフローを修正する予定です。
Q:L-Gatesや全体的なワームホール、そして他のゲート、またパス発見などがパフォーマンスが落ちる原因であると指摘されています。
あなたもこれについて認識していますか?この更新プログラムはこれらの問題も解決していますか?
A:私たちは(まだ)その問題に取り組んでいません。
残念ながらこれは問題であるもののまだ解決策がありません。
私たちの問題は、私たちがシステム(星系)から他のシステムまでの距離を含むキャッシュを持っているということです。
そしてあなたがバイパスまたは星系を追加/削除するとき、私たちはこのキャッシュを再計算する必要があります。
これは、すべてのバイパスに全員が同じアクセス権を持っているわけではないという事実によってさらに複雑になります。
ハイパーレーン距離だけのための “基本的な”キャッシュがあり、それからその帝国にアクセス可能なゲートウェイを通して距離を追加するキャッシュパッチがあります。
この帝国固有のキャッシュは、バイパスが追加されるたびに空にする必要があり、最終的には各帝国でゲートウェイの構築が開始され、大量のキャッシュの無効化と再構築が行われます。
それに加えて、プレイヤーが同じポイントに到達するためのより多くの方法を得るので、不変で経路探索自体はより複雑になります。
天才的なアイデアが見つかるまで、それを改善するために私たちができることがたくさんあるかどうかはわかりません。
開発内で削除する機能を提案するときに、私はゲートウェイ/ワームホール/ Lゲートを削除することを提案しました。
しかし何らかの理由で誰もそれを好みません!
Q:このゲームで遭遇する最大の遅延は、新しいシステムが生成されたとき(つまり、ホームシステムが出現するようになる前兆となる発見を完了したとき)です。
その状況の後ゲームは少しの間フリーズします。
これに関しても改善はありますか?
A:なぜそれが起こるのかを上で説明したところですが、今のところ良い解決策はありません。
Q:もし可能であれば、ロード時間を改善することが試みられていますか?
A:多少の改善はありますが、望んでいたほど多くの時間をこれに費やすことができませんでした。
Q:パフォーマンスの問題が最適化されるのであれば多くの人々が感謝することでしょう。
A:不思議な事にすべてのポップの75%を殺すとパフォーマンスの問題が解決します。
上のMoahさんの回答に対するJamorさんのA:私を誘惑しないでください。
こんなん笑えます(笑)。
そしてここからフォーラム内でパフォーマンス向上の為、75%抹殺を望む意見がちらほら出始めます。
Q:(住民の75%抹殺でパフォーマンスが上がると聞いて)私は次の銀河の危機のための考えがあります!宇宙インフルエンザです!
帝国の人口の75%を殺し、テーブル上のカードを再シャッフルします(全部で75%であり、配分は等しくない)。
A:私は宇宙風邪のような危機を望んでいました。
しばらくの間戦うことなく銀河系間の絶滅レベルの事件を解決するために各国に協力してもらうような内容です。残念ながら今は計画に入っていません。
Q:64ビットへ移行する際Ver2.2でのセーブデータはVer2.3でも動作しますか。
A:いつものように我々は互換性を維持しようとします。しかし何も保証することはできません。
Q:長距離のための最適なルート計算を見直して欲しい。
A:「クラスタ」パスファインディングを行うことを考えましたが、それらを調べる時間がありませんでした。
他にもゲート等に関して長文で延々と書き込んでる人達に対しての回答もあったのですが、内容的に理解しづらいのでカットしました(・_・)
住民を75%減らせばパフォーマンスが上がると聞いた後の反応を見ると、皆さんパフォーマンスの面で困ってるんだなぁという印象です。
実際ゲームの後半に行くほどあまりにも重すぎるんですよねえ( ´Д`)
感想・まとめ
以上、Stellaris 開発者日記 第149回の紹介でした。
ステラリスが64ビット対応になるといきなり発表されましたね(・_・)
ただしこれでパフォーマンスが劇的に変わるーという事とはまた違うようです。
メモリの上限がこれまで4Gだったというのにはちょっとびっくり。
かと言って今後は上限がいくらになるとは書いてなかったので、どこまで解放されるんでしょうか( ‘ω’ )
また今回の日記でステラリスはちゃんとマルチスレッド処理をやってるぞということが明言されました。
ていうかマルチスレッド処理をやってるのにこの重さなのか…(›´ω`‹ )
と、そういう意味ではやや絶望的な気がしなくも無いですが、
パフォーマンス改善については開発陣も適宜取り組んでいるようなので今後に期待したいですね。
64ビットになることで各種Modは対応する必要があるのか?
これまでのままで何もしなくていいのか?
ていうか32ビット版の古い版もバージョン下げておけばこのまま維持できるんですよね?じゃないとST:New HorizonsのAARが打ち切りになる…(´・_・`)
などなど色々と気になりますので、また情報が出てきたら紹介したいと思います。
それではまた( ✧Д✧) カッ!!