今年のプロコンの優勝者のプレゼンスライドです。

1. 魔王の作り方 2014
石井(健)研究室
OB6年目 Java歴11年目
原 大曜

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. まとめ
• 今年難しかったね
• 計算量との戦いだった
• ビットボード面白い
• 参加させていただきありがとうございました