「UnityでiPhone向け3Dゲームを作る」レポート

本日「3DCGツールとUnityによるゲーム開発実践セミナー」に参加してきました。
そこで講演されたセガさんのUnityを使ったiPhoneアプリのグラフィックの最適化の話が、大変濃かったのでレポートします。

2012 / 02 / 24 07:40 追記
Game Watchさんにレポートが上がりました。写真が豊富でわかりやすいです!
http://game.watch.impress.co.jp/docs/news/20120223_514183.html

講師

  • 株式会社SEGA
    • チーフデザイナー
    • 築島智之

概要

  • セガさんで走っている、Unityを使ったiPhoneアプリのプロジェクトから出てきた、グラフィック最適化のノウハウの総括

レジュメ

  • iPhone4で3Dを快適に動かす方法
    • iPhone4の特徴
    • 最適化の方法
  • シーンの管理方法
  • ゲームエンジンとコンテンツ工学

環境

  • Maya 2012
  • Unity3.5
  • iPhone4(4Sではない)
    • 4で30fpsを保てれば、4S・iPad2では60fps出るくらいの感覚

はじめに

  • Unityのマニュアルに書いてある事は正しい
    • ただし具体例がちょっと少ない
    • マニュアル自体、iPhone3をベースに書かれているので少し古い

iPhone4の特徴

大きなサイズのテクスチャが使える!沢山?
  • ライトマップが普通に使える
  • むしろ頂点カラーに焼くのが駄目
    • 頂点カラーのシェーダ自体が無い
    • しかも作っても遅かった
  • レイヤーテクスチャよりも1枚のテクスチャ
    • ライティングが焼かれた1枚のテクスチャはモアベター
    • 小さいテクスチャサイズを3枚用意してタイリングする手法は遅くなる
    • タイリングした結果を、2048x2048くらいの1枚のテクスチャにレンダリングして貼った方が圧倒的に軽い
  • テクスチャ設定のAniso Level(異方性フィルタ)を上げても、ほとんどコストがかからない
    • そもそもMipmapの設定が無いのでAniso Levelで調整
    • ライトマップを焼くと、デフォルトで「3」が入る。
    • 「6」くらいにしてもほとんど描画コストが変わらない
Retinaディスプレイ
  • アンチエイリアシングしなくても綺麗
    • ほとんどドットがわからない
  • Unity上でちょっとボケたテクスチャでも、iPhone4上では綺麗に見えるレベル
    • 逆に言うと、Unity上で綺麗に見えているテクスチャは豪華すぎる可能性もある

最適化

  • 注意すべきはDraw Call数
    • マテリアル数を少なくする
    • テクスチャ数を少なくする
    • アトラス
      • テクスチャをまとめる
  • どのくらい重い?
    • Draw Call : 200以上
    • Draw Call : 100以上
    • Draw Call : 50あたり
  • Batch数
    • Unityが自動でオブジェクトをまとめた数
      • オブジェクトにある「Static」にチェックボックスをONにしておくと、Unity側でまとめてくれる
      • マニュアルでは「チェックボックスを入れないでください」と書いているが、「アニメーションの再生がされません」という意味で、ニュアンスが違う
    • 多ければよくまとまって、Draw Callが減るが、多すぎると処理が重くなる
  • メッシュの確認方法
    • Unity上でオブジェクトメッシュを選択すると、オブジェクト毎の形状がサムネイル(右下)で見れる
    • ゲームを再生した状態で同じ項目を見ると「Combined Mesh」となり、実際にまとめられたオブジェクトが確認できる
  • 「In Summary Combine, Combine, Combine…」
    • マニュアルの中で太字で書かれている一文
    • ハイエンド向けのTipsとして書かれているが、まとめればまとめるだけiPhone4上でも速くなる
      • Draw Callが減る
  • ただし、アーティストが管理しにくくなってしまうと問題
    • 従来通りMayaでレイアウトする方が良いかも
  • 頂点数
    • マニュアル通り、50000頂点くらいが望ましい
    • "Tris(ポリゴン)"ではなく、"Verts(頂点数)"が重要
    • Hard Edgeを使うと、ポリゴンが分けられ、頂点数が増えてしまう
    • Normal Mapを利用するモデルならば法線の情報が焼かれているので、全てソフトエッジにした方が良い
  • またライトマップを焼き付けた後のポリゴンメッシュは”Normal”のパラメータを"None"にして法線を破棄すると、少しパフォーマンスが上がる
何が処理を重くするのか?
  • リアルタイムライティング
    • 描画面積が小さければ問題ない
  • 多くのテクスチャを参照している
    • 3枚以上は重い
    • レイヤーテクスチャより、むしろ大きい1枚テクスチャ
    • カラー・スペキュラなどを分けて使うとパフォーマンスが下がる
      • Unityの標準のテクスチャでは、カラーのα成分にスペキュラが入っている
    • 極力枚数を減らす
  • フォグは重くなる?
    • 使っても問題ない
    • iPhone3時代の話?iPhone4では問題にならない
    • それよりも、無いと絵作りが破綻する
      • またフォグを利用しつつ、距離でカリングをする事も重要
  • フィルレートが低い
    • フィルレートが高かったハードには出会った事ないが・・・。
    • 半透明は相変わらず危険!
    • 面積がそれほど大きくなければ、エフェクトは結構出る
    • パンチスルー(cut out シェーダー)が重い
    • アルファテスト苦手
処理を速くするための対処
  • まずはカリング
    • 表示しないのが一番
    • カメラの視錐体でカリング
    • 3.5から入ったLODも使える
    • 距離に応じてカリングする処理をスクリプトで実装
    • ゲームデザインでの工夫
      • 一直線で遠方まで見渡せる地形を極力避ける
      • 壁を設け、視線を遮る
  • スキニングオブジェクトを少なく
    • ジョイント数も少なく
    • ただし、動く親子構造のメッシュより、スキニングのメッシュが良い事もある
    • 例:クレーンなどの機械的なオブジェクトで、土台・アーム1・アーム2・爪本体・爪(右)・爪(左)などを分けてアニメーションさせると、Draw Callが「6」かかる
    • Draw Call 100以下を目指す時に「6」取られるのは危険。10個配置すると「60
    • そういう場合はスキニングして1メッシュ化する方が高速。Draw Callが「1
  • 1Skin Cluster, 1マテリアルが理想
    • コンバイン、コンバイン、コンバイン
  • ライトマップは低ポリゴンに都合が良い
    • 地形(Terrain)に家などをブッ刺しても、ライトマップは良い感じに焼けてくれる
      • 頂点カラーに焼く場合は、頂点の流れを考慮しないと行けなかったが
    • 大きなテクスチャが使える事と相性が良い
  • Unity標準のスカイボックスに問題がある
    • テクスチャの圧縮が汚い
    • 立方体でレンダリングするのでDraw Call が「」かかる
    • 従来ながらの半球(全球)が効率が良い
      • Far Clip問題
      • 半球用のカメラを用意し、半球を写しておけば、Far Clipで消え無いようにできる
  • 出来るだけまとめる
    • 配置されている同一オブジェクトは出来る限りまとめる
      • 同じテクスチャ・マテリアルを使っているもの
    • 半透明を使っているオブジェクトは、ソートで問題が出る場合がある
      • ソートはオブジェクトのセンターから行われる
      • プレイヤーが見ない方向に留意しセンター位置を編集
      • 360度見る可能性があればまとめないのも手
iPhone4を大まかにまとめる
  • iPhone4以降のモデルなら、ひとまず3Dモデルを表示してしまう
  • 最適化は常識的な範囲で行えば十分!
    • テクスチャを大きくできる点を活かす

ドンドン出してみれば良いのだ

シーンの管理

エディター・エンジンとは何なのか?

  • 効率アップには絶対に重要な事
    • 繰り返し試せる
    • 作業中と最終結果の見た目が同じであればあるほど良い
    • 似た作業は同じ様に出来る
  • これらの事はコンテンツ工学で決まっている
コンテンツ工学の現状


  • 日本の開発には、コンテンツ工学の部分が抜けている
    • なんとなくツールを使ってそれなりのデータを作成は出来るが、効率的ではない

コンテンツ工学

    • 職人技を一般化。誰でも出来るように
      • 勘に頼る部分を数値化
      • 実際にどういうテクノロジーなのか、どういう手順なのか調べる
      • 客観的な分析
      • 学びやすいように体系的な情報にする
    • これらを工学面でまとめ、コンテンツに応用したもの
  • ゲームに置けるアーティストやプログラマの行っている作業をどうしたら効率が良くなるかを考えて、考えて、考えたものがゲームエンジン

おすすめ書籍

  • 映像コンテンツの作り方:コンテンツ工学の基礎

映像コンテンツの作り方―コンテンツ工学の基礎

映像コンテンツの作り方―コンテンツ工学の基礎

餅は餅屋で

  • Unityには様々なミドルウェアが内包されている
  • 専門部分は専門家に任せて、日本人には日本人の得意分野で戦えば、まだまだいけるはず

以上。

AUJ2011 Dragon's Dogma ゲーム開発事例 レポート

昨日に続いて Doragon's Dogma ( 以下 DD )の開発事例のレポートです。講演冒頭 TGS2011 で発表されたティザームービーが流されました。

2011/09/20 09:00


概要

  • DD 内のアニメーションは、標準体型( 男・女 )のキャラクターで全て制作されている
    • 主人公キャラのエディットへの対応・400種類を越えるNPCへの対応
    • フェイシャル・ボディとも標準体型からの、リターゲッティング
    • Softimage上で組んだエディットシステムをベースに、実機へ移植している

講師

  • 株式会社カプコン
    • ディレクティング室 ディレクター
    • 柳原 孝安 氏

インゲームでのキャラクタエディット説明

MTフレームワーク上でのキャラクターエディットツールの紹介。
下記動画はインゲームのものですが、編集イメージは近いと思います。

体型
  • 身長
  • 頭の大きさ
  • 手・足・胴体の長さ
  • 手・足・胴体の太さ
    • スケール XYZ
  • 足の幅(付け根)
  • 特定部位の誇張
    • 腹を出す・胸を大きく
  • 胸位置の変更
    • 乳首の位置を左右に広げたり

エディット出来る範囲は、ストッパーが設けられており制限がある

  • 眉毛
    • 移動
      • テクスチャのUV値の変更
    • 目全体の大きさ・角度
    • 黒目の大きさは別で調整
    • 左右別々にカラー変更 ( オッドアイも可能 )
    • カラー変更

  • まつげ
    • 長さ
  • 顎( アゴ )
    • 細い・太いあご
    • ケツあごも可能
    • 大きさ
  • その他
    • 顔の下半分を伸ばしたり・縮めたり
      • イメージ的には、クシャおじさん・帝都大戦:加藤
  • 髪型
    • 数十種類のパーツを用意
      • シミュレーション用の骨仕込み済み
      • パーツ毎の大きな変更はできない
    • カラー変更
    • エディットした頭の形に沿う
  • ヒゲ
    • パーツ
    • カラーエディット
    • 顎のエディットに沿う
  • 傷・ホクロ
    • テクスチャのパターンを用意
    • テクスチャデカール
    • 顔にも体にも貼れる
  • 化粧・タトゥー・民族的なボディペイント
    • テクスチャのパターンを用意
    • アイライン
    • カラーエディット
      • パターンを選んだ後色替え
  • エディット補助機能
    • 顔の骨 : 70〜80本
      • それらを一つずつ動かして、顔の編集を行うのは困難
    • 補助機能 : ミラーリング
      • 左右別々でも可能。
      • 独眼なども作れる
    • 補助機能 : 簡易リグ
      • 骨を動かしたら、周りの骨も動く
      • 唇をいじると、頬の肉も連動
      • 目をいじると、頬骨が連動など
ノーマルマップのブレンド
  • 筋肉質 <-> 凹凸が無い ( 脂肪が乗っている )
    • ボディのノーマルマップの強弱で調整
  • 若い <-> 老いている
    • 顔のノーマルマップの強弱で調整
  • 顔は年齢。体は筋肉量。
    • メモリの関係上割り切ったが、必要十分だと考えている
エンベロープの最適化
  • 全ての編集を終え"決定"ボタンを押すと、エンベロープを一体化する
    • エディット専用骨を削減:250本 → 170本
    • 実機上で行う (PS3 / XBOX360)
      • 上記動画(1分50秒辺り)のエディット決定後に行っているものと思われます。

Softimage と 実機へのエディットデータの相互利用について

  • MTフレームワーク上で動作する、キャラクターエディットツールの試作はまずSoftimage上で行った。
    • Softimage上でシミュレートした計算式を、MTフレームワーク上に移植
    • 実機ではIKを使っているので、肘・膝の位置変更はしなかった
  • Softimageでエディットしたものと、MTフレームワークでエディットしたものは同じ結果になる
    • 編集したファイルは .xml ファイルで保存しておく
    • 作業がプランナでも行えるようになった

エディット後のキャラクターにも使い回せる、アニメーションの管理方法

  • 体・顔とも、標準体型( 標準くん )でアニメーションを制作
    • エディット( 体型・フェイシャル )キャラでも使い回しできる
    • 標準体型より目が細いキャラクタにエディットしても、まぶた同士がめり込まない
      • 元の標準顔からの変形値を常に持っており、アニメーションデータに掛け算して再計算
  • キャラクターデザインが決まらず、アニメーションがつけれない状態がなくなる
    • 標準体型でアニメーションを制作すれば、エディット後の動きは保証する
    • DDに登場する主人公・NPCは全て標準体型でアニメーション制作されている
フェイシャルキャプチャ
  • カットインイベントにおいて、フェイシャルキャプチャを使用
    • フェイシャルキャプチャーデータを標準顔にセットアップ
    • そのままでは、アクターと、インゲームキャラの顔の形状が違いすぎる
      • 初期位置の差分をオフセット
      • マーカのトランスレーションだけを利用する
    • アクターの表情の強弱については、顔の部位毎に係数を掛け算
      • 強弱をコントロール ( FaceRobot の Tune のイメージ)

NPC の膨大な数のリップシンクデータの自動生成

  • 今回のセリフ量は150万文字
    • 全てをフェイシャルキャプチャー不可能
  • MTフレームワーク上で音声ファイルからアニメーション作成
    • BATファイルでの処理が可能。帰宅時に走らせておけば、翌日出来ている
アニメーションの使い回し
  • 歩いているアニメーション中に、スケールをかけるデモ
    • スケールしても足がすべらない
    • 大きいキャラは歩幅が大きいので移動距離が長い。逆も然り。
モーションフィルタ
  • 一つのモーションにバリエーションをつける計算式を開発
    • 男らしい <---> 女らしい
    • 猫背 <---> 背を逸らす ( 太った人 )
    • 疲れた <---> 元気
  • 男らしさ・女らしさとは?
    • 単純にガニ股・内股にしても違和感が残る
    • 男らしさとは、任侠映画のイメージ
      • 上半身の動きを抑える
      • 腕の振りを大きくする
      • 腰を落とす
    • 女らしさとは、スーパーモデルのイメージ
      • 鎖骨の動きを大きくする
      • 腰のひねり・横移動を大きくする
  • イメージ優先!
  • モーションブレンドでも同じ事が出来るじゃないか。と言われた事があった
    • 確かに、参照するデータを用意すれば可能ではある
    • ただ、参照するデータ全ての準備・調整などを考えると作業があふれる
  • またベースモーションに変更が生じたら、全てモーションを修正しないといけない
    • アクションゲームなので「ジャンプまで、3f伸ばして」などは開発終盤まで起こる
    • モーションブレンドでは、修正作業が膨大になる

キャラクターエディットできる主人公の体型変更による特殊なイベントツールの説明

  • 注視点と、カメラの位置を変える
    • キャラクターエディットしたキャラクターでも見きれない・めり込まない
      • 注視点は極力ターゲットを見たまま
      • カメラの位置はキャラのエディットを反映
  • 210cmのキャラならカメラも見下ろす。140cmなら見上げるなど大きさにあった演出となる

以上。

AUJ2011「Transformers Prime」制作事例 レポート

2011/09/16 22:00

  • 書き忘れていた「Asset と Shot」という考えを追記

本日、Autodesk University 2011に参加してきました。
そこでポリゴン・ピクチュアズ(以下、PPI)さんが講演された社内制作環境の考え方が学ぶ所が多かったのでレポートします。

概要

PPI がTransformers Primeを受注し、そのために行った社内制作環境の取り組みを紹介。
特に長期に渡るTVシリーズでは不可欠となる「安定した品質」かつ「大量な物量をこなす」手法をピックアップ

講師

PPI

  • 1983年設立
  • 350名前後 ( 60人強が外国人 )
  • 映画・TVシリーズ・ゲームのティザー映像などを制作している
  • 基本、分業制。
    • 分業制はメリット・デメリットあるが、規模を活かす動きを取りやすい
  • 国際的。日本のみならず、海外からの受注も多い
    • 売り上げは、国内が3割、海外が7割
  • タイ・マレーシア・中国にもAsset制作を依頼している。
    • インドも少し。

Transformers Prime とは


  • インターナショナルな配信を前提とした、大型TVシリーズ
  • フルCG
  • 第一シリーズ 26話 x 22分
  • 制作会社 Husbro Studio
    • Hub チャンネルで放映

チャレンジ

物量
  • 572分 = 9.6時間
  • 最初のエピソード納品まで 7ヶ月
    • 普通は1年 〜 1年半
  • プロジェクト完遂のため、最大150名のスタッフが必要な計算

プロジェクト完遂のための課題

Asset と Shot という考え

Asset
  • シリーズ全体を創り上げるために必要な、基本的な素材
    • Model・Texture・Shader・Rig・Display
Shot
  • エピソードを創り上げるための専用素材
    • Layout・Animation・Effect・Lighting・Composite
    • 使い回しは難しい

リクルート

制作人数最大在籍時 150名のうち、100名を新規採用

新規 100名
既存 50名
150名
海外のスタッフ確保での問題点
  • 震災の影響
    • 震災後1週間で、海外メンバーの2割がいなくなった (地震原発)
  • ビザの影響
    • すごく優秀なスタッフでも、ビザがおりない
    • 最近はビザ取得についてのノウハウが溜まってきた
  • 日本の報酬体系
    • 海外とくらべると、見劣りする部分もある
    • 海外に居る時の報酬のままではなく、日本の報酬体系に合わせられる

外部・内部での膨大なトラフィック

  • 情報共有フローの改善
    • メールによるコミュニケーション
    • Excelによる情報集約からの脱却
グループウェアの導入
  • スケジュール
  • 掲示
  • 社内ニュース
プロジェクトWiki
  • 静的な情報共有の場。既に決まっているものを集約する場所
      • 今までは口伝でやっていた所
  • プロダクションの情報をまとめる。
制作管理データベース
  • 動的な情報の蓄積
    • 制作したAsset / Shotの情報を集約
      • このAssetは誰が作った・何処で使われている
      • このShotで使われているAsset
    • 最初は評判が悪かったが、バージョンアップを繰り返し現在はかなりの信頼を得ている。
    • もうTransformer Primeシリーズでは無くてはならない
タスク受発注チケットシステム : Redmine
  • メールにかわるシステム
    • 情報の見える化・一覧
    • モデル班へのチケットをフォーマット化し、メールベースの手間を削減
    • やり取りのログ化
  • Redmineのカスタムはほとんどしていない
スーパーバイザー・ディレクターによるレビューの高速化
  • 作業の中で"画"を作っている時間は短い
    • 一番時間を取られるのが、チェックでのやり取り。
  • PPIテイクサブミッションツールの開発
    • チェック用のAEで作って、スーパーバイザーにお伺いを立ててチェックしてもらう工程をなくす。
    • 所定のスレッドへジョブをなげ、データベースにその旨を記入。
    • レビュー用に "RV"という再生ツールで行われる

大量生産可能な制作体制

ディレクトリ構造の改革
  • PPI、29年間の中で真剣に考えたことがなかった
    • 150人の人間が、それぞれ好きにディレクトリを作っていてはお話にならない。
  • 大元のフォルダをユーザーで分けるのでは無く「Asset」と「Shot」で分ける
大別層 エピソード・カテゴリ シークエンス ショット 目的別 デパートメント ユーザ アプリケーション プリプロジェクト層

PPI ディレクトリマネージャ
  • 上記、ディレクトリ構造を自動生成するツール
    • GUI上で任意の項目を設定し、ボタン1つで自動生成
ルックデブ (Look Dev) ステージの導入
  • 今まではシェーダを作る人が居なかった
    • ライティングの過程で、シェーダとライティングが調整されていた
    • 結果、ショット毎にシェーダが変わっていた
  • Look Devでのシェーダー管理の一元化
Beauty Pass方式
  • 一発レンダー。
    • マルチパスに分け、コンポジットでの合成をやめる
    • 素材管理の手間と、品質のばらつきを抑える
    • ショット毎のバラつきを無くす
  • 見た目は、Look Devが保証したものがでる
PPI レンダーシーンマネージャの導入
  • 新しいShotシーンを始める時に、モデルを読み込んで、ライトを読み込んで・・・、という手間を省く
    • Mayaシーンのテンプレート化・アラカルト化
    • Mayaライティングシーンセットアップ時間を短縮
コンポジットを After Effects から NUKE へ移行
  • NUKEを使えば素晴らしいクオリティが!ではなく、効率化のため。
  • ノードベースのコンポジット
    • テンプレート化しやすい
    • 一目でわかる
    • テンプレートとギズモ、をスクリプティングでゴニョゴニョしている(書き取れませんでした・・・。)
  • 「他人の作った After Effets シーンを渡されて、パッとみてわかります?」
マットペイントの最大活用
  • 今までの PPI ではあまりなかった。
    • 今回からマットペイントデパートメントを作って、メンバーを集めた。
  • マットペイントに置き換える所
    • 3Dで作っても費用対効果に見合わない遠景
    • 一瞬しか映らないもの
  • 背景制作にかかるコストを削減
SMOKEによる、ポストプロセスの高速化・高度化
  • リテイクを3Dステージに戻さないために導入
    • 3Dのメンバーは次の作業を行っているので、そのまま戻すとボトルネックになる
  • SMOKEをいれて、期待以上の効果が出た
  • 現状はSMOKE使いは一人。それでも回っている。
    • 今後アシスタントを一人増やそうかと検討している。
  • 「お金があるなら入れた方が良い。非常にオススメ!」
ステージの完全分業
  • ステージの完全分業ということで、モデラー・アニメータ・リガーなどをステージ(セクション)で分かれている。
  • その中でも、特に特殊なステージ「Electric Display」「変形」の紹介
Electric Display
  • SF世界・基地に登場するモニターに映る映像を制作するメンバー
    • 現状:3人
変形
  • トランスフォーム(変形)のアイデアを作成する
  • 3日で変形パターンを1つ作成する

課題

  • 円高
    • 受注当初よりドル円レートが14%程度下落している
    • ドルベースでの支払いを交渉して、少しましになっているがそれでも厳しい
  • 人月・工数削減
    • コストの低い、海外に外注
  • 経験値
    • 受注当初よりも、メンバーの作業スピードが上がっている
    • PPIメンバーのモチベーションが高い
      • 上手く導けば円高が進もうと相殺できるのではないかと期待している

所感

業界も会社の文化も違うので、そのまま取り入れて効果が出る部分は少ない。ただ、自社の環境と作るタイトルから導き出した制作環境を作るまでの道のりは学ばないといけない所。早速自プロジェクトでも、再度非効率な点を洗い出し、改善に向けて動いてみる。(会社のレポートみたいな…。)

CEDEC 2010「ネットワークゲーム開発における構成管理ソフトの活用方法」

今回はSEGAさんのPERFORCEの導入事例のセッションをレポートします。

ネットワークゲームのデータ管理の複雑さと、PERFORCEとその他のソフト(静的解析・BTS・自動ビルド)との連携などなかなか興味深かったです。

ではレポートです。

概要

ファンタシースターシリーズでのPERFORCEの導入と、その他のソフトとの連携

  • なぜ構成管理ソフトを導入するのか?
  • PERFORCEを採用した理由

はじめに

セッション最後の質疑応答であった、PERFORCEと連動しているツールです。レポートに出てくる各種ツールは以下のものになると思います。

連動しているツール

なぜ構成管理ソフトを導入するのか?

導入のきっかけ
構成管理ソフトとは?
  • バージョン管理ソフトと、構成管理ソフトとどこが違うのか?
    • 成果物の制御や変更管理・ワークフロー管理なども行う
    • ビルド環境の構築のコアとなるツール
      • プログラムのソース・デザインデータ・企画パラメーターなども一括管理
      • デイリービルドも行える
    • 成果物の状態を把握し、任意のバージョンを再現可能とする
      • 日付を指定しての再現・バグのない状態への巻き戻りも容易にできる
通常のゲームのタイムライン

ネットワーク開発において
  • ゴールは一つではない(運営が終了するまで)
  • しかも同時に別の道を走らなければならない
  • しかも、同時に別の道を走らなければ
  • それも"全力疾走で"
ネットワークゲームのタイムライン

ネットワークゲームで不具合が発生した場合


  • 並列に複数のバージョンを作成する環境の構築
  • 緊急事態への迅速な対処方法の確率
  • 取得・サーバアップなどの処理時間の軽減
  • チェックの効率アップやバグの減少
構成管理ソフトの再検討
  • 継続的なインテグレーション環境
    • ビルドとテストを自動で行う環境の構築
  • バグを減らすためのツールの導入
  • 作業タスクの把握と変更管理
  • チェック体制の見直しとツールでの補完
要求
  • ブランチとマージ機能の充実
  • 修正項目の把握と管理ができる
  • 速くて軽くて簡単に扱える
  • 他のツールとの連動ができる
    • BTS・静的解析・タスク管理ソフトとの連携
選定候補
  • PERFORCE
  • AlienBrain
    • データが大きくなりがち
    • 全体的に処理が重い
    • ブランチ・マージの機能が求めるレベルではなかった
    • アーティストが使うデータ(画像など)のビューアが充実している
      • アーティスト間のデータのやり取りには使われている
  • Subversion
    • データが増えると重くなる
    • バイナリデータの扱いが苦手
    • ブランチの機能が弱い
      • ファイルを丸々コピーしてしまう
    • ".svn"フォルダが生成されてしまう
      • そのまま360のデータフォルダに入って問題になったことも
  • Git/Mercurial/Bazaar(分散バージョン管理)
    • Linuxベース
    • Windows GUIが用意されていない
    • 日本語対応※
    • プランナ・アーティストに使ってもらうには、使いづらい
  • ココの比較記事も分かりやすいです
  • ※セッション後に聞いた話では、Gitなどでもビューアや、GUIツールが対応されれば、全然使えるような事も言われていました。

PERFORCE 決定理由

  • 軽い・速い
    • 採用理由の大半がここ
    • 40GBのデータを1回でコミット出来たのは、PERFORCEだけ
      • 他のソフトは途中で止まる
      • 分割してコミットするなどして、対応しないといけない
  • Linuxでも、Windowsでも使える
  • サーバのセッティングと管理が楽
  • ブランチの機能が強力
  • GUIのクライアントが存在する
  • ソースとデータを同一に管理できる
  • 日本語対応されている
  • サポートが受けられる
    • 社内でサポートする必要が減る
運用
  • ソース・データともにPERFORCE
    • リポジトリにアップするようにした
    • プランナ・アーティストにも直接サブミットをしてもらう
    • チェンジリストで作業を管理する
    • マイルストーンごとにブランチを作成
    • 2〜3のブランチを同時並列で開発
活用
  • 並列作業となるパッチ作成に活用
  • ローカライズ対応
  • 他機種への移植
  • ゲームショーなどのプレゼンROMの対応
Tips
  • サブミットする単位は一つの変更毎に行う
  • サブミットコメントのフォーマットを揃える
  • ブランチするタイミングを見極める
  • ブランチのブランチは作らない(メインラインパターン)
  • Excelとの差分が取れないので、インハウスツールを作って対応する
利点
  • プラグインが充実
    • googleでも採用している
    • WEBで検索すれば結構出てくる
  • 補完機能が便利
  • オフライン機能を使うと、簡易分散型のような使い方もできる
  • リビジョングラフが、分かりやすくて便利
  • ラベルが速くて軽い
    • ほぼ一瞬
    • 容量も1KBくらい
    • 自動ビルド作成時、毎回ラベリング
要望
  • 日本語対応P4V(GUIツール)のバージョンアップを速くしてほしい
    • 日本語のリリースが、英語版と比べて半年程度遅れる
  • コマンドラインの機能すべてをGUIツールがサポートしていない
  • 他の構成管理ソフトとの操作の違いをフォローして欲しい
開発環境の紹介
  • Hudsonを使って、継続的インテグレーション環境の構築
    • 日本語環境に対応している
    • PERFORCEのプラグインがあった
  • 常時サブミットを監視してビルドを行う
    • 専用PCを設置、自動ビルドを行う
    • 出来たものは成果物として、サーバにアップする
  • バージョンを指定しての成果物作成が可能
    • 以前のバージョン・日付を指定して再現することが出来る
  • IRCを使ってビルドの要求と結果の通知
    • 各職制でIRCのチャンネルを持っていて連絡・質問などを行える
    • 自動ビルドの結果はそこに通知される
      • またIRCにコマンドを入れることで、自動ビルド環境のコントロールも出来る
  • 静的解析ツールとの連動
    • 毎晩、静的解析ツールを回している
    • 毎朝、引っかかった部分は各自の所に結果が届く
  • タスク管理システムやBTSとの連動
    • サブミットのコメントに、BTSやタスク管理システムにリンクを貼る
    • PERFORCEのチェンジリストの番号を、BTSのタグを貼ったりできる

まとめ

  • リリースに必要なファイルは全て管理しよう
  • アーティスト・プランナにも使いやすい環境を整備しよう
  • 変更管理をしっかりしよう
  • 様々なツールを連動させよう
  • より良い環境になるように、みんなで工夫しよう

ひとまず、これでニュースサイトに上がっていないセッションのレポートは、いくつか補完できたでしょうか。もうそろそろCEDECアーカイブが公開されるはず(?)なので、それまでの繋ぎ情報になると思いますが、活用していただけるとありがたいです。

あとマズい情報など載っけてしまった時は、お手数ですがご連絡ください。すぐに対処させていただきます。

では。

CEDEC 2010「Q-Games流アジャイル開発手法:PixelJunk での実践例を紹介」

今回はQ-Gamesさんアジャイル開発手法のセッションまとめます。

このセッションでは、Q-Gamesさんが開発手法としてアジャイルを取り入れた経緯と、取り入れた後の問題点を紹介しており、その変遷での試行錯誤の内容に共感出来るところが多かったです。う〜ん、うちもあるなぁと…。

ではレポートです。

概要

Q-Gamesでのアジャイル開発手法をPixelJunk 最新作を例にして紹介

Q-gamesの会社紹介

関わってきたタイトル
  • Nintendo案件
  • PixelJunkシリーズ
    • Racer
    • Monsters
    • Eden
    • Shooter
  • R&D
人数の比率
  • 社員数:37人
案件 比率
Nintendo 50%
PixelJunk 40%
R&D 10%

Q-gamesの開発スタイル

実際にプレイして判断する
  • 良いところを見つけて残す
  • 悪いところを見つけて除外する・または変更する


 →イテレーションをひたすら繰り返し、ゲームを完成まで持っていくのが、Q-Games流の制作スタイル

問題点
  • 当初の仕様や計画通りには進みにくい?
    • ただし、実際に遊んで感じた結果の方が重要
  • 無駄な実装が多くなる傾向?
    • 面白くなるためには、無駄も必要なプロセス

アジャイル開発の試みと必然性

  • イテレーション
    • 実装物による検証の繰り返し
    • スクラムミーティング(朝礼)
    • これらはアジャイルを知る前から、似たような事をやっていた
  • Q-Gamesは元々、タスク管理にMantisを使っていた
    • Webベースのバグ管理システム
    • スタッフの作業タスク管理に利用


 →元々アジャイルを導入する土壌があった

Mantisの特徴
  • 無料
  • 処理が高速
  • 検索条件が多様(絞り込み)
  • セキュリティが高い
  • ロードマップが定義しやすい
  • タスクの親子関係・関連付けがしやすい
  • ツール自体のカスタマイズがしやすい
    • 社長のディラン自ら、カスタマイズしている
Shooter2以前の課題点
  • マイルストーン式なので、最終チェックまでのスパンが長い
  • タスクの割り振りが外部依存になりがち
    • Q-Gamesではプランナーがほぼ全てのタスク入力を行う
  • タスクが多すぎて、精神的プレッシャーが大きくなった
  • 管理側がスペックの実装漏れに気づきにくい
    • 調子にのって入力していると、管理側が見落とす事があった


 →そこで、Q-Gamesなりにスプリントを導入

スプリント導入意図
  • 2週間分のタスクだけに集中出来るので、タスク過多による精神的プレッシャーが減る
  • 2週間ごとに成果物が出来上がるので、イテレーションが早くなる
    • 開発の軌道修正がしやすい


 →クオリティと、作業効率アップが期待できる

スプリント運用プロセス


  • Mantisのロードマップ機能
    • スプリントごとの進捗を確認するのに便利
  • Mantisのカスタマイズ
    • スプリント用に"予定工数"の項目を追加
Shooter2のスプリントタスク
  • 現在、16スプリント経過したShooter2での3つのフェーズ

スプリント運用で発生した問題点
  • タスクをこなす事に慣れ常態化
  • スプリントの定義を混同
    • 達成すべきタスク = ゲームの目的になってしまった


 →本来は品質的要求仕様(Quality)をスプリントの目的として設定するべき

今後の課題と取り組み


モジュラーディレクションシステムの導入

  • ディレクター・アシスタントディレクターは職種に関係なく選ばれる
    • 担当箇所のクオリティについては、完成までの責任をもつ
    • 他のスタッフからの提案。報告の管理を行う
    • 職種に関係なく選ばれる
      • やはりポイントは人選
スプリントの流れ
  • モジュラーディレクションシステムが有効に周りだした
    • 結果”2週間のスプリント期間は長い”となり、1週間に変更

まとめ

  • Shooter2以前の体制では問題が多かった
    • 最終チェックまでのスパンが長い
    • 見えるタスクが多すぎる
    • タスクを見逃す事も多い
  • 改善案として、スプリントを導入
    • タスクの消化が目的となり、モチベーションが上がらない
  • モジュラーディレクションシステムの導入
    • 任天堂さん案件で成果が出ている


 →まだまだ改善途中、今後も他社との交流の中で、新しい体制を模索していきたい

Q-Gamesさんのレポートは以上です。

次は、セガさんのファンタシースターシリーズでのPERFORCE導入事例を書こうかと思います。あのセッションもタメになりました。