「Stellaris」開発日記#149――技術的改良

「Stellaris」の開発日記#149が更新されましたので、その内容をご紹介。今回は2.3「ウルフ」における技術的改良について。長め。

前回：開発日記#148――遺物と遺跡惑星

概要

開発日記#149は、今回は2.3「ウルフ」における技術的改良について。今回はStellaris技術リードのMoah氏によるものです。

Stellarisの64ビット化

• 様々な要因によって、私たちはこのパッチで64ビット化を行うことになった。だがおそらくみなさんの期待を鎮めることになるだろう。多くの人はStellarisのあらゆる問題を解決する特効薬だと言うが、実際はそんなに大したことはない。

どういうこと？

• 確実な恩恵はStellarisが4GBのメモリ容量に縛られなくなり、上限に達してもクラッシュしなくなったということだ。巨大な銀河で、大量の帝国を登場させ、大量のModを入れて、3000年まで遊ぶような人々にとっては恩恵がある。
• だが、パフォーマンス面ではそんなに変わらない。技術的な詳細は避けるが、一度に多くのデータを扱えるようになるため早くなると言えるが、同じ理由で遅くなるとも言える。結局のところ、私たちの測定では体感できるほどの違いはなかった。
• 64ビットにすることの一番の効果は32ビットのコンピュータやOSではプレイできなくなるということだ。私たちは多くのプレイヤーが影響を受けるとは思っていないが、影響を受けるプレイヤーはいる。

パフォーマンスはどうなるの？

• まずフォーラムのあちこちで言われている噂を打ち消しておこう。Stellarisはマルチスレッディングを行っており、私たちは新しいものをスレッド化するように常に注意している。実際、2.2.0から2.2.7の間には職とPopのスレッド化に大変な努力を行い、バージョン間でのパフォーマンス改善の大きな要因のひとつとなった。
• 現在、Popと職がCPUの処理時間の大半を消費しているのは確かだ。私たちはそれをPopそれぞれが評価する職を減らすことで改善した。また以下のように処理が多すぎる部分をカットした。
  • 耐久値が最大のときにも毎日回復量の計算をする艦船
  • 画面外のアイコンの更新
  • Popがいる惑星と同じ評価をしている入植されていない惑星
• そうした一見無意味なことはなぜ起こるのか。私たちは一般にコンテンツデザイナーがゲームを早く何度も繰り返すことができるようにゲームプレイを仕上げて早く動作させることに注力しているが、こうしたことはよく無視されてしまう。システムの一部は非常に複雑で、新たなコードの規模はそんなに簡単にはわからない。そう多くのことをやらないので目標の数を制限しなくても問題ないとしても、数か月後に誰かが別の理由でさらなる計算や大量のオブジェクトを追加することがあり、それが突如としてパフォーマンスの問題となるのだ。

補正

• 他のPDSタイトルとStellarisが異なるのは、補正の使用（濫用）量だ。あらゆるものが補正になっている。補正は他の補正によって補正されたものによって補正され、ときにはそれ自身によっても補正されている。追いかけるのは非常に困難で、あらゆる値が気づかないうちにいつでも変更され得る状態になっていた。
• 「新しい職が生まれたときになぜ計算に入れないのか」と、こうしたことに関連してよく聞かれる。これに対する簡単な答えは、いつ新たな職が生まれるのかを検知するのは非常に難しいということだ。職は国家、惑星、Popに対するあらゆる補正からも生まれる。そうしたものは志向、伝統、アセンションパーク、イベント、建造物、職、国家、惑星、Pop、技術などによって補正を受ける。
• これまでは全体のつながりを追いかけなければならず、手動で補正を計算しようとしていた。例えば国家の補正を再計算するときにはその国家の惑星の補正を計算し、それから個々の惑星でPopの補正を再計算していた。一部のフリーズはそうしたこんがらがった毛糸玉をほどこうとすることで起こっている。

• これが補正のフローチャートだ。最新のものではないが、システムの複雑さはわかってもらえるだろう（開発ツールであって記事用に作ったものではないので洗練されていない）。

もう無理！

• 2.3「ウルフ」のために私たちは補正のノードシステムを変更した。これは各ノードに後に続くノードを登録し、使用された際にはそのチェーンにしたがって再計算される。必要なときだけ計算される最新の補正もあり、これによって無意味な再計算は減少する。
• このシステムは驚くべき可能性を示しており、ゲームの（例えばロード後に特に多い）「長いフリーズ」の回数を減らす。いくらか問題はあるが、作業を進めていくことでよりよいものになり、パフォーマンスとプログラマーの正気を助けてくれるようになるだろう。

それで、どういう評価なの？

• テストでは、2.3「ウルフ」は今のところ2.2.7よりも10-30%早く動作する。リリースまでそれが維持されてほしいが、こうした最適化によってなにかが壊れたり、問題の修正によって改善が無効になったりすることもあるものなので、約束はできない。
• 測定はsabrenity（注：パラド社スタッフと思われる）によるもので、ベータ版のビルドから得たものだ。「SHIPS_SERIAL」という紫の線がほとんどなくなっているのは注目に値する。

AI

• AIにも改良を行っている。まずGlavius（注：Mod制作者）の許可を得て彼の仕事を用い、全体的なAIの職の配分を改善した。また通常の改良も行い、もちろんすべての新しい機能の使い方も教えてある。

他に新しいことは？

• 新たなクラッシュレポーターを実装した。これは次回のゲームスタート時ではなく、クラッシュが発生したらすぐにレポートを送る。また、接続性の問題など非Steamネットワークのスタックも改善した。

質疑応答

Q1：Lゲートやワームホールやその他のゲートも経路探索で大きなパフォーマンスの悪化を生じさせていると言われているけど、それについては解決したの？

A1：私たちはまだそれに取り組んでいない。これについていい解決を見つけられていない。私たちが問題にしているのは、あらゆる星系から他のあらゆる星系への距離を含むキャッシュを持っており、プレイヤーがバイパスや星系を追加/削除したときにこのキャッシュを再計算する必要があるという点だ。これは全員がすべてのバイパスに同様にアクセスできるわけではないためにさらに複雑になる。素晴らしいアイディアが見つかるまで、私たちがこの点の改善に多くのことができるとは思わない。私はいくつかの理由でゲートウェイ・ワームホール・Lゲートの削除を提案したが、賛成する人はいなかった。不思議だ。（注：最後の削除提案は冗談だとのこと）

Q2：（Moah氏の投稿）おかしな話だが、全Popの75%を殺せばパフォーマンスの問題は解決する。

（StellarisプロデューサーのJamor氏）私を誘惑しないでくれ。

（別の投稿者）それなら次の銀河の危機には宇宙インフルエンザというアイディアがある！

A2：（Moah氏）しばらくの間戦争をやめて、国家が強制的に協力して星間絶滅レベルの出来事を解決するような危機を私も求めていた。だが、残念なことに今のところ計画にはない。

（別の投稿者）Stellaris: Reaper’s Dueだ。

（Moah氏）私とDarkrenown（注：パラド社スタッフ）にとっては懐かしい。

（Darkrenown氏）Reaper’s Dueの古き良き日々のようになるだろう。

スレッドでは経路探索の方法についてスタッフと参加者の間で専門的な内容が活発に議論されています。気になる方は直接スレッドをご覧ください。

次回：開発日記#150――2.3「ウルフ」パッチノート