ゲームの花園

「Ragdoll」開発事例〜MayaからUnityへのアプローチ〜 レポート

セミナー, Unity

先日参加した「3DCGツールとUnityによるゲーム開発実践セミナー」のレポート、2つ目です。先日のSEGAさんのレポート同様、実践的で非常に濃い内容でした。こちらのレポートもGamewatchさんの記事と合わせてご覧いただくと、セミナー内容がうまく補完できるかと思います。

• GameWatch - オートデスクとUnity、「3DCGツールとUnityによるゲーム開発実践セミナー」開催
  • http://game.watch.impress.co.jp/docs/news/20120223_514183.html

追記：2012年2月28日(08:00)

• Insideさんにも記事が掲載されていました。写真も豊富で素晴らしいです。
  • http://www.inside-games.jp/article/2012/02/24/54785.html

講師

• 株式会社マトリックス
  • コンテンツ事業部デザイン開発
  • 主任
  • 高崎奈美

• 株式会社マトリックス
  • コンテンツ事業部技術開発課
  • 杉浦祐輝

概要

2010年末からUnityを使用し開発を続けてきたノウハウと、Androidアプリ「RagDoll」開発事例

レジュメ

• プロジェクト構成
• ワークフロー
• チーム構成
• デザイナ
  • モデリング・シェーダ・モーション・メニュー・フォント
• プログラマ
  • スクリプト・シェーダ・メニュー・シーン管理

プロジェクト概要

• スケジュール
  • 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を選択した理由

• ”速い”が実現できる
• 予算
  • スマートフォン開発が初めてだった
  • Unityともう一つ候補となるエンジンがあった
• やりたい事が出来る
  • リアルに見えるという用件から、シェーダーがカスタマイズできる必要があった
  • もう一つの候補はシェーダのひな形を選択する事しか出来なかった
• DCCツールに似たGUI
  • アーティストにも敷居が高くない

モデリング

• Nurbsでのモデリング
  • 均一なUV
    • 編み目・縫い目が同じ幅で入り均等に表現できる
  • 版権キャラの丸みの表現
    • リテイク時の容易な対応
  • 最終的にはポリゴンに変換しエクスポート

モデルパーツの作り方

• 全てYupで制作
  • ゲーム中に編みぐるみをエディットするため
  • 手・足などのパーツは、胴体パーツの各頂点の法線方向に向く仕組み

マテリアル

• 全てのマテリアル設定はUnity上で行った
  • Mayaで設定したマテリアルの詳細な情報はFBXでは転送できなかった
  • Mayaではマテリアル数に分けるのみ（クラスター分け）
  • モデリングも仮のマテリアルで行った

• 使用したのは、Strumpy Shader Editorアセット
  • ノードベースのシェーダーエディター
  • アーティストがシェーダを発注し作成
  • ただしこのツールで作ったシェーダはモバイルデバイスでは重い場合もあった
    • 重いシェーダーは手直しして使用
    • Unity標準のシェーダーも利用する
  • また版権キャラクターなどはFurシェーダーを専用で用意する事もあった
• 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では開発初期から気をつけていたので、大きな問題にはならなかった

• 各場面毎に2つのシーンを用意
  • プログラマが使うシーン
  • アーティストがGUIを配置するシーン

• シーンを読み込んだ時に、別のシーンを追加で読み込む機能がある
  • プログラマが使うシーンに、アーティストのシーンを追加読み込みする

• 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ファイルのインポートも選択出来るが、インポート時間がかかる

モデル・アニメーションデータの持ち方

• アニメーションデータにメッシュを持っていると、うまく行かなかった
  • メッシュを付けず、Locatorをつけると解決できた

アニメーションデータの容量削減

• 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に最適な内容であれば問題なく使っても良いと思う

FAQ

Q,他のセミナーに参加時に聞いた話で、EZGUIの中にバグ（ボタンの押下時のタイミング）があるらしいがRagdollではその辺りどうだったか？そのセミナーでの解決法はEZGUIの中身を見て、バグ取りをしたという事だった。

• A,同様のバグが出て、一部中身を編集して直した。
  • ただ大きな問題にはならなかった。

Q,EZGUIで制作したGUIと、Mayaで制作したGUIの切り分けはどのようにやっていたか？

• A,EZGUIでレイアウトが複雑になるもの、アニメーションが豪華なものはMayaで行った。
  • 通常のGUIはEZGUIを中心に行っている。

以上。

Permalink | コメント(2) | トラックバック(0) | 23:12