「Victoria 3」新DLC「Pivot of Empire」発売!

「Crusader Kings III」開発日記#36――早く行かなきゃ

CK3 開発日記

「Crusader Kings III」開発日記#36が公開されていましたので、その内容をご紹介。今回はパフォーマンスについて。本体発売前の開発日記です。

前回:開発日記#35――リリース前のユーザーテスト


スポンサーリンク

開発日記

開発日記#36は、パフォーマンスについて。

パフォーマンス

  • パフォーマンスはCK2のライフサイクルの中ではHoly Furyリリース時に最良のものとなり、今日では最初のバージョンは現在のものと比べて糖蜜のように遅く感じられる。CK2はPDSタイトルの中でも特にパフォーマンスに優れており、CK3の開発期間中、特にリリースが近づいてきた今もパフォーマンスを優先している。CK2とは異なるアプローチをとったが、これが素晴らしい結果につながった。
  • パフォーマンスについてCK2ともっとも異なるのはスレッドとレンダリングの2つのシステムだ。CK2では、ゲーム全体はメインスレッドを中心に構成されていた。メインスレッドの主な仕事はゲームの状態を更新してゲームを進行させることだ。ユーザーが起こっていることを確認できるようにフレームをレンダリングするため、定期的にゲームの状態の更新を停止して別のフレームを作成する。レンダリングはフレームが完成するまで全体を引き継ぐ。
  • ゲームの状態が更新される間に、多くの異なる動作が進む。こうしたCK2の動作は主にキャラクターを中心にしていた。キャラクターの毎日の更新は並列化のルールが異なる一握りのセグメントに分割されていた。CK2は大きく並列化されたゲームであり、並列化の増加によって速度が大幅に向上した。同様の設定は称号やplotsなど他のオブジェクトにも適用された。
  • しかし、重要な欠点もあった。最大の欠点は、プログラマーがアップデートでできること、できないことに関する多くの制約だ。ルールに違反すると一般には同期ズレが発生し、マルチプレイの体験を損なう。時にはゲームがクラッシュすることもある。また、ゲーム内のすべてのキャラクターを処理しなければならないという大きなオーバーヘッドもあり、ほとんどのチェックでは「アップデートのこの部分をやる必要はない」という結果が出るだけだった。
  • CK3ではこのシステムを完全に置き換え、オブジェクトレベルの並列処理からシステムレベルの並列処理とした。例えば、策略(scheme)と評価(opinion)のシステムを同時に更新する。これにより、できることとできないことのルールを大幅に単純化できた。ルールを単純化することで、バグ、特に同期ズレの発生を減らすことができる。そして、CK2よりも並列化できるものを特定するのが簡単になり、結果として以前よりも多くの作業が並列化されるようになった。

大半の並列更新にかかる時間のチャート。

  • これはCK3の新しいレンダリングのアプローチとも相性がいい。CK3ではレンダリングはメインスレッド上で行われるのではなく、別のスレッドで行われる。変更されたオブジェクトをチェックすることができないので、メインスレッドとの同期が依然として必要だが、このためにロックのシステムを作った。すなわち、レンダースレッドがゲームの状態にアクセスする必要があるときはゲームの状態を変更できず、ゲームの状態を変更する必要があるときはレンダースレッドはアクセスできるようになるまで待機しなければならない。
  • CK2と同様に、ゲームの状態は自身を更新している間、レンダースレッドがアクセスを必要とするか定期的にチェックし、必要な場合は短期間で制御を引き継ぐ。大きな違いは、レンダースレッドで行われる作業の大部分がゲームの状態へのアクセスを必要としないため、ゲームの状態の更新と並行して行える点だ。そして、ゲームの状態に対する並列更新では表示の状態を変更することが許可されていないため、こうした更新の間はレンダースレッドを更新しても安全だ。そのため、全体的にレンダー スレッドが待機しなければならない可能性のあるセクションは非常に小さく、ゲームの状態と同時にほとんどの作業を行うことになる。
  • まだだオブジェクトレベルの並列化としてAIが残っているが、CK3のAIはゲームの状態を直接変更しないように設定されているので、AIがやることを考える間にレンダリングを続けられる。
  • こうした変更により、全体的にCK3はCK2よりもスレッドの使用率が高く、より安定したフレームレートを実現し、プログラマーがバグ・同期ズレ・クラッシュにつながるスレッドのミスをしにくくなった。
  • 私のマシンでCK2とCK3を比較した。単にゲームを1分間フルスピードで走らせ、フレームレートとゲームの進行状況を比較してみると、どちらも1066年9月から始まって1069年4月までは同じように進んだが、CK3のフレームレートはCK2よりもはるかに高く安定していた。

  • スレッディングの違いを見てみよう。私のマシンで1分間最高速度でゲームを走らせてみた。左がスレッディングを有効にした状態、右が無効にした状態だ。赤い線はフレーム間の時間で、60FPSのときに緑の水平線よりも下に行く。
  • ご覧のように、その差は歴然だ。スレッディングを使った場合、ゲームは958日進んだが、使わなかった場合は546日しか進まなかった。つまり、スレッドを使った方が75%速く、フレームレートもはるかにいい。
  • これを実行しているマシンは自宅のPCで、記録時にはi7 4770K、GTX 1080、16GBの2400MHzのRAMを搭載し、最高のグラフィック設定で実行した。CPUとRAMは両方とも非常に古いもので、新しいモデルではもっとずっと性能がいい。これでも最高速度は通常プレイではほぼ使わないくらい充分に早く、普段は3速か4速を使っている。
  • これまで述べてきたこと以外にCK3のパフォーマンスについてなにをしているか? 私たちは定期的に新しいパフォーマンスの問題を解決するために時間を割いており、さらなる改良点も探している。私が特に気に入っているゲーム高速化の手段は、プレイヤーが影響を受けない高くつく計算を避けるために設計を少し修正することだ。一例を挙げると、プレイヤーの評議会の任務の進行状況は毎日更新するが、AIの評議会については月に一度しか更新しないというものだ。プレイヤーがその違いに気づくことはほとんどないが、この方法で更新にかかるコストを1/30に抑えることができる。
  • このような最適化は、CK3では至るところで行われており(CK2でもある程度は行われている)、パフォーマンスに大きな影響があるが、プレイヤー体験にはほとんど影響がない。

AI

  • 私たちのAIの主な目標は、プレイヤーにとってゲームをより楽しくすることだ。これにはいくつかの側面がある。
    • ある程度のレベルの困難を提供しなければならない。最初から塗り絵できるのは楽しくない。
    • たとえ「賢く」なるとしても、イライラさせるようなことは避けなければならない。
    • 中世世界のもっともらしい主体として感じられなければならない。
  • CK3のAIにおける特に大きな構造的変化は、AIが軍隊をどう扱うかということだ。CK2では、戦争で一方の陣営に複数のAIがいた場合、調整のためのシステムはあったが、基本的には互いに独立して行動した。これはおおむねうまくいったが、時には変な判断をしてしまうこともあった。
  • CK3では同じ陣営の複数のAIを扱うためのシステムを一から設計した。それぞれのAIが自分の部隊を指揮するのではなく、すべての意思決定を行う戦争コーディネーターに部隊を割り当てる。個々の意思決定はどの部隊を割り当てるかということだけだ(参加できる戦争が複数ある場合に作動する)。こうしてAIはより協調して行動するようになった。
  • しかし、これはプレイヤーとの協調性に対応しているわけではない。CK2では最終的にAIに指示を出すだけのAI命令システムを導入した。CK3では今のところそうしたものはないが、AIはプレイヤーを支援することに重点を置いている。一般的に言えば、AIは自分の軍をプレイヤーの近くに置いておき、加勢があっても負けそうな戦闘だとしても加勢してくれる。
  • CK2のようなAI命令システムでさらに改善されるかもしれないが、その差はCK2よりもずっと小さいので、優先的にはリリースしないことにした。また、CK2での命令システムの存在はAIのコードを大幅に複雑にしてしまい、それ以上の開発を難しくした。そのため、導入には多くのバグが出ることが考えられ、AIの開発速度が低下する可能性も高まる。
  • 「ある程度のレベルの困難を提供」することには触れたが、それではイライラを回避することについてはどうだろうか? CK3では、AIには「stand and fight」と呼んでいるシステムがある。プレイヤー(または他の敵)がAIの軍の近くにいて打ち負かされそうな場合、あるいはAIの軍は既に集結しているが戦争に勝つ見込みがない場合、AIは逃げるのではなく近くの防御に適した地点を探し、敵に撃破されるまで最大1か月そこで待機する。
  • 結果としてプレイヤーはCK2のように軍隊を追いかける必要がなくなったが、これは明らかにプレイヤーが勝つであろう戦争でのみ発生する。
  • 同様に、多くの場合でゲームデザイン自体は少なくとも部分的にはAIを念頭に置いて作られている。砦のシステムについて以前ご紹介したが、簡単に要約すると最初に包囲せずに敵地の奥深くに侵入するのは自殺行為だということだ。AIは事実上そうしたことをしないため、プレイヤーの軍が防衛線の内側にいる場合は軍を再編成してなにをすべきか考える時間がある。同様に、AIを彼らの領土の奥深くに追い詰めようとする要因もほとんどない。
  • こうしたことは私が挙げた目標すべてに寄与する。つまり、取れる選択肢が少ないために私たちはAIにより賢く選ばせることができる。プレイヤーのイライラも減る。この時代の歴史的側面も強調され、世界の半分を移動する馬鹿げた追撃戦も避けられる。
  • 軍事AI以外では、全体的なアプローチはCK2にかなり近いものの、ゼロから再構築されている。AIは定期的に取り得る行動をチェックし、意味のあるものであれば実行する。少しばかりランダム性があり、AIの性格はさまざまな行動に影響を与え、ゲームが決定論的ではなく生きているように感じられるようになっている。ハードコードされたインタラクションシステムが大幅に減っているため、AIはCK2よりもより幅広く改造可能になった。インタラクション以外の行動などハードコードされた部分はまだあるが、体的にはCK2よりもう少し幅広くAIに影響を与えることができる。
  • ハードコーディングが減ったということは、プログラマーとしては常に複雑なことをしなくてもよくなり、CK2よりもAIのバランスが取りやすくなったことを意味する。特に、リリース後に多くのプレイヤーからフィードバックを得られれば、CK2と比べてコードのアーキテクチャが改善され、AIの反復処理が以前よりも簡単になると思う。また、他のキャラクターがすることの大部分はCK2よりも広い範囲がイベントなどで処理される。
  • 一般的に言えば、非軍事AIの目標は世界を生きていると感じさせることだ。これは、時にはプレイヤーが圧倒されないように制限が必要になることを意味する。例えば、ゲーム開始時に数少ない女性領主でプレイする場合、私たちはプレイヤーに対する膨大な誘惑の機会をスパムにならないように制約する必要があった。
  • 全体的にAIはCK2と似ているが、プレイヤーができる限り最高の体験をできるように、さらに力を注いでいる。リリース後はCK2の時よりもさらにAIを改善しやすくなるはずだ。

PCのアップグレード

  • おかしなことだが、この開発日記を書いてから、ついにPCをアップグレードする時期が来たと思った。古いi7 4770Kを最新のRyzen 9 3900Xに交換し、16GBの2400MHzのRAMを32GBの3600MHzのRAMに替えた。そして、私は1分間のテストを再記録した。

私の新たなマシンはゲームを1000FPSで動作している。マップの隅っこで一時停止している間だけだが。

  • ご覧のように、ゲームをプレイできないほど速いとしか言いようがないレベルで動作している。1分で1498日と、古いCPUより56%早く進んでいる。フレームレートも以前より安定しており、この結果には非常に満足している。

来週はModについて。

次回:開発日記#37――Modの作成

スポンサーリンク

コメント

タイトルとURLをコピーしました