娯ログ(β)

ゲームデベロッパー 娯匠 公式ブログ

June 2010

モーション制作の流れ

 堀内です。

 今日は、キャラクタの動きを制作する流れについて書いてみます。といってもバトルアクションに関してはモーションデザイナーの梅田にほぼ一任してますので、自分が管理をしていたイベント系について、デス。

 剣闘士 グラディエータービギンズのイベントシーンは

1:画面上に腰から上が映された人物がこちらを向いて会話する「バストアップイベント」
2:キャラクタの演技をカメラを動かしつつ魅せる「カットシーン」

の二種類に大別されます。

 バストアップイベントの場合は、キャラクタの人物像をシナリオを読みながら固めていき「こいつは、こんな動きをしながらしゃべりそうだな~」とか考えつつ、最低限必要な動きを洗い出して、何人かのイベント担当モーションデザイナーと共に制作していきました。

 以下は開発初期に作ったテスト動画です。



 まだキャラクタのグラフィックスデータが全然なかった時期なので奴隷モデルを用いてテストしています。こういったものを作って、1つのアクションの長さ、人物が表示される大きさ、表情の程度や骨の数等々、「こんな感じならプロジェクトの範囲内で作っていけるかな?」と検証していきました。

 次にカットシーンですが、今回はかなりスピードを要求されましたので絵コンテは殆ど描きませんでした。3Dソフト上でアニマティックとよばれる簡易動画コンテをガッとつくったり、細かい演技部分は自分たちで動いた動画を撮ったりして、「こんな感じで作りこんで~」と制作担当にお願いしていました(開発末期は「こんな感じ!」と動きながら口でいうのみという感じでしたけど…担当者の皆さん、ごめんなさい)。

 アニマティックの一例はこちら。
 最後までプレイした人なら「あ、あのシーンだ」とわかりますね。



 こんな感じで最初にキャラクタの立ち位置&演技の概要、そしてカメラを決めておくことで、作り込む人が「ここはばっちり見えるな」とか「このカットは脚が見えないからザックリでいいな」と力の入れどころを把握できます(作り込んでいく段階で「こっちのほうがつくりやすい」とか「このほうがもっと映える」とかの理由から変更する事はあります)。

 次に演技動画です。キャラメイク後の演出です。



 これは一人二役でやってます。はたからみれば「ぷぷ…なにやってんの?」って感じでしょうが、演っている本人は「こいつならどう動くかな」「こういうときはこんな気持かな」とか真剣に考え羞恥心を捨てて動きます。ちなみに私は以前所属していた会社で犬の動きを把握するために四つん這いになって遠吠えをしている人を見たことがあります。これが本当のプロってもんです。

 同じようによく自分で動いてみるスタッフとは、「やっぱ体格がよくないと、"体格がいい動き"にはならんね~」とボヤいています。普段マウスをカチカチやっている程度では、鍛えている剣士の動きにならないんです。ですが、力の伝達具合とか、まあ、動かないとわからないことだらけなので、やっぱり動きます。あとは実際にデータを作成するときに想像力による補完で「もっと体重のある筋肉質な動き」等、足りない部分を補っていくしかありません。ここが各人の腕の見せ所ともいえます。

 ここまで読んで「モーションキャプチャすればいいじゃん」と思われるかもしれませんが、それはそれでむずかしいのです。まず、いい役者さんを見つけないといけないし、限られた時間内に望んだ動きが収録できるようこちらの意図を言語化し、理解してもらわないといけないし、収録がうまくいっても、それを実際ゲーム中に使えるように手を加える必要が…いや、そもそもスタジオを抑える費用(略

 うん、手で作れる方が、いざってときに融通が利きますよ。やっぱり。はい。

 ともかく、私は個人的にも「動き」「タイミング」「感触」というものにとても興味がある人間なのです。そこをもっともっと追求できるようなプロジェクトをいつか立ち上げたいと考えています。それを目標に今後も進んでいきたいです。

 ちなみに今作で、自分が好きなイベントの動きを一つあげるならば“カシウスが画面を指差す動き”デス。あれ、イラッときません?イラッとしてもらえたなら成功です。

チョーナゲーけど?

■はじめに

 娯匠のゲームに関わるとロクなことにならないし、ロクなこともしないプログラマー西森こと nistake の部屋へようこそ。あなたはこの糞長い文章についてこれるでしょうか?

 で、前回(?)と同じく、ゲーム内容の話を私がしたところで全く面白くありませんから、思い切ってビギンズで使用したデザインパターンの話でもします。

 いまさらパターンの話なんてツマランとか、いまどきパターンと提唱されているものなんて何兆個あるのかわからん、みたいなご時勢ですが、そんな文句は聞く耳も無く、古典 GoF(※) の 23(+1) パターンからテキトーに抜粋します。


■Template Method と Strategy

 手順やフレームはしっかり決めておいて、細かいところは適材適所で部下に責任を持たせてやらせる、という理想の上司と部下の関係的なパターンです。

 最近 iPad 持って、「僕ちゃんって有能~」みたいに勘違いしているクズが増えましたが、そういったゴミ未満の人間共は Template Method や Strategy を見習って欲しいものです。だからその iPad はオレにくれ。

 ビギンズでも、個人的には Template Method や Strategy パターンは大活躍でした。二つは細かくは違うんですが、結構似たような、両方のいいとこ取りみたいな実装をしてる人もいっぱいいるように思います(身勝手予想)。

 面白いかなーと思うものとして、シーングラフ中のキャラクタ(モデル)インスタンスの実装あたりを挙げます。

 キャラクタインスタンスは要するにポリゴンメッシュでできたオブジェクトのことなんですが、そのクラスのフレーム毎の更新と描画の関数は次のようになっています。

update() {
  インスタンスの全マニピュレーターの pre_update() を呼ぶ。
  インスタンス自身のコアな update() 処理。
  インスタンスの全マニピュレーターの post_update() を呼ぶ。
}

draw() {
  インスタンスの全マニピュレーターの pre_draw() を呼ぶ。
  インスタンス自身のコアな draw() 処理。
  インスタンスの全マニピュレーターの post_draw() を呼ぶ。
}


 マニピュレーターは、各キャラクタインスタンスがリストにして管理しています。で、マニピュレーターとは何かというと、

  ●二度描きが必要だったり、描画に少し小細工をかける処理
  ●直前のモーションと今のモーションをスムーズにつなぐ補間のような処理
  ●キャラの姿勢計算後に必要なデータ更新

のようなことをやっています。こういう処理って、

  ●毎フレームの姿勢の計算直前、直後に何かしたい
  ●モデルの描画直前、直後に何かしたい

といった要求なわけで、こういうのをヅラヅラひとつの関数やクラスに、インスタンス本体の処理と一緒に実装すると、全然違う処理なのにマゼコゼになるし、常に必要なものでなければ、フラグも増えて大変面倒です。

 そこで、処理タイミングだけちゃんと実装しておいてやって、あとは各マニピュレーターで勝手にやってもらえば、キャラクタインスタンス本体はずっとすっきりしたままですし、それぞれの処理もちゃんとクラスにわかれて気分も良いです。

 マニピュレーターは単純な配列やリストで管理できますから、動的にこれらの機能を追加したり取り外したりもできます。enable() とか disable() とかいうスイッチング関数やフラグも基本的には必要ないです(生成や廃棄のコストはあるけど)。

 と、ここまで書くといいことばっかりですが、


■Command

 エディタみたいなツールを作るときは、ベガ戦の波動拳や、天津飯戦のカメハメ波よりはるかに役に立つ、超必殺技としておなじみのパターンです。必殺度が高すぎるため、エディタを書くと思った瞬間にメクラ滅法に書き出したくなる麻薬的なところもありますが…。

 ビギンズのキャラクタはスクリプト(正しくはコンパイル後バイトコード)によって挙動処理されています。キャラクタのスクリプト(バイトコード)は、

 「ガード(条件式)」「処理本体」

の二つの組の羅列です。

 ガードはゲーム中の入力のチェックやモーションのフレーム検査、ゲーム中のシチュエーションチェックなど色々です(ガードはスクリプトの論理式なので、実際にどんな検査をしているかは、前野のヒゲに聞くほうが良いでしょう)。

 あるフレームのキャラクタの処理は次のようになっています。

 1:全キャラが持つ全ガードの評価をする。
   真なら対応する処理本体を実行するコマンド発行。
 2:評価後、全キャラについて、発行された「本体実行コマンド」を実行。

となっています。このようになっている理由は、プログラムやスクリプトの処理順によって結果が変化してしまうことを防ぐため -- 条件評価中のキャラクタは不変(invariant)にするためなんですね。

 一見、これは細かいんですが、キャラクタの挙動が複雑で、キャラクタ相互の関係が強いゲームの場合、この不変性をある程度担保できないと、修正が大変やっかいな不具合やバグに見舞われるケースがままあります。例えば、記述順を変えたら挙動が極端に変わったり、同時ヒットがきちんと処理できなかったり等…。

 ただ、でもここまで気にする必要があるのは、やっぱりビギンズがあのようにビギンズなゲームだからです。よくあるジャンプアクションぐらいならどうでもいいことだと思います(でもビギンズはジャンプしないけどね)。

 「今回のゲームは以前(road to freedom)に比べて簡単なゲームですよ」と最初に言われてましたが、結局こうしているところ等からするに、私ははじめから娯匠の人間たちを、

「大して信用もしていなかった」

ということになります。えぇ、信用するわけ無いでしょ。奴らが単純簡単なゲーム作るわけ無いでしょ。そんなゲームは他の会社に作らせとけ。



■State

 状態遷移図で書くとわかりやすくなりそうなブツを実装するときにすぐ頼ってしまう、かっこいいアニキのようなパターンです。

 外面は変わらなくても中身がポンポン変わる、という点では最近の日本みたいですが、日本の場合は中身が変っても挙動まで変わることは少ないですし、大体遷移自体が一方通行で図にする必要もありません。

 ビギンズでは先の「ガードと処理本体」の集合となっています。
 たとえば、攻撃をするモーションであれば、その State (ビギンズ中はとおりが良いのでアクションと呼んでました)は、乱暴には、

 「攻撃フレームになったかどうかのガード」「攻撃設定処理」
 「攻撃フレームまでかどうかのガード」「他のシフト入力処理」

といった感じの「ガード+処理本体」スクリプト(バイトコード)の集合として定義されていると思います(詳しくは前野のヒゲに聞くのが良い)。

 ビギンズは複雑なゲームなので、この State が大量に定義されています。処理本体には他の State への遷移、というのもありますから、大量の State に大量の遷移となり、もう

「図にするのが馬鹿らしい」

ぐらいなはずです。それでも、アクションの遷移だけに限れば、他の細かい対戦格闘ゲームほどではないとは思いますけど。

 この State とスクリプトのあたりについては、実はコンパイラやスクリプト言語(と呼ぶか?)の仕様含めて結構

「チョーヘンテコ」

な面白いもので、専門の言語屋さんからみても「なんだそれー」的なところがいっぱいだと思うのですが、紙面の都合上、割愛させていただきます。



■Abstract Factory

 「僕ちゃん、こんなスゴいメカ欲しいんだけど。これでトッキョ取るョ」とクーピーで描いたテキトーな設計図を持っていっても、がんばってスゴそうなモノを作ってしまう工場です。そんな奴はアメリカに行って、ビショビショのネコを入れてもちゃんと乾燥できる電子レンジでも発明してればいいと思います。

 ビギンズの Factory といえば、

「超ウルトラスーパー大好評」(つまり逆)

だった、BattleBuilder クラスでしょう。

 Builder という名前なのに Factory なのは、最初は Factory という名前だったのが重ね重ねの書き換えにより、名前も変えざる得なかった事情によります。

 この Builder という名の Factory も、キャラクタと同じくスクリプト駆動です。

 スクリプト処理によりバトル中のあらゆるオブジェクトを「生成する」、というところでは、Factory と呼べますが、作られたインスタンス(群)のクラスは大抵、フツーの具象クラスか具象クラスと同等のものなので、Abstract とは呼べないかもしれません。まぁ気にするな!ボーイ!

 この BattleBuilder、実は開発中の歴史的(?)な経緯やその扱われ方などお話すると、

「目が回るような面白さ?(他人事)」

と個人的には思うのですが、紙面の都合上、割愛させていただきます。



■Visitor

 全くあたらしい工場ラインです。恐ろしいことにベルトコンベアの上に乗っているのが作業する人で、ベルトコンベアの脇に車や機械や材料が並んでいます。「シートをつける人」はカウンタックの前にきたらそこにあるシートをカウンタックのボディに取り付け作業をします。ミニクーパーの前にきたらミニクーパーのシートを取り付けます。

 シートをつける人はシート付けのスペシャリストです。逆に言えばシート以外については全くしらなくても大丈夫。どこにどの車があるなんてことも知らなくて平気ですから、工場長は好きなときに好きな車種を好きなように配置できます。新しい「カイゼン」なのです。

 で、この visitor、ビギンズでは意外にいろんなところで使っています。わかりやすいのは木構造になっているシーングラフ中のノードのトラバースとかでしょうか。

 シーングラフ中からキャラのモデルノードだけにこんな処理したい、背景だけにこんなことやりたい、といったことはアリガチなんですが、そういうときに、シーン中のインスタンスをトラバースする InstanceVisitor クラスを派生実装して、シーンにぽいっと渡せばもうOK、というのは個人的には重宝しました。

 ただ、色々めんどくさがって、なんでもかんでも visitor 使ってトラバースしていたので、真にオブジェクトが大量なゲーム向きの実装ではなかったかもしれないなーとも思ったりします。visitor ってダブルディスパッチ(関数ポインタ二回参照)なんで、命令キャッシュにも優しくなくて、高速とは言いがたいかもしれないです。

 と、↑のように思う私は多分富豪になりきれていないのです。イカンイカン。

「Viva! 富豪プログラミング!」



■Chain of Responsibility

 できないことはどんどん他人に流して自分は知らん顔。役に立たないバブル時代の就職組がどんどん偉くなった結果、こんな風潮の社会ができあがってしまいました。全員シねば日本はバラ色です。

 ただ、ホンモノの Chain of Responsibility は責任範囲であれば確実に対処する、責任感の強いモノたちの連なりです。脳細胞が実は豆腐のバブルバカ共とはまったく違います。

 ビギンズでは Chain of Responsibility を何箇所かで利用しています。一番いい採用だったな、と思うのは、コリジョン発生時の処理かと思います。

 ビギンズに限らず、衝突(剣と体、とか、剣と盾等)発生時の処理は、いくつかの種類に分かれます。例えば、

  ●ダメージの計算
  ●リアクションの決定、設定
  ●エフェクトを出す
  ●経験値などの計算

等です。

 これを下手にコードにするととりあえずはこんな感じでしょう。

ヒット処理( キャラA , キャラB ) {
  if ( キャラA の武器がキャラB の体に当たった ) {
   ●ダメージの計算
   ●リアクションの決定、設定
   ●エフェクトを出す
   ●経験値などの計算
  } else if ( キャラA の体がキャラB の防具に当たった ) {
   ●ダメージの計算
   ●リアクションの決定、設定
   ●エフェクトを出す
   ●経験値などの計算
    :
    :
}


 ビギンズはヒットしたブツの組み合わせにより色々処理が変わるのでベタで書くとこうなりますが、下手すぎです。もう少しなんとかします。クラスにして、上記の if - else if ... (相当の処理)はどっかにすっ飛ばすことにします。

class ヒット処理クラス {
 void 武器→体 ( 攻撃キャラ , やられキャラ ) {
   ●ダメージの計算
   ●リアクションの決定、設定
   ●エフェクトを出す
   ●経験値などの計算
 }

 void 体→防具 ( 攻撃キャラ , やられキャラ ) {
   ●ダメージの計算
   ●リアクションの決定、設定
   ●エフェクトを出す
   ●経験値などの計算
 }
  :
  :
}


 少しマシになりました。ただ、このクラス、きっとメンバ変数や #include は、

   ●ダメージの計算
   ●リアクションの決定、設定
   ●エフェクトを出す
   ●経験値などの計算

すべてについて包含していることになります。そして、特にこのあたりが細かいタイプのアクションゲームは、この辺のコードが得てして

「いろんなものがあってぱっと見、なんだかぐっちゃぐちゃ」

になりがちです。だって「呼び出しタイミング」「参照する衝突データ」という点以外に、上記の●の処理間には大きな意味での共通点がないのですから…。

 こういう場合、多少関数に分けたぐらいではグチャグチャ感は解消できません。ひとりで書いてればマシですが、二人以上でやるとスゴイことになることがよくあります。そしてビギンズでも石川ヒゲが言い出したのです。

「観客の評価処理入れたり、AI の処理やりたいんですがー」

 ということで、上記の「ヒット処理クラス」には空の仮想関数だけ定義して、上記の●や石川ヒゲの評価処理は全部別のクラスにすることにしました。

 で、それらのクラスのインスタンスは、単方向リストでつなげておいて、衝突時は、リストをたどって全部の対応関数を呼び出してやれば、シヤワセ~なわけです。

 実は Chain of Responsibility は Chain 上の個々の責任者は、ある処理を次へ委譲するかどうかを決定できるのですが、この実装はそうでないので、正しくこのパターンとは言い切れないです。でも「衝突処理という要求の結合度を低くする」「それぞれの責任の割り振りを柔軟にする」という点が上手く利用できていると思うので、いいかな~とか思ったり。

 開発後半は、前野ヒゲも実装に加わって(プランナーなのに!)、三つ巴でヒット処理をグチャグチャいじってましたが、なんとか、

「あー、その行うっかり消しやがったなー、バカー!」
「先にそれやられると困るのよ」

みたいなことは無かったかなーと思います。あくまで、この衝突確定後の処理についてだけですが…。

 この点について本人達がどう思ってたかはわかりません。コーディングがうまくいったとか、上手に書けた、なんてのは結局、

「プログラマーのオナニーの話」

ですし。



■デザインパターン総括

 大体、こういう文章というのは、いいとこどりで、悪いことをちっとも書かないような感じになるので、読むと、

「この方法でばら色の人生が~」

みたいに思えてしまうことがあります。そういえばデザインパターンの本を最初に読んだのはもう10年以上前ですが、そのときは、

「これでオレも天才プログラマーになれる」

のようなことを本気で思ったものでした。そして、あのころも今もずーっと同じように、

「たらたら汚いコードを書いて、バグを生産し続けている」

のですね。デザインパターンを勉強して利用して、いったい何が変わったのだろう。



■終わりに

 娯匠では、中の人々が意識しなくてもいつのまにか、

「全然簡単じゃない、ゴリゴリのゲームゲームしたゲーム」

へ勝手に話や方向が流れていきます。何が今回は簡単なゲームだか知りませんが、「いや、このシステムは実は簡単なんです」とか言いながら、ホワイトボードまで使って説明してるのに

「ちっともわからない」

ようなものを提案するあたり、もうこういう方向でしかゲームが作れない集団なのです(これは言い杉)。要するに、個人的に思うのは、

「娯匠みたいな会社が本当にやっていけなくなったら、ゲーム屋廃業しようかな」

ということでしょうか。そんなゲーム業界ならいらないよね。勝手にヤッテロ、みたいな感じ。

 やー、でも本当に、今回のプロジェクトは何回「簡単」とか「シンプル」とか聞いたかなー。プレイヤーの感想も是非聞きたいですね。簡単でしたか?シンプルでしたか?


おしまい。



※GoF
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides:
Design Patterns: Elements of Reusable Object-Oriented Software
Addison-Wesley

本位田真一、吉田和樹 監訳
オブジェクト指向における再利用のためのデザインパターン
SOFTBANK BOOKS

誕生日会

雑談担当のようになっている、モーションデザイナーのKamuです。

今日は(も?)、仕事から離れた話をしましょう。

うちの会社は、あまり「仕事の後に飲もう」というのがないのです。
というのも、お酒を飲めない人が結構いるからです。
ですが、いざ飲み会をするとなると、その日忙しくない人全員で出席します。

先日も誕生日会を名目に、飲み会しました♪
男臭い「剣闘士」ゲームを作る会社なのに、誕生日会なんてしちゃうんです。
意外とかわいいでしょ?

娯匠の幹事はいつもプランナーがやります。
「プランナー=企画=飲み会企画もやれぃ」というノリです。
6月9日誕生日が1人、6月10日誕生日が2人いるので、人数の多い10日に開催しました。
なぜか、5月末の誕生日も主賓側にいます。

20100610_01

20100610_02

20100610_03

飲めない人がいる飲み会なので、ご飯もお酒もおいしいところを選びます。
今回は「カリフォルニア料理」のお店。

でも飲み会の席なのに、社内にいるのとあまりかわりません。
お昼ごはんをみんなで会議室を使って食べるので、話題もその延長線です。

20100610_06

20100610_04

20100610_05

場所を変えても、こんな感じです。
飲み会中にiPadでポーカーやるあたりがゲーム会社らしい情景です。

今回はそんな飲み会のお話でした。

ちなみに最近では隔週金曜日に「ランチ会」もしています。
かわいらしすぎ?

誰が言ったか知らないが‥

 株式会社トーユー・キネマテック 平田です。

 先日、空耳アワーを観ていたら、われらがチタシチーナこと佐藤かおりさん(既にネットで名前が出てるから問題ないよね?)が出演していらっしゃいました!空耳役者です。

 すごかった!巨乳レースでプルンプルンしてました!ぜひ、全力坂(深夜にやってる「この坂も、実に走りたくなる坂である。」ってナレーションの番組)にも出てほしい…

 以下、エロ自重。

 さて、僕はPS2の前作も参加しているのですが、今回担当した部分では、DLCシステムが印象に残っています。

 まず、ミッションとして、「湯水のようにDLCを使う」「プレイヤーにとって空気のような存在」というのを目指し、基本的に何でもDLCに出来ちゃうんじゃないかというような仕組み造りに取り組みました。

 ところが、それだけであればスムーズに済んだはずなのですが、現実には、DLCをダウンロードしていない人のPSPでの対策の都合などがあって、ゲームプログラムのほぼ全体を把握して、DLCが使われた場合に問題が出そうな部分を適宜修正しなければならないなど、DLCの仕組み以外にも手を付けなければならない部分が多々あり、思った以上に手間がかかりました。

 空気のような存在として、決して目立つわけではないけれど、プレイヤーの皆さんに楽しんでいただけたのであれば、ミッション達成です。

 DLC、思う存分楽しんでいただけましたでしょうか?

血湧き肉躍る曲

 PSP『剣闘士 グラディエータービギンズ』にてBGMを担当した柳川剛です。

 BGMと一口に言っても、ゲームによって実に様々なアプローチがあります。プレイヤーの皆さんが血沸き肉踊るアクションに没頭して頂くのはもちろん外せない大事な要素ですが、今作ではもう一つ、世界観──ローマの息吹を肌で感じて頂くことを念頭に制作しています。

 舞台は栄華を極めたローマ帝国。

 数ある歴史ものの中でも、他の追随を許さないであろう壮大なスケールを持ち、『スパルタクス』『グラディエイター』『スリーハンドレッド』など、映画でも度々題材として取り上げられる、血なま臭くもドラマチックな物語の数々がそこには眠っています。

 数千年の時を遡り、プレイヤーの皆さんをいかにして「そこ」へ誘うか。

 今回、オーケストラサウンドを中心にスケール感、重厚さを出し、中近東を中心とした様々な民族楽器を用いることで、PSPの画面の中から「ローマの息吹」を感じられるよう、音楽面からサポートさせて頂きました。

 剣。   槍。   盾。   鎧。

 戦いとは「肉と肉のぶつかり合い」であり、己の五体が、血と肉こそが、真実だった時代。そのことを意識しながらプレイして頂くと、また違った楽しみ方が見つかるかもしれません。

 柳川 剛 拝
 http://www.az-sound.net/



 今回は新曲を担当して頂いた、柳川剛さんから届きましたコメントを掲載いたしました!また特別に掲載許可をいただいたので、新曲の中から2曲ほどご紹介いたします。

  ♪『剣闘士 グラディエータービギンズ』BGM 1 - デュエル
  ♪『剣闘士 グラディエータービギンズ』BGM 2 - ラストバトル
記事検索
プロフィール

有限会社 娯匠

最新コメント