2019年10月5日、北海道は札幌にて、開発技術者・クリエイター・学生を対象にしたゲーム/エンタテインメントの技術カンファレンスCEDEC+SAPPORO 2019が開催された。
この日に行われたセッションのひとつ、ハル研究所のカービィチームによる“カービィチームの開発力を最大化せよ！ ―内製フレームワークで大事にしたこと―”は、“チームのチカラを引き出す開発環境作り”というテーマ。
開発チームを支える縁の下の力持ち的なアプローチであり、ひいてはゲームの開発スピードやクオリティー全体を底上げする重要なポイントだ。どんな意識を持ってどんな工夫を重ねてきたのか？ こちらをお伝えしていこう。
登壇したのは、ハル研究所カービィチームのリードテクニカルプログラマーの中野宏晃氏、開発環境チーム所属プログラマーの野下徹也氏と鶴岡友和氏の3人。
“ツールに振り回されてはいけない！”開発環境はシンプル、スピーディー、安心が大切
中野氏がまず冒頭で伝えたのは、“理想の開発環境はチームごとに異なる”こと、そして“チームの個性に寄り添うことが重要。理想の開発環境で開発力を最大限まで引き上げること”だ。これはセッション全体のキーワードとなるが、ゲームとチームに合わせた開発環境が求められる。
ゲームを作るために開発ツールを使うわけだが、“ツールに振り回されている状態”になると大きくロスしてしまい、ゲームを作る前にツールの使いかたを覚える時間がかかってしまう。それは本質ではない。
そこで開発環境チームでは、ゲーム作りに集中できるようにするには、
“オペレーションがシンプル”
“より短い実行時間”
“安心感”
という3つのキーワードが必要と考えているということだ。
まずひとつめの“オペレーションがシンプル”というものでは、内製ランチャーツール“Navits”を制作。開発におけるすべてのことは、この“Navits”から始められるように統一しているそうだ。
“Navits”は、各ツールのバージョンチェックも行なって、使用者へ通知をだす仕組みも持っているし、インストール不要なツールはリポジトリ管理していて、ワークスペースを最新にするだけでツールも最新になるようになっている。
開発者の作業中の“視線移動”にも着目して、これを極力少なくさせているという。目の動きもオペレーションのひとつであり、大きな視線移動は集中力を下げる原因にもなって、開発者が頭の中で描いていた完成イメージを薄れさせる。なので、開発者に伝えたい情報を開発者の視線の近くに表示すれば集中力が下がらないというわけだ。
開発中にはさまざまなメッセージがPCに表示されるが、別ウィンドウに開発用のログをおいてもけっきょくは見ないままになるし、視線移動も手間も多い。そこで、同社のツールでは“メッセージをゲーム画面に出す”ことを基本にしているそうだ。
キャラクターに吹き出し型のメッセージをつけたり、確認したいアクターの情報をクリックで呼び出せるようにしている。
カービィチームでは、内製のFratFrameworkを使用している。
ふたつめの“短い実行時間”。オペレーションの実行にかかる時間が長いと開発者の意欲や意識が途切れてしまう。1回あたりの実行時間が長いとイテレーションを回しづらくなるのでクオリティーも上がりにくくなる。どちらの意味でも、実行時間は短くあるべきというわけだ。
カービィチームの開発ツールでは、ホットリロードを徹底。ゲームを再起動したり再構成したりすることなくリアルタイムにプレビューできるし、テクスチャの差し替えもノードの変更でリアルタイムに反映される。
背景の装飾や配置もリアルタイムに編集可能で、ローテートや拡大縮小などももちろんできるし、ライティングも、さらにはSEのパラメーター調整もできるということだ。
また、ビルド時間を短縮するため、一番時間がかかるC++のコンパイル＆リンクはコミットがあるたびに『Jenkins』（統合自動化ツール）に行わせて、実行ファイルをアップロードさせている。ビルド時間を大幅にカットしているというわけだ。
3つめのキーワードは“安心感”。これだけ手軽に触れるツールにすると、今度は手軽さがゆえに使う人は“気軽に触ったことがほかの人の作業に影響してしまうことや不具合を発生させてしまう”そういう恐れを抱くという。使用者がミスを気にしなくていい開発環境にすることが重要だ。
そこでカービィチームのツールでは、ゲームロジックをすべてC++ではなくスクリプト化。スクリプト化したことでコーディングに対する安心感が高まり、ミスをしてもちょっとやそっとのことではゲームが止まることがなくなった。そうして安心感がアップしたことで、純粋にゲームのことを考えやすくなったということだ。
また、カービィチームは「作ったモノをすぐにほかの人にも見てもらいたい！」と考える人が多いということで、コードレビュー（ソースコードの誤りを検出・修正するための検査）を一般的な事前ではなく事後、つまり後から行う方式にして反映のテンポを速めたというわけだ。
デバッグの時間を短くしてクオリティーアップの作り込み時間を稼ぐ！
続いては、野下氏が伝える“マスターアップ直前まで作り込める開発環境”作りについて。
ゲームの要素がひと通り出揃った開発終盤のほうがクオリティーアップの作り込みはしやすいのだが、その時期にはデバッグもしなければいけないので、時間がかけられないというのが実際のところ。
そこで開発環境チームでは“不具合と向き合う時間を減らす”ことを考えたそうだ。
開発途中に不具合を見つけやすくして、開発終盤時期のデバッグ時間を軽減。途中過程で不具合が見つかっても放置されないように、ゲームプレビューに警告を表示する機能を追加したという。
マップの動作チェックなどのいわゆる総当たり的なテストには“Jenkins”を使用。同時にCPUやGPUの処理負荷も記録させて、パフォーマンスのチェックに役立てているという。また、操作入力のチェックにも人間の代わりに行ってくれるシステムを導入していて、帰宅前に実行させて、翌朝にログをチェックするというやりかたをしているということだ。
不具合を再現しやすくして直しやすくすることも大事ということで、とくに再現性が低くて厄介なのがメモリの状況に起因する不具合だ。そこでカービィチームではヒープを細かに分割して、再現度をアップしている。
また、テストプレイ時にプレイを記録しリプレイできるようにするフライトレコーダーのシステムを導入している。フライトレコーダーは映像による保存ではなくプレイヤーの操作を記録する方式にしているので、コードを変えて再度テストすることもしやすいという。
そうして発生した不具合のエラーレポートは、スクリーンショットやフライトレコーダーのデータとともに送信されるようになっている。ゲームプレビュー中に表示される警告メッセージからはそうした不具合の詳細にアクセスできるようにしているだけでなく、解決方法が書かれた社内Webページへもジャンプできるようにしている。こうして共有することで、それぞれの理解度アップをうながしているということだ。
チームの特徴にあわせて、通例と言える業務割り振りも変えていく！
鶴岡氏が紹介した取り組みは、“職種の枠にとらわれない開発環境”というものだ。
一見するとツールの効率化や最適化の話とは逆へ向いているように思えるところもあるテーマだが、これにはカービィチームの特徴が背景にあるという。
カービィチームはほかの開発チームと比較するとプランナーが少ないそうで、一般的に“この仕事はプランナーがやるもの”という考えかたをしていると、プランナーの負担が多くなりすぎるからというのがその理由だ。
そうした環境に合わせて最適な作業分担をすることがポイントであり、そこで“職種の枠にとらわれない開発環境”という考えかたをしてワークフローの最適化をしたというわけだ。
まず行ったのは、“詳細な仕様書をプランナーが書かずにプログラマーに委ねてしまう”という大胆なもの。確かにこうしてしまえばプランナーの負担は下がるが、そのぶんプログラマーの負担は増す。
そこで、プログラマーの負担を軽減する工夫も行わなければならない。これには前述の“コードのスクリプト化”があり、ビルド時間の短縮やトライ＆エラーのしやすさも同時に加わり、負担を軽減したという。
スクリプトシステムには“Mint”という内製のものを使用。C++、C#、D言語を参考にした仕様を持つ静的型付け言語とのこと。
MintはWiiのころから使っているということで、パッケージタイトルでのシリーズ最新作であるNintendo Switch『星のカービィ スターアライズ』では、Mintの行数は全体の70％なのだとか。
ただし、現在ではさらに開発効率を向上させるため。最新環境では言語部分をC#に差し替えたスクリプトシステムに乗り換えていっているということだ。
チームの個性に寄り添って開発環境を作ることで、完成するゲームがもっとよくなる
セッションの最後には、再びリードテクニカルプログラマーの中野氏が登壇。解説していったカービィチーム用の開発ツールで行った取り組みや工夫を踏まえて、冒頭にも語った“理想の開発環境はチームごとに異なる”こと、“チームの個性に寄り添うことが重要”であることを再度紹介。
チームの個性と寄り添い、求めるものや最適な方法はそれぞれに異なることを再確認することが、開発環境改善の一歩であると、セッションを締めくくった。