延々と作っているとデータ設計からし直したくなる時が来る。
その新しいデータ設計も速くはなりそうだけど、まとまるのか自信がない。
しっかり練って作り直さないとダメになる確率も高い。
chessの改良どうしたものかと悩んでいる中 amazonsというゲームが投稿（制作中)されていたので遊んでみます。
最初は簡易なものから作成、移動先の空き2マスぐらいを評価値にしようとしましたが、
関数作成中にやめて、chessで検討中のデータ構造と似た解析を導入してみます。
10x10マスでクイーン4個の移動制御、移動先、移動先の評価、移動先から矢を打つ
軽く２手の読みは必須のようで意外に手強いのかもしれません。
一手の速度制限も100msと多め。
＜ルール説明＞
プレイ人数は2人、10x10マスのエリアに4個ずつクイーンを置きます。
チェスのクィーンと同じ動きをしたあと（空間地以外動けません）、クィーンの動ける範囲に矢を放ってそこに壁を設置します。
お互い一手ずつ動かして、最後まま動けた方が勝ちです。
同じCodinGameのPenguinsとWondev Womanと似ています。
こんなアルゴリズムにします。
1手の移動範囲が少ない駒をまず選び、移動先の1手の移動範囲が多い場所に移動して
移動先から一番遠い地点に矢を放ちます。
コーディング完了！
デバッグ開始
コロン ： ほんとよく忘れます。
インデントずれ、一文字ならラッキー 4つズレて想定外の動きをされ、最近どこかでハマりました。
合法手を指していない。
条件設定ミスで初期値から変更されていませんでした。
10行目のp 数値を想定していたのですがlistが入っていました。
今回移動先のデータを個別でなく、方向+個別にしていたので新しいデータ設計との認識ミスでした。
合法手を指していない。座標の指定順が逆でした。
合法手がさせていない。
矢の放った先が全然違ってました。（コピペで修正ミス）
合法手がさせていない。
特定条件の時、座標の計算元が違ってました。
60stepぐらい、20分ぐらいデバッグで完成、その最初の対局は...引き分け
そのままTEST IN ARENAへ暫定トップ。
そのソースを一画面で収まるように少し圧縮
