「Europa Universalis IV」開発日記2019年4月9日

「Europa Universalis IV」開発日記2019年4月9日分が公開されましたので、その内容をご紹介。今回は技術的負債について。

前回：開発日記2019年4月2日

概要

2019年4月9日分の開発日記は、技術的負債について。今回はEU4プログラマーのMatRopert氏によるものです。

• 技術的負債は1.28.3以降のEU4チームが注力しているところだ。私たちプログラマーはEU4のコードベースの整理で忙しい。
• EU4は2012年のGamesCon（注：GamesCom?）で発表され、実際の開発はその1年前から始まっていたので、このコードは8年目に入った。当時のチームはすべてを開発したわけではなく一部はEU3から引っ張ってきていて、その中には現在も使われているものがある。
• 技術は進歩が早く、ソフトウェア工学も例外ではない。10年の間に開発業務は進歩した。10年前はSSDは一般的ではなく、解像度1080pは出たばかり、DirectX10が大人気で、人々はWindowsVistaに反発して32ビットのWindowsXPを使い続けていた。
• だが、EU4は00年代後半から10年代前半のものだけを今でも使っているというわけではない。その時々で私たちのエンジニアはゲームを最新のものに保とうとしてきた。しかし、見過ごされるものがあるのも避けられない。そうしたものの蓄積を私たちは技術的負債と呼んでいる。
• 以下は私たちが今まで取り組んできたものの例だ。

64ビット

• 32ビットはEU4開発開始時には理にかなった選択だったが、今では64ビットが一般的だ。64ビット化が完了すればMacOSの次のアップデート（32ビットへの互換性が完全に取り除かれる）でも動くようになるし、より多くのRAMを利用できるようになる。直ちにゲームのメモリ使用量が増える予定はないが、Modで多くのプロヴィンスやタグの追加にあたってはこれまでの上限を超えられるようになる。

レンダリング

• 私たちのゲームでは最先端のグラフィックを使っていないということは隠していない。EUでワールドマップ上に表示されるのは戦う男たち（と象）くらいだ。しかしImperatorを見てみると、EU4のリリース以降に学んだグラフィックの専門家がいるのがわかるだろう。
• 私たちはどうにかImperatorチームの行った改良の一部を再現しようとしている。その主なものがマップ上でのプロヴィンスの色付けの大部分をGPUによって行うものだ。これまでは貴重なCPUサイクルを使っていた。

このベータ版のスクリーンショットにおける現在のバージョンとの違いがわかるだろうか？　違いは7つある。

クラッシュリポーター

• これは私たちのQAが問題を再現し、プログラマーが問題箇所を特定して修正する助けになる。EU4リリース以来、エンジンチームは新たなクラッシュリポーターを作った。これはLinuxやMacOSでも機能し、こうしたプラットフォームでも簡単に問題を調査できるようになった。またダンプにメタデータ、例えば現在の年数、利用されているModのリスト、狩猟事故で6/6/6の後継者が何人死んだかなどを追加でき、問題の発端の理解の助けになる。

起動時間

• ゲームのロード時間の改善も常に考えていることだ。私たちは問題の最良の解決法（Windowsのサポートを打ち切ってLinuxとMacOSでゲームの起動をずっと早くすることだ。本当だよ）を適用することはできないが、できることをどうにか探し出した。
• もっとも大きなものは多くのビデオゲームでリソースのロードに使われているサードパーティソフトウェアであるPhysFSをアップグレードすることだった。依然としてUnixのパフォーマンスからはかけ離れているが、Windowsにおいても起動時間は数秒早くなった。

全体的なパフォーマンス

• ゲームの速度ももちろん考慮している。私たちは毎晩何回分かのゲームをベンチマークマシンで走らせて平均値が一定値以下であることを確認している（私たちの現在の上限はゲーム中での1日あたり80msだ）。みなさんは時間とともにパフォーマンスは改善していくもの（例えば新しいハードウェアなどで）とお考えかもしれないが、実際は新しい拡張の開発が進むに連れて平均時間は長くなっていく。そこで問題ない数値まで下げる作業がある。
• 一般的な考え方とは対照的に、ゲームに新たな機能を追加してもそれがパフォーマンス悪化の要因になるばかりということはない。実際にはタグやプロヴィンスの追加が大きい。
• ゲーム中のあらゆる2国間は、毎日多くのこと（関係やAIの態度など）を計算する必要がある。またあらゆる2つのプロヴィンス間では、AからBへ行く方法を知る必要がある（私たちは経路探索と呼ぶ）。これは二次関数的問題として知られている。数学が嫌いな人向けに説明すると、X個のプロヴィンスがあるとき、問題の複雑さはXの2乗になるということだ。プロヴィンスの数が倍になると、計算しなければならない数は倍ではなく4倍になる。これまでEU4のプロヴィンス数は2000から4000以上に増加した。
• しかしながら、ソフトウェア工学では最適化で0.1%早くなれば非常によい結果と考えられ、1%では素晴らしく、10%改善すれば深刻なバグができた（あるいはそれが修正された）と考えるということも知っておいてほしい。私たちはどうやってそうした数値を改善するのか？　答えは単純だ。最後には全部がうまくいく。
• 技術的なことについて詳しく知りたい場合は私のブログを見てほしい。開発業務の実際の詳細について書いている。

次回：開発日記2019年4月16日分