CEDECプログラミングセッションにおいて株式会社セガの平山尚氏による講演「マルチプラットホームライブラリを作ってみた - パワースマッシュ4の場合」が行われました。
『パワースマッシュ4』は2011年6月30日にプレイステーション3/Xbox 360版で発売され。今後はプレイステーション Vita版の発売も決定されたテニスゲームです。
平山氏によると開発当初はPC、PS3、Xbox 360、Wiiの複数機種による開発が進められていたとのことです。リアル系の画質重視志向。開発部署は元々アーケードタイトル専門の部署であり、スタッフの人数は30人程度だったそうです。
まず平山氏が行った、プログラムにおいての本作の基礎部分となる設計です。これはボールの動き、鳴らす音、可能であれば描画もといった、機種ごとに依存しない部分のプログラムを基本設計として共有したいという思想の元から取り組んだということが語られました。
これはWiiであればWiiリモコン、プレイステーション3であればPlayStation Move、Xbox 360であればKinectといったインターフェースをはじめ、シェーダーなどの機種に依存する部分はアプリから切り離し、複数のゲーム開発で共有したいという思想があったからだと語っています。
この結果、平山氏はマルチプラットフォームライブラリを作ることが今回の開発におけるニーズを満たす手段だという結果に辿り着いたそうです。結果的として「マルチプラットフォーム開発が前提であった、『パワースマッシュ4』では必須だった」と語っています。
では今回作ったものというのはどういったものなのか。まず、平山氏が行ったのは、機種に依存する部分の抽象化だそうです。列挙していくと、描画、音声など機種依存部分から、超越関数、ベクトル、行列など数式におけるもの、STL（Standard Template Library）などのコンテナ類、文字の表示形式、デバッガ出力などになります。
これらを統合した環境ライブラリをパワースマッシュ4開発チーム内で「SegaLib」（セガリブ）と称し、ライブラリの開発に着手したそうです。
SegaLibの位置づけとしては、プラットフォームSDKの上に乗ったサブフレームのようなものとなります。平山氏によると、セガには共通のライブラリという概念がなく、各開発チームで個別に作るのがモットーみたいなスタイルがあるそうです。
では、なぜ新規に作るのかという部分では、『パワースマッシュ3』のプログラムコードや、そのほかの資産を利用するという部分でも、当時、平山氏の手に届くものは、アーケードのライブラリのみだったこともあり、さらにWiiでの開発を織り交ぜると難しくなる部分が発生するからだそうです。
また、家庭用の開発部署においても内部制作で4機種同時という例は少なく、他部署に頼むことは社内においても大変なことであり、無茶がありすぎるということから部内のみでの制作へと踏み切ったとのことです。開発段階では4機種でしたが、以後も増えそうであった（実際にVitaが増えた）ということから、機種追加は手元でできるようにしたいという懸念もあったそうです。
では開発にあたり、どれくらいの資源を使えるか？ スケジュールは、2009年初頭開発開始、2011年春発売予定。完成（マスターアップ）を2010年冬とすれば2年弱の開発期間になります。ですので、ライブラリは可能な限り早く必要となり、そのためにはPCでの開始からスタートする必要があったと語っています。これはハードウェアのスペックによる制約が厳しい順からだそうです。厳しい順番でいうとPC、Wii、プレイステーション3、Xbox 360になり、PCでの開発が最優先。理由は制約の緩いハードウェア開発に慣れてしまうと、後に制約が厳しい機種に移植した時に動かない可能性が高いからだそうです。結果として5月末に全機種で動作を確認できたものを形にできたと語っています。
開発人員に関しては、各機種の環境構築と初期実装、SDKなどをインストールして、関数を書いたりする初期実装に1人。絵素材のパイプラインがらみに1人。平山氏は、途中でアプリケーション開発に異動しながらもライブラリの保守も行っていたそうです。実際には、最初に行ったのは開発機種すべてでゲームを形にするために2人で数カ月を対応。その後は平山氏が完成へとブラッシュアップを行ったそうです。
平山氏自身は大規模な開発は死を招くといったことや、実装よりも保守が問題となるといったほか、プログラムのコードは資産ではなく、負債というロジカルな考えがあるため、コードはあればあるほどもたらされる機能と量が今後の開発における負債に化けると語っています。
では、機種依存環境の分離ということでSegaLibに含まれないものとはなにか。平山氏は「設計部分に含めないものこそが重要で、β時点で含まれていないのは、作っていないのか、それとも含めないのかを明確にするのが大事です。これをノリで作ると未来に負債を残すことになる」と語っています。
たとえばゲームの目的に寄与しない機種固有機能であるKinectやMOVEは提供してもライブラリに対してはメリットがないため除外といったものや、抽象化が困難あるいは不可能な機種依存によるセーブロード、OSのダイアログなどが代表例となり、そのほかにも現在の開発チームのスキルでは無理だったネットワーク機能など、技能的な部分も外したと語っています。
それ以外にも、本来はライブラリの範囲外ではあるものの、高速化に機種固定実装が必要なもの、スキニングが必要なものに対し、アプリ側の作り方を規定することで、STL風コンテナやアニメーション、XML風テキストなど、ライブラリの実装に必要でアプリにも有用なものなどはSegaLib内に実装したそうです。とはいえ、アプリ側に公開しているクラスタは一部であり、ショット時のパラメータ設定などは、所定のフォーマットを制定して、それに従ってもらったといった話もでています。
また『パワースマッシュ4』での描画部分の話になりますが、これはSegaLib側での制御ではなく、別途アプリ側で描画処理を行っているといった話も語られています。理由としては、描画部分はいずれ古くなるため、いつまでも持っているということではなく、切り離せるものが望ましいく、SegaLib内ではDirectXやOpenGL相当のライブラリしか持っていないといったことだそうです。
また品質バランスという面では、
・性能
・自由度
・保守コスト
・導入しやすさ
・更新への追従しやすさ
・学びやすさ
・バグのなさとデバグの容易さ
・コンパイル速度
これらの項目をあげ、すべてにおいて全項目に目標が必要であり、優先度を設けるのは有効だが、無視していい要素は一つもないと語っています。またマルチプラットフォーム下において、全機種で可能な限り同じものを動かすため、平山氏が決めた基礎方針は、例外的な部分は低性能機種を優先にして作業すること、速度よりもメモリ管理が大事、メモリ内に入らないと発売できないからだと語っています。
とはいえ、アプリケーション部分でも自由度が必要な個所もあります。そのため、アプリがやりたいことができることを網羅すべきこともあったそうですが、今回は時間の制約もあったため、『パワースマッシュ4』で使わないものは、SegaLib内に入れていないといったことも語られていました。
これは保守性という面からも言えることで、機能を増やしてしまうと、多い、複雑、難しいといった弊害が発生するといったほか、「ちょっと作ってみて」と言われて作った機能であっても必要がなければライブラリから削除するといったことや、必要な機能と最低限の複雑さと難しさであれば、いずれは単純化するといったことが挙げられていました。
覚えにくいということはコストが増大するという側面もあり、プログラム上においては、クラス、関数を最小限に、いらない関数は作らないといったことも覚えやすさにつながるといったこととなります。
またアプリの制作者が知る必要がない余計な情報は隠し、作らないクラスのヘッダは配らないといったことなどから、命名規則やスタイルなど、情報を単純化させることで覚えやすくなるといった努力もしていたと語られていました。
さらに、導入部分で平山氏は、導入のしやすさも意識して設計していたそうです。たとえばlibSega.aあるいはSega.libといった部分のみだけとプラットフォームSDKの配布を一緒に行ったほか、Aというクラスを使うならA.hをインクルード、VertexBufferを使うのであれば、VertexBuffer.hといったヘッダーからインクルードすればいいという話があったほか、反面Sega.hを読めば全機能が使えるといったことは推奨しておらず、これはビルドの時間に甚大な影響えるためだったそうです。
ではライブラリの更新作業はどうだったかというと、ライブラリにおいてはバグのなさが重要で、ライブラリを使うアプリのバグはライブラリの責任であると語っています。ですので、バグが発生した場合、責任を持ってライブラリのバグを修正、今回は速度優先で出荷までには直すといった部分もあったため、チーム内で隣の席のスタッフとの連携を取り、フットワークを軽くして行ったそうです。
この時のビルド時間については、目標を決めておくほうがいいと語られています。これは5分が長いか短いか？10秒以下への短縮に価値はあるのか？といったことを踏まえてブラッシュアップしていったそうです。結果として『パワースマッシュ4』のビルドに必要とする時間は、PC版を例にあげると15秒になったそうです。
なお、SegaLibの更新頻度についてですが、SegaLibは直したくなったら直すというコンセプトだったので、大改造があっても躊躇せず行ったと語っています。これは早く治せば、その分アプリ制作に発生する作業も長期化せず、また移植で長期化しそうな個所もあったためだそうです。結果として隣に座っていたスタッフの方が最大の被害者となったということですが、平山氏いわく、「席を引っ越すまではかなり控えめに更新を行っていた」といった苦労話も語られています。
では、SegaLibに対して、アプリ側での対応方法はどうだったかという話になります。描画担当のプログラマーからライブラリを使用しているのは平山氏の隣の席に座るスタッフのみで行われ、担当者のアプリをビルド後に、動作確認をしてからバージョンの更新を行ったそうです。そのほかそのバイナリデータはバッチで自動変換。この隣の席のスタッフとのコミュニケーションの頻度が非常に重要だったと語っています。
次に実装環境ではどうだったのかとう話へと移ります。SegaLibはライブラリファイルは1つしか作らず、その中にグラフィクスや音声、パッド入力に数学まですべて実装したそうです。
近年モジュール化が流行ではあるものの、ライブラリファイルを分けるとプリコンパイルヘッダの生成がライブラリファイルごとになるためにビルド時間の増加、結果として、ビルドのほとんどがIncludeになってしまうことを避け、C++で書いたコードを減らすことで高速化を図ったそうです。ヘッダーの処理を減らしていったり、非公開クラスいくらいじったりしても使用者に害をなさないように書くといったコツなどもあったと語っています。
結果として、一番遅いハードウェア用のコードで50万行あったとしても遅くても4分23秒でビルドが完了することができたと語られています。とはいえ、平山氏は現状には満足しておらず、パワースマッシュでは512ファイルあったC++で書いたコードを減らせすことでより短くなるとも語っていました。
ちなみに、ライブラリのディレクトリ構造についてですが、SegaLib/core/下のディレクトリはアプリケーションプログラマーには公開していないそうです。
次にGPUの抽象化になりますが、GPUはシェーダーの有無、レンダーターゲットの置き場所、シェーダー定数のセット。特にシェーダー部分は他の仕事を放り出してでもやらなければならない問題が多かったと語っています。この問題を解決するにあたり、シェーダー機能がないハードウェアだけを例外処理扱いにしたそうです。また、整合性のために最低限のラッピングを行い、プログラム部分でもシェーダー機能のマシンは極力SDKを露出する方向で行ったと語っています。
一番厄介だったのがシェーダー定数だったそうです。これは機種によって仕様が異なり、GPUがメモリを直接参照するようなタイプや、Set Shaderみたいな関数を作ると最適化に対しての自由度が減るといったデメリットがあるため、前処理済みのバッチを提供して、それらを実行させたと語っています。結果、機種によって異なる処理を前ステートを前もって与えておくことで高速化が図れたそうです。
CPUの抽象化という部分では、1コアマシンが現存するため、SegaLibではシングルスレッドを基本に設計したそうです。これは、開発スタッフ全員がマルチコアに対するプログラム経験があったわけでもなく、教育やスキルの問題も発生する恐れがあったからだと語っています。
とはいえ、アプリ側のプログラマーが適当なコードを書いた場合を考え、念のためのスレッドプールを用意し、1コアマシンはスレッドなしにして、その場で実行するようにしているそうです。
またSegaLibでは、優先度や、依存関係を構築せずに設計してあるそうです。これは、慣れないことをコードに組み入れるとバグが発生する原因にもなるため、機種によてはスレッドは立てられるものの、非追従にしたといった内容が語られていました。
平山氏の見解としては「マルチコア時代はこれからこれからくるでしょうが、携帯電話が4コアになるくらいまでには色々考えようと思っている」と語られていました。
なぜシングルスレッドのみでの設計にしたかというと、「描画とアプリケーションのスレッドを分けて、描画セットを見て非同期に実行といったことで高速化を図ることはできるが、非同期を使ったバグに悩まされた過去があるので、コア数に依存することはあまりよくなかった」といったことも語っています。
まとめとしてSegaLibを制作したにあたり、平山氏は「完璧なライブラリは存在しない、かといって汎用のライブラリなどもなく、SegaLibはその幻影を追わない。組織ごとに、人材、用途、時間などの問題があるので、しっかり考えることが大事です。また、プログラムには賞味期限があり、SegaLibも『パワースマッシュ4』のみで使用されて以後は使わなくなっても構わない」といったほか、ライブラリの度を越した延命は歪みを生むので、“今”使えるものを作る。そして、ライブラリは必ず肥大化するので、積極的に必要のなくなった機能は捨てなくてはならない。捨てるのを後にすると、歪みが発生する恐れがあるので、捨てても良い状況作り、捨てることを納得させるのが大事」と語っています。
そのほかにも、あらゆるライブラリの目的はいいゲームを作る助けになることにあるといった説明のほか、「目的に寄与しないことにコストを払うなといったことや、コードのエレガントさは目的に寄与するか？ その最適化は目的に寄与するか？ その新技術は目的に寄与するか？そいう言うことを考える前に、ベーシックな部分を大事にすることを忘れてはいけない」と語られています。
最後に、「使うのも作るのも人間なので、日ごろから真面目に働いて、スタッフに嫌われないようにすること。何か新しいものを作る時には、ライブラリが必要か？と考えることが大事」だと締め講演を終了しました。
《鬼頭世浪》
この記事が気に入ったらフォローしよう
インサイドの最新の話題をお届けします
