少人数開発でもクオリティを諦めない - エンジニア視点から見る少人数開発の極意 -

© historia Inc. #ue4fest
少人数開発でもクオリティを諦めない
- エンジニア視点から見る少人数開発の極意 -
historia Inc.
原龍

登壇者紹介
 Airtone（AMG GAMES 様）
– Lead Engineer
 過去作
– アーガイルシフト（バンダイナムコエンターテインメント様）
 Lead Engineer
– ランページランドランカーズ（スクウェア・エニックス様）
 Lead Server Engineer
 Client Engineer
 コミュニティ活動
– NekoNekoOnline プラグインの WebApi 機能における設計思想 & 実装Tips
 http://hogetatu.hatenablog.com/entry/2016/12/01/000000
– GameplayDebugger をプロジェクト用にカスタマイズして利用する
 http://hogetatu.hatenablog.com/entry/2016/12/03/002946

今回ご紹介するもの

弊社で開発中の “Airtone” を実例に挙げ
少人数開発における開発の流れ
効率化のために実装した機能
をご紹介します

アジェンダ
 Airtone のご紹介
 少人数開発で必要なもの
 Airtone で実装した機能やツール

まずは “Airtone” のご紹介

AIRTONE VR Gameplay Movie
I promise you Yasushi Asada feat Mary
https://youtu.be/jShjM3ivg7Y

ジャンルエアーリズムアクション（VR）
ハードウェア / プラットフォーム
• Oculus Rift / Oculus Store
• Vive / Steam
エンジン / ミドルウェア
• Unreal Engine 4（UE 4.12 → 4.14）
• Wwise
開発期間約10ヵ月
開発体制（ピーク時）
• プロデューサー & ディレクター × 1
• ゲームデザイナー × 2
• エンジニア × 4
• アーティスト × 3
• UIデザイナー × 1
• サウンド & チャートデザイナー × 3 （社外）

0
2
4
6
8
10
12
14
16
7月 8月 9月 10月 11月 12月 1月 2月 3月
人月
ディレクターゲームデザイナーエンジニアアーティスト UIデザイナーサウンド
 7月
– プロジェクト発足
– プロトタイプ量産
 8月
– 1曲通しプロトタイプ完成
 11月
– α 版完成
 2月
– β 版完成

Airtone は 10時間以上遊べるボリュームのVRリズムゲームです
それを 4人から始め、最終的に 14人で 10ヶ月という期間で作ってます
（控えめに言っても少人数だったなと思います）

今回はこのような少人数開発を
どのように実現したかについてご紹介します

少人数開発で必要なもの

常に "最適な完成度" を目指すこと

一例としてツール制作について掘り下げてみます

ツール制作における工数と効果の関係
工数
効果

工数
効果
ツールとして実運用に耐えうる
ツールとして機能し始める
ぼくがつくったさいきょうのツール

工数
効果
ツールとして実運用に耐えうる
ツールとして機能し始める
ぼくがつくったさいきょうのツール
それともこの辺でも大丈夫？
今回必要なのはこの辺？

クオリティはできるだけ上げたい
でも工数は無限ではない
↓
作るものに応じた “最適な完成度” を目指す

"最適な完成度" を導き出すために

何が必要とされているのかを明確にする

要件定義は大事
 何が求められているのか、実際にそれを必要としている人に直接確認する
 この相談は十分に時間をとる。考えうる可能性の話もする。想像力は大事
 その上で「やらなければいけないこと」と「できると良いこと」を決める

完成形のイメージが固まらない場合は、とりあえず “雑に作ってみる”
 完成形を正確にイメージでき、それを言語化できる人はあまりいない
 何かそれっぽいものを作って出してみると話し合いが短くて済む
 複数人で「誰もよくわかっていない何か」を机上で考えている時間は無駄

“雑に作ってみる” 時にこそ、UE4の真価を発揮できる
とにかく速く、それっぽく、プロトタイプが作れる

ただし、これは高確率で地雷を踏みます

地雷の要因
 雑に作ったことが忘れ去られる
– 「完成している」と思っていた機能がプロトタイプコードで、
実は見た目だけだったという事がプロジェクト後半に発覚するのは割とよくある話
– プロジェクト後半でバグが出たり、機能拡張時の対応コストが高くなって辛いやつ
 “とりあえず” で使いまわしたアセットが残り続けて想定外の依存関係を生む
– プロジェクト後半に最適化等を行うためにアセットを整理しようとした時に、
様々なところに依存が発生していて手が付けられない状態になっていたり…

“雑に作ってみる” を皆が理解する事が大事

“雑に作ってみる” ということ（エンジニア / アーティスト編）
 「雑でもいいから見せる事の重要性」を理解する
– 全てを言語化するのは難しいし、言語化してもわかりにくいものは可視化するしかない
– 相手が自分の感覚を正確に理解してくれるという考えは幻想。諦めて手を動かそう
– だからと言って作り込み過ぎると、ボツになった時に工数的にも精神的にも辛いから雑で良い
– 確認が済んだら、相応のコストを払って作り込む期間を作るのは必須

“雑に作ってみる” ということ（ディレクター / ゲームデザイナー編）
 「雑に作られていること」を理解する
– 目の前にあるものは完成されたものではない。あくまで「形にしてみた」だけ
– 作り込むことで良くなっていく部分がある。その辺りは想像力で補う必要あり。
– しっかり作るとコストがかかるのは当たり前。作業者が必要と言ったコストはもちろん必要
– ここを無視して「ガンガンいこうぜ」をやり過ぎると、プロジェクト後半に身動きが取れなくなる
– 確認が済んで問題なければ必ずGOサインを出すこと。
あやふやなままだと作り込みに入れない

Airtone では初期にプロトタイプを量産し
早い段階でゲームデザインを確立させています

Airtone プロトタイプ制作過程
https://youtu.be/WswQn7mT7yc

ここまでのまとめ
 限られた工数の中でクオリティを高めるために、"最適な完成度" を目指す
– 最適な完成度を導くために、要件定義を密に行う
 要件が定まらない場合はイメージを共有するために雑に作ってみる
– ただし “雑に作ってみる” という事について皆が理解する

少人数UE4開発における共通の悩み

カスタムビルドエンジンにする？
（エンジン改造する？）

カスタムビルドエンジンにおけるメリットとデメリット
 メリット
– プロジェクト固有の改造ができる（どうしてもやりたい場面は出てくる）
– バグがあったら自分たちで修正できる（報告してからの修正対応を待てない）
– 必要なログを入れたり、深い部分のデバッグがやりやすくなる
 デメリット
– プロジェクト全体の動きが遅くなる（エンジンがバージョン管理され、手軽さが無くなってくる）
– エンジン更新に対するマージコストが大きい
– 自分たちが入れた改造によるエンバグの可能性

Airtone に求められる品質をクリアするためには
カスタムビルドエンジンにしないという選択肢は難しい

ただし Airtone のエンジニアは 4人のみ

Airtone におけるエンジニアの大まかな分担
原
スケジュール管理 / ツール全般 / システム
プラットフォーム対応 / 最適化
N さんシステム / 演出 / シェーダー
K くん UI全般 / SE組み込み / Jenkins管理
E くんヘルプ対応 / チャートデザイン兼任
少人数だからこそ、それぞれにかかる負担は大きい…

開発期間全体を通して、エンジンの保守に
工数を割ける程の余裕はない
↓
できるだけ移行時期を後ろに持っていきたい

カスタムビルドエンジンへの移行を遅らせるために
 カスタムビルドエンジンへの移行予定日を決める
– Airtone の場合は規模感を考慮し、オールインの2ヶ月前を目安に予定を立てた
 マージコストを極力減らせるように進める
– カスタムビルドエンジンに移行した後は、基本的にエンジンのバージョンアップは行わない
– どうしても必要なパッチは随時当てる
 プレビュー版で公開された新機能の検証は捨てブランチで
– 捨てブランチで効果を確認し、結果次第で移行予定日を調整する

カスタムビルドエンジンへの移行を遅らせるために
諦めなければいけない部分もある
（絵作りにおける抜本的な改修はできないとか…）
↓
これもチームで検討して "最適な完成度" を目指す

ここまでのまとめ
 カスタムビルドエンジンを使うメリット / デメリットを理解する
 少人数開発で保守コストを払えないなら、できるだけ移行時期を遅らせる
– マージコストを極力減らす運用を心掛ける
 それによってできない部分は諦める
– 諦めて良い部分かどうかはチームと相談

ここからは、もう少し具体的な事例として
Airtoneで実装した機能やツールをご紹介します

ここでも重要なのは
"最適な完成度" を目指す
ということ

なるべく工数を減らしつつ
作品としてのクオリティを出したい
↓
ツール整備
プロシージャル生成

チャートエディタ

Airtone におけるチャートデザイン作業

１．複数種類のノーツを配置（ここだけは普通のリズムゲームと同じ）

２．ジェットコースターのように、コース自体が3D空間上で曲がる

３．コース上には5本のレーンが存在し、それぞれが円周上で移動する

４．トンネルに入ると、レーンが円周上ではなく自由に動く

５．コース周辺に曲のリズムに合わせたエフェクトを発生させる

普通のリズムゲームよりも明らかに作業量が多い

専用のチャートエディタを作って
開発効率を上げよう

要件定義
 チャートデザイナーからの要望
– タイムライン上にキーを打ち、ノーツのタイミング調整や演出を入れていきたい
– できれば MIDI エディタのようなインターフェースでコピペ等は使えるようにしたい
– 作業内容は即時画面上に反映され、簡単にビジュアル面のプレビューをしたい
– プレビューで確認した後、実際にプレイ確認するまでのフローを確立したい
– 演出は同じIDで指定するが、ステージを変えた時にステージに合った演出が出てほしい

要件定義
 アーティストからの要望
– コースの周りやステージ全体に発生する演出はアーティストが実装するが、
タイミングはチャートによって変わるのでチャートデザイナーに任せたい
– チャートが調整された後に、アーティストが調整をかけなければいけないフローだと辛い

Airtone チャートエディタ
https://youtu.be/3kZvOnLJfi8

実装内容
 シーケンサーを専用チャートエディタとして改造
– キーのコピペやスナップ等、シーケンサーの標準機能はほぼ使える
– MIDIエディタのように、目盛のハイライトやキーボードでの打ち込みに対応
– シーケンサーの関連モジュールをそのままプロジェクト側にコピーすることで、
エンジン改造を回避（シーケンサーとしてのバージョンアップは必要無いと判断）

実装内容
 タイムライン上に構築された内容はViewport上にリアルタイム反映
– スプラインとノーツのメッシュを用いた最低限のプレビュー機能を提供
– Viewportで使っているカメラを乗っ取り、実際の見た目に近付ける
 演出トリガー用にアセット指定のイベントトラックを新規に実装
– トリガーの配置はチャートデザイナー、トリガーの内容はアーティストが担当

これを使って Airtone では約100チャートを実装
（チャートデザイナーの皆さん、お疲れ様でした）

チャートエディタ完成までの道のりを
もう少し掘り下げてみます

チャートエディタ完成までの流れ
7月
• プロジェクト発足
• プロトタイプを量産しつつ、ゲームデザインを模索
8月
• 1曲通して遊べるプロトタイプの完成
• Excel / MIDI からチャートを作る簡易的な仕組みの構築
9月
• ノーツ全種実装
• チャートツール仕様策定
10月 • チャートツール制作開始
11月 • チャートツールを使ったチャート制作開始
12月 • チャートツールを使ったチャート制作に完全移行

8月にはもうプロトタイプが動作している必要がある
↓
そこまでにチャートエディタが完成するはずもないので
“とりあえず打ち込むことはできる” レベルの簡易ツールを用意

ゲームデザインが定まらないまま
豪華なツールを作るのはリスクが高い
簡易的なツールでお茶を濁すのは大事

工数と効果が見合わなかったため、諦めた部分
 エディット時の完璧な安定性
– UE4.13時点でのシーケンサーに潜在するバグらしき挙動には目をつむった
– ランタイムでの安定性が高ければ問題無し
 演出（エフェクト）のリアルタイムプレビュー
– そもそもスプライン自体が簡易的な表示だったため、
エフェクトを含めた演出の完全なプレビューは意味が無いと判断
 各レーンの曲線が歪なところが散見される
– 計算でやる以上、思い描く完璧な曲がり方にはならない（ある程度でOK）

作品の根幹部分であるため
色々あったけど概ね良かった

今だから思う、「もっと良く出来たのでは？」
 サブトラック機能（パターンのプリセット化）
– 同じ曲ではチャートレベルが変わってもノーツ配置、演出が共通なことが多い
– サブトラックを作れるようにしてプリセット化できたらもっと効率化できたかも
 評価基準の可視化
– 複数人で作業する上で、クオリティの統一が大きなコストとなった
– 出来上がったチャートの良し悪し確認コストを減らすために、
評価の手助けとなる評価基準を収集できる仕組みを検討した方が良かったかも
（ノーツ密度、コースの曲げ具合、エフェクトとノーツの重なり、etc…）

プロシージャルメッシュの活用
※画像貼る
プロシージャルメッシュの活用

Airtone では、いくつかの演出を
プロシージャルメッシュで作っています

各種レーンに関してはもちろんですが
その他にもあるので一例をご紹介

アーティスト要望
正三角形だけで作られた球が、特定の位置から
徐々に三角形が縮んで壊れていく演出を入れたい

Airtone プロシージャルメッシュ活用事例
https://youtu.be/icNy8c9FcKU

プロシージャルメッシュで正20面体（Geodesic Dome）を生成
更に、任意の数で三角形を分割できるように対応
（ConstructionScript でプレビュー可能）
分割

三角形が縮む演出は頂点アニメーションで対応
基準位置や移動方向、移動量は
Normal や VertexColor をバッファとして使用

プロシージャルメッシュを活用することの利点
 アーティストが用意するには手間暇がかかる演出の工数を削減できる
 ConstructionScript と連携することで柔軟に形状を変化させることが可能
 VertexColor 等をバッファ代わりにして任意のパラメータをマテリアルで使用できる

音と演出の同期
音と演出の同期

リズムゲームの醍醐味
音に合わせた背景演出

Airtone 音と演出の同期
https://youtu.be/Wtjdd5LmF6A

音と同期して背景が動いているだけでも
それっぽく見える

Airtone で使われている、音と同期した演出
1. 1拍 / 2拍 / 4拍毎に背景がリズム良く上下に動く
– ほとんどの背景がこれで頂点アニメーションしている
2. 各種アニメーションやモーショングラフィックスの速度がBPMに合わせて変動する
– リズムに合わせて動くと気持ち良い
3. 音の周波数からアニメーションを生成する
– スペクトラムアナライザを Wwise プラグインとして用意
– 音のアタックを取ってエフェクトを出したり

音に関するパラメータを受け取りたい
↓
Wwise からコールバックで受け取る
Wwise プラグインを作る

音のパラメータに合わせて世界全体を動かしたい
↓
マテリアルパラメータコレクションが大活躍
（プロパティを設定する場所が集約される）

Wwise
音のパラメータをコールバック通知
マテリアルパラメータコレクション
背景マテリアルA
各種マテリアル
背景マテリアルB 背景マテリアルC
背景マテリアルD 背景マテリアルE 背景マテリアルF

リップシンク

Airtone のヒロイン “ネオン” は
フルボイス & リップアニメーション対応

リップアニメーションは手付け？

アーティストが死んじゃう
(ヾﾉ・∀・`)ﾑﾘﾑﾘ

フェイシャルキャプチャー？

機材を持ってません
(ヾﾉ・∀・`)ﾑﾘﾑﾘ

母音推定？

音声ファイルを解析したら母音を推定できそう

http://tips.hecomi.com/entry/20131110/1384096497
みんな大好き “凹みTips”

記事より引用
1. 微小時間音声データ取り込み（WAV ファイル or Mic）
2. ハミング窓を掛けて周期波形にする（周波数高域ノイズ低減）
3. レビンソン・ダービン法で LPC（線形予測分析）係数を得る
4. 得られた係数を元にしたデジタルフィルタの周波数応答を得る
5. これが LPC スペクトル包絡線
6. 包絡線の山から１番目と２番目のフォルマント（ F1、F2 ）を特定
7. F1、F2 の分布から母音特定

要約すると、音声ファイルを解析する事で
微小区間毎に以下の情報が得られます
時間, 第1フォルマント, 第2フォルマント, ボリューム

解析された情報の使い方
 第1フォルマント、第2フォルマントの値から母音の推定が可能
– 第1フォルマントが 600 ～ 1400 かつ、
第2フォルマントが 900 ～ 2000 ならば「あ」と推定など
– これらの値は人によって変わってしまうので、論文等に載っている
サンプリング情報を参考にしつつ、ネオンの声優さんに合わせて細かく調整
 ボリュームカーブを元に、リップアニメーションのブレンドタイミングを調整
– ある程度のボリュームが無ければ口を開けない

Wavファイル Lipファイル
Voice2Lip コンバータ
LipCurveアセット
LipPlayerコンポーネント
インポート
ネオンアニメーションBP
LipCurve指定で再生
コールバックでフォルマント、ボリュームを通知して加算するリップアニメを指定
ネオンBP
UE4

これにより、ほとんどのケースで上手くアニメーションされた
更なるクオリティ向上のためには閾値の調整が必要
↓
解析された情報を可視化する仕組みを作る

Airtone リップシンク調整ツール
https://youtu.be/5fcxb2x5cVk

アーティストが閾値やアニメーションのブレンドタイミングを調整
調整

可視化はとても大事

工数と効果が見合わなかったため、諦めた部分
 完璧なリップシンク
– あくまで “推定” なので、完璧なリップシンクを目指すと調整にコストがかかる
– アニメ調なのが幸いして、完璧じゃなくても割と良く見える
 Voice2LipコンバータをUE4に組み込む（全てをUE4内で完結させる）
– 解析に使っている外部ライブラリが64bit対応されていなかった
– そもそもwavファイル用のインポーターは既にUE4にあり、
一つの拡張子に対して複数のインポーターを作るのは現状だと不可能

フォルマント解析に関する詳細はこちらから
 フォルマントから母音推定してリップシンクを目指してみる - 凹みTips
– http://tips.hecomi.com/entry/20131110/1384096497
 線形予測分析（LPC）-人工知能に関する断創録
– http://aidiary.hatenablog.com/entry/20120415/1334458954

デバッグツール

RHI のメモリダンプをグラフ表示

1フレーム内での SpawnActor 回数を可視化

Mip バイアス調整用テクスチャジェネレータ

解像度を指定しつつ、
Mip レベルによって色が違う
単色テクスチャを生成

特に VR コンテンツでは、エディタ上のプレビューと
実機で表示される Mip レベルに違いが出るので注意

手にアタッチされたデバッグメニュー

目線追従メニューだと邪魔
Vive のメニューを参考にした

まとめ

まとめ
 限られた工数の中でクオリティを高めるために、"最適な完成度" を目指す
 要件が定まらない場合はイメージを共有するために “雑に作ってみる”
 カスタムビルドエンジンを使うメリット / デメリットを理解する
 少人数開発で保守コストを払えないなら、できるだけ移行時期を遅らせる
 ツール整備、プロシージャル生成で全体のコストを削減する

Airtone は 2017年春発売予定！

ご清聴ありがとうございました

少人数開発でもクオリティを諦めない - エンジニア視点から見る少人数開発の極意 -

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (8)

Similaire à 少人数開発でもクオリティを諦めない - エンジニア視点から見る少人数開発の極意 -

Similaire à 少人数開発でもクオリティを諦めない - エンジニア視点から見る少人数開発の極意 - (20)

Plus de historia_Inc

Plus de historia_Inc (20)

少人数開発でもクオリティを諦めない - エンジニア視点から見る少人数開発の極意 -