●トップデベロッパーが舞台裏を明かす！
2011年9月6日〜8日の3日間、神奈川県のパシフィコ横浜・国際会議センターにて、ゲーム開発者の技術交流などを目的としたCEDEC（コンピュータエンターテインメントデベロッパーズカンファレンス） 2011が開催されている。
2日目となる9月7日には、Epic Games提供のセッションが3本連続で行われた。言うまでもないが、Epic Gamesは『ギアーズ オブ ウォー』シリーズや、そのゲームエンジンであるアンリアルエンジンを手掛ける北米のトップデベロッパー。まだ発売されてもいない最新作を例に開発手法を公開するセッションもふたつあるということで注目度も高く、決して大きい部屋ではないとはいえ、3本とも立ち見が出るほどの超満員だった。
ここでは、エピック・ゲームズ・ジャパンの下田純也氏と、『ギアーズ オブ ウォー 3』のシニアレベルデザイナーであるグレイソン・エッジ氏、そしてゲームプレイプログラマーのニック・ホワイティング氏による講演で、Epic Gamesがどんな意識でゲーム開発を行っているかをお伝えしよう。
 |
 |
 |
●プロトタイプを素早く作り、よりおもしろく、被害は最小限に！
3人に共通していたのは、プロトタイプ制作によるコンセプト検証を重視していたこと。たとえば下田氏は、アンリアルエンジン導入のメリットとして、開発中のゲームのアイデアをすぐに形にできることで、（実際に見せたほうがわかりやすいことで）企画を通しやすくなったり、本制作への移行が容易であるといったことを挙げていた。
現在主流の市販ゲームエンジンでは、仮素材を使ってエディター上に配置していくことで、すぐに動作するものを作ることができる。下田氏は数時間で制作したTPSの簡単なデモを見せていたのだが、この制作手順がおもしろい。テンプレートをロードした時点でもう平面の上を一人称視点で歩くことができ、Unreal Tornamentのテンプレートを呼び出せば銃も撃てる。カメラを書き換えて三人称視点にし、敵を生成する機能を呼び出し、さらに敵を増やし、作りおきの素材であるドラム缶を置き、岩を置き……とやっていくことでそれっぽいTPSが完成。
もちろんこのままでは「ただのTPS」でしかないので、実際にはアンリアル・スクリプトのコードをプログラマーに書いてもらって特色となる機能を足したり、デザイナーの協力で足りない素材を作ってもらって、コンセプトの最低限の実現を目指すことになる。それでも、ゼロからプログラムを書いたりするより早いのは明白だ。
さらに下田氏は、エンジンにプログラムをiPhone用に書き出させ、動かしてみせた。プラットフォームの違いを吸収してくれるというのも（もちろん最適化は別途必要だろうが）、アンリアルエンジンを始めとする市販のゲームエンジンの特色のひとつである。
 |
 |
 |
 |
 |
 |
 |
 |
では、『ギアーズ オブ ウォー 3』ではどうだろうか？ エッジ氏とホワイティング氏のふたりとも“POC（Proof of Concept、コンセプト証明）”という作業を紹介していたのが印象深い。ホワイティング氏いわく、『ギアーズ』のようなタイトルの開発中にはさまざまなアイデアが出てくるが、実装してみるとおもしろくないことも多いのだという。
Epic Gamesの基本理念として「早めに、頻繁に失敗せよ」というものがあるそうで、ホワイティング氏は補足として「……ただし、失敗から確実に学ぶように！」とつけくわえていた。なぜおもしろいはずなのにおもしろくなかったのかを学んだうえで、次のアイデアを生み出し、またPOCを行う……という作業を行っていくというわけだ。こういったトライ＆エラーは、『ギアーズ オブ ウォー 3』の2.5年の開発期間の33％を占めているとのこと。
●実際のレベルデザインの制作手順
全体の進行については、エッジ氏の講演が参考になる。グレイソン氏は、『ギアーズ オブ ウォー 3』の最序盤、レイブンズ・ネストと呼ばれるレベル（マップ、またはひとまとまりのシーン）を例に制作手順を説明した。
まず脚本を考えるライターと、レベルデザイナーで、コンセプトについてのディスカッションを行い、ざっくりとした高次のコンセプトを決めていく。どういうレベルで、どの新キャラクターをここで入れるのか、旧キャラクターはどうやって再登場してもらうか……。
お次はブレインストーミング。1ページのコンセプトの要約を、3ページに膨らませていく作業だ。ここではレベルの主要な雰囲気（アート的なものだけでなく、“防衛”とか、“不気味”とか“狂乱”といったイメージ）を決定し、天候や時間帯なども決定。例となっていたレイブンズ・ネストでは、“スローペースでスタートして、徐々にテンションを上げていく”、“大きな驚きの要素として、巨大ボスの変種であるランベントリバイアサンが出てくる”といった構成や、ゲームプレイにかかる時間、登場する武器や敵クリーチャー、このレベル特有のプレイ要素、イントロの流れ、会話やムービーなどの概要などのストーリー要素もここで決定される。
第3段階は、エッジ氏が「1番楽しい」とする“シェリング”と呼ばれる作業だ。ブレインストーミングをもとに、シンプルな素材だけで構成した“シェル”を作る。これを遊んで、フィードバックを受けては直していくのだ。この段では、アートは作りこまない。エッジ氏はシェリングのメリットを、実際に見て遊べることで、フィードバックや新アイデアを促進する点としていた。「このモンスターを撃てるほうがいいんじゃないの？」となれば、またそれを作ってチェックしてみる。実際、説明を聞いただけではシェルとPOCは似ている気がする。POCは、新たなプレイコンセプトや武器、モンスターを素早く実装するための手段と位置づけていたので、レベルを主眼に置くか、プレイ要素のコンセプトを主眼に置くかが違うのだろう。
この先は、どんなライティングやパーティクルFX（蒸気が出ているとか火が噴き出しているといった効果）が必要か、どんな絵作りのシーンになるかを決める“ビジュアルパス”、全体のプレイ体験を決定し、主要音声や会話の内容を詰めたりする“スクリプティングパス”があり、関係者が集まってシーンを検討して詰めるべき点を決めていく“レベル・スウォーム”を経て、各スタッフが自分の仕事に集中する“ファイナルポリッシュ”（最後の仕上げ）へと向かっていく……。とにかく作ってみてフィードバックを受け、よりよいものにしていくという方針が、ここでも生きていることがよくわかる。
●限られた時間と人員で最大限の成果を得るために
エッジ氏はシネマティックカットシーンについても、絵コンテを描き、アニマティクス（映像の完成像を把握するために簡単に映像化したもの）を行って全体の尺とショット数を決め、アンリアルエンジン上でテストを行って必要なものを決め……と、段階的に制作を進めていく過程を解説していた。
一連の作業の中でエッジ氏が重要視していたのが、早期からイメージを共有するためのプリプロダクションだ。それは、限られた開発人員で膨大な量を処理し、かつクオリティーを高めるためには、プリプロダクションをしっかりやってチームが完成像をイメージし、深いコミュニケーションで、ともに作業を進めていくということが必要だからだ。
そもそも、Epic Gamesがゲームエンジンを作っているのも、“より多く、より良いものを、少ない手間で！”という同社のポリシーによる。レベルデザイナーがプログラマーの手をそれほど借りずにプロトタイプを制作できるとか、アーティストが素材を作り込む前にレベルデザインを進めておけるとか、そういったアンリアルエンジンの特色は、よりおもしろいゲームを作るために、タイムロスを防ぎ、時間を最大限に使うという発想のもとにあるのだ。
このため、Epic Gamesでは開発パイプライン（各パート間での制作手順）の最適化も行っている。ホワイティング氏は、旧来型の開発パイプラインを“垂直型モデル”と定義。企画職が仕様書を制作し、プログラマーがそれに従ってツールやエンジンなどを実装、レベルデザイナーがツールを使って作りこみ、企画にフィードバックが戻って作り直していく、上（企画）から下（レベルデザイナー）へと流れていく形式だ。
ホワイティング氏は、“よく理解されている方法だからスケジュールも組みやすい”とか“各自が自分の仕事に集中できる”といったメリットを挙げる一方で、この方法では、みんなが誰かの仕事が完了するのを待つ必要がありタイムロスが激しく、同時に前後のパートの人しか気にしなくなりがちで、チームの一体感が減るとともにフィードバックも減少、企画職がいいアイデアを仕様書に盛り込んでいても、文字だけだと誤解や異なる解釈により元の良さが失われてしまう、またアイデアが形になるまで時間がかかることで、あまりおもしろいものにならなくても「もったいない」という意識が働いてしまいがちといったデメリットを挙げた。
逆に、アンリアルエンジンの利用はプログラマーをこうした旧来の場所から開放し、新たな役割を与えるものだとして、スタイルを“水平型モデル”と位置づけた。企画職がアイデアを作成したあとは、企画とプログラマーとレベルデザイナーが水平になる。企画とプログラマーがゲームエンジンとありものを組み合わせてプロトタイプを制作して、アイデアをデモにして詰めていくという、先程説明したような手順になる。ここでプログラマーは、企画やプログラマーの要請に応じてサポートを行い、フィードバックによる新たなアイデアや代替案の実装を行うようになるのだ。お互いの進行に依存しない形で協力関係を深める形にすることで、チームとして一部が全体に影響を出すことをなくすのと同時に、逆に一体感は増すというメリットが強調されていた。
また、プログラマー職では“プログラミングバブルス”というシステムを導入しているとのこと。これはプログラミングチームをAI、ストーリー、マルチプレイ、オンラインといった要素で分けられた小さなチーム（バブル）に分け、他パートと組ませるというもの。特定の機能を専門的に担当することで、参加意識と意思疎通のレベルが向上するという。各バブルは開発の進行により構成が変化し、ストーリー面の開発に目処がついたら、E3のプレゼンテーション用デモのバブルと、プレス向けのプレイヤブルデモのバブルに人を割くといったフレキシブルな体制にしているそうで、これにはプログラマーがおなじバブルに居続けないよう、フレッシュさを保つ目的もあるらしい。
ここでもくり返されたのは、おもしろいゲームを作るためにチームが一体となって進むということ。海外と聞くと個人主義のイメージがあるかもしれないが、あくまでチームワークが強調されていたのは印象的だった。
