Miyabiarts.net

一年に一度の更新頻度

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

2016年

今年の年末は昨年に輪をかけて何もやっていないので、生存報告だけ。

来年はブログを移転する予定です。

2015年

三年連続の大晦日のみの投稿です。Twitterの方には大体いつもいるので、生存報告の役割すらここにはないようです。

今年というかここ数年は仕事 イズ マイライフな状態なので、趣味で何か作ることは少ないです。正確には小さいものを色々作っていないこともないですが、ある程度作ったら割と自己満足するので、特に後悔することもなく闇へと葬っています。しばらくはこの調子だと思いますが、そのうちまた何か出すようになるかもしれません。

今年は「ラブライブ!The School Idol Movie」を映画館に50回見に行ったり、BD届いた日から毎日見ていたり、そんな感じでした。スクフェス ラブライブスクールアイドルフェスティバル始めたら毎日結構な時間していたり、毎週ゲームセンターでクレーンゲームした結果、いつの間にかプライズが40個以上集まって自室の結構な領域を占めていたりします。例年通りゲームも年間100本くらいは確実にやっているはずです。来年は大作ゲームが多数出るのでさらに楽しみです。生き方の方向性が完全に決まってきた気がする今日この頃です。

年末年始のお休みで毎年何か適当なものを作っているのですが、今年は12月に発売したRPGツクールMVで何かRPGを作ってみようと思いました。そして、RPGツクールMVのエディタを触っていたら、データベースまわりでデータの追加・削除をあまり自由にできなかったので、そのあたりができるツールをちまちまと作っていました。RPGツクールMVでは、ゲームに必要なデータがjson形式で置かれているので、それを読んで編集して書き戻しています。追加・削除・並び替えなど基本的な操作はすでにできているので、足りない部分はその都度追加・修正していこうかなと思っています。公開するかどうかは気分次第です。

rpg_editor

ただ、元々の目的は何かRPGを作ることだったので、ひとまずそちらの方は進めるつもりです。こちらはいつまで続けるかは分かりませんが、まぁ飽きるまでということで。

2015年は良い年だったので、来年も引き続き良い年にしたいですね。

2014年

見事に二年連続一年越しです。

数日前からUnityでオンラインゲームを作り始めたので、2015年はしばらくこれを作っているかもしれません。

uco3

2013年

来年こそは何か書くかもしれません。

2012年

結局、これが今年3つ目の記事になるとは。 社内ブログの方は結構書いていたりするのですが、こちらは放置しすぎですね。 まぁ気が向いた時にでも、ということで。

今年について

人生が結構動いています。 3月に博士(情報科学)を取得。 4月から会社で働き始めました。 実家関連でも色々とゴタゴタしていたこともあり、例年よりもあっという間に過ぎ去った1年でした。

仕事はとても楽しいです。楽しくてあっという間に月日が経ってしまいました。

そして、働き始めることで比較的安定した生活リズムを得ることにより、コンテンツ消化能力が格段に向上。

  • ゲームを70本くらいプレイして、50本くらいクリア
  • 映画館で映画をのべ43本鑑賞
  • 漫画・アニメは数えてなかったですけど、だいぶ見た気がする

今年の抱負について

達成できたり、部分的に達成できたり、全くダメだったり、と、そんな感じです。 もう個々に触れることはしないです。

来年について

まともに更新するかは分かりませんが、気が向いたら更新します。 来年もよろしくお願いします。

区切り

随分と間が開いてしまいましたが、色々と区切りの時なので久しぶりの更新。参加した勉強会の記事なんかも実は書いていたのですが、中途半端だったので載せずに放置していました。

2012年が始まってから本当に色々なことがありましたが、大きくは以下の事項ですね。

  • 就職先が決まりました。
  • 博士(情報科学)を取得しました。
  • 名古屋CV・PRML勉強会を新しい幹事に引き継ぎました。

それぞれに対して語れば長くなることがあったりしますが、それはまたその内ということで。これまでお世話になった方々、本当にありがとうございました。そして、これからもまた頑張っていきたいと思います。

今年の抱負

2012年も明けたということで、新年の抱負でも書いておきましょう。(随分遅くになって書いていますが)

大体、去年と同様な感じで。

  1. 新天地:とても長かった学生生活に終わりを迎えそうです。まだ新天地は見つかっておりませんが。
  2. 名古屋CV・PRML勉強会: 名古屋から去る可能性が出てきたので、次の世代にバトンを渡したいと思っています
  3. その他の勉強会: 学生じゃなくなるのでどうなるかは分かりませんが、できる限りは出ます
  4. ブログなど: また停滞しているので、もうちょっと書きましょう
  5. プログラミング: 今年こそ3Dモデリングソフトを機能をまとめる
  6. ゲーム制作: 小さいゲームは作ったりしているので、もっとまとまったものを作りたいですね
  7. ギター: 作曲なんかもしてみたいですね
  8. 読書: 読むだけではなくて、なるべく書評も書くように
  9. 絵・3Dモデリング: 練習できるだけ練習
  10. 体重: 80kg以下にまずしましょう

今年のまとめ

今年のまとめを、今年の抱負に対応するようにまとめてみます。

1. 研究: 効率を上げる(PDCAサイクルを心がける)

分かっちゃいるけど、結局上がらなかった気がしますね。来年以降も継続ということで。主な原因は、実験がうまく行かなくて、それをなんとかするために近視眼的になりすぎたことだと思います。博士課程の最後と言うことで、まとめようと気負いすぎたことも原因だったかと思います。

2. 論文誌: 最低1本通す

最低限の1本はクリアしました。おかげで博士後期課程を修了するための条件はクリアできました。

3. 名古屋CV・PRML勉強会: 1年間継続

多くの方々の協力もあり、なんとか1年間継続することができました。関東や関西のコンピュータビジョン最先端ガイドを読み進めることと違い、名古屋は毎回異なるテーマを扱ったりして、なかなか難しい所もありましたが、その結果大変面白いものになったかと思います。今後も続けていくことで、よりこの分野に関わる人が増えていくことを目指していきたいと思います。

4. その他の勉強会: IT関係で暇だったらなるべく参加する

関西ゲームプログラミング勉強会、Boost.勉強会、Qt名古屋勉強会、LL名古屋など、色々な勉強会で発表してきました。他にもわんくま勉強会などに参加したりで、本当に勉強会に充実した1年でした。

5. ブログなど: 文章の練習も兼ねて、なるべく更新するようにする。ただし、更新することが義務化しない範囲で

半年くらいまではそれなりに更新していたのですが、後半の数カ月は忙しさを理由にまったく更新していませんでした。反省。

6.  プログラミング: 3Dモデリングソフトを機能をまとめてそれなりのものにする

作る作ると言っておきながら、まったく進みませんでしたorz

7. ゲーム制作: なんとか一作完成(コミケとか出せたら良いな)

ちゃんとしたゲームは作れなかったのですが、Unityの使い方なんかも分かってきたので、もっと色々なことができるゲームを作ることを目指していくつもりです。

8. ギター: 暗記して弾ける曲を最低5曲

一応ジブリとファイナルファンタジーの楽曲を数曲は弾けるようにはなりました。ひっかかりまくりますが。

9. 読書: 積んでいるオライリーや洋書を出来るだけ消化

結構読むことはできたのですが、書評を書かないといけないなと思っていたので、来年から書いていくことにします。

10. 絵・3Dモデリング: 練習できるだけ練習

0ではなかったのですが、全く上達しませんでした。

11. 体重: 80kg以下をキープ

無理でした(´・ω・`)

12. 就職活動? : どうなることやら

まだまだ続くのじゃよ。

CEDEC2011 3日目

情報化社会、インターネット、デジタルアート、日本文化

猪子 寿之 (チームラボ株式会社 代表取締役社長)

メディアと日本文化を融合させることで新しいアートを切り開いたり、コンピュータを使った面白いものを沢山作り出しているチームラボの猪子社長の基調講演。前に飛行機の機内番組でチームラボ特集をやっていたのを見たことがあるため、猪子社長がどんな人物であるかはなんとなく分かっていたのですが、予想通りその場で考えて話すタイプなので、面白い事を言っているけど、なかなかまとまらずに伝わらない感じでした。映像再生のためにWindowsのエクスプローラからファイルを探したり、該当箇所をシークバーで探すなどの細かいところで話の腰を折ってしまうのも、話の世界から遠ざけてしまうので、このあたりは基調講演でありますし、しっかりと準備してきていただきたいと思います。

上のこともあって、話全部を覚えているわけではないのですが、講演の内容は、日本文化がどういうものであるのか。今あるものが昔からあるものとどうつながっているか。ということが多く語られていました。こういった対比は面白いのですが、ゲームの話に関しては、それは後から意味付けをしたものであって、当時の開発者たちは考えていたわけではないだろう。という感想を抱きました。

講演本体が終わってから、会場の方や司会者からの質問に猪子社長が答えていたのですが、ここが一番面白かったです。この人はきっと一方的に何かを語る。というよりも、人とインタラクションすることでアイデアを高めていくというタイプの人間ですよね。質疑応答の時のほうが、とても人間的な魅力を感じました。

メモ

  • 芸術とプレゼンの違いはあるとは思うけど、表現を扱っているなら、こういう場所での見せ方ももうちょっと拘って欲しいかな。映像再生のためにWindowsのディレクトリに行ったり、シークバーで探すなどの細かい部分が気になってしまう。
  • 比べたいというわけではないですが、その点を考えると、昨年のMIT 石井裕先生は徹底して表現に生きているな。と感じました。
  • 日本の庭は3次元的でレイヤー構造で、横に歩いて美しく見える。 西洋の庭はパースペクティブで、正面に歩いていくことを想定しており、横方向に歩くとレイアウトが崩れる。
  • 横に歩いて見える文化が、マリオにつながっている。
  • 日本の大和絵も、ドラクエにつながっている。
  • ゲームに関しては(特にゲーム開発黎明期)、その映像表現が技術的制約からきたものであることが多いとは思うけど、まぁ技術者がその時に技術レベルで出来る限りのことをしたことを、後世の人達がより文化的な背景を見つけようとするのは、ゲームに限らず良くあることかな。
  • 「言語化できない特有の積み重ねが、最大の強み。」というのは感情的に支持したいとは思う一方で、特定の人にしかできないことを誰にでもできるように言語化・システム化・大衆化していくことが技術者の矜持でもあったりするので、そこは難しいところだな。
  • あれや、人類全体が言語ではなく、感覚を共有するようにして、うまく言語化できないものを皆がなんとなく理解できるようにできる仕組みを作ればいいんや。 なんだかそんな設定の映画かアニメあったような気がするけど忘れた。それが実現された社会がどうなったかも忘れた。

『時代を超えるキャラクターと世界を創る』 ~ボトムズからのメッセージ~

髙橋 良輔 (大阪芸術大学)

 

メモ

  • 大学でアニメーションを研究している先生方が、驚くほどアニメーションを知らない。
  • 虫プロダクションは、手塚治虫先生がまず漫画好きで、集まった人たちも中学生くらいからプロの漫画家として活躍する人がいるほど漫画好きだった。
  • 手塚治虫は、元々極東のディズニーを作ろうとする東映を手伝っていたが、思うことあってか、自ら虫プロダクションは設立した。
  • 手塚治虫は、「アニメーション」と「TVアニメ」を区別して呼称するように指導していた。
  • アトムには、多くのシナリオライターが参加した。今言えばあの方か、と言われるようなSF作家の人もストーリーを作っていた。
  • ある意味で、手塚治虫が大きなお兄ちゃん向けのアニメの文化を作り上げる基盤となったとも言えますね。
  • アニメーションはお金がかかる。 アトムの頃は一社提供が多かった。 それがアニメ界を支えてくれた。 宇宙戦艦ヤマト・ガンダムの頃からは、複数のスポンサー提供になり、関連グッズがアニメ界を支えた。
  • ガンダムなんかも、お金がカツカツの時に生まれた作品ですね。
  • 技術の進歩により、コピー商品が増え、パッケージビジネスに大打撃を与えている。
  • 「有能な人は有能な人を見つけるので、なかなか私のところには来てくれない。何年も鳴かず飛ばずの人を頼りにしていた。」
  • 仕事をしてくれる人を悪く言う会社はない。 次から仕事が少なくなることはあるけど。
  • 企画を100本考えて、1本が映像化されれば上々。

ゲームにおける破壊

原田 隆宏 (AMD) ほか2名

 

メモ

  • パーティクルベースの水面シミュレーション。GPUのアーキテクチャに適している。
  • 水面シミュレーション。パーティクルの衝突。統合。 衝突のためにいくつかのアクセレーション。一様グリッドがGPUに適している。ダイバージェンスの計算。
  • パーティクルの衝突計算。パーティクルが一様グリッドのどこにいるかを計算。GPUに適した条件としては、異なるパーティクルのサイズが大体同じ程度であること。計算の領域が変わるため、スレッドごとの計算のムダが多くなる。
  • 大小のパーティクルが存在する場合、それぞれの大きさで計算した後に統合。小さいサイズのパーティクル間はGPUで計算。大きいサイズはCPUで計算。同期を取りながら結果を統合。
  • マルチコアCPUのために大小のパーティクル間の衝突に対して、更なる最適化。 スレッドを使って共有メモリに書き込み。
  • 小さいパーティクル間の衝突にCPUを利用することで、更なる改善。 パーティクルをZ curveに並べることでキャシュヒット率を上げる。このソーティングにCPUで行う。基数ソート。

メモ

  • 事前に破壊する場所を与えたモデルを作し、ランタイムで破壊する。
  • ConvexとConcave
  • Voronoi Scatterで3Dモデルを分割。MAYAで動くコードがGoogleCodeにある。Blenderにもスクリプトがある。
  • Convex Decomposition Sourceforgeにコードが存在。
  • Tetrahedraへの分解もSourceforgeに存在。
  • リアルタイムにブーリアンで地形を破壊するデモがGoogleCodeに。
  • いくつかのパーティクルを接続した物理シミュレーションがBulletに組み込まれている。
  • GPUへの有限要素法の実装が行われている。 恐竜がプニプニ。
  • 剛体のシミュレーション。Box2D。絵が思いっきりAngryBird。
  • Composit method 事前に破壊したデータと破砕面の接続、破壊される限界を決めるしきい値をアーティストが作成。ランタイム時にしきい値以上の力がかかったら、接続を切る。
  • 静的有限要素法を用いて、剛体を分割する手法もある。
  • Blender上での破壊デモ中。
  • アドインで、Fractual Objectを入れて、有効にしておく。
  • MAYA上での破壊デモ中。

超シンプル物理!~「ドラゴンズ ドグマ」での衣服/髪シミュの秘密+剛体/ラグドールへの拡張~

松宮 雅俊 (株式会社カプコン)

メモ

  • 「超シンプル物理!」
  • パーティクルの並進運動のみで物理シミュレーション。 蛇の多関節IK。IKチェインによる髪の毛。ソフトボディによる布。剛体。ラグドール。
  • Verlet物理の復習。 いきなりシンプルじゃない気がw
  • PixelJunkシリーズとかがVerlet物理を使っている。
  • Verlet積分:位置を直接動かすことができる。 速度のつじつまが自動的にあう。位置と速度がずれないので安定。 現在の位置と速度ではなく、現在の位置と前の位置を保存しておく。
  • スティック拘束:パーティクル間の長さ(距離?)を維持する。Verlet積分の特性により位置を動かすだけ。
  • スティック拘束をチェインにするだけで、揺れものができる。 上位の拘束から順に計算。
  • sqrtは重いので、近似計算を行う。 √a ≒ r + (a-r^2)/r
  • コリジョンは、各パーティクルの位置を形状外に押し出すだけ。
  • チェインの姿勢と角度制限:姿勢はバインドポーズからの最小回転で算出。コーン形状により角度制限。コーンの軸に直交な平面上に投影し、xの比較のみを行う。範囲を超えていたら制限位置に戻す。
  • ヘビIK:目標位置を決める。現在位置と目標位置をバネモデルで近づける。あとはスティック拘束とコリジョンが面倒みてくれる。
  • ソフトボディは、キャラクターの服・マント、ライオンのたてがみ、やぎのヒゲなどに使われている。
  • スティック拘束は逐次処理なので、互いに独立した処理群に分割してからGPU計算。 トポロジーが変化しない場合は事前計算。 SPUでは、1SPUのLSに入る頂点数分をLSに送って逐次処理。 今回は入り切れない場合などはなかった。
  • コリジョン:画像ベース テクスチャに保存した高さフィールドとのコリジョン。 背景やキャラクターを高さフィールド化。
  • ドラゴンズドグマでは、Verlet剛体・ラグドールはまだ使われていない。
  • Verlet剛体:4パーティクル。6スティック拘束。質量=4パーティクル質量合計。慣性テンソル=4パーティクルの質量配分と配置。四面体で配置:重心座標系で配置。多面体で最小の頂点・辺・面であるため採用。
  • Verlet積分なので、位置を移動するだけ。コリジョンは物体形状。 衝突した位置から、4頂点をどう動かすかが重要。衝突しない位置までの移動量を4頂点に分配。このときに重心座標に応じて分配。
  • 摩擦:頂点移動を行う際に、摩擦面に投影したベクトルに摩擦係数を掛けることで、擬似的に摩擦を計算。
  • ボールジョイント:4頂点の位置をジョイント位置に移動するだけ。 ヒンジジョイントのために、ボールジョイントに最小距離を加える。
  • ヒンジジョイントは、ボールジョイント1個、最大距離ジョイント3つで表現。
  • 最大距離で関節角の制限を行うことができる。 どう計算するかは、今回は割愛。
  • 四面体は形状よりも大きくても問題ない。
  • モーション駆動ラグドール。 基本はモーションによる位置・姿勢に合わせてVerlet剛体の4頂点位置を動かすだけ。 2フレーム動かしてラグドールに切り替えれば、モーションからラグドールへスムーズに切り替え。
  • 本当に超シンプルだった。
  • しっかりするならインパルスベース。 簡単にそれなりにするならVerlet。

CEDEC CHALLENGE: 3Dアニメーター列伝!メイキング特別講演

橋本 トミサブロウ (株式会社サテライト) ほか3名

異なる会社の3名(+1名)に、「伝説の剣を引きぬく勇者」というお題を与えて3Dアニメーションを作ってもらうというものでした。全編通して映像を見せながらのものだったので、説明は難しいですが大変面白かったです。プロが実際に3Dアニメーションをつけているところを見たことがなかったので、スクリーンを凝視していましたよ。自分が一番気に入ったのは、最初のセガの方の足で剣を引きぬくスタイリッシュ剣抜きでした。

モーション付けのやりかたは今のところ全く分からない(操作というよりも、感覚的なものですが)ので、時間が空いたら少しずつでも覚えていきたいなと思います。年が明けたら少しは時間があるはず。

新・ゲームAIを横浜で語る

南野 真太郎 (ポリゴンマジック株式会社) ほか2名

Twitterを見てれば、どれほどAIを愛しているかが分かる三宅陽一郎(@miyayou)さんを一目見ておこうと思って、参加しました。ラウンドテーブル形式で、参加者を含めての討論大会でしたが、少し盛り上がりに欠ける感じでした。自分もTwitterのハッシュタグで数件つぶやいていたりしたのですが、ちょっと残念な感じに。

なかなか議論が行われなかったので、色々なイベントの宣伝に入ってしまい、そしてそのまま終わりの時間が来てしまいました。何気にラウンドテーブル形式のセッションは初めてであったため、惜しい記憶とともに刻まれるでしょう。でもまぁAIについては、@miyayouさんをフォローしておけば、今後も充実するので満足しておきましょう。

 

という感じのCEDEC2011の3日間でした。毎年真面目に参加している方ですが、今回は特に技術方面でしっかりと勉強した感じです。後は、参加して勉強したつもりになるだけではなく、いくつかは自分で実装したりすることで、ちゃんと技術として身につけることですね。ついでにですが、今回おそらくCEDEC関連で一番つぶやいたのは私でしょう(笑)

CEDEC2011 2日目

「ムーンショット」 デザイン幸福論

奥山 清行 (工業デザイナー / KEN OKUYAMA DESIGN 代表)

ホテルでダラダラしていたら、思いっきり遅れていくことになりました。正直、工業デザイナーなので聞かなくても良いかなあ。と最後の15分ほどだけ聴いていたのですが、全部聞けば良いなと後悔しておりました。

自動車の自動運転に関する話は、直接というわけではないですが、今大学で行なっている研究にも近いことであるので、野心的だと思って聴いていました。確かに、環境が整えば自動運転は可能だとは思うのですが、現実の環境では、歩行者がいたり、想定外の事象が多く発生するため、この点をどう解決していくかというのは非常に興味深いところです。

聴いていないところはあとから記事を見て補完したのですが、「来るかどうか分からない15分のために準備するのがプロ」というのは良い言葉ですね。

ショートセッション: リアルタイムCG技術の先端

五反田 義治 (株式会社トライエース) ほか5名

前半はグローバルイルミネーションレンダリングの基礎的な話。基礎的な話と言っても、今回は式が多く出てきたので、初めて聴く方で、普段数式とかに触れていない方にはつらいのではないかなという印象は受けました。私は、ここらへんの話は個人的に色々やってきたので、復習がてらに聴いておりました。

内容は、グローバルイルミネーションレンダリングの基本となるKajiyaのレンダリング方程式の説明から入り、BRDF(双方向反射分配関数)、反射モデルをLambertにしたときの具体的な式展開という順番で行われました。また、そのまま実装するとリアルタイムでは動かないため、どのように実装するかの簡単な話で、実際に実装する話については午後のセッションとなりました。(午後のセッションは、私は聴いていません。)

メモ

  • セッションの目的 Kajiyaのレンダリング方程式を解いて、物理的に正しいレンダリングを行う。
  • 放射輝度。それを領域で積分した放射照度。それを時間微分した放射束。
  • ここらへんはPBR本とか、Jensenのフォトンマップ本に詳しく書かれていますね。
  • ある地点の放射輝度=反射光+発光。反射光はその地点に入射する半球全ての光と反射特性であるBRDFから決まる。
  • BRDFの物理的制約: エネルギー保存の法則、入ってきた光と出ていく光の総量は等価。可換性、入射角と反射角を入れ換えてもBRDFの値は変わらない。
  • レンダリング方程式には再帰性があるので、そのままだと解けない。→ パストレースなどの近似解法。
  • Lambert、というか間接光をシェーダで扱う方法。放射輝度マップをキューブマップで用意し、シェーダで参照。
  • そのまま実装すると計算量が半端ないので、大胆な近似が必要。球面基底関数を利用したPRT系など。
昨年のCEDEC2010のポスタで見た話ではあったのですが、今年はオーラル形式で聴講。半透明物体をラスタライズ形式でレンダリングすることは、今まであまりやられておらず、また難しい問題だったのですが、BRDFに反射面の曲率を加えたCRDFを考えることで、これを解決するという発表でした。原理を簡単に言ってしまえば、通常は入射光と法線のなす角が90度を超える場合は、視点から見えないので、レンダリングしないのですが、このような箇所から光が見える領域に滲み出るようにレンダリングすることで半透明物体を表現していました。
学会発表みたいだと、Twitterでつぶやいていたら、講演者にリプライを受けました(笑)。発表自体は大変分かりやすかったです。

メモ

  • BRDFに表面の曲率を加えたCRDF
  • 物体表面に曲率を持たせることで入射光と法線が90度を超えるような箇所の光を滲み出させることによって半透明物体を表現。

物理エンジンを利用したクリーチャーのプロシージャルアニメーション

辛 孝宗 (株式会社バンダイナムコゲームス)

前日の別のプロシージャルアニメとはちょっと趣が異なったのですが、こちらは多足クリーチャに対して、プロシージャルにアニメーションをつける話でした。対象とするクリーチャーはクモ型で、メインボディに2関節を持つ脚が付いているようもので、このクリーチャーをどのように制御するかについての話でした。序盤の方は、一般的なロボット制御の話で、単純な制御から問題点を解決して、一般的に用いられる制御の式を導きだしていたのですが、ここらへんの話はちょっと冗長だった気がします。最後の方は、CGだとそのまま式を使ってしまうと安定し過ぎてしますので、いかにバランスを崩すかという話になり、いかにバランスを取ろうかとする現実のロボット制御の話とは正反対の話で、聴いていて興味深かったです。

メモ

  • プロシージャルアニメーション: 作ったアニメーションをベースにインタラクティブにアニメーションを生成。
  • 肩ジョイントは2自由度のUniversal Joint 肘ジョイントは1自由度のHinge Joint
  • 足が増えると、足を上げ下げするタイミングを考えないといけない。
  • 物理エンジンでジョイントの角度を制限
  • 旋回するときは、旋回方向の足の上げ下げの周期を変える。ボートのオールのように。問題点は安定過ぎるため、演出に向いていない。
  • つまるところ目標の関節角を与えて、そこに近づけるような逆運動で、そのままの目標関数がばねモデルで振動する。そのため、ダンピング項を加える。さらに、目標値に届かなくなる場合が起こるので、それを考慮した項をくわえる。というロボット制御では極めて一般的な話かな?
  • メインボディの6自由度の位置、姿勢と、足のジョイントの制御をどうつなげるか。
  • CGだと安定しすぎてしまうので、Zero Moment Pointを考慮するなどして、わざとバランスを崩す。
  • ロボット工学と違うところは、ロボット工学はバランスを取るために色々工夫すること。CGではそれっぽく動かすためにバランスを崩すことに色々工夫すること。
  • さっきから足をぶちぶちと切られる8足キャラクター スパイダーくん。

SpyPartyの初期ベータマルチプレイヤーゲームアーキテクチャ

Chris Hecker (definition six, inc.)

一世を風靡したMinecraftと同じビジネスモデルで、次に来ると言われているSpyPartyの作者の講演でした。「ゲームデザイン」ではなく「ゲームアーキテクチャ」というところを間違えたのが悪かったのですが、正直良くわかりませんでした。最初に本人も言っていたのですが、早口過ぎて何言っているかわかりませんでした。もちろん英語です。

「ゲームデザイン」と思っていたので、インディーズのゲームを作る上で、どういう考えでゲームデザインをしたのかという話と思っていたら、前半は延々と認証周りのシステムの話。後半もネットワークの問題をどうするかという話を非常に高いレベルで、超高速で話していただいたため、ほとんど理解できずまま終わってしましました。残念。

メモ

  • SpyPartyのゲームデザインの話。スライドがすごく古風な感じ。「私は普段話すのが凄い速いので、できるだけゆっくり話しますね。」と言った途端、超早口。はい。私もですが。
  • SpyParty: Minecraftと同じビジネスモデルのインディースのオンラインゲーム
  • SkyPartyをStartCraftみたいなゲームにしていきたい。
  • モダンな特徴:ロビーがある。ビデオチャットがある。上手い人が見えるような仕組み。誰がオンラインであるかが分かる。マッチメイキング。etc
  • アイテム課金みたいなものは入れたくないので話さない。 プレイヤーのスキルを競いあうようなものを作りたい。
  • 完璧主義者なので、洗練されている、セキュアである、スケーラブルである、柔軟であることを目標とする。これが正しいかは疑問であるだろうが、自分は正しいものだと思っている。インディーゲームの作者であるので、こういうものを目指す。
  • Minecraftのログイン画面のIPを入力させる画面は、講演者の理想とするものの全く反対のもの。 セキュアでもスケーラブルでも全くない。
  • 認証と許可は異なる。運転免許証で自分を特定するのが認証、実際に車を運転することを許すのが許可。
  • 認証まわりの結構濃ゆい話が、超高速で流れて行っているので、そろそろついていけなくなって参りました。
  • MITで作られたチケットシステム(プロトコル):ケルベロスhttp://en.wikipedia.org/wiki/Kerberos_(protocol)
  • ケルベロス クールだぜ! ほとんど拡張せずにセキュアな通信できるぜ! オープンソースで移植性あるぜ! スケーラブルも当然! 皆使っているよ! サポートもあるぜ!
  • オープンソースをデバッグをすることは善良な市民としてできる。
  • オンラインゲームにおけるNAT Firewallの問題に関する話。
  • SpyPartyがどんなゲームであるかを全く分からないまま終わりそうだぜ。 HAHAHA

ARMORED CORE Vの対戦AIにおける階層型ゴール指向プランニングと機体制御

岡村 信幸 (株式会社フロム・ソフトウェア)

前日に続いてACVのAIの話。最初マシントラブルがあったようで、動画が再生されませんでした。他のセッションでもちょくちょくあったので、事前に動画を確認しましょう。とまぁ学会ではよくあることです。

前日はパス検索の話でしたが、今回はACの戦略をどう決めるかの話。ACVでは広大なフィールド内でACの挙動を決めるために階層型ゴール指向プランイングによるAIを採用しています。ゴール指向プランニングは最終ゴールに向けて、途中の行動を決定していくもので、ACVのように広大なフィールドを対象としたときには、意思決定を行うまでの計算コストが大きいため、3段階の階層構造を取っています。この時に状態遷移関数を上手く設計してやる必要があるのですが、目で確認しながらは色々と問題がある。機械学習の手法は見通しがまだ立っていないので見送り。そのため、ACV独自の方法を取った。という流れが少し分からなかったです。結論としては、ACVでは現在状態から目標状態までのパスをいきなり計算するのではなく、機体制御の予測結果を始点として目標状態までのパスを探索するものであるという理解だったのですが、あっているかはちょっと自信がありません。

最後まで聴いた感想としては、行動決定のための状態遷移関数などの設計はまだまだ人手によるところが非常に大きいので、機械学習分野の研究者が入り込む余地があるのではないかと思いました。

メモ

  • AIに要求すること。異なる時間粒度を解決すること。短期戦略と長期戦略。 並行する複数の条件をクリアすること。
  • ゴール指向プランニング。目標を達成する手順を決める方法。
  • はじめにゲームの状況から「状態」を作る。キャラクタの残り体力など。状態は無数にあるが、そのなかに「AIの目標を達成した状態」がある。現在状態から目標状態への状態遷移をする行動手順を見つける。
  • 「行動」は状態遷移の関数として表現。木構造の状態遷移図を作り、ゴールへのパスを求める。より良いゴールへ辿り着くためにパスに評価値を割り当てる。AIの性格を評価関数で表現。
  • パス探索はあくまで予測なので、行動の途中で無効になることがあるので、それに対応する必要がある。
  • 階層型ゴール指向プランニングで、短期戦略と長期戦略に対応。ACVでは3階層にした。第1層は戦略層、第2層は戦術層、第3層は機体制御層。層が下になるほど空間的、時間的にも粒度が細かくなる。
  • 再探索の効率化; 下位階層だけの再探索のときは上位階層は保持。一度失敗したパスは再探索しないようにカリング。
  • 状態遷移関数は「不確定な未来の予想」どう設計するかが匙加減次第。敵も予測する場合、どう全体をマージする?まだまだ改良の余地がある。
  • 複雑な制御ルールの機体の制御は難しい。経路は求まっても、機体の性能次第で、旋回できずに経路を辿れない場合などがある。
  • ACVにおける状態遷移関数の設計方法: 機体を動かしながら目測で決める→色々ダメ 。数理モデルの利用→上手くいくかわからなかったため見おくり。 機体制御の予測結果を初期状態としてゴールへのパスを探索するようなアプローチ。
  • ちょっと状態遷移関数まわりの説明が理解できなかった。
  • 経路探索は行動の経路を探索しているので、空間的な経路と混同しないようにしないとな。動画の壁を蹴って上に昇るなどの例を見て思いました。
  • さっきの状態遷移関数まわりは、現在状態から目標状態へのパスを直接探索するということではなく、機体制御の予測した結果から目標状態に迎えるように状態遷移関数を作る。ということかな?
  • ACVの状態遷移関数の設計を機械学習で解決できるかは検討しているけど、まだできるかどうか分からない段階みたいなので、機械学習屋さんは売り込むチャンスですぞ。