少人数開発でもクオリティを諦めない -...

© 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 MovieI promise you Yasushi Asada feat Mary

https://youtu.be/jShjM3ivg7Y

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

（社外）


7 月 8 月 9 月 10 月 11 月 12 月 1 月 2 月 3 月0

2

4

6

8

10

12

14

16

人月

ディレクターゲームデザイナーエンジニアアーティスト UI デザイナーサウンド

7 月– プロジェクト発足– プロトタイプ量産

8 月– 1 曲通しプロトタイプ完

成

11 月– α 版完成

2 月– β 版完成


Airtone は 10 時間以上遊べるボリュームの VR リズムゲームで

す

それを 4 人から始め、最終的に 14 人で 10 ヶ月という期間で

作ってます

（控えめに言っても少人数だったなと思います）


今回はこのような少人数開発を

どのように実現したかについてご紹介しま

す


少人数開発で必要なもの


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


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

てみます


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

工数

効果



工数

効果

ツールとして実運用に耐えうる

ツールとして機能し始める

ぼくがつくったさいきょうのツール



工数

効果

ツールとして実運用に耐えうる

ツールとして機能し始める

ぼくがつくったさいきょうのツール

それともこの辺でも大丈夫？

今回必要なのはこの辺？


クオリティはできるだけ上げたい

でも工数は無限ではない

↓

作るものに応じた “最適な完成度” を目指す


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


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

る


要件定義は大事

何が求められているのか、実際にそれを必要としている人に直接確

認する

この相談は十分に時間をとる。考えうる可能性の話もする。想像力は

大事

その上で「やらなければいけないこと」と「できると良いこと」

を決める


完成形のイメージが固まらない場合は、とりあえず “雑に作ってみる”

完成形を正確にイメージでき、それを言語化できる人はあまりいな

い

何かそれっぽいものを作って出してみると話し合いが短くて済む

複数人で「誰もよくわかっていない何か」を机上で考えている時

間は無駄


“ 雑に作ってみる” 時にこそ、 UE4 の真価を発揮で

きる

とにかく速く、それっぽく、プロトタイプが作れ

る


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


地雷の要因

雑に作ったことが忘れ去られる–「完成している」と思っていた機能がプロトタイプコードで、

実は見た目だけだったという事がプロジェクト後半に発覚するのは割とよくある話

–プロジェクト後半でバグが出たり、機能拡張時の対応コストが高くなって辛いやつ

“ とりあえず” で使いまわしたアセットが残り続けて想定外の依存関係を生む–プロジェクト後半に最適化等を行うためにアセットを整理しようとした時

に、様々なところに依存が発生していて手が付けられない状態になっていたり…


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


“ 雑に作ってみる” ということ（エンジニア / アーティスト編）

「雑でもいいから見せる事の重要性」を理解する

–全てを言語化するのは難しいし、言語化してもわかりにくいものは可視化す

るしかない

–相手が自分の感覚を正確に理解してくれるという考えは幻想。諦めて手を動か

そう

–だからと言って作り込み過ぎると、ボツになった時に工数的にも精神的にも

辛いから雑で良い

–確認が済んだら、相応のコストを払って作り込む期間を作るのは必須


“ 雑に作ってみる” ということ（ディレクター / ゲームデザイナー編）

「雑に作られていること」を理解する

–目の前にあるものは完成されたものではない。あくまで「形にしてみた」だけ

–作り込むことで良くなっていく部分がある。その辺りは想像力で補う必要あり。

–しっかり作るとコストがかかるのは当たり前。作業者が必要と言ったコストは

もちろん必要

–ここを無視して「ガンガンいこうぜ」をやり過ぎると、プロジェクト後半に身

動きが取れなくなる

–確認が済んで問題なければ必ず GO サインを出すこと。

あやふやなままだと作り込みに入れない


Airtone では初期にプロトタイプを量産し

早い段階でゲームデザインを確立させてい

ます


Airtone プロトタイプ制作過程

https://youtu.be/WswQn7mT7yc

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

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

https://youtu.be/icNy8c9FcKU


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

（ ConstructionScript でプレビュー可能）

分割


三角形が縮む演出は頂点アニメーションで対応

基準位置や移動方向、移動量は

Normal や VertexColor をバッファとして使

用


プロシージャルメッシュを活用することの利点

アーティストが用意するには手間暇がかかる演出の工数を削減できる

ConstructionScript と連携することで柔軟に形状を変化させることが可

能

VertexColor 等をバッファ代わりにして任意のパラメータをマテリアルで

使用できる


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


リズムゲームの醍醐味

音に合わせた背景演出

Airtone 音と演出の同期

https://youtu.be/Wtjdd5LmF6A

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”

http://tips.hecomi.com/entry/20131110/1384096497


記事より引用

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

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

http://tips.hecomi.com/entry/20131110/1384096497

http://aidiary.hatenablog.com/entry/20120415/1334458954


デバッグツール


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


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


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


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


特に VR コンテンツでは、エディタ上のプレ

ビューと

実機で表示される Mip レベルに違いが出るので注

意


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


目線追従メニューだと邪魔

Vive のメニューを参考にした


まとめ


まとめ

限られた工数の中でクオリティを高めるために、 " 最適な完成度 " を目

指す

要件が定まらない場合はイメージを共有するために “雑に作ってみる”

カスタムビルドエンジンを使うメリット / デメリットを理解する

少人数開発で保守コストを払えないなら、できるだけ移行時期を遅らせる

ツール整備、プロシージャル生成で全体のコストを削減する


Airtone は 2017年春発売予定！


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

少人数開発でもクオリティを諦めない -...

Engineering