デッキリストを元に、デッキの中身を見てデッキ名を決める試みの第2回です。

第1回のアルゴリズムもここで紹介しましたが、当時は統計分析に使える精度ではありませんでした。
バージョン2ではカードデータベースと連携させて、いくつかの課題の解消に成功しました。

9月7日に主催するポケカ攻究会では、新しいエキスパンションを使った人を表彰したり、大会後に分析レポートを作成するといった、あまり例のない試みをしています。

これらの企画は、デッキタイプ判定アルゴリズムが存在することが前提でした。60人分のデッキを当日に確認して、その内容で表彰する。自動化の威力を発揮できる仕事です。

当記事では自動判定のロジックの概要と、判定結果の例示、また残る課題をご紹介します。
ポケカ攻究会でエキスパンション勝利賞を獲るヒントも兼ねています。
是非ご覧ください。

第1弾:進捗報告：リストからデッキタイプを自動判定した

[判定ルール概要]

デッキの中のポケモンに種類別に点数を付けて、点数の高い3種類を並べてデッキタイプとして扱います。

大まかには以下のルールで採点されます。

(1) 採用枚数が多いポケモン
(2) GXポケモンは、そうでないポケモンの1.5倍の枚数として扱う
(3) 点数が同じ場合は、新しいカードを優先する

採点するとき、内容が同じカードは収録エキスパンションやカードナンバーが違っても、同じカードとして扱います。(採録やSRなど)
反対に、同じ名前のポケモンでもゲーム中の能力が違う場合は、違うカードとして扱います。

GXポケモンを優先しているのは、非GXのポケモンに比べて1枚当たりがゲームに与える影響が大きいからです。非GXポケモンと同じ点数が付いた場合は、GXポケモンを優先してデッキタイプに組み込みます。

そのほか、デッキタイプから除外するポケモンがいくつかあります。

(1) デッキ内に進化先がいるポケモン
　進化ポケモンを使う場合、進化先よりたねポケモンの枚数が多い傾向にあります。メインになるのは進化ポケモンのため、デッキ内に進化先がいるポケモンはデッキタイプから除外します。
　ただし、進化前の枚数が多い場合はデッキタイプに表示する場合があります。
　「進化先の枚数が、進化前の枚数の50%よりも少ない」場合は、進化前のポケモンでもデッキタイプになります。
　
　例:
　・アローラロコン×2枚、アローラキュウコンGX×1枚のデッキ　→　アローラロコンはデッキタイプになりません
　・アローラロコン×3枚、アローラキュウコンGX×1枚のデッキ　→　アローラロコンがデッキタイプに入る場合があります

(2) デッキ内にふしぎなアメが入っている場合のたねポケモン
　デッキにふしぎなアメが入っている場合は、対応する1進化ポケモンがデッキになくても、たねポケモンを進化前として扱います。枚数の基準は普通の進化と同じです。
　当然ですが、対応する2進化ポケモンが入っていなければ、たねポケモンは除外されません。

(3) 一部のシステムポケモン
　カプ・テテフGX, デデンネGX, メタモン◇は、デッキタイプから除外します。これはメインポケモンではないことが多く、(2枚は)GXなので非GXより優先して表示するのを防止するためです。
　しかしこれらがデッキ内で大きな位置を占める場合に備えて、デッキタイプに並ぶポケモンが3種類に満たない場合は、これらのポケモンがデッキタイプに加わります。

[自動判定した例]

第1弾で紹介した4デッキと、ふしぎなアメを使用した1デッキの自動判定結果を紹介します。
前回のものはチャンピオンズリーグ2019京都大会(4月)、マスターリーグの入賞デッキです。

1位 manaさん
まとめサイトによるデッキ名：レシラム&リザードンGX
前回のデッキ名：レシラム&リザードンGX/ジラーチ/ミルタンク
バージョン2によるデッキ名:レシラム&リザードンGX(SM10-007)/ジラーチ(SM8a-034)/フーパ(SM10a-029)

このデッキはGXとジラーチ以外は1枚投入なので、あまり変化はないです。3枚目がミルタンクでも、フーパでも大きな問題はないでしょう。
(どちらかといえば、表示されない方がうれしい)

2位 タケトさん
まとめサイトによるデッキ名：ルカリオ&メルメタルGX/フーパ/HAND
前回のデッキ名：ルカリオ&メルメタルGX/フェローチェ&マッシブーンGX/フーパ
バージョン2によるデッキ名:レジギガス(SM4S-041)/フーパ(SM3p-056)/ルカリオ&メルメタルGX(SM9b-029)

GXの優先度を前回より下げたので、4枚投入のレジギガスとフーパが表に出ました。
フェローチェ&マッシブーンGXよりもデッキの中核に近いので、改善していると言えます。
しかしながら、アンノーン(HAND)はやはり出てきません。

ベスト4 会長さん
まとめサイトによるデッキ名：レシラム&リザードンGX
前回のデッキ名：レシラム&リザードンGX/ブースターGX/ヒードランGX
バージョン2によるデッキ名:レシラム&リザードンGX(SM10-007)/ブースターGX(SMI-001)/ヒードランGX(SM10a-004)

これは変化なしです。元からGX3種入りで枚数に差があったため、ロジック変更の影響をうけませんでした。

ベスト4 みれ
まとめサイトによるデッキ名：サーナイト&ニンフィアGX/ムウマージ
前回のデッキ名：サーナイト&ニンフィアGX/ムウマ/ムウマージ
バージョン2によるデッキ名:サーナイト&ニンフィアGX(SM9a-031)/ムウマージ(SM10-039)/ゼルネアス(SM4A-036)

進化前のムウマが除外されました。良い変化です。

シティーリーグ5月 がしらさん
まとめサイトによるデッキ名：-
前回のデッキ名：バンギラスGX/アローラキュウコンGX/ニドクイン
バージョン2によるデッキ名:ニドクイン(SM9-041)/メガニウム(SM8-005)/ラグラージ(SM7-024)

第1弾ロジックではメインでないGXポケモンが2種表示されましたが、今回はメインの3種類が並びました。たねポケモンも除外できていて、改良の成果が顕著に出ています。

[課題]

第1弾の記事で挙げた課題は以下の3つでした。

(1) 進化前を除外できない
(2) メインでないGXポケモンも優先される
(3) 同タイプのデッキでも名称が固定されない

このうち1番と2番は、解消したと言えるのではないでしょうか。

3番は少し説明が必要です。第1弾ロジックでは同率の場合にデッキリストの並び順を考慮していたので、同じ内容のデッキでもリストの書き方で結果が変わってしまいました。
第2弾では点数が同率の場合にカードの発売順で決めるので、ゲーム的に同じデッキなら毎回同じデッキタイプと判定します。

しかしながら、カードの発売順は厳密にいうと公式サイトのカードIDを使って判定しています。基本的には発売順になりますが、一部で例外もあるようです。また同じ内容のカードでもイラストなどによってカードIDが違うので、データベースの登録状況によってズレが生じてしまいます。
課題の残る部分です。

また一部課題が解消したことで、前回は取り上げなかった問題が顕著になりました。
京都大会のmanaさんのデッキや、ミュウツー&ミュウGXデッキなど、1枚採用が多いデッキタイプの問題です。メインポケモン以外のオプション的なポケモンが2～3番目に入ってしまい、デッキの本質から遠い部分がデッキタイプに反映されてしまいます。
デッキリストの枚数配分バランスによって、表示を1～2種類で打ち切るなど、調整した方が良いかもしれません。

加えてデッキタイプの判定にカードデータベースを使っているので、データのメンテナンスの手間が掛かってしまうのが運用上の問題です。
(公式サイトのカードデータベースにアクセスするわけではないので、定期的に整備する必要があります。)

そしてHANDを含められないなど、プレイヤーの感覚とのズレも解消できていません。

以上を踏まえて、今後の課題を3点挙げました。

(1) メインでないポケモンを除外したい
(2) カードデータベースの管理を省力化する
(3) 人間視点を取り入れたい

特に1番が重要です。
サブポケモン1枚の採用有無でデッキタイプが変わってしまうと、分析に使えない場合がありますから。

[まとめ]

カードデータベースと連携をしたことで、いくつかの課題を解決することができました。
本来デッキタイプ自動判定とは別の目的で用意していたものですが、こちらが先に活用されることになりました。

残る課題のうち、2つは技術よりは考え方が問題となってきます。同じカードでもプレイヤーによって重要度が異なるため、それをデッキリストからどうやって読み取るか、モデルを考えていかなければなりません。

まずはポケカ攻究会が初仕事です。裏方ですが、よく活躍することを願うばかりです。

[余談]

第1弾はシェルスクリプト(bash)製ですが、今回はストアドファンクション(MySQL)で作成しています。データベースと密に連携するので、プログラム言語でカーソルを扱うよりは、ストアドにした方がシンプルだとの判断でした。

投入するデッキリストも、TSVのフラットファイルからデータベースに登録済みのデッキリストに変更されました。カードデータベースの整備と併せて、全体的に準備が重たい仕組みになってしまいました。
TSVやデッキコードを基に、デッキタイプ判定まで自動で進めるバッチを作るなど、省力化を進めないと使い難いです。

しかし、MySQLのストアドの機能の貧弱さには悩まされました。仕事ではOracleを使うことが多くMySQLのストアドは初めてでした。try-catch系の構文がなかったり、中間テーブルに実テーブルを使えないなど、ロジックとは別の部分でずいぶん苦労しました。
しかしこれも経験。副産物として経験を得る目的も含めて、こういうことをやっているのではあります。