先日参加した「3DCGツールとUnityによるゲーム開発実践セミナー」のレポート、2つ目です。先日のSEGAさんのレポート同様、実践的で非常に濃い内容でした。こちらのレポートもGamewatchさんの記事と合わせてご覧いただくと、セミナー内容がうまく補完できるかと思います。
- GameWatch - オートデスクとUnity、「3DCGツールとUnityによるゲーム開発実践セミナー」開催
追記:2012年2月28日(08:00)
- Insideさんにも記事が掲載されていました。写真も豊富で素晴らしいです。
プロジェクト概要
- スケジュール
- 2010年末 企画提案
- 2011年1月 開発スタート
- 目標:短期間・低コスト・成果
- 早い・安い・うまいを目指したプロジェクト
ゲームの内容
- 手芸の一つ、編みぐるみ・ぬいぐるみをスマートフォンで手軽に楽しむ事が出来るアプリ
- https://market.android.com/details?id=jp.gree.android.pf.greeapp3130
チームの目標
- 早い
- 早く結果を見てもらえる
- 自社ブランドでの開発となったので、短期的に成果を見せる必要があった
- 安い
- 予算が少ない
- うまい
- やりたい事が実現できる
初期メンバー
※D = ディレクター、PL = プランナ、PG = プログラマ、GD = グラフィックデザイナー、TA = テクニカルアーティスト。
(2012年3月4日 22:40コメント欄で頂いた内容を元に修正しました。)
必要要件
- リアルに見える
- 編みぐるみ・ぬいぐるみを実際に触っているように感じる質感表現
- リアルに揺れる
- ラグドール演算
- 自由に作れる
- かわいい(必須)
開発環境
- Autodesk Maya 2011
- Unity2.1 〜 2.4.2
Unityを選択した理由
モデルパーツの作り方
- 全てYupで制作
- ゲーム中に編みぐるみをエディットするため
- 手・足などのパーツは、胴体パーツの各頂点の法線方向に向く仕組み
マテリアル
- 全てのマテリアル設定はUnity上で行った
- 使用したのは、Strumpy Shader Editorアセット
- http://u3d.as/content/strumpy-games/strumpy-shader-editor/1C4
UI
- 通常のUIはEZGUI、リッチなUIはMayaで制作
- なぜEZGUIなのか?
- Unity標準のGUIテクスチャーでの不都合
- 複数の画面解像度・縦横比に対応が困難
- 表示が崩れる
- マテリアルがまとまらない
- 同じテクスチャを利用していてもDynamic Batchingが働かずDraw Call数が増える
- EZGUIの利点
- オブジェクトが3D座標上にセットされる
- 解像度・縦横比に依存されない
- マテリアルをまとめるとDynamic Batching が働く
- Draw Call 数軽減
- MayaでのUI制作
- 動きの多いメインメニュー画面(地球)は全てMayaで制作
- 各オブジェクトの挙動はMayaで制作したアニメーションを流す
テクスチャの容量削減
- アトラス
- アプリ本体の容量軽減のため、複数のテクスチャを一つにまとめる
- アトラスの問題点
- 特定のテクスチャしか使っていないシーンでも、まとめた大きなテクスチャを読むようになりロード時間増大
- 一部のデータ修正でも、まとめたテクスチャ単位で更新が必要になる
- Asset Bundlesの使用
- 特定のデータをアプリ内に持つのではなく、サーバーなどに置いておく
- 実行中にデータをサーバに読みに行く
- Ragdollではシーン毎にAsset Bundles を作成
- ダウンロードしたAsset Bundles はローカルに保存
- アプリの起動時に更新を確認し、更新があればそのデータだけをダウンロード
- アプリの更新をする事なくデータ更新が出来る
- Asset Bundlesの注意点
- アプリを起動したUnityのバージョンと、Asset Bundles を作成したUnityのバージョンを揃えないといけない
- アプリ側のUnityをアップグレードした場合、Asset Bundles のデータも全てビルドしなおし
シーン分け
- Unityを使った共同開発ではシーンの競合が問題になる事が多い
- Ragdollでは開発初期から気をつけていたので、大きな問題にはならなかった
- シーンを読み込んだ時に、別のシーンを追加で読み込む機能がある
- プログラマが使うシーンに、アーティストのシーンを追加読み込みする
- EZGUIを導入後問題が発生
- EZGUIでアトラステクスチャを更新した際、別のシーンに配置しているEZGUIを使用しているPrefabのコンポーネント情報が更新されない
- アーティストによる更新が必要となる
- 手間の増大
- ヒューマンエラーの発生
- 対策
- アーティストはPrefabをシーンに置くのをやめる
- Prefabの用意までをアーティストの作業とする
- プログラマはシーンの追加読み込みではなく、Prefabを直に読み込むように変更
ライティング
- Unityはスマートフォンでは、シャドウマップをサポートしていない
- Blob Shadow Projector での丸影実装が現実的
- パフォーマンスも申し分ない
- Pixel Light Count の最適化
- ライティングの負荷が高い場合Pixel Light Count を減らす
- 大幅な処理負荷減
- Rag Dollでは、ノーマルマップの見え方の違いもほとんど影響なし
MayaからUnityへのデータ渡し
- FBXを選択
- Mayaがインストールされている必要がある
- Mayaからは.maファイルのインポートも選択出来るが、インポート時間がかかる
アニメーションデータの容量削減
- Unityに読み込んだアニメーションFBXは、アニメーションクリップだけ複製し抜き出す
- 抜き出した後のデータは削除する事で無駄なデータを省く事が出来る
※Gamewatchの記事のプレゼン資料が詳しいです
- データを更新する毎に上記作業をするのは面倒
- Asset Post Processorクラスの関数を利用し自動化した
Maya・Unity以外のツール
- パラメータの編集にExcelを使用
- プランナーはUnityを使用していなかったため
- プランナーがUnityを使う場合は、パラメータを拡張して使ってもらう方が良いと思う
- Unityだけで完結できるし
- バージョン管理はSubversion
- 1.6以前
- 各フォルダに隠しフォルダで管理フォルダが作られる
- Unity上でフォルダを複製すると、管理フォルダ毎に複製され不具合が発生する
- 1.7以降
- チェックアウトフォルダのみに管理フォルダが作られるようになった
- Unityでも使いやすくなった
Unity・Mayaへの要望(Ragdoll開発で感じた両ソフトの強化要望)
- 受け渡しフォーマットの強化
- Mayaから直接Unityで利用できるAssetの書き出し
- またUnityで利用しているAssetを、Mayaへインポートする機能
- Asset Bundlesのバージョン互換性
- Unityのバージョン違いでAsset Bundlesが読めない問題を解決
- Ragdoll開発中に何度か泣かされた
- 3.5から機能が拡張されたが、モバイルプラットフォームでは利用できない
Unityを使って良かったところ
- 開発力・チーム力の向上
- すぐに絵が出るので、レビューを受けやすくなった
- ゲームを見ながら、あーでもないこーでもないと意見を交わせる
- 実装までの速度UP
- コミュニティ
- コンシューマー開発環境に比べると、開発環境・ノウハウについての情報が多い
- FacebookのUnity助け合い所に業務中に書き込んで、解決する事もあった
Unityを使って良くなかったところ
- Unityで何でも出来るわけではない
- 自動化ゆえの不具合
- Unity自身の向き・不向き
- プロジェクトに必要な遊び・表現ができない事も
- お金を動かす人は「すぐできるんでしょ?」「お安く買えるんでしょ?」と言いがち
- それを開発側はそのまま受け入れるのではなく、やりたい事とUnityを使う事の相性は見極めないとダメ
- Ragdollでは早い・安い・うまいを全て達成できていない
- 特に早いに関しては達成できていない
- プロトタイプまでは早かった
- ただプロトタイプからリリースまでにはバグ対応・やりたい事が出来ないなど、いくつか障害があった
まとめ
- Unityは画材。作りたいものが明確でUnityに最適な内容であれば問題なく使っても良いと思う
以上。