Miyabiarts.net

一年に一度の更新頻度

カテゴリーアーカイブ: Game

CEDEC2011 1日目

夏はなんだかんだでやること沢山ありました。お久しぶりです。CEDEC2011というエンターテイメント(主にゲーム)の開発者会議に参加しました。パラレルセッションで、同時に聴けるのは1つだけなので、自分が聴講したセッションのみのレポートをします。今回は、聴きながらかなりつぶやいたので、Twitterを参照すると良いかもしれません。ただし、入力が間に合っていない場合があり、いくつかの話をまとめながらなので、正確性には自信がありませんので、そこらへんはご了承ください。内容の詳細な話は、ニュースサイトなどにまとめられているので、気が向いたら、後でリンクを貼ります。

未踏宇宙を拓く「はやぶさ」探査機搭載イオンエンジン

國中 均 (宇宙航空研究開発機構 宇宙輸送工学研究系 教授)

イオンエンジンの説明から、はやぶさプロジェクトがどのような経緯で進められていったか。そして、度重なるトラブルを「こんなこともあろうか」と技術を駆使して解決し、無事に帰還を果たすまでのストーリーを小気味良く話してくださいました。日本の宇宙事業は、他国に比べて予算も規模も小さいですが、その制限された中で、他国よりも優れたことを成し遂げたというエンジニアの誇りみたいなものを感じられるような講演でした。

今回のCEDECのテーマが「CROSS BORDER」ということで、異なる分野からの基調講演ということのようです。話自体はとても面白かったのですが、参加者の期待するものとはちょっと違うのではないかな?という懸念はありました。

また、講演そのものとは関係ないのですが、運営がちょっと拙い感じでした。基調講演が始まっても、かなりの人数が会場に入りきれず、話の途中で次々に人が入ってきたり、入り口が一つしか開放していなかったため、終わったあとも長い行列ができ、次のセッションになかなか行けない人も多数いたようです。このあたりは、反省事項になると思いますので、来年は頑張ってください。

『アニメのエフェクト、ゲームのエフェクト』 ~前篇~

橋本 敬史 (株式会社竜の子プロダクション) ほか1名

スチームボーイなどのエフェクトについてトーク形式で進めていったのですが、画像が全く出てこない。言葉でエフェクトの感じを説明されるので、残念ながら全く理解できませんでした。ホワイトボードに描く場面が多少出てきたのですが、ペンが薄かったりで、ここもちょっと拙い感じ。過去の作品を流しながら、この部分のエフェクトはこんな感じで作りました。というようなセッションを期待していたので、ちょっと残念でした。

開始が25分遅れた割には、その理由が説明されなかったりと、ちょっと不信感を抱かせる感じになってしまいました。講演者の遅刻だったとしても、理由を説明してくれるだけで随分心象は違うものなんですけどね。前後篇通して聴くつもりでしたが、前篇のみにしました。遅れた分、延長はあったのですが、そのおかげで昼飯はまともに食べれず。あ、でもUnity本は買えたことは良かったです。

ショートセッション: AI に命を吹き込むには

並木 幸介 (株式会社フロムソフトウェア) ほか2名

前半は「ぽかぽかアイルー村」のAI、後半は「ARMORED CORE V」のパス検索の話でした。

前半の「ぽかぽかアイルー村」では、キャラクターの行動をそのままスクリプトで記述すると、組み合わせ数が爆発してしまうので、アフォーダンスの考え方により、これを解決するという話でした。通常のAIでは「キャラクターが環境に合わせて行動を決定する」ことに対して、アフォーダンスを用いた場合は「環境がキャラクターの行動を決定する」という考え方でAIを設計します。これによって、組み合わせの数を大きく削減することができるようです。

メモ

  • アイルーが個性に応じて提案する提案の組み合わせ数が爆発する
  • if文で分岐させると一匹あたり1 ,500行のスクリプト
  • バランスに関わるので人海戦術が取りにくい
  • アファーダンスを取り入れる。 環境がキャラクタのAIを決定する
  • アフォーダンス志向にすると、組み合わせ数が抑えられる
  • 提案テーブルとアフォーダンステーブル
  • アフォーダンステーブルの値を提案テーブルの値に加算し、全てのアイルーの提案テーブルをまとめてから、提案を提案する
  • 結論: アファーダンス志向にすることで、組み合わせ数が爆発しがちなAIを上手く設計できる

後半の「ARMORED CORE V」では、3次元空間のパス検索についてでした。2次元のパス検索では地形のようなナビゲーションメッシュからパスを構築できることに対して、3次元ではそれができないため、衝突形状からAABB集合を作成し、それからナビゲーショングラフを構築する方法が説明されました。一度、ナビゲーショングラフが構築されれば、A*アルゴリズムを用いて一般的な方法と同様にパス検索できるのですが、ACVでは上空に上がるときにはコストが高く、下がるときにはコストが低くなるなど、1つのパスのコストが非対称であったりするところが、パスが立体的になった時の特色だな、と感じていました。

メモ

  • 複雑な地形に衝突しないようなパス検索が必要
  • 空を飛んだりするため、地形に沿ったパス検索ではダメ
  • 衝突モデルからナビゲーショングラフを生成し、A*でパス検索
  • 衝突モデルをまずボクセル化。ボクセルには属性別に重み付け。ボクセルからAABB集合に変換。変換の際、適したものになるように、色々工夫
  • 工夫はなるべく均等になるとか、同じ属性のボクセルが同じAABBに入るように、など。焼きなまし法で最適化
  • 工夫はなるべく均等になるとか、同じ属性のボクセルが同じAABBに入るように、など。焼きなまし法で最適化
  • AABBをノード、隣接面をエッジとしたナビゲーショングラフを生成
  • パス検索は普通にA*を利用。機体の機動力を考慮してエッジコストを調整
  • 機体は上空に上がるときはコストが高い。下降するときはコストが低い。非対称なエッジコスト
  • 理想は地形は三角メッシュ。空間は凸包分解。ただ、空間の凸包分解は難しい
  • 焼きなまし法の計算コストが非常に大きい。高速化も頭打ちになっている

ショートセッション: オープンソースとの付き合い方

蒔田 修一 (株式会社オージス総研) ほか3名

前半はオープンソースの基本的な話とかライセンス形態の話、後半はセガ内でオープンソースを適切に利用するための取り組みの話でした。ゲームで良く用いられているオープンソースとはどんなものか。という話を期待して聴きに行ったので、ちょっと思っていたのとは違う感じでした。

「ドラゴンズ ドグマ」のグラフィックス表現の技術解説

清水 大輔 (株式会社カプコン) ほか1名

前半は、時間変化を伴うフィールドで動的にライティングを行う技術の話。スクリーン空間でライティングを行うDiffered Lightingとか、技術的には飛び抜けて新しいことはなかったですが、タイトルに合うような様々な工夫を聴けて面白かったです。

メモ

  • ライトマップなし・動的ライト/シャドウのみ・ディファードライティング採用
  • ディファードライティング:スクリーンスペースでライティングを生成
  • デカールはジオメトリバッファをアルファブレンド合成。正確ではないが問題ない結果
  • 半透明オブジェクトは、2回のディファードライティングを行う。計算コストを減らすためにバッファを縮小
  • アンチエイリアシングFXAAは今年発表されたけれど、既に幾つかのタイトルで採用されている
  • 天球レンダリングは、ミー散乱とレイリー散乱をシミュレート。任意の時間をレンダリングできる
  • グローバルシャドウは、スクリーンスペースでシャドウマスクを生成して、ライトを減衰させる
  • シャドウに対して優先度をつけて、描画負荷、メモリ使用量を一庭に抑える。 優先度は、カメラから見える・カメラとの距離・スクリーン投影面積でつける
  • 良かった点:動的な時間変化が表現可能、ライトマップを使用しないので、変更がしやすい・作業工程が減少、動的な影に利用により表現の幅が増えた
  • 改善すべき点:アーティストが描画負荷を簡単に把握できる制作環境が必要。もっと沢山のシャドウが必要

後半は、広大なオープンワールド上に存在する木や草を扱う話。木を部分に分割して、個別に動かすだけでも随分と良い動きをするなあ、と感心して見ていました。こちらも品質やコストに応じて、適した方法を選んでおり、こういった工夫のノウハウは大事だと感じました。

メモ

  • インスタシングとビルボード
  • 木の揺らし情報はDCCツールで付加してから、MT Framework上で生成。 テクスチャの種類・描画パス・LODで木を部分にクラスタリング。クラスタ内のテクスチャ情報などから重みを付与。大量にデータを作ることが用意
  • ゲーム中の風は、常に流れている全体風と、ゲームイベント連動するポイント風。ゲームイベントは、嵐や爆発など。
  • 風で揺らす仕組みは、波の方程式。 水面の屈折度に近い処理をモデルの頂点に与える。
  • 木をクラスタに分けて、クラスタごとに揺れ方がことなるため、それっぽく揺れる木を作れる。
  • ビルボードに対しても、インスタシングで使った揺らし情報を再利用。
  • 草はDCCツール上で、頂点カラーで草領域を定義。 MT Framework上で草領域に草を生やす。
  • 草はフォワードライティング。地形のアンビエントオクルージョン・ライトマップを参照。 ディファードライティングは草に不向き。 描画時のオーバドローが過負荷。将来的にはディファードシェーディングで対応。
  • 草は、描画領域を倍にすると描画コストが4倍になるので、LODや、クラスタ単位で間引くなどを行うことで、なるべく違和感ないように描画コストを削減。
  • 良かった点:条件設定に基づくデータの作成。物量をこなせる。変更しやすい。
  • 改善すべき点:直感的ではない操作性。満足できる条件を探すのが大変。DCCツールからプレビューまでが長い。

Kinect専用フリーローミング型ゲームを題材に、ジェスチャ認識をゲームに取り入れる時に考えること

三宅 俊輔 (株式会社セガ)

Kinect対応ゲーム「RISE OF NIGHTMARES」を作る際に、ジェスチャ認識をどのように作ったかという話。当然ですが、ジェスチャ認識を利用するゲームは、上手くジェスチャを認識することが必要となります。このチームは誤認識がなくなるまで、とにかくサンプルを収集するというアプローチを取りました。開発が進む中で、サンプルを収集して行った過程でのワークフローの改善や、収集して分かった傾向などが、具体的な例で紹介されたので分かりやすかったです。私もKinectでジェスチャ認識をやったことがあるので、いくつかの苦労は実体験として共感できました。普段、私が出ているコンピュータビジョンや機械学習の勉強会でも見られる似たような話ではありますが、ゲームの場合、実際に動くことが目標なので、より泥臭い感じの話で面白く聴いていました。このような話を聴くと、ゲームは大きな応用先として、研究者のモチベーションとすることは良いことだと思いました。

メモ

  • 足の開き、腰の回転で移動
  • 手を掲げるとポインタ操作
  • 特定のジェスチャを指示されたら、プレイヤは対応したジェスチャを行う。
  • 疲れることへの否定的意見。移動のジェスチャは、足踏みだと疲れすぎるため、足を前に出すようにした。旋回は腕旋回は疲れるので、型のみで。 Kinect使うゲームは、疲れへの考慮が必要となる。
  • アバタのモーションは、アニメーション再生+ジェスチャによる補正。
  • アニメーションにジェスチャ補正する場合はラグが問題になる。アニメータに発注する段階で注意
  • Kinectを用いたジェスチャ認識は、姿勢情報+深度情報。ルールベースで実装。初期は、画面にデバッグ情報を表示し、席を立って動きながら画面を確認。席に戻ってデバッグ。その繰り返し。
  • 問題点: デバッグ効率悪い。疲れる。自分はジェスチャ認識できるけど、骨格や体型の違う他人は誤認識。
  • 対策: サンブル数を増やす。チームで誤認識が問題ないレベルになるまでひたすらジェスチャをテスト。個別のジェスチャごとのテスト。ステージ全体を通してのテスト。
  • チーム内で10ヵ月かけてサンプルを収集。不定期にチーム外テスト。
  • 改善後の開発: 仕様のサンブル収集。データの分析実装。ジェスチャチェック。問題があればデータ再生。デバッグか仕様の再考。過去のデータを再生し、チェック。繰り返し。
  • 改善した開発フローで分かったジェスチャの問題点:
  • 1.指定したジェスチャをできない人がいる。膝を痛めているなど。→ 代替手段を用意する。
  • 2. 想定外のジェスチャをする人がいる。 ドアを開けるのに手でなく、足を使う。 → ユーザの気持ちを十分に検討する。
  • 3. 想定外のタイミングでジェスチャを行う人がいる。 → ユーザの行動を十分に検討する
  • 4. 同時に認識する動作が衝突 しゃがむとほぼ同時に足を下げる。ストレートパンチとフック。→ 予備動作の検討。動作の優先度付け。
  • ジェスチャ認識が絡むと、工程数が非常に読みづらい。数日で終わることもあれば、数ヵ月かかることもある。原因が複数あるため。後から変更が少ないように初期の仕様段階でしっかり検討。
  • 難しくなるようなものとして、同時に認識する動作がある動作。繰り返しとなる動作。成立するまでしばらく維持する必要のある動作。認識結果がブールではなく連続量になるような動作。
  • 人はキャラクタの動きを見て判断することが多い。自然に動きをさせたい場合に効果的。その反対も然り。させたくないジェスチャを誘発させるような動きをさせない。
  • これだけ労力をかけてやる必要があるならば、CV研究者の大きなモチベーションになるなあ。いやまあ、Kinectは元々ゲーム用途ですがw

懇親会

学生交流会など、いくつか非公式懇親会は発生していたのですが、今回は秋猫さん(@akineko)と同じ会社の人とTwitter上で声をかけた人と一緒に飲みに行きました。CEDEC自体は、最近は毎年参加しているのですが、いつも一人で夕食を取っていました。昨年から色々と活動の場が増えたり、Twitterの知り合いが増えたりで、こんな感じで一緒に飲みにいける人もできてきて、嬉しい限りです。ただ、皆さん、悉く自分より5歳くらい年下で、どちらかというと自分は最高齢に近かったので、軽くショックを受けていました。はい。まだ私は学生です。働いていませんよ。

話していた内容は、主にCEDECの講演の内容とか感想とかです。元々、「秋猫さんにゲームプログラミングについて問い詰める」「Unityについて問い詰める」つもりでしたが、なんだか色々話しているうちに夜遅くなってしまいました。また次の機会ということで。あと、自分の無職ネタはまだまだ絶好調です。