Game Developers Conference 2006現地レポート

会場：San Jose McEnery Convention Center

左より、福山さん、田中氏、細野氏、杉山氏

　「Game Developers Conference(GDC) 2006」での人気セッションの1つ、ソニー・コンピュータエンタテインメントの「ワンダと巨像」を扱った「事後分析:『ワンダと巨像』における情緒的キャラクタ制御」。SCEのプロデューサー海道賢仁氏、そしてディレクターの上田文人氏が見守る中、同作のリードプログラマーである杉山 一氏、リードゲームデザイナーの細野淳一氏、アニメーターの田中政伸氏、福山敦子さんが登壇した。

　このセッションが行なわれた夜、「6th Annual Game Developers Choice Awards」において、同作はBest Game of The Yearをはじめ、多数の部門で栄冠を勝ち取ったが、このセッションはフロア2つを使ったもので、開場前には長蛇の列ができ、人気の高さを図らずともこの時点で証明していたわけだ。

■ プログラマの視点から見た「ワンダと巨像」プロジェクト

　セッションは、「ICO」から「ワンダと巨像」につながるエポックメイキングな作風が上田ディレクター以下、「ワンダと巨像」チームにおいてどのように具体化されたか、キャラクタ制御を例に取り、主にプログラマの杉山氏の視点で語られた。

　なお、本稿は、グラフィックやプログラム的な要素に多数言及しており、専門的な要素に関しては、西川善司氏の連載に丁寧に解説されている。ご一読いただけるとわかりやすくなると思われる。未見の方はぜひご一読いただきたい。

　過去に6チーム、10タイトルを経験した杉山氏によれば、このチームは少し特殊だという。「表現の質の追及への意識が著しく高い」そうだ。通常のプロジェクトではコスト追求で切り捨てられてしまう話題が、このチームではあえてそういったところを追求していく傾向があるそうだ。

　杉山氏らは、SCEIが「上田チーム（便宜上こう呼称する）」を抱えていることの業界的意義について考えるそうだ。経済的追求以外に、もっと行なうべきことがあるのではないか……すなわち、短期的売り上げにはつながらなくても、市場をかき回す役割が、チームの存在意義であると感じているようだ。

　また、上田氏の企画は、技術的な挑戦が必ず含まれていることが特徴だという。これもこのチームの役割にマッチしており、通常なら既存のシステムを使って確実に制作を完了することが命題となるが、このチームではあえてチャレンジングに課題に取り組む。結果的に杉山氏にとってはモチベーションの向上につながっているそうだ。

　さて、先ほどのコスト追求で切り捨てられてしまう課題とは、杉山氏にとっては、「変形コリジョン・判定オブジェクトの処理」にあたる。プログラマがこの作品の企画を見てまず思うのは、「これ、コリジョンオブジェクトにプレーヤーがはさまれちゃうじゃん」ということ。実際、杉山氏もそう思っていたそうだ。しかし、プログラマが嫌がることをきちんと処理することができれば、この企画のアドバンテージにつながると考えたという。この決断で、プログラマおよび、ほかのスタッフの労力はかなり増大するわけだが……ちなみに「ICO」においては、「手つなぎ」や「ヨルダのAI制御」がこの要素にあたる。

　このチームにおいては、こうした考え方がいろんなセクションでも行なわれている。プログラマが1つあるシステムを作ると、クオリティアップのサイクルがゲームデザイナーやアニメーターに託される。つまり、クオリティアップに関わる部分をプログラマ側で積極的にパラメーター化し、その他のセクションに調整を任せてしまう。それと同時に、プログラマは自己完結するパートのクオリティアップを追及していく。データコントロール部分をプログラマからアウトソーシングしていくことで、クオリティアップへとつなげていこうという意図があるわけだ。この段階で、上田氏は不自然な部分を発見した場合、仕様の見直しはもちろん、一緒にクオリティアップにつなげる解決策を検討する役割を担っている。

● キャラクタコントロールのクオリティアップに関する具体例

1.巨大キャラクタのモーション制御

　これはモーション遷移のコントロールのこと。どのようにモーション同士を繋げれば、操作性と美しいモーション再生を両立できるかの試行錯誤なのだが、この領域はこのチームにおいては、アニメータやゲームデザイナーにゆだねられている。プログラマの作業領域は、それに必要な遷移の命令、パターン、禁止フレーム、補完フレームを指定できる環境を作成した後は、ほとんどこの領域には関与しない。

　“大型キャラクタ”と限定していることには理由がある。プレーヤーのリアクションの力学計算は、ほぼアニメーターが作成した、“巨像の動きに対するリアクション”となる。アニメーターは動きを印象的にしようとするから、当然のことだが、必ずしも物理法則通りにアニメーションを付けることはない。このような状況の中で違和感なく見せるという試行錯誤をアニメーターやゲームデザイナーに任せる必要が出てくる。

　プログラマ側では、速度や加速度に制限を付けるなどの対応を行なう。つまり、プレーヤーにとっては“床”となる巨像が、異常な速度や急加速をした場合、キャラクタがおかしな動作にならないように保険をかけているわけだ。

2.マルチレイヤーのモーション再生

　アグロ(馬)に騎乗しているプレーヤーが、加速するために馬の腹を蹴るという動作や、剣で刺された巨像の適切な部位がリアクションを起こすといった、モーションの遷移のコントロールは、1つのキャラクタに対して複数同時に起こる。この作品では、基本のアニメーションの上に、非同期にいくつもアニメーションを重ねて再生する仕組みを導入している。

　また、乗馬中のプレーヤーが、馬の動きに合わせて揺れる動きなど、ペアレント処理された先のキャラクタ(前例でいえば、馬が親、プレーヤーが子にあたる)が再生中のモーションにシンクロさせて再生することができる仕様も実装している。

　プレーヤーキャラクタに大して最大12レイヤーをコントロールできるが、この処理はプログラマが手がけてはいない。

3.キャラクタの地形適応

　これは、計算によるポーズ修正システムのこと。西川氏の連載でも触れているが、2足や4足のキャラクタが斜面や複雑な地形に置かれた場合、どのような姿勢になるかという表現のことだ。プログラマから見た場合、逆方向キネマティクス(IK:Inverse Kinematics……動物で言えば、手足が置かれる位置に対して、そこに至る間接の角度や位置を求めるもの)のゴール解決を実装することになるのだが、単に地面に対して足を伸縮させるだけでは、胴体が水平を維持するだけとなるなど、違和感が取れない。

　そこで、そのゴール位置を使って姿勢をアニメーターにアレンジしてもらうということになる。比較的数字に強いアニメーターに、計算式としてデータを入力してもらうことで解決するわけだ。ある場所に置かれたキャラクタをどのような姿勢にすればいいのかを知っているのは、アニメーターだろうということで、作業を分担したという。

4.足のすべりの解決

　巨像の体の移動量や回転量は、アニメーターの作った情報から算出している。キャラクタの表現の質に関わる部分であることから、この判断になったという。この作業方法では、キャラクタの到達性……あるキャラクタが移動目標にたどり着くか、ということを優先すると、足が滑ってしまうということが起こる(モーションの再生が終わった時、目標に足が到達していない場合、目標位置に足が滑るように移動してしまう)。

　一般的な小さいキャラクタに関してはこういったことは問題にはあまりならないが、この作品のように、キャラクタが巨大になると、画面に対してキャラクタが占める割合も大きいため、ごまかしが効かず、容認できない問題になる。

　この問題は、手足のボーン(骨)を固定するかどうかのON/OFFをアニメーターに設定してもらうことで解決した。「ICO」の時は、あるツールを作成して、このデータをツールを通すことでこのON/OFFの判定を算出していたのだが、今作では、そのツールを使ってみると、こちらの意図で動いてほしい小さなパーツが止まってしまったり、止まってほしい小さなパーツが微妙な振動で動いていると判断されたりして、なかなかうまくいかなかったようだ。

5.大型キャラクタの移動到達性の確保

　これは、杉山氏がタッチするプログラム層の上に乗るプログラムやゲームデザイナースタッフの苦労につながる。例として、4足の巨像が円形の台に前2本足で載る(台の半径は前2本の脚の感覚とほぼ同じ)、という映像が上映された。

　この場合、巨像と台の位置関係が非常にシビアで、およそ5度位置がずれてしまうと台の上に足は載らない。この問題は、上位層のプログラマと杉山氏が相談し、体の移動量や回転量にスケールをかけるシステムを実装。それを上位層のプログラムでコントロールするという手段で解決した。かなり面倒な到達の方程式を解いて、そこにパラメータを入力することで解決したという。ゲーム性を重視すればモーションを枠にはめてしまうことになり、情緒的な動きは失われてしまう。ここにも、アニメーターの作成した素材と、ゲーム性を両立しようという努力が伺える。

6.モーションとダイナミクスの融合

　これも西川氏の記事を参照していただければ幸いだ。巨像につかまるキャラクタが巨像の動きによって振り回されるアクション時、関節をいくつかの振り子に見立てた物理シミュレーションを行なって、その結果に対して適切なタイミングで2.のマルチレイヤーのモーションを再生、こらえる演技を行なっている。それに加え、IKを適用してパーツのずれを補正している。

■ デザイナー(プランナー)からの視点

　プランニングとスクリプト全般を担当した、プランナー(デザイナー)の細野氏からは、デザイナーの視点からのこのプロジェクトについての話があった。

　このプロジェクトにおいては、データの集約や制御のまとめ、メモリ分配にいたるまで、デザイナーが担当している。使用の煮詰めに加え、トライ&エラーや仕様の導入に対しての膨大なデータ制御を行なう基幹となっている。キャラクタの制御で言えば、リソースの管理、モーション分岐の実装、馬や巨像のAIの制御……通常のプロジェクトではプログラマが担当する領域もあるが、これらもデザイナーが担当している。

　モーションで言えば、プレーヤーキャラクタのモーションは920、馬は119、最初に登場する巨像には85のモーションデータが存在する。これをデザイナーが管理して、モーション分岐を実装しているという。これらの制御はEXCELで構築されたデータベースを使用。右にその一部があるが、C列が現在のモーション、Dがコマンド、Eが次につながるモーション、という表現になっており、キャンセルフレームや補完フレームもこのデータベースで指定している。

　このデータベースのメリットは、プログラマからゲームデザインに関する仕様がおおよそ切り離されているので、仕様の作成から反映までが比較的短時間で実現できる。反面、致命的なバグをデザイナーが載せてしまうことにも繋がる。実際、今作のデバッグレポートの約3割がデザイナーによるものだったそうで、「マスターアップ前は非常に苦労した」と細野氏が吐露していた。

　このシステムを利用することによって生まれた“こだわり”としては……

1.巨像に取り付いたプレーヤーのリアリティのある動きの構築に、デザイナーが試行錯誤をしやすい環境であったことから、演出面に力が入れられた、ということ。例えば、着地したときのリアクションでも、プレーヤーが着地する地面(巨像)の角度によって、モーションを4種類のなかから選択して再生していたりするわけだ。3Dアクションゲームではここまでやっているタイトルはあまりないのではないだろうか。

2.巨像の動きについて。リアルに見せることはもとより、遊びやすくする工夫を行なっている。右の画像は、ドラゴン型の巨像に、馬に乗ったプレーヤーが飛びつくシーンだが、プレーヤーのスピードに合わせて、巨像の移動スピードも可変する制御を入れている。

　これにより、飛びつきやすくするだけでなく、馬と巨像が併走する画面を演出しやすくなり、臨場感のある演出を生み出しているというわけだ。こういった細かい工夫の1つ1つが、プレーヤーをのめりこませる要因の1つになっているという。

　このような細かいアイデアをデザイナー自らが仕様の実装までできる環境を構築したこと、それが「ICO」や「ワンダと巨像」のようなチャレンジャブルな企画の実現に繋がった要因の1つだと細野氏は締めくくった。

■ アニメーターからの視点

　続いて、主人公と巨像のプレイアブルモーションを担当した田中氏から、モーション制作の流れと、インタラクティブな地形対応がどのようにして行なわれたかの説明があった。

　“敵によじ登って倒す”という前例のないゲームであるため、紙面上の仕様だけでは決定できない要素が多数存在したこのタイトル。アニメーターはまず、仮のモーションを作ることから始めたそうだ。この時点でのモーションは、品質こそ低いものの、容易にゲームに組み込むことができるもの。その後、モーションのブラッシュアップと平行して、デザイナーが検証を行ない、調整で煮詰めていったという。この方法はリトライ回数が多くなってしまうが、前例がないため、ある程度はしかたがなかったようだ。

　前作から、動きの説得力を重視したモーションがこのチームの持ち味。例えば、巨像の動きは緩慢で、プレーヤーを完全に追いかけられるだけの性能は持っていない。巨像のように重い物体を急に動かしたり、ベクトル方向を変化させると、非常に大きなエネルギーを必要とする(現実味がなくなる)。もし、プレーヤーへのレスポンスを高めるため、巨像を急ターンさせたり急発進させてしまうと、動きの説得力が失われてしまう。主人公のレスポンスに対しても同じことが言える。ユーザーがボタンを押した瞬間にジャンプしたり、剣を振ったりはしない。ジャンプはボタン入力の後、腰を落としてからジャンプする。攻撃も入力後、剣を振り上げ、振り下ろす。

　以上の例のような判断がなされているのはこのチームにおいては、ボタン入力に対するレスポンスのよさ≠操作性のよさと考えられていることに起因する。レスポンスを重視するがゆえに説得力やリアリティのない動きを主人公がとってしまうと、重さを持ったキャラクタを表現できなくなってしまうと考えるからに他ならない。「質量やエネルギーを感じられて初めて、リアリティある動きとなる」と田中氏は断言していた。

　また、田中氏は、杉山氏の解説にもあった「キャラクタの地形適応」に関してにも触れた。アニメーターがツール上で作成した表現データをゲームに移植できるシステムを構築した。これは、傾斜に立たせる可能性のある4足歩行の巨像、そして馬のすべてのモーション、弓を撃つときのプレーヤーキャラクタの姿勢制御に使用された。

　足の高さやコントローラの入力情報を取得し、ボーンをどれだけ曲げるか、という式をボーン単位で作成。この表現データを元のモーションを壊すことなく重ね合わせ、インタラクティブにアニメーション再生が行なえるシステムになっているのだ。このような要素は、一見地味で目立たないが、あるのとないのでは見た目の自然さはまったく違ってくるし、モーションのバリエーションも無限に広がる。会場では、この制御をOFFにした状態と、ONにした状態の映像が上映され、笑いを誘っていた。

　田中氏も、「通常、コストを考えるとこのような制御はやらないか、地面を平らにすることが多いと思う。ゲームクリアにもほとんど関係しない。しかし、こうした不自然さに冷めてしまうプレーヤーも多いと思う。不自然な要素を取り除き、より自然なモーションを作ることで、興味を持ってくれるプレーヤーもまた多いのではないかと考えています」と締めくくった。

　「ICO」ではヨルダ、「ワンダと巨像」ではアグロと、NPCを担当した福山さんは、「どちらもゲームの世界に生きる意志を持ったキャラクタとして成功させる必要があった」と話を切り出した。「ICO」の制作以前、8年ほど前、福山さんにはゲームに登場する女性キャラに不満があったそうだ。ゲームの中の女性キャラは、女性であることを誇張して作られていることが多く、福山さんにはどこがよいのかがわからなかったという。

　そんな思いもあって、ヨルダは自然でありながらも魅力的なキャラに仕上げようと心を砕いたそうだ。上田チームでは、モーションキャプチャを使っておらず、アニメータの手付けのモーションを使用している。手付けにしている理由は、キャラクタをより個性的にするための手段だが、それにこだわっているということではなく、それ以上の表現が可能であれば、MCを使っていくこともあるかもしれないそうだ。

　この手付けによるこだわり、アニメーションのテクニックは語りきれないとしながらも、端的には、“アニメーターがいかにそのキャラクタになりきれるかが重要ではないか”と考えているという。キャラクタの置かれた状況を深く考え、「自分ならどうやって動くか」を考えることが最も大事で、これは役者と同じことだという。そういう意味で、今作の担当は馬だっただめ、苦労したそうだ。

　また、アニメーターとタッグを組んで仕事を受け持つプログラマやデザイナーの絵的な要素やセンス……自然かどうかのセンスを共有できるかどうかが重要だともいう。最終的な画面へのアウトプットはこのようなスタッフの協力が必要になるため、アニメーターがイメージしたものをどれだけ伝えられるかで、結果が大きく変わってくるが、こだわりのセンスがあう人がチーム内にいると、結果がスムーズに得られる。上田チームはそのあたりが優れているのではないかと感じているそうだ。

　「イメージを共有できる人が多いということはもちろん、杉山氏の言う通り、アウトプット後の調整をアニメーターやデザイナーが直接タッチできる環境が整っており、理想的」と福山さんは締めくくった。

　ここまでの話を聞くと、「プログラマ以外にパラメータを渡せば質は上がる」、「プログラマはシステムに特化すべき」と考えるかもしれない。もちろん、パラメータを渡せば調整の幅は広がるが、逆にプログラマがシステムを作る作業に追われてしまったり、パラメータが多次元化して調整が不能になってしまうこともある。上田チームでもこういった事態は起こったという。

　ゲームデザイナーやアニメーターは、どの調整項目を受け渡してもらえればクオリティアップの作業として完結するのか、プログラマはどのパラメータをほかのセクションに渡せばパフォーマンスが得られそうか、ということを、セクション間で話し合うことが非常に重要だと杉山氏は語る。プログラマはどのような情報を入力すれば最適な動きをするかを知っているはず。そのあたりをセクション間で話し合うことが大切だという。

　また、プログラマは数字で物事を完結させて表現したいという気持ちはある。モーションや地形の自動生成、物理シミュレーションですべてを解決するという方法だ。「グランツーリスモ」シリーズではこうした試みが結実しているが、杉山氏もうらやましいと思うこともあるそうだ。ただ、今の技術では、これだけでは生み出せないものがあると杉山氏は言う。

　例えば、首の傾け方。この角度の微妙な違いで、印象がまったく変わってくる。このチームではこのパートもアニメーターに8方向のパラメータを入力してもらい、通常のモーションにレイヤーで重ねている。「究極的にはAIの役者を作り上げ、それに演技指導をするということになるかもしれませんが、何か意思を持った情報を表現するには、外部からの情報のインプットが必須」と杉山氏は言う。

　本作の制作の終盤、馬の手綱やタテガミ、人物の髪やマントの判定を実装していたとき、杉山氏にとっては非常に楽しい時間だったそうだ。プログラマとしてのアウトプットが表現のクオリティアップに直結する……達磨に目を書き入れるように……。こういった作業があるから、プログラマは自分にとって天職だと考えている、と杉山氏はセッションを締めくくってくれた。

　立場の違う4人のスタッフが、共通の目的に向かって製品を完成させるには、いろんな道のりがあることは想像できる。その中で、製品の魅力のキーポイントを自らが振り返るという形のセッションだったが、細かな技術的なことはわからなくても、「ゲームができあがるまで」を垣間見た気分になれる、貴重な体験をさせていただけた好セッションだったと思う。

(C)Sony Computer Entertainment Inc.

□Game Developers Conference(英語)のホームページ
http://www.gdconf.com/
□Game Developers Conference(日本語)のホームページ
http://japan.gdconf.com/
□ソニー・コンピュータエンタテインメントのページ
http://www.scei.co.jp/
□製品情報
http://www.playstation.jp/scej/title/wander/

(2006年3月25日)

[Reported by 佐伯憲司]