現在開催中のオンラインゲーム開発者向けカンファレンス「CEDEC2022」。その中で『星のカービィ ディスカバリー』の変化し続けるプロジェクトに寄り添ったシステム・ツール開発の講演が行われた。
 |
講演者はハル研究所のエンジニアから3人。中野 宏晃さん、鶴岡 友和さん、鈴木 雄也さんが、それぞれのセクションに分けて講演を行った。
『星のカービィ ディスカバリー』は『カービィ』シリーズ初の3Dアクションゲームとなり、前作までの2Dアクションとは大きく遊びが変わった。それによって開発に必要なものも大きく変わり、たくさんのシステム、ツールを新規作成したり改善したりしたそうだ。
その開発の道中で「フェーズによって求められる機能が変わる」、「当初想定していた仕様やアセットの物量が変わる」、「チームメンバーの増員や入れ替わりでチーム構成が変わる」などの変化が起き、いかに変化し続けるプロジェクトと向き合い寄り添うことが大事なのかの知見が講演では共有された。
 |
文／tnhr
3Dマップエディタの話
講演はまず3Ｄマップエディタの話から始まった。ステージクリア型のアクションゲームにおいて、マップエディタは非常に重要なツールのひとつ。マップエディタも2Dから3Dへと変えるために、新しくエディタの開発、データフローの準備を行ったそうだ。
プロジェクトが始動してからすぐに企画実験をするためには、エディタとデータフローは必須。早く準備できていれば企画実験でいろいろと試せることも増えるからだ。ただ、速さを重視して雑に作ってしまうと、量産時に使えないものが完成してしまうので、開発までのスピード感と将来を見越した制作を両立しなければならない。
 |
マップエディタはまず、必要な機能や作り方を考えるところから始まる。最初に機能を列挙しようとしたが、今作が初の本格3Dアクションゲームだったため、必要な要素を列挙しきることはできなかったそうだ。
そのため、拡張のしやすさとトライアンドエラーのしやすさを重視した。拡張がしやすく、トライアンドエラーがしやすいマップエディタ開発環境を検討したところ、UnityとUnityのエディタ拡張機能を使用したそうだ。
この方針が決定したあと、第一弾として最低限必要な機能である「地形の作成」、「アクターの配置」、「ランタイムデータコンバート」から開発を始めた。以下ではその機能について説明する。
まず、地形の作成に使用する「ブロック配置方式の地形エディタ」から。この方法は過去作でも実績のある方法で、ブロックをマウスで配置することによって地形を作成し、ブロックの形状はFBXファイルで登録することができ、いつでも切り替えることができる。
 |
ブロックの配置が終わったらコンバートの作業に。先ほど作ったブロックの配置情報から3Dデータとしてエクスポートすると、簡易的な装飾がされた地形をゲーム画面上ですぐに確認することができる。
その後、アクターと呼ばれる敵キャラ、ギミック、アイテムの配置作業を行う。アクターはUnityのプレハブ機能を使った。まず各アクターの種類ごとにプレハブを準備し、そのプレハブをシーンに配置するというオペレーションで実現したそうだ。
アクターにはいろいろな敵キャラクターの挙動などのパラメーター情報が存在している。これらは、UnityのComponentを使って設定しるようにしたという。ここまで開発することによって企画実験するレベルには到達した。
 |
次は量産に耐えることのできるように機能を改善していく校庭に進む。この量産フェーズではさまざまなスキルレベルの人がプロジェクトに参加し、それに伴いマップエディタを使用するメンバーも増加する。以下では、そのために追加した機能について説明する。
まずは、「プレハブ連続配置ツール」から。アクターをカテゴリから選択、連続配置することのできるツールを準備した。スタンプを使うように配置させるようにでき、補助機能としてグリッド位置吸着、地面法線回転吸着、ランダム回転もサポート。さらに、この配置ツールはアクターだけではなく背景にも対応しているそうだ。
 |
次の「レイヤ―ウィンドウ」はUnityの機能をより使いやすく改良したものを作成。レイヤーごとの可視フラグや編集ロックフラグの切り替えをサポート、レイヤーの属するファイルロック取得もワンクリックでできるようになった。
「シーンオープンウィンドウ」はシーンを開く操作をしやすくなるツール。テストを含めると数百オーダーになるシーン数。それをコンテキストメニュー方式で最低限のオペレーションで目的のシーンが選択できるようにした。最近開いたシーン選択や前後のマップ選択もサポートしたそうだ。地味だけど存在感のあるツールになっている。
「プレハブ削除ウィンドウ」は既存のプレハブを削除したり別のプレハブに置換するツール。配置済みの全シーンに対して削除、置換しデータコンバートまで実行することができ、このツールのおかげでデータ整理に対するハードルが下がったそうだ。
最後に「リアルタイムプレビュー」。変更したらすぐに画面上に変更結果を反映する機能。すべての変更状態に対応するのは大変だったため、優先度の高い装飾パーツなどに絞って対応したそうだ。
 |
ビルドシステムの話
次はビルドシステムについての話。ビルドシステムとはビルドやそれに関係するバージョン管理、CIなどの仕組みの総称。アセットに関するビルドシステムは3DS時代のままで、要改善状態だったそうだ。さらに、2Dから3Dになり、アセットはさらなる肥大化の見込みがあった。
 |
まずは「コンバート環境の刷新」について。コンバートとはアセットをランタイム用のデータに変換する処理のことを指す。前作までのコンバート環境は、2プラットフォーム分（PC、Switch）のデータを各開発者のPCに保持していたそうだ。これはCIが不要なシンプルな仕組みだったのだが、問題点も多数あった。
「コンバートの時間が長い」、「SVN更新の時間が長い」、「ローカルSSDの容量が圧迫」という2プラットフォーム分も扱うことによる負荷に限界が訪れたのだ。
せっかくなら良いビルドシステムを作りたいが、プロジェクトの状況は量産開始をするために必要な作業が多く、コンバート環境の改善のためだけに時間を確保することができない。そのため、費用対効果の高い改善に注力したそうだ。
まずは、開発者PCではPC版のデータだけを扱うようにしたという。開発者PCでは普段使用するPC版のデータに限定するようにしたことによって、単純に処理や物量が半分になり、コンバート時間、SVN更新時間、ローカルSSD容量が改善された。
 |
あわせてCIによるコンバートも進められた。コンバートデータのコミットはJenkinsに委託。CIのトリガーは開発者ごとに用意したコンバート履歴ファイルを使用した。開発者はコンバートしたアセットが記録されたコンバート履歴ファイルと一緒にコミット。そしてCI側がコンバート履歴ファイルに記載されているアセットをコンバート、およびコミットしていく流れになるそうだ。
ストレージの圧迫についてもさまざまな改善が行われ、3Dグラフィックのアセット容量が想定以上に増加、さらにSVNで全アセットをローカルにダウンロードしていたことが原因だったそうだ。
どうしようか悩んでいるときにPlastic SCMというツールの存在を知った。Plastic SCMはバージョン管理ソフトのひとつで、部分的なデータダウンロードが可能。サポートツールを用意せずにアーティストにも使ってもらえそうだったため導入したというだ。また、SVNのようにファイルの複製を別途保持しないため、ディスク容量にも優しいのだ。
各種CIツールをSVNからPlastic SCMに移行する校庭の確保が難しかったため、3DグラフィックスアセットのみをPlastic SCMで管理。それによってSSDの消費容量は約1TB削減することができ、ダウンロード時間ロス問題も解決された。
 |
最後に紹介されたのは全アセットコンバートについて。本ビルドシステムはテクスチャなどのアセットを変更するだけではコンバートデータが更新されないため、深夜に全アセットのコンバートを毎日実施していたそうだ。
しかしプロジェクト終盤になると、最初は40分くらいで終わっていたものが300分まで増加。このペースで処理時間が増えると最終的には朝になっても終わらないという問題が発生してしまった。そのため少ない校庭でコンバート時間を短くする改善が必要と考えられた。
これについてはハイパワーマシンの導入で改善。マシンの導入と一部コンバート処理の見直しで300分から45分まで改善。マシンは当時60万円程度だったが、工数の捻出の難しさや費用対効果を考えると妥当だったそうだ。
 |
スクリーンショット撮影ツールの話
『星のカービィ ディスカバリー』では処理負荷削減のために3Dモデルではなく2D画像を作ることがあるという。そしてここではその2D画像のことを「スクリーンショット」と呼ぶ。そして、本セッションではスクリーンショットの撮影をアシストするツールを解決した話が行われた。
 |
過去作でもスクリーンショットを使ったことがあるが、デバッグカメラで画像を作っていたために、3Ｄモデルの変更があったときは再度コントローラーでカメラで再撮影しなければならなく、コストが高かった。
また、モデル製作者と再撮影の担当者が違うため、連絡を取り合う必要があり再撮影を忘れることが多かった。プロジェクト規模が大きく撮影枚数が増えるため、撮影専用のツールを用意する運びになったそうだ。
スクリーンショット撮影ツールの名前は「ジオラマツール」。画面内に自由にモデルやエフェクトを配置し撮影することのできる機能が付いており、撮影した時の状況（モデル、カメラ、エフェクトの状況）は構図ファイルとして保存されるため、3Dモデルが変わってもあとで簡単に再撮影することができるそうだ。
 |
このジオラマツールの活用方法が紹介された。まずは「トレジャーロード」の開始画面。特別なステージに入る前のステージ開始用の画面にスクリーンショットが使われた。
「ガチャルポン」というフィギュアを獲得できるコレクション要素では計250枚以上のスクリーンショットが必要で物量が多く、ひとつひとつ細かく調整するのが大変だったそうだ。なのでエクセルを使ってパラメーターを調整できるようにしたとのこと。
 |
便利な機能であったため、UIではないセクションでもジオラマツールを使いたいという要望がチームで出たらしく、やりたいことにあわせてジオラマツールに機能を追加していった。
まずは「アートワーク作業」。アートワーク作業はパッケージや広報で使われる画像を作成すること。過去作ではアートワークの案だしのために仕組みを用意していったが、今作はジオラマツールを使えるのではと考えた。
同じ3Dモデルをいろいろな角度から撮影したいという要望から、ジオラマツールのカメラ機能を複数設定できるように機能拡張し、さまざまな角度から撮影できるようにした。
他にはエンディングに使う画像をジオラマツールで作成したいという要望があったため、ステージを背景に撮影できるように、被写体震度などの細かいエフェクトも調整できるように改良された。
 |
当初の想定以上の領域でジオラマツールを活用することができ、「つりぼり」のハイスコア画像。「カービィハウス」の壁掛け写真など、各スタッフのアイデアでジオラマツールが活用されるようになったとのこと。
 |
C＃スクリプトシステムの話
最後のセクションではC＃システムについての話が行われた。『カービィ』チームでは長いあいだ、独自のプログラミング言語で記述する内製スクリプトシステムMintをしようしていたが、今作からC＃で記述する新しい内製スクリプトシステムであるBasilに乗り換えたとのこと。
旧スクリプトシステムであるMintは「言語使用が古い」、「エディタ環境の改善ができていない」、「コンパイラとVM両方の実装が必要なことによる開発時間の増加」、「独自言語のための学習コストが高い」などの問題を抱えていた。そのため、Basilへの乗り換えを検討したそうだ。
Mintの問題点を考慮して、Basilでは既存の言語であるC＃を採用。優れた言語でエディタサポートが充実しており、言語使用の策定やコンパイラの実装が不要になるため開発行程が大きく現象、そしてなによりC＃ならすでに熟練している人が社内外にたくさんいることが理由であった。
 |
 |
 |
開発期間は8か月。MintからBasilへの移行は約2週間で終わり、効果は大きかったとのこと。C＃は書きやすく、IDEでコードを補完しながらホットリロードで開発できるのが快適だったという。
 |
本作の開発が最終段階に入ると。スクリプト処理がプロファイル上位に上がってくるようになった。開発速度優先でIL命令をそのままバイトコードに出力しており、Mintに比べて2～3倍遅かったそうだ。そのため、バイトコードの最適化をおこなって、性能を改善しようと試みたという。
結果、おおむね10％ほどCPU負荷が減少し、マップによっては20％ほどのCPU負荷が減少した。
 |
『星のカービィ ディスカバリー』は前作から大きく遊びが変わった作品。それによって、プロジェクトもスタートからマスターアップまで変化し続けた。
開発するシステムやツールそのものだけを見ていても開発力は上げることはできず、変化に対応しながらさまざまな角度から問題を見ることが大切そうだ。
