[セッションレポート]カービィチームの開発力を最大化せよ！ ―内製フレームワークで大事にしたこと― #CEDECSAPPORO

もこ@札幌オフィスです。

本記事はCEDEC+SAPPORO 2019 「カービィチームの開発力を最大化せよ！ ―内製フレームワークで大事にしたこと―」のセッションレポートです。 　

登壇者

株式会社ハル研究所

開発本部 第一開発部 商品開発課

中野 宏晃様

開発本部 開発環境室

鶴岡 友和様

野下 徹也様

セッションレポート

理想の開発環境ってなんだろう？

理想の開発環境はチームごとに違う →チームによって作ろうとしているゲームが違うから

開発環境は作りたいゲームに寄り添うことが大事

作りたいゲームに寄り添うことがそれを使えるチームメンバーが居なければいけない。

開発環境は開発力を上げるツール

開発力を上げるにはチームの得意、不得意、使うメンバーなどを考慮して初めて開発力を最大化出来る。 チームの個性は重要

星のカービィの制作チームには

• 作り込みが好き
• 習熟度のばらつきがある
• プランナーが少なめ
• 拠点は山梨

こういった特徴によりそう必要がある。

開発環境作りで大事にすること

• ツールに振り回せない
• マスターアップ直前まで作り込める開発環境
• 職種の枠にとらわれない開発環境

ツールに振り回せない開発環境

ゲームに作るにはツールを使う、チームメンバーのツールが使える度は違う

新しいツールを導入したらついていけない

間違った使い方をしていて、時間がかかる

そもそもツールの使い方がわからない

→ツールに振り回されている状態

ゲーム作りの本質

1. 作りたいものを考える

    

2. ツールを使って作る

3. 作ったものを確認して改善

2番は本質ではない、2番のツールに意識が囚われていていると、ゲーム作りに集中できない

ツールに振り回されないようにしてゲーム作りに集中する

どのように集中できるようにする？

オペレーションがシンプル

オペレーションは「手段」、クリエイターが求めているのは「結果」と「その先」

オペレーションをシンプルにして「結果」と「その先」を重視する

→Navitsという内製ランチャーによってツールの起動方法を統一している。

機能追加はXMLを編集、デザイナー向け、プログラマー向け、マップ制作向けをタブで分けて、「自分に関係あるツールを感覚的に選択」出来るようにしてる

古いバージョンがインストールされている場合などはバージョンチェックしている

その他のツールはリポジトリ管理

ゲーム内メッセージで視線移動の削減

開発中に大きく視線を動かさないように設計、 →シセンイドウで疲れ、頭で抱いていた完成イメージが削がれることもある

開発環境には「アラート機能」を作成し、ゲーム画面内で文字列を出力出来るようにしている

→専用のprintf関数を呼ぶと表示できるようになっている

「ワールドコメント機能」 キャラクター、敵などの下にマウスカーソルを当てると情報をゲーム内で出力できるようにでき、視線移動を最小限に

フレームワーク

フレームワークはゲーム開発用の内製フレームワークを使っている

カービィチームは必要ならフレームワークを編集して新機能を追加する。

コンフリクトが起こりづらいようにリポジトリを管理している。

ユーザー→Subversionリポジトリ→プロジェクトGitリポジトリ→フレームワーク

間にGitを挟んでコンフリクトを最小限に

より短い実行時間

オペレーションがシンプルになっても処理が終わるまで時間がかかると意識が途切れてしまう。 →よってオペレーションが回しづらくなる

ホットリロードの徹底をしてオペレーションの高速化

ゲームの再構築、再起動などをなくして、すぐに変更を適用出来るようにしている

テクスチャーの差し替え、サウンド、背景パーツなども可能

ゲーム画面で確認しながら、リアルタイムにオブジェクトを設置・調整することが可能。

ソースビルドキャッシュ

ビルド時間1番はC++

コミットがあるたびにJenkinsでビルド、ビルドした.exe 成果物をダウンロードできる環境に

安心感

ミスが原因で他の人を止めたり不具合を仕込んでしまったら怖い、「ミスしないようにしないと」 →不安になってしまう

ゲームロジック全スクリプト化する →昔は全部C++だった

C++はミスするとゲームが止まってしまうが、スクリプト化でミスしてもゲームがクラッシュすることもない、不正なメモリアクセス、解放済みオブジェクトへのアクセスによるエラーもあまりない

• コードレビュー

一般的なレビューは、実装→レビュー→修正→レビューOK→Mergeだが、

カービィチームはコミットしたらすぐに反映されるようにした

SubVersionにコミットメッセージにJiraのIssueをもとにGitにMerge Requestがでる

同じ課題番号が出たら以前のブランチにコミット

マスターアップ直前まで造り込める開発環境

ゲームの作り込みに時間をかけたい人はたくさん

終盤はデバッグもしないといけなく、作り込みの時間を確保することは難しい。

カービィチームでは「開発環境を効率化してデバッグ時間を短くして、作り込みの時間を確保する」

不具合と向き合う時間を減らすためには

• 発見のしやすさ
• 再現のしやすさ
• 修正のしやすさ

を重視して改善していった

発見のしやすさ

• 手間を掛けずに発見できるようにする

「画面内警告メッセージ」で不具合を画面上に出し、気がつきやすく、放置されづらい仕組みを用意する

• マップの巡回テスト

マップのテストをJenkinsで自動化 カービィを移動させて、エラーがないかをCheck

→CPU/GPUの負荷も記録、パフォーマンス計測も可能。

• 人間の代わりにゲームをプレイする

HID ロボット 人間の代わりにゲームをして、帰宅前に実行、翌朝ログを確認する。

HランダムHIDキー入力タイプ、ボスを倒し続けるなど、挙動はスクリプトで作ることが可能。

再現のしやすさ

不具合を再現しやすくする

• ヒープの分割

メモリ不足 メモリリーク メモリ破壊 メモリ断片化 メモリ参照

→再現性が低く、調査に時間がかかってしまう

「発生しづらく、再現しやすい艦橋が必要」

ヒープを分割し、メモリ周りの不具合の再現度を上げる。

「シーンヒープ」(次のマップまでの移動区間)では、シーン開始時にヒープ画からであることを保証して、再現率を上げている

• フライトレコーダー

ゲームプレイのリプレイを出来るように記録する

HID入力、シーンの開始状態、各フレームのデルタタイムなど、エラーが出たあとに同じ動作を正確に再現刷ることが可能。

映像の保存ではなく、プレイヤーの操作。バグ報告時にフライトレコーダーのデータを一緒に渡し、修正。

修正後も同じフライトレコーダーを使い、修正確認

修正のしやすさ

• エラーレポートを送信している。

ゲームプレイ中でクラッシュすると、自動でコンソールの出力、スクショ、フライトレコーダーを添付して、Jiraに上げれるようにしてる

• エラーコードへのジャンプ

「画面内警告メッセージ」をクリックすると不具合の対処方法のページにジャンプ可能

職種の枠にとらわれない開発環境

カービィチームはプランナーが少ない。10%ほど

一般的なプランナーの仕事をカービィチームのプランナーに割り当てるのは合わない

「職種の枠にとらわれずに最敵な作業分担ができるようにする」

スクリプトシステムMint

詳細な仕様を書かずにプログラマーに委ねるようにし、ビルド時間、コーディングのTry/Errorをやりやすくして、スクリプトシステムを導入した

内製のスクリプトシステム、静的型付け言語。Mint

C++プログラマーもなれやすい言語仕様、読みやすい文法

静的型チェックで早めのエラーチェックが可能。

「安心」してゲーム作りに集中できる

ビルド時間も短く、130万行のコードもフルビルドで30秒。1ファイルだと3秒

ホットリロード対応で、ゲームをしながら内容を更新できる

グルーコード生成の最適化

C++ではなく、YAMLでグルーコードを自動生成するようにしている。

星のカービィ スターアライズのMint行数は70%

→できる限りC++書きたくない状態にできる。

VMも軽量で最適化されている

MintからC#へ

最新環境ではMintのVMなどを流用して、C#に移行　より高速な開発が可能に

プレインエディタ

プレイン: ザコ敵、ボスの行動パターン

ブレインはプログラマーに依頼していたが、プランナーが新しいアイディアがあったら毎回プランナーに依頼していたら両方とも大変

→プレインエディタ　Fabrick

視覚的にブレインを編集できる内製ツールで、Scratchのように簡単にすぐ修正でいるように

ブレインはスクリプトコードとして出力され、Mint/C#で出力され、ホットリロードができる。

まとめ

ツールに振り回されない開発環境

マスターアップ直前まで造り込める開発環境

職種の枠にとらわれない開発環境

ツールの強化だけではなく、チームの個性に合わせて寄り添って、開発環境を改善していく。

スポンサーブースでカイロ配ってます！

スポンサーブースで何回でも使えるカイロをお配りしています！

会場にいらしている方は是非お越しください！