『Cities: Skylines II』が重いのは「開発中“予想外の自力実装”が発生したからでは」との調査報告。技術分析から推理する、開発元の苦悩

とあるソフトウェア開発者が『Cities: Skylines II』が“重い”理由を独自に検証。検証結果に基づき、本作が重いまま発売された背景なども推察されている。

『Cities: Skylines II』は、高い評価を得た都市開発シミュレーションゲーム『Cities: Skylines（シティーズ：スカイライン）』の続編だ。前作に引き続き、Colossal Orderが開発を手がける。本作は発売前に「目標とするベンチマークに達しないまま」リリースされることが告知されていた。結果として本作は最適化不足という課題を抱えたままのスタートとなり、発売後にはパフォーマンス問題を中心に報告が寄せられている。

パフォーマンス問題の原因についてはユーザーが独自検証をおこなう例も見られ「市民一人ひとりの歯が詳細に描画される」といった点を報告。ほとんど見えないような部分まで細かく描画される点がパフォーマンスに影響しているのではないかとして波紋を広げていた。開発元はこれを受けて、キャラには歯については「パフォーマンスには重大な影響を及ぼしていない」と否定しつつも、そうした指摘を一部認めていた（関連記事）。

「何が原因で重いのか」をユーザーが独自検証

今回はPaavo Huhtala氏により本作のパフォーマンス問題に関する独自検証がおこなわれ、詳細な調査結果が報告されている。同氏はフィンランドのIT企業Reaktorにてソフトウェア開発者を務める人物だ。同氏はこれまで趣味としてゲームエンジンを使ったり、時おりグラフィックプログラミングをしたりしていたこともあるものの、プロのグラフィックプログラマーではないと前置き。分析が一部誤っている可能性もある点は明言されている。

なおPaavo氏はパッチ1.0.11f1適用環境で検証をおこなったため、記事内で報告された問題については後日配信されたパッチ1.0.12f1で一部修正された可能性もある。ただし同氏は同パッチでも、問題は解消されたとは言い難いとの見解を示している。検証においてはGPUにNVIDIA RTX 3080、CPUにAMD Ryzen 7 5800Xを搭載したミドルスペックPCを使用。ディスプレイは画面解像度5120×1440pのモニターが使用されたとのこと。調査にはグラフィックデバッガー「Renderdoc」が用いられたそうだ。

【UPDATE 2023/11/11 21:20】
スペックの表現について調整

Paavo氏は下記の画像におけるフレームタイム（フレームの描画にかかった時間）を計測。ゲーム開始後1時間弱、人口約1000人の町で検証はおこなわれたといい、人口や都市の規模が小さく比較的動作が軽い序盤の環境といえる。一方で描画には約87.8ms（ミリ秒）を要したといい、この状態で動作し続けると仮定すればフレームレートは約11.4fpsになる。これを仮に固定60fpsで動作させたい場合には、フレームタイムは約16.7msとなる必要がある。少なくとも下記のフレームの描画において、同氏の環境では快適とは言い難いパフォーマンスであったようだ。

細かすぎるキャラモデルとLODの問題

では、何が原因で本作のパフォーマンスは下がっているのか。Paavo氏はこれを探るために1フレームを描画する際におこなわれるさまざまな工程について、それぞれ描画に要した時間を分析して紹介。所要時間の長い工程から本作の抱える問題を分析しようとしたわけだろう。

そしてPaavo氏いわく、フレームタイムのなかで特に時間を要していたのがPre-passやMain passであったという。本作では物体の描画とライティングを別々におこなう遅延レンダリング（Deffered Rendering）が採用されているそうで、それぞれのパスを通して3Dモデルが構築されていく。そしてこれらの工程で長い時間を要した原因の一つと見られるのが、市民のキャラクターモデルのポリゴン数の多さだったそうだ。本作のキャラは歯やまつ毛などに別々のポリゴンメッシュを備えており、髪や服・アクセサリーが追加される前の“丸裸状態”であっても、膨大なポリゴン数が用いられているという。

さらにキャラたちのポリゴンメッシュにはLOD（Level of Detail）に向けたバリエーションも用意されていないとのこと。LODは簡単に説明すると、プレイヤーの視点から遠くにあるオブジェクトは粗めに、近くにあるオブジェクトは詳細に描画する仕組みだ。距離によって描画を変化させ、描画にかかる処理を軽減させる狙いがある。しかしPaavo氏の今回の検証時点では、本作では遠くから見たモデルのポリゴン数を少なくするといったバリエーションがなく、どの距離で見ても市民のモデルが詳細に描画されてしまう状態だったようだ。なおキャラのLODが不足していることは、開発元も海外メディアPC Gamerなどに向けた声明にて認めていた。

また不必要なほどポリゴン数が多い3Dモデルは、キャラモデルだけでなく街中の小物にも複数確認されたという。たとえばガスボンベをまとめたケースや、住宅の庭に置かれた物干し竿、建物の中にあるパソコンのキーボードやディスプレイなどのオブジェクトが例として挙げられている。物干し竿の洗濯ばさみのほか、キーボードやディスプレイから伸びたケーブルなど、普通は見ないような細かな部分までモデリングされていたそうだ。また小物類にはLOD向けのバリエーションが用意されていない傾向も見られたという。

　

Paavo氏は、ほとんど見ることがないような詳細すぎる3Dモデルが積み重なっている点は問題であると指摘。本作のような都市を作るシミュレーションゲームでは1フレームに最適化されていないモデルが密集する場合もあり、GPUに無駄な負荷をかけているとの見解を示している。またこのほかにも、本作では物体の見えない部分を描画しないようにして負荷を減らす「カリング処理」が不十分であったという。ほか、影の処理にも大きな負荷が見られたそうだ。

なぜ問題を抱えたままリリースされたのか

なおPaavo氏は上記のような問題を抱えたまま本作がリリースに至った原因も推察している。同氏によるとグラフィック問題の背景には、Colossal Orderが本作にUnityの新システムData-Oriented Technology Stack（DOTS）を採用している点があるという。

DOTSとして開発されているシステムは、従来のデータと処理が一体化したオブジェクト的な志向ではなく、データの独立性を高めるデータ志向（Data-Oriented）的なアプローチで作られているとされる。たとえばECS（Entity Component System）ではデータをメモリアクセスの効率性に特化して並び替えることが可能だという。またC# Job Systemの利用によってマルチコアCPUの性能を最大限に引き出すこともできるそうだ。

そしてPaavo氏によると、本作はゲームエンジンとしてUnity 2022.3.7バージョンで開発されているとのこと。同バージョンにて、DOTSの一環であるECSやBurstコンパイラーといった新技術が活用されているという。そして同氏は、本作『Cities: Skylines II』ではDOTSの導入によって、前作よりも遥かに効率的に複数のCPUコアが利用されていると評価。しかし一方では、グラフィック関連の問題の多くが新たな仕組みによって間接的に引き起こされていると推察している。

というのも、本作はグラフィックの描画にDirect3D 11およびUnityのHD レンダーパイプライン（HDRP）を利用している。しかしHDRPは従来のMonoBehaviourベースのオブジェクトでしか動作しないため、ECSなどのDOTSを利用して構築されたゲームでは変換が必要になる。そのための仕組みとしてUnityにはEntities Graphicsというパッケージが用意されているものの、Paavo氏によると本作にはこれが用いられていないという。

なぜ、Entities Graphicsによる適切な橋渡しがおこなわれていないのか。その点についてPaavo氏は、同機能は現時点では不完全であり、サポートされるレンダリング機能が限定的だと判断されたのではないかと推察している。Unity 公式サイトを見ると、Entities Graphicsではカリング処理などが試験実装段階（Experimental）とされているほか、GPUでのテクスチャ処理がより効率的になるとされる仮想テクスチャリングといった機能はサポートされていない。

そのためPaavo氏の調査によると、Colossal OrderはDOTSを用いるにあたり、グラフィックを描画するために自力で“繋ぎ”となるシステムを構築したと見られるそうだ。結果として先述のようにカリング処理などが不十分な状態で実装されている点が、パフォーマンスに影響しているとのこと。先述の3Dモデルのポリゴン数の多さやLODの不十分さも相まって、現状ではGPUへの負荷が非常に高いゲームになっているという。

前作の課題克服を目指したがゆえに

Paavo氏は総括として、Colossal Orderは前作での課題であったCPU使用率のボトルネックを解消すべく、DOTSを採用したのではないかと推察。結果としてマルチコアCPUへの最適化は実現したようで、同氏は本作についてシミュレーションゲームとしてのスケールや深みは増していると評価している。ただ同スタジオはDOTSのレンダリング面でのエンジン側の公式サポートを“当て”にし過ぎたために、土壇場になって自力での実装が必要になり、最適化が完了しないままのリリースを迎えたのではないかといった見解を説明した。同氏はソフトウェア開発者である自身にも似たような経験があるといい、こうした事態への一定の理解を示している。

なおPaavo氏は「本作はUnreal Engine 5で作られるべきだったのではないか」との読者からの質問にも回答。同氏は、たしかにLODについては同エンジンのNaniteを利用できるほか、ライティングやシャドウについてもLumenやVirtual Shadow Mapsといった機能を使えるだろうとしている。しかし一方で同氏は、ゲームプレイのロジックや大規模なシミュレーションの構築が可能なECSのような機能が提供されていないとの見方も示している。

またPaavo氏はUE5はプログラミング言語がC++である点から、Mod制作への柔軟性・アクセス性もUnityに比べて劣っていると説明している。Modは前作にて人気を博していた要素であり、本作でもMod開発のハードルの低さは重視された点なのだろう。UnityにせよUE5にせよリソースのかかる独自の実装は必要であり、Colossal Orderのような比較的小規模な会社は公式サポートを当てにする“賭け”に出る必要もあったのかもしれない。

今回のPaavo氏の検証結果報告は独自検証や推察に基づくものの、本作の抱える問題やその背景などさまざまな事情も垣間見える。なお本作は発売以来、現状では毎週のペースでパッチが配信されており、ゲームプレイの不具合とあわせて最適化も進められている。今後のパッチにより、報告が寄せられているパフォーマンス問題が改善に向かっていくのかは注目されるところだろう。