Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (16)
Featured
Featured (20)
魔王の作り方2014
- 2. ボンバーマン • Ken’s Cup 2008 から 6年ぶり2度目 – 当時SDK作った • これまでの歴史 2006: オセロ 2007: ぷよぷよ 2008: ボンバーマン 2009: XI 2010: パックマン 2011: ブロックス 2012: ぷよぷよ(二回目) 2013: タワーディフェンス 2014: ボンバーマン(二回目)
- 3. はいはいKensCupKensCup • ブロックス(2011)の時 – はいはい、４人分の手を考慮して ゲーム木探索すればいいんでしょ。 – どこまで先読みできるかの高速化と 評価関数の精度とセンスの勝負ね、はいはい。 • ぷよぷよ(2012)の時 – はいはい、(ネクネクである)３手目先までの 自分と敵のゲーム木探索すればいいんでしょ。 – 発火タイミングの考慮と、連鎖を組むための ポテンシャル最大化法ね。５年前にやったわー。 これやったわー。
- 4. はいはい、KensC…、、、 • タワーディフェンス(2013)の時 – はいはい、バックトラックバックトラック。 優良そうな手から順に試してみて 敵の行動をシミュレートして最高スコア選ぶ奴ね あ、最長経路？NP困難？ – どっか既存手法… あるけど今回使えない… – まあ方法は思いつくしなんとか…
- 5. うわー • ボンバーマン(今年) – や、やべーよ！n人ゲーム、 シミュレータ作るのも面倒な上に計算時間多いよ 1手先読み間に合うのか？これ？ いや、よく考えたら1手だけ読んでも意味なくね？ 爆弾爆発する最長10手読み？できねーよ。 ゴリゴリif分岐の作り込みは作業時間的に不利、 楽する方法は…行動パターンの推定＋モンテカルロ？それ全 然楽じゃないわ。 – 既存手法…ボンバーマンに既存手法なんてねーよ あっ、CODE VS3.0 がそうか。（というか、これ参考にテーマ決 めたんだろうなあ）いやいや、CODEVSでは二人ゲームだし。 状況違うしやだー。
- 6. 分析 • N人ゼロ和完全情報ゲーム – 二人ゼロ和とくらべて研究も情報も少ない • キングメーカー問題 – 上位二人以外の人の行動が決着要因になり得る – ３位、４位が１位に近づくようなアルゴリズムなら ２位の逆転が難しくなる、とか。 – 相性が存在する • １手で盤面に起こる変化の計算量が(比較的)多い – 爆風の伸び、連鎖、ブロック破壊、アイテム処理 – オセロやブロックスの比では無い • 結論：非常に難しい – ここ数年で一番アプローチの選択が困難なテーマだった
- 7. アプローチ • 誰かの真似をする – Code VS 3.0 • 確率論的にやる – モンテカルロ探索 • 真面目にやる – バックトラック(ゲーム木探索) – ヒューリスティックなルール付け – 計算時間との戦いが待っている 情報少なく 条件も異なる 越えられない 時間の壁 仕方ないから 真面目にやった
- 8. 今年の関連研究 • N人ゲームにおける最良優先探索 ( 02 篠原) – Max-n探索の解説 • UCT探索による不完全情報下の行動決定 ( 09 三木 ら) – UCT探索 – n人ゲームの構造説明 • CODE VS 3.0 関係者のツイート – Githubにコードを公開している上位陣 – ヒューリスティックなルールを考える上では 参考にするのもありだったかも
- 9. 魔王の実装 • １手先を全通り探索 – 1手先だけなら最善手 – 最善手をきちんと打てるなら攻守ともに強力！ • 手そのもの評価 – 爆弾を非交点に置く行動は減点 – 立ち止まる行動だったら減点 – 最後の爆弾を使い切る行動は減点 – 敵に近づく行動は加点 • 序盤はアイテム取得用に 特殊思考ルーチンを用意 結局すごく普通！
- 10. 死ぬの？死なないの？問題 • 爆弾が爆発するまで10ターン • 愚直にやると、10ターン先まで 完全に読まないと自分が死ぬのか否か不明 – 死亡確定箇所の伝搬（後述）によって スマート化必須 • さらに自分の爆風で死ぬのか 他人の爆風で死ぬのかが大問題 – それぞれ分けて扱う
- 11. 計算量の評価 • １プレイヤーにつき最大10通り – ５方向 x 爆弾を置くか否か • ４人なのでその4乗 – 10^4 = 10000 • それぞれの盤面で最終的に死ぬか否か – 10^4 x 10ターン分の盤面評価 – これを１秒で！？ • 最初の実装だと1secオーバーが頻出した • 今年の敵は計算量！！
- 12. 大事なこと • 以下の二つは分けて考える – 敵の手を考慮して1手先を読む – 死亡確定かどうか調べるため10手先を読む • 前者は完全な盤面のシミュレーションが必要 • 後者は必要な情報が限定される – 必要：死亡確定箇所 – 不要：プレイヤーの持つ爆弾の数 – 不要な部分はどんどん計算省略
- 13. 削減方法１：同一盤面のキャッシュ化 • 爆弾を置かない行動なら盤面変化の共通化が可能 • 一人に関して爆弾を置かない５行動は 最初の一度だけ盤面を計算してそれを保持する • 二度目以降は保持した盤面に 移動箇所のみ変更して評価 • 最大計算量が10^4から6^4へ • この時点で1secオーバーは「稀に起こる」程度に
- 14. 死亡確定箇所の算出 • 一番計算負荷が高い • 例えば火力２の爆弾が2ターン後に爆発する時 0ターン目に死亡が確定している場所は？ • この計算を爆弾の持ち主を考慮して すべての必要な箇所について計算必要
- 15. 死亡確定箇所の伝搬 • F(n,p):nターン目に座標pが死亡確定なら真 G(n,p):nターン目に座標pに移動可能なら真 • F(n,p){ for(p’ in pの隣接5箇所){ if(!F(n+1,p’)&&G(n+1,p’){ return false; } } return true; } • これを各ターン、各座標について繰り返す – もっと省略できないだろうか？
- 16. 削除方法２：ビットボード • 死亡確定箇所を1とする8x1のビット列 – 例： 1110 0000 – 0～2番目の３箇所が死亡確定 • 通行可能箇所を1とする8x1のビット列 – 例: 0111 0000 – 1～3番目の２箇所が通行可能 • この１ターン前の死亡確定場所は – 例：1100 0000 • 盤面をビットで表したものをビットボードと呼ぶ
- 17. 計算式 • f[n] : nターン目の死亡確定ビット列 • g[n]: nターン目の通行可能ビット列 • f[n] = f[n+1] & ((f[n+1]| ~g[n+1])<<1) & ((f[n+1]| ~g[n+1])>>1) & ((f[n+1]| ~g[n+1])の上シフト) & ((f[n+1]| ~g[n+1])の下シフト); ビット演算によって複数箇所を同時に計算 （ビットパラレル） これを各ターン、1度だけ行えばよい
- 18. 高速化の結果 • 1secオーバーは皆無に – 思考時間はたかだか300msec程度に(自分PC) • それでも2手先を読むことは困難な計算量 • ビットボードの実装例はオセロで有名 – Wikiに専用ページがある程 – 盤面が8x8だから非常に最適 • 知っておくと意外なところで応用が効く小技 習得をオススメします
- 19. まとめ • 今年難しかったね • 計算量との戦いだった • ビットボード面白い • 参加させていただきありがとうございました
Editor's Notes
- 研究室では非完全情報といったけど、完全情報でした。 非完全情報＝あるプレイヤーしか知らない盤面上の情報がある、ということらしいっぽい。 間違っていたらごめん。 本筋に影響はありません。
- 研究室ではこの情報を16パターン持つ、といったけどそれは厳密ではありませんでした 本当は死亡確定箇所とは別に、死亡可能箇所も伝搬してます。 死亡可能箇所は、その場所から移動した時に（将来的に）死亡する可能性が僅かでもある物を伝搬させたもので、 例えば4ターンずっと右に進み続ければBさんの爆弾で死ねるけど、それ以外の行動だとまったくBさんの爆弾では死なない、 というようなケースでも真となるような情報です。 死亡確定箇所と死亡可能箇所の情報を組合させて、死因の算出を行っています。
- やや濁した説明。 上下シフトは配列で実装することもできるし、64bit以内の範囲内で定数シフトでも実装できる。 あと本当は左右シフトの時に、論理反転してからのシフトだと画面外が0=通行可能になってしまうため、 通行不可になるようなビットマスクも追加する必要があるが簡単のため省略