この前のエントリーで書いた、BungieがGDC2009で講演したプレゼンテーション資料を読み終えましたが、新鮮な内容で面白かったです。
Bungie流のプロダクションの作り方に関するPPT
※下から2つ目。Download articleで、PPTファイルが落とせます。
内容は、HALO 1 〜 HALO 3を制作していく過程で、開発スタイルがどのように進化してきたのか、Bungie流のプロダクションの作り方を解説したものとなっています。ゲームのクオリティも譲れないけど、開発者の生活も大切。その時、Bungieでは、どういう取り組みを行ってきたのか。といったものになっています。
ちょうど今、地球の反対側ではGDC2010が開催されているので、ものすごく旬を過ぎた感が否めないですが、簡単にまとめてみました。
はじめに
Halo3では、それまでの体制から脱却を図り、プロダクションの効率的な運営を目指してきた。これより語られる内容は、それまでのBungie独自の文化が根づいているプロダクションに、どのように新しい手法を浸透させていったかのケーススタディです。
今までのHalo1と2での体制は
- Halo1・2制作時のスタッフは現在よりもずっと少なく、プロデューサーの役割も違っていた。
- Halo2の開発時は、1日12〜14時間作業を行い8カ月間の間、ほぼ無休の状態に陥いっていた。
→結果として、チーム全体の雰囲気も、各メンバーのメンタルもボロボロ
改善するために
メンバー構成
- 2005年9月ごろの体制(Halo3：開発初期)
- プロデューサーが3人いたが、全員ゲームを把握できていなかった
Team Size 75 Producer 3
- 2007--9カ月の船までの1月頃の生産配置。
- 6人に増やしたが、ゲーム全体を把握できていなかった。
Team Size 110 Producer 6
- 2009(Halo3 : ODST)
- 最終的には11人体制で、プロダクションの管理
Team Size 150 Director 1 Executive Producer 1 Senior Producer 3 Producer 3 Assistant Producer 3 Bungieで採用した手法
- 品質優先 (By focusing on Quality First)
- 開発者優先 (By focusing on People First)
- 状況に適応する (By being extremely Adaptable)
品質優先 (QUALITY FIRST)
開発者は皆、最高のゲーム体験を作りたいと思っている。
ただし、全ての仕様の実装ができるワケではないし、そんなに予算もない。スケジューリングへの柔軟なアプローチ
- 我々は、いつも開発の終盤でスケジュールを破綻させてしまう。これでは、その後の対応が出来ず、中途半端なものを世に送り出すことしかできません。
早い段階での選択と集中 例: FORGEモード
FORGEの最初のバージョンは、発売6ヵ月前までオンラインで遊べませんでした。
- ただこのモードは、ゲームデザインチームが長い間考えていたものだという事と、このゲームに必須となる要素だと確信があった。
- なので、我々は他のコンテンツを作っているメンバーをFORGEの制作のために連れてきた。
- また仕様についても、重要な部分を残して、多くの細かい仕様（そのほとんどはUIでした）は切られたか、スケジュールの後ろに回されました。
→結果：製品には実装でき、出荷1年半後でも、ユーザーが新しいマップをシェアし、、オンラインであると遊んでいるので、この決定はうまく行ったように思う。
ゲームをブラッシュアップする作業を削らない
私たちは、Halo2までの経験から、ゲームには必ず磨きをかける期間(調整期間)がなければならない事を学びました。
- この期間は、スケジュールでは変動しては行けない重要な要素です。
- 1人およそ2〜4週。これは少なく出来ない、必ず必要となる期間です。
- それは非常事態のために使われる期間ではなく、ゲームを磨き上げる時間です。
→作業が終わっているだけなら100%でしかなく、磨きをかけてそれ以上を目指します。
事前に計画されたクランチタイム(追い込み期間)
クランチタイムは、チームの意識を1つにする事も、または分断させる事もできる要素です。長時間の労働をいとわない、ストレスの掛かる期間なので、下記の要素が重要になってきます。
- チームの意識を一つにするポイント
- クランチタイムが事前に伝えられている事
- メンバーに理解される期間
- 共有される終わり(ここまでやれば終了。となるチームとしてのゴール地点)
→短いクランチタイムは、チームの士気と結束力を構築することができる方法であり、使い方によっては非常に有意義な期間となる。
役に立たないクランチタイム
- 予定していた期間から長引いている
- 「ここまでやれば終わり」と言う、明確なゴールが用意されていない
- 進歩している、明確な形跡がない
→クランチタイムが上手く使えていないのは、プロデューサーの責任
開発者優先 (PEOPLE FIRST)
人々の暮らしや幸せこそが最も大切。チームメンバーは、我々の家族。
→既にマルチプレーヤー部門などは、有効性を確立していましたが、全てをカバーしきれているワケではありませんでした。
適応性のあるプロジェクトマネージメント
- 品質重視(Quality)と、開発者優先(People First)を中心に考える。
開発サイクルの6つの主要なフェーズ
- コンセプト段階：ゲームはどういうものか？訴えかける他。
- プリプロダクション：概念を証明して、楽しみを見つけてください。
- プロダクション（量産）：ゲーム、繰り返し、繰り返しを構築すること。
- ブラッシュアップ（調整）：このダイヤルは、11へ行きます。
- リリース：出荷
- 計画の継続：DLC、Expansions、Bungie.Netコミュニティのサポート
→この考え方を中心にマイルストーンを設定
という感じでまとめてみました。
この体制はBungieやから、できるんやろうなぁ？という部分もありますよね。
ただ「開発者はみんな、ゲームを最高のものにしたいと思っているのは当然だし、プライベートなスケジュールがあるのも当然」と言う前提に立って、じゃぁそこで、みんなが納得するような、スケジュールを設定するにはどうするのか？と言うところを、きっちり見据えた考え方には、惹かれるものがあります。個人的な経験では、最初からどちらかの判断(どちらも無い…)で進んでいる事が多いなぁと。
スケジュールを立てる時に、"ゲームの品質"と"開発者の環境"を両立させる手法。今まで、そんな風に考えた事も無かったのですが、気持ちだけは実践出来そうです。
