naoppyの日記

自分が欲しいなと思った記事を書きます。

Procon29に参加しました

こんにちは、naoppyです。明石高専の競技部門として高専プロコン29に参加しました。

先に結果から書きますが、予選はP6ブロック1位通過できました。

f:id:naoppy_ac:20181030212447p:plain

決勝トーナメントは一回戦で敗退しました。惜しくも勝てなかった!(>_<)

f:id:naoppy_ac:20181030212632p:plain

大会までの流れ

5月

校内で競技部門に出たいチームが僕らを含め2チームいたので、校内予選に。無事突破。

メンバーは僕(2年)、ecasdqina(2年)、dawning(1年)の3人。それぞれGUI担当、Solver担当、書類担当ということに。(ココ重要)

この頃GitHubリポジトリを作った。

7月,8月

少しだけ開発をした。レポーヨに追われて迫真のコミットメッセージなのが当時の忙しさを物語っている。

9月

夏休み真っ只中の9月、当然開発は進みますよね???いいえ。宿題多すぎて一ヶ月で4日しか開発してません。

大会は10/27日なのに、10月まで何もしてなくない?

そうだよ(震え声)

10月

10/10にSolver以外は一応完成。

10/17には「あれ...? Solver担当からの進捗報告がないな...(フラグ)。一応人力の為にスコアも表示するか」ということでスコア表示実装。

10/26にSolver担当の死を確認し、人力でなんとかなるようにGUIを大幅変更(詳細は後で)

いざ、大会へ~

大会での流れと自分達のプログラム

1日目

僕が司令塔なのは決めていましたが、朝にエージェントへの支持伝達方法を考えて連絡。練習とかはなかった。

練習試合はあのWA_TLEさんのいる北九州高専。そこで

  • QRコードの読み取りに手こずると死ぬ
  • 敵のエージェントの動作を入力する時間が無い
  • トランプで支持を出すのが時間が無くて間に合わない

という3つのことが判明。

QRコードを読むのに2,3ターン使うと、敵の動きが入力できないので当然メインサイクル(自分の行動決定→指示→敵行動入力)が回せない。→人力へ。

練習試合の後半から指差しでエージェントに指示し始める。事前に示し合わせていないのにもかかわらず、めっちゃ伝わる。

ぶっちゃけトランプより早くて正確。トランプいらんやんけ。

そして予選トーナメントへ。

お待たせしました、GUIです。

入力

f:id:naoppy_ac:20181030230648p:plain

起動時

f:id:naoppy_ac:20181030231728p:plain

敵位置をクリックで入力するとSolverが走って右側に動く方向が表示される

f:id:naoppy_ac:20181030231744p:plain

敵の行動をクリックで入力(画像省略)

もう一度Solveを押すと盤面が進んでSolverが走る、以下繰り返し。

ですが、このGUI、練習試合で使えませんでした。

というのは、前述の通り、敵の行動を入力するのは忙しくて不可能だからです。

そのため、Moveボタン(Editモード)によって「動いた結果を入力させる」という方法に予選では切り替えました。

クリックでタイルの色塗り、ドラック&ドロップでエージェントの移動。

こんな感じで自分の望む盤面を作ってSolverの動きを見るために開発したんですけど、思わぬところで役に立った...

f:id:naoppy_ac:20181030233303p:plain

これにより、QRコードの読み取りが遅れたとしても、一瞬で現在の盤面を作成し、スコア計算をしたりSolverを走らせることができるようになりました。

スクリーンに現在のターン数が書いてあったので、ターン数がわからないデメリットは消えました。

やったね!これで戦えるよ!

ところが、Solver担当が作ったSolverが弱すぎて、Solverは人間の脳になりました。(ここ爆笑ポイント)

人間の脳は普通に強くて、予選通過しました。えぇ...。

2日目

前日の反省を生かし、舞台に対して左のチームが青色、右のチームが赤色になるようにGUIを変更しました。

今までは味方が青、としていましたが、現実と違うと頭がバグることを1日目で学んだからです。

そして、決勝トーナメント第一試合

分岐を逆に書いていて現実の色と逆になっていました。頭(Solver)がバグって死亡

夜中に開発するとチェックゆるゆるなのでダメですね...。

Solverについての考察

まず弊チームで候補に出たのは

ぐらいでした。 このゲームのルールは

  1. 敵と味方が同時に動く
  2. 終局までのターン数、フィールドのサイズ、各マスの点数、エージェント4人の初期配置が試合までわからない。
  3. 1によってエージェントの行動によっては衝突が発生する。
  4. 最終的な点数はタイル点+領域点(囲った点)で決められるということ。

という特徴を持っています。

オリジナルゲームなのでこれまでの対戦事例などはなく、特徴2のことも考えて機械学習は上手くいかないと考えました。

また、焼きなましも実装してからわかった(らしい)のですが、特徴3によって衝突が発生した場合に弱く、あまり強くなりませんでした。

更に、特徴4によって、ビームサーチはそのアルゴリズムの特徴から、長期的な目で「囲う」ということができず、弱いのではないかと思いました。

モンテカルロ木探索は今回のような厳しい時間制限の中でも、効率的に深くまで探索し、またいつ探索を打ち切ってもその時点での最適解がだせるという特徴から、このゲームに向いていると思いました。

まあ実装間に合わなかったんですけどね。

実装したチームは感想教えてくれると嬉しいです。

運営について

最初にQRコードの形式について説明したpdf、唯一載っていたQRコードサンプルが既にそのpdfの説明と矛盾していて「やべーわこれ」と思ったけど間違ってなかった。やばかった。

最初は競技ターン数は60~80ターン、1ターンにかける時間は5~10秒と非常に厳しいものだったが、ターン数は40~80、1ターンの時間は10~20秒に。なんでもっと早く気がつかなかった。絶対運営がやってみて初めてこんな時間じゃできないことに気づいたやつじゃん。

ソースコードGitHubのリンクで提出することもできます!とか言っておきながらprivateリポジトリをどう提出するのか一切情報はなく、それについての情報を締め切り1日前に公式サイトではなくfacebookで公開するとかいうクレイジームーヴをかましてきた。こいつはやべぇや。

会場のwifi環境は良かった。そのせいか毎年恒例プロコン会場SSID大喜利大会が無かった。悲しい。

予選にて競技フィールドが一方のチームに有利になっていたため再試合。運営はちゃんとルール把握しような。

再試合のこともあってスケジュールは1時間半以上遅れており、全ての試合のターン数が40ターンに。ランダムだからSolver作成に苦しんでるのに結局全部同じになるのかよ。

実はルールには、エージェントが示した方向を無視して移動すると、そのターンの全ての変更は無効になり、ターンだけ進む。というものがあった。つまり貪欲法でスコアが高いものを取っていき、自分達の点が相手の点を超えた瞬間からエージェントが変な行動をすることで必ず勝てる。というものがある。これをするチームは善意により現れなかったが...現れていたらどれだけ悲惨なことになったかは言うまでもない。プログラミングコンテストとは...

結論:運営・ルール共にひどいものだった。

まとめ

阿波踊りっていいですね。

プロジェクトマネジメントが一番大事。

Solver担当君、進捗報告はちゃんとしような!💥