長久さんや三宅さんがやっている「ゲームAI連続セミナー」 の第４回に行ってみました。
今回のテーマは、有限状態マシンです。
今回も三宅さんとグループワークの２部構成です。
基本的にセミナー中にメモったものを起こし直したので、 聞き漏らしたり、勘違いしているところがあると思います。すいません。
最初に、定番のゲームAIセミナーの概要紹介。
ゲームAIセミナーの目的紹介
1.紹介、発表の場
2.討論
3.ゲーム業界で本当に必要なセミナーの形は？
ゲームAIの特徴：ゲームとAIが相互進化
繰り返して、良いセミナーを模索する
今回の改善点
設定を限定的に
事前公開が良かったので、みんな原論文も読んでね
ボランティア随時募集中
ゲームAI現在の構造を理解
FSMの話が多いがそれだけではない。
ゲームの進化に対応して、ゲームAIは進化してる？
Halo(2)は、ゲーム世界の複雑さに向き合ってAIを製作した
有限個の状態が遷移条件で結ばれている
今回は、状態によって出力が変化するムーア型を扱う
（入力が直接出力に関与することがない）
ゲームAIでは、意思決定に状態を使用する。
イベントによって内部状態が変化
例
パックマンの敵AIでは、「追う」、「逃げる」、「死ぬ」、「復活」の状態を遷移
（実際にこう実装されているというわけではない）
Quake
ミサイルについて、発射状態、移動、爆発、死などの状態が使われている
トレジャーハンター
宝箱を追う状態の中に別のFSMがある（階層型）
階層型FDM(HFSM)
同じ状態の遷移が実はまとめられる場合がある
講演の例ではないが：ゲームのセーブでは、常にメモリカードが抜かれる可能性がある
DAG形式のHFSM
一方向に再送かされて、ツリーの形式になっている。
例：Quake の敵
攻撃状態になったら、前進攻撃やミサイル攻撃などの複数の細かな状態を取る
Halo2 も同様に階層化されている。
FSMの注意点
パターン化しやすい->ランダム化
状態遷移の振動がおきやすい->条件を変えたりファジーなFSM(FuSM)
世界はAIにとって十分複雑
常識的（基本的）なことが分からない
空は青い、地球は丸い…
たくさん覚えさせれば良いがデータベースが巨大になる
でも、本当に使えない？
ゲームAIに必要な常識は少ない
行動レベルに関して、常識に基づく思考をゲームAIに与える
どうやって？
1)コードを書く(Halo)
2)全キャラクター共通の柔軟なシステムを作る(Halo2)
ただ、Halo と Halo2 の違いは分かりにくい
Halo2 では、世界を「解釈」するように見せている
特徴
敵は、大中小のクリーチャー（自分は人間）
知性を持つ
敵はプレイヤーができることはできる。
意思を明確にする
種族ごとの特徴あり
グループの戦略的な目的を持つ
いいリアクションを返す
良いレスポンス
驚きなどの感情
チートっぽく見えない馬鹿っぽさ
意外な行動を起こす
窮鼠猫を噛む
予測不可能性を持つ
毎回やるごとに違うことを行う
ただし、ランダム性は使わない
プレイヤーの動きに反射的に答える
プレイヤーの動きをアナログで所得
知的なAI
プレイヤーから分からない状態は無くす
プレイヤーに意思を伝える
驚きの声などの演出
こそこそとした動き
AIの意識を視線などから分かるようにする
プレイヤーに対する対話
インタラクティブ性
固体ごとに記憶を保持
情報量が多くなりすぎるので、基本情報だけ保持
オブジェクトに関しては周辺のものだけ
予測可能性
面白い行動が自然に出てくるように
最初はファジー制御だったが断念
次にイベントに反射して行動
結局キャラクタが世界を認識して動かす
チーム制御は必要なかった
アーキテクチャ
状態を所得して、それらを解析してイベント生成
イベントを意思決定してアクションを起こす
意思決定
イベントからの状態と敵の行動に伴うFSMからアクションを選択
アクション選択ロジックは、敵ごとに簡単なコードで実装
アクション選択ロジックで、キャラごとのカスタマイズ
全体
ある程度全体的な行動
レベルデザイナーが戦闘の全体的な流れを制御
チームごとに使ってほしい場所をグループ分け
メンバーと出撃エリアも決定
敵の単純な制御はロジックで、複雑な制御はスクリプト
位置取り
人間の射線がなるべく通っていないところに移動
レイキャストの負荷が60%(残りはパス検索と意思決定)
演出
見方や敵からの会話
イベントに関係があったり、近くのキャラと会話
まとめ
コンセプトが考え抜かれている
試しながら改善
プログラマが仕組みを作って、デザイナに制御を任せる
コンセプト
柔軟な拡張性を持たせる
行動の種類
飛ぶ、隠れる
キャラクタの種類
演出
ストーリーに絡んだ行動
思考
単純なゲームならFSMでOKだが、複雑になると遷移条件などが難しい
HFSM の振る舞いツリーによる意思決定
直感的、モジュールに分解可、スケーラブル
ただし、単純ではなく、デバッグが難しい。また、メモリも取る
ノード選択
子ノードが競い合ってノードを選択（親が与えるわけではない）
バイナリテスト（今、行動が取れるかどうか）と選択アルゴリズム
選択アルゴリズムは沢山ある
振る舞いの順序を規定できる（常識を決められる）
優先度の制御には、状態でトリガーをもたせる仕組みを採用
上位のレベルを遷移させる制御もあり
振る舞いの実行可能性をビットのテーブルにして高速化
キャラクタごとの制御には、最初に沢山の状態を追加するのではなく、キャラクタごとに遷移状態を追加する
めったに起きないイベントの判定は割り込みができるシステムで対処
黒板による協調動作（あまり重要ではない…）
記憶
ツリーが大きくなるとメモリが圧迫される
ツリー自身は静的なツリーにして、キャラクタごとにツリーに状態を追加して利用
問題点としては、行動の履歴を残すのは難しいので、専用のメモリプールを用意
永久記憶、短期記憶、ターゲットの認識、ターゲットの振る舞いを保存
移動
AI に何をさせたいかによって適切なデータ構造を用意する必要がある
ナビゲーションメッシュ
いろいろなノウハウがある。
あまり鋭い三角形は良くない
ポジション
戦略的位置をプレイグラウンドとしてグループ化
その間は（処理の重い）パス検索しなくても移動できないようにする。
まずプレイグラウンドで移動して、それ以外に行くときはパス検索
デザイナーコントロール
静的なキャラクタ定義
継承構造によるパラメータ定義
効率よく沢山のキャラクタを作成
ツールによる振る舞いのマスク（スタイル）
動的なスクリプト制御
メンバーとエリアを分離してグループのエリア間移動を実装
"Order"という概念を入れて移動の制御（前進、突撃）
スタイルと組み合わせる（特徴的）
その場でできる行動を選択されたスタイルをエリアごと容易
Q. スタイルがエリアごとあるとデータが増えたりデザインが大変になる気がするけど（今給黎）
A. 確かに、テンプレートを用意しているのかも。キャラのスタイルの制限もあるので、下手すると何もできないキャラが出てくる（腕の見せ所といえば見せ所）
AI の内面の描写
振る舞いによって、個性付けられる。
世界の複雑さがあり、その解決で賢くなる
FSM は、世界をAIの関係性を表現するグラフ
作り方
シチュエーションから、まず、FSM を洗い出してみる。
分けられるものを分けて階層化していく
状態遷移リストを作る
出てきたリストをつなげてFSMにする
「スムーズに進められるところまで落とし込んだ例を考えた」
シチュエーション：MGS2 A脚ポンプ室
カロリーメイトが２つある（どこか分からない）
カロリーメイトを探すかスネークを倒す
基本構造
索敵、追跡、警戒、リセット
１０人：学生一人、あと各社（確か企画が２人）。
特徴あるAIを追加
居眠りをする（居眠りを見つけたら起こす）
臆病
小銭を拾う
うそをつく
最初から物を考えたので時間が無かった
さくさく進んでいた（三宅）
綺麗（字も綺麗）（長久）
索敵に遊びを入れて、警戒になったら本気
巡回中にどうサボるかを考えた（そのとき仲間にみつかったら殺される）
死体を見つけたら警戒態勢に入るとかあったと思う
1vs1だと負けるので、なるべく仲間と一緒に攻撃しましょう。
反撃の時は仲間を呼ぶ
警戒中は出入り口を閉める必要が歩けど、４人だと倒されるので、６人ぐらい？
上司と部下（仲が悪い）
部下はサボりたいけど、手柄はほしい
上司はまじめ
上司は巡回。部下がサボろうとしたら説教。
部下は巡回よりもさぼりが重要
サボりでも、ある程度大丈夫になったら仲間を呼んで一緒にサボる
上司が階段を転げ落ちたイベントでは、介護する
長久さんのグループと似たような感じ
FSMでうれしいこと
仕様書が箇条書きだと
->膨大な箇条書きになる
->不整合があっても分からない
->だいたい作ってから問題発見
->あいつの仕様書つかえねえなー
仕様書がフローチャートっぽくなると
->表現力が足りない(例外処理は難しい)
->表現しきれていない部分に不具合ができやすい
->だいたい作ってから問題発見
->...
仕様書が UML (のステートチャートによるFSM) だと
->キャラの挙動がすべて連結されている
->網羅的に書きやすい。追加しやすい。
十分な表現能力で細かいところまで書ける
悪いところがあると図にならない
そもまま実装できる
->GJ
日本語（企画）とコンピュータ（プログラマ）の思考に差がある
それが UML 化されると
論理的思考のサポートと見える化ができる
実装しやすく、レビューもしやすい
技術者は家に帰ったり寝ることができる
のではなくて
重要な作業に時間を割くことができる
みんな幸せ
もっと嬉しい未来の話
モデル検査にかけられる
コンピュータサイエンスの形式手法の１つ（ツールもあるCSKとか）
FSM で特定の条件の時に状態を取るかチェックできる
デッドロックが起きているか調べられる
ゲーム全体だと難しいが、AIなららんとかなるんじゃない
定理証明にかけられる
数式で書くとちゃんと動くことが分かる
今回は、参加者のノリが悪かったように感じました。
と、いうのは、ゲーム開発者ってFSMは、タスクシステムとして頻繁に使って慣れてるんですよねぇ…
グループワークの方は、みんなのネタが発散して、うまくまとまりませんでした。
これは、反省点が多いなぁ…