【GDC 2011】 記事チェック

記事リンク集＋簡単な感想。随時追記予定。
★付きはオススメ。

【GDC 2011 preview】 プログラミングセッション系の事前チェック（その３）

すっかりサボってました。GDC 2011 までは後もう1週くらいですが、のんびりやろうかなと思ってます。

Direct3D 11 の演算シェイダーの効率的な使い方を紹介するスポンサーセッション。

Direct3D 11 の演算シェイダー (compute shader) はポスト処理のようなグラフィックス性能を向上させるために強力な機能で、従来 CPU 演算していた処理を代替する事により性能向上を見込める。ただ、軽微な変更が大きな影響を与えたりするので、上手に作るにはハードウェアの知識が必要だったりする。デバッグや最適化を行なう上でAMD の PrefStudioを活用してみようという話。

2013 年くらいには平均的な PC は 4 コアである事が想定され、最新のハードウェアを最大限に活用するには、Tasking を使うと良いという話。レンダリング、アニメーション、MLAA 等の並列化あたりが実例として出てくる模様。

MLAA については Practical Morphological Anti-Aliasing あたりを見るといいかも。

テスト系サーバーとか中国サーバーとかを除けば、基本的に単一の「ワールド」で運用されている EVE ONLINE でのリアルタイム分散システムを構築する上での理論や設計上の制約、運用上の問題を解説するセッションかなと思われる。

SPU ベースのディファードシェイディングのシステム設計や豊富なマテリアルの種類のサポート、HDR 関連、いろんな種類の光源、カリングやオクルージョン、最適化回りの話。PLAYSTATION3 を触る人は聴いておきたい感じがするセッション。

Windows でゲーム作る上での最新情報を大本営が発表するセッション。

XNA math、DirectX11、GPUView 、DirectX SDK のロードマップとかの紹介がトピックの模様。

【GDC 2011 preview】 プログラミングセッション系の事前チェック（その２）

Web, iOS, Android, コンソール向けの Unity のチュートリアル。作りたいものをエディタで構築したり、シェイダーの記述する基礎レベルから、アセットパイプラインの自動化や iOS, Android 向けの最適化あたりまでの話題を取り扱う模様。

自動テストがテーマのラウンドテーブル。

計算機が暇な時に自動テストを動かせば、不具合の早期発見やイテレーションの時間を削減する事ができるので便利だという話。最近、よく話題にもなっていますね。モンキーテスト、自動ビルド、ユニットテスト、静的コード解析、AI やバランスや世界構造をテストするためのシナリオ、各種性能測定あたりがキーワード。水曜日はテスト、木曜日はインフラ整備回り、金曜日はデータ収集とその活用についてがトピックのメインになる模様。

AI、プロシージャルの系譜で、ユーザを楽しませるだけじゃなくて、開発者も楽しくやる事が結果的にタイトルのクオリティを向上させるという考え方がベースというか。

kinect のダンスゲーム "Dance Central" をいかにして作ったのかを紹介するレクチャー。kinect に希望を見出してから全身を使ったダンスゲームを一つのジャンルに昇華させるまでの過程を紹介する模様。

既存の技術の延長上に乗らない技術の登場に対する対応についての実例報告という意味で興味深いセッション。意識の持ち方というより、チームマネージメントとしてどうだったのかは詳しく知りたいところ。

バージョン管理、データ処理、ライブ編集、ワークフロー間の連携等のベストプラクティスを盛り込んだ Autodesk 製のパイプラインのフレームワーク DNA を紹介するセッション。

パイプラインフレームワークが標準化すれば、対応にあたる TA も標準化が促進される事になるんじゃないかなとも思う。

【GDC 2011 preview】 プログラミングセッション系の事前チェック（その１）

GDC 2011 のセッション事前チェック。業務の都合今年も行く事は叶わない情勢ですが、トピックに触れておくだけでも得られるものは大きいので、個別に見ていく事にします。

GPU/APU を活用するような最先端の PC ゲームグラフィックス環境で使えるような様々な特殊効果を、DirectX 11 を軸に履修するチュートリアルセッション。グラフィクスエンジンやシェーダを構築する上で、高度なリアルタイムレンダリングの詳細説明と、ベンダー中立な最適化までがカバーされる。

Google がゲーム開発者向けに提供するサービスを紹介するチュートリアルセッション。Google Cloud, Chrome, WebGL, Native Client, Google App Engine, YouTube APIs あたりが紹介される見込み

Android でのゲーム開発がテーマのチュートリアルセッション。グラフィックス、サウンドの扱いから、NDK を使った C/C++ での開発の説明がなされる模様。

アプリケーションでの活用系と、よりよく使うための Tips を扱う系の 2 系統のチュートリアルがあるらしい。

物理シミュレーションの基本的なところから、アプリケーションでは流体力学、高速化テクニックでは並列化等を取り扱ったり、ツール群やプログラマ同士の連携までの至れり尽せりを 1 日で叩き込む意欲的なチュートリアルセッション。

イケてる TA になったり育てたりするためのチュートリアエウセッション。チュートリアルとなっているけど、ほとんどラウンドテーブルといった様相になるのかも。

トピックとしては、TA の地位向上、プログラマと TA の技術の違い、コンテンツを作り出すアプリケーションをいかに拡張していくのか、データベースの知識がツールやパイプラインの自己管理や新しい方法論のために拡張に役立つ事、パフォーマンスへの影響を避けられるようなシェイダーの作り方、ゲームグラフィックの限界を押し広げるような方法等。

紹介文を読んでいると前半の方の論調としてTA の重要度が増している割には、他の職種からの転籍組みが多い事、専門教育を受けて TA になった人が非常に少ない事、TA のスキルセットは非常に多彩である事、多くのスタジオで TA を「自家栽培」する文化が、TA がいまいち理解が得られずに、ある会社では価値のあるスキルセットが別の会社では意味が無いという状況を生んでいたりして「もんにょり」している事を訴えていて、TA という職種はまだまだ確立されていないんだなという印象を受けた。

今日はここまで。

【CEDEC 2010】 メニーコア対応ゲームエンジン

http://cedec.cesa.or.jp/2010/program/PG/C10_P0166.html

グラフィクス関係の新規技術を導入してもインパクトの薄い昨今、欧米に勝つためにはどうしたら良いのか。日本人は刃物が好きだし、欧米は銃が好き。日本人にとって銃は身近ではないから、合わせる方向で攻めても負けるだろう。ここは新しい流れを作っていくべきではなかろうか？ ハードウェアの進化の方向を見定めて技術的な方向からの検討を試みる。というお話。

ムーアの法則は 18 〜 24 ヶ月毎に CPU のドランジスタ数は 2 倍になる*1という経験則。CPU 屋のモチベーションにもなっている*2。微細化、消費電力や発熱の増加で単にクロック周波数を向上させる事は困難になっている。性能を向上させるには SIMD 化、マルチコアが必要だというのは、「メニーコア時代へのプログラミング言語からのアプローチ」でも言われている通り。

ムーアの法則を逆に言えば、同じ性能の CPI は 18 ヶ月 〜 24 ヶ月毎に半分のサイズで出現するという事でもある。これはメインフレーム → PC → ケータイへの小型化の歴史からも物語られる。小型化、省電力化、グラフィクス能力の向上にあたって CPU と GPU を統合したプロセッサも出現してきている*3。

将来的なプロセッサの方向としては、CPU と GPU の完全なる統合が進むであろうし、メニーコア化にムーアの法則が作用するのであれば、PPE 64 core + SPE 512 core という構成のプロセッサが出現するかもしれない*4。

そこまで極端なものは出現しないにせよ、想定しておき準備をしておかねば、対応はできないのだから、せめて考察は必要だろう。

プログラミングするにあたってのテクニックとしては、SIMD や fork-join モデルはコンパイラの支援を受けられるかもしれない。負荷分散を行なうにあたってはタスクマネージャーによって負荷の均等化を図る、タスクマネージャー自体を分散化する事によりタスクマネージャー自身の負荷を下げる、プロセス毎にメッセージのやりとりをする事によって協調してタスクの制御を行なう、終了条件の判定として双方向リング終了アルゴリズム*5の話が出た。

将来データバスが問題になるだろうという予測も考えられ、これはデータバスをメッシュ化したりハイパーキューブ化したりといった方向で対抗されるだろう *6。コアに微細化したプロセスを半ば固定的に割当りあて、これらをバスで繋ぎパイプラインを形成する事により処理能力を引き出すというアーキテクチャが考えられる。

これらを有効に利用したゲームデザインは、2^25 (=約3300万)のオーダーの個別に AI を持ったキャラを扱うゲームといったものが考えられる。点以下の情報は確率分布等で扱い簡易的に計算し、復元計算には一定の展開アルゴリズムを使うと良いだろうという示唆がなされた。

*1: http://ja.wikipedia.org/wiki/%E3%83%A0%E3%83%BC%E3%82%A2%E3%81%AE%E6%B3%95%E5%89%87

*2:予言の自己成就ですね

*3:fusion APU 然り、PS3 なら PPE+SPE、XBOX360 なら XCGPU といった具合。

*4:ただ、この話は単純化しすぎの話であって、ある意味冗談レベルの話

*5: http://www.is.kyusan-u.ac.jp/~bob/para04-part6ap.pdf

*6: http://ja.wikipedia.org/wiki/MIMD

【CEDEC 2010】 画像認識技術とゲーム・インターフェイス

http://cedec.cesa.or.jp/2010/program/PG/C10_P0129.html

昨年からの引き続きのセッション。結構楽しみにしてました。

EyeToy から EyePet へ

PlayStation2 で発売された EyeToy は認識を「動き差分」で実現していた。動き差分とは前のフレームと今のフレームの画像の差分をピクセル毎に取ったものである。負荷も低く、高ロバスト性を示す。

PLAYSTATION3 で発売された EyePet は当初背景差分*1で実現していたが、2 〜 3 分も動かしているとカメラの揺らぎ等でノイズが蓄積して認識精度が下がる。また床のカーペットが大きくずれるなどすると一気にノイズだらけになってしまう。そこで EyePet では動き差分に回帰した。

スクリーンを格子状に区切ってスイッチのように扱う。スイッチのエリア内で一定以上の動きを検出したら押された事にして、ユーザーとのインタラクションを実現する。「なでる」のようなペットキャラとの関わりは動的にスイッチを生成して動きの検出を行なう。ＢＧとスプライトの関係みたいな感じ。

ユーザーの没入感を壊さない*2ためには、激しい変化があった場合にペットが逃げ惑う等の回避アクションでユーザーの動きを抑制するよう演出で誘導する。また仮想世界内のアイテムを使ってペットと戯れるというギミックにより直接触る事を避けて安定度とユーザーの楽しみを両立するというシステムを取っている。表面にＡＲマーカーが張られている盾のようなもの*3を用意して、マーカーをカメラに向けさせる確率を高めるという工夫もしている。

実用に於いては演出やギミックで認識の安定性を高める工夫が重要である。

物体認識

「物体認識」と一口に言っても、いろいろある。Categorization はカテゴリーが多すぎて対応が大変。

Verification 画像中の指定したものが指定のカテゴリーのものなのか判定する
Identification 画像の中から特定の個体を発見する
Detection 画像の中から指定のカテゴリーの物体を発見する
Categorization 画像中に含まれる要素が一体どんなものであるのかを識別する

画像認識の研究史は以下のような感じになっている。

1980 年代 線画マッチング
1990 年代 グローバルマッチング
2000 年代 ローカルマッチング (局所的なマッチング)
2010 年代 ???

画面全体を見るグローバルマッチングではなく、画像の一部を見る局所的なマッチングを行うのが今の主流。
入力画像から特徴点を抽出し、特徴量を抽出し、学習や認識を行なうやり方である。

特徴点とは、画像のうち着目点になる点であって、コンピュータにとって都合の良い点が選ばれる。具体的な手法としてはハリスのコーナー検出がある。特徴量の抽出で特徴点から何を見るべきパラメータを抽出したりする。例えば SIFT という手法であれば特徴点付近の画像情報を使ったりする。

得られた特徴量を使って学習や認識を行なうのが画像認識の流れになっている。

これからの画像処理

これからの課題として以下が挙げられた。

  • より認識が難しいものを認識する: 顔や車といったものは成果が得られているが、人、馬、犬はまだ良い成果が得られていない。
  • シーンセグメンテーション: パーツを分割して、それぞれに意味を与える。車は空に浮いていない、とかのコンテキスト情報(知識)を使う事が有力でないかと言われている。
  • 平面画像からの 3D 認識。
  • 多くの物体の認識

画像認識の動向を追っていくには ICCV とか CVPR 等の学会の流れを追っていくと良いだろう。

まとめ

来年も楽しみです。SLAM とかやらないかなー。

*1: http://ja.wikipedia.org/wiki/%E8%83%8C%E6%99%AF%E5%B7%AE%E5%88%86

*2:「作られた世界を維持する」という表現が使われていた

*3:マジックカード

【CEDEC 2010】It's a showtime!! -DISSIDIA FINAL FANTASYのAI設計-

http://cedec.cesa.or.jp/2010/program/GD/C10_P0124.html

「全ての仕様は根本の部分で繋がっている」

「分けて考える」

DISSIDIA FINAL FANTASY は対戦アクションゲームであり、その CPU サイドの AI に要求される性能として以下が挙げられる。

  • 短い時間で個性が表現できる事
  • アクションとして手応えのある強さ
  • バリエーション
  • FF らしい事。戦闘でキャラが魅力的に見えない事には意味が無い。

1 つのタイミングで伝えたい事が多すぎると受け手には伝わらない。確実に伝えるためには内容を絞る必要がある。これらの要求を実現するためには「分けて考える」事にした。具体的には以下の戦略を採った。

  • 時間を区切り、いつ何を見せるのかをはっきりさせた。
  • 性格とスキル(ここでは AI としての強さ)を分けた。

この戦略を実現するにあたって、戦闘の流れを想定しアクション毎に区切る事で時間を区切り、それぞれの仕切りで性格とスキルのどちらを表現するべきかを考察した。例えば以下のようになる。

→時間 移動 攻撃 反撃 移動 割り込み 攻撃 … …
性格の表現 ● ● ● ●
スキルの表現 ● ●

性格とスキルについても、細かく定義をしていく。ただ、全部が割り切れるわけではなく召喚のように性格にもスキルにも依る行動も考えられる。

  • 性格
    • 様子見行動
    • 残ＨＰによる変化、ピンチ時の行動
    • etc..
  • スキル
    • 回避、ガード。
    • 攻撃距離
    • スキに対する対応
    • 敵の攻撃レンジに入った場合の行動
    • スキの長さ

処理の流れ

AI 処理の基本の流れは、「状況判断 → 指針決定 → 行動選択 → アルゴリズム実行」の 4 つのフェイズに分かれる。

  • 状況判断では、自分のＨＰ、相手のＨＰと、ブレイブの値から「攻撃」「通常」「守備」等の指針を決定する。
  • 指針決定では、該当の指針から「好戦的」「ノーマル」といった行動セットを選択する。
  • 行動選択では、行動セットの中から「接近」「攻撃」といったアルゴリズムを選択する。
  • アルゴリズム実行で、最終的な行動が生成される。
データ駆動

キャラの AI 、特に行動決定は主にデータ設定により実現される。データ化する事によって待ち時間を短縮する事ができ沢山存在するキャラクターの設定を現実なものとしている。

全ての攻撃アクションには

  • 得意な間合
  • 攻撃の射程
  • 攻撃への対応方法

が設定されている。

状況から指針の判断、指針から行動セットの判断等もデータ化されており、多彩な AI を作り出す事ができる。

アルゴリズム

攻撃系のアルゴリズムは移動→攻撃アクションで構成される。あまり長々とした行動になると意味不明のアクションに見えてしまう。

待機系のアルゴリズムにはいろいろバリエーションがある。性格を表現するのに便利であるが攻撃の頻度が下がるとユーザーには退屈だと感じられるので要注意。

防御系のアルゴリズムは攻撃を見てから差し込んでいる反射型の挙動である。割り込み系の処理となるので、バグが顕在化しやすくユーザーには超反応であるように感じられてしまう。

移動系は A* により経路探索をしている。目的地の設定に特徴があり、プレイヤーの移動先に設定される。これにより、移動の駆け引きがより人間らしく感じられる効果が得られた。

問題解決にあたって 〜 ユニバーサルチューニング

問題解決にあたっては今までのアプローチの延長でなくて、まったく違った側面からのアプローチが必要。

防御系が超反応であるように感じられてしまう問題に対して、反応タイミングを遅らせた。結果として AI が弱くなってしまったが、強化学習により強化を図った。具体的には攻撃の前に回避かガードを挟み込む。プレイヤーの行動を解析し、失敗行動を抑制するようにした。

まとめ

実際の問題解決の過程では試行錯誤が見られたようだが、きちんと課題を認識してコンセプトに沿った問題解決を図る思考様式は、大量のデータ作成時のクオリティ確保に寄与し、繰り返しによるクオリティ向上をより一層豊かなものにするという結果に繋がっていると確信する。