こちらのシリーズではナイアンティックは『マッチング操作はしているが意図したマッチングができていないのではないか？』という議題について考えていきます。
今回はマッチングの処理に際して使われる値のお話です。もちろんもうそうで。
こちらの記事はシリーズ第二弾となりますので、未読の方は第一弾を先にお読みください。
こういう狙いと実情はありそうというのを書いています。多分第一弾は予想としてはまとも。
本記事はちょっと妄想激しいけどありそうな取得といった感じです。
今回も数的根拠は無く、あくまで妄想全開で書いていきます。
マッチング相手を決める基準とタイミング
マッチング相手を決める基準は運営側の都合を考えると、レートの平均化や緩やかな山型の形成が目的です。
なので、勝ち過ぎれば負けさせたい。負けすぎれば勝たせたいという設計を基本にしていると妄想します。
マッチングを組む上で勝利数の値を取るのは簡単なので、ここは良いとして問題はどうやって有利不利を見分けているのかという事になります。
マッチングの有利不利の作られ方
ズバリ、これは機能の横断になりますがレイドの自動選出機能の流用ではないでしょうか。
レイドでは耐久指数を重視した自動選出が成されますが、そのロジックを流用すると。
3体の耐久指数や苦手関数など、ある程度の値を抽出して有利不利の値を出しているのではないでしょうか。
ただし、これには対戦相手を探す時にまず技のタイプを含む総合尾的なタイプ相性を全部演算させなければいけませんね。
アットランダムに対戦相手を探すとなると、個別の探索ではかなり労力が要りそう。
何せこの仮説だと、負けさせたいユーザーと勝たせたいユーザーをそれぞれの事情でマッチングさせないといけませんから。
負け数の指定
ここまでのような流れで、対戦相手を決めていくとして、セット内の負け候補数が常に処理に組み込まれているとしたらどうでしょう。
例えば3敗させたいというフラグをそのセット中常に立てられており、5戦終わるか3回負けるまで解除されない。
それらの処理を優先的に行い、対戦相手とフラグがあった場合にマッチングする。
という余計な操作を行っているとしたら。
確実に同じレート帯に人はいる筈なのに、なかなかマッチングが生成されないというのに説明がつくようになるかも。
対戦サーバーの仮説
私は対戦サーバーはある程度の数に分かれていると思っています。
膨大な数に上るGBLプレイヤーすべてを同じ箱に収めている筈が無いので。
レートの上下幅30～50ずつくらいで細かい部屋がいくつもあって、その中でセットを組まれているのではと考えています。
だから、基本下ばっかりと当たるサーバーとか、上ばっかりと当たるサーバーも発生する可能性がありますね。
で、対戦候補がいなければ上下の近しい部屋に対戦相手を探しに行くと。
実際は現在いる対戦サーバーではなく、本人のレートに近い処からマッチング相手を探していくことを優先してくるロジックなのかもしれませんが。
それだと演算が膨大になったり3人が同じ対戦に放り込まれないか？という疑問があります。
なので何かで仕切っているのはまず当たっているのではないかなと。
それがルールのある部屋なのか、レートだけを参照した部屋なのかはわかりませんが。
まぁ、それはともかく。
さらにそこから、先ほどの『対戦者に勝たせたいor負けさせたい』というロジックが走るわけです。
これはかなり対戦待機時間が長くなりそうですね。
サーバー移動のタイミング
で、同じ対戦サーバーにずっと居ると前に戦った相手も混じって来るし、もしかしたらさっき勝ち負けの有利判定で除外した相手も混じってくるかもしれないので、段々と対戦相手候補が居なくなる可能性があります。
※実際にどんなマッチングロジックを使っているのかは、判りません。あくまで妄想仮説です。
そこで、対戦サーバーの移動のタイミングが必要になりますがそのきっかけは以下ではないかと考えています。
- 1セットが終了した時
- 使うパーティを変えた時
実際にこれら跨ぐと「あれ？なんか対戦相手の特色変わってないか？」と感じることが多々ありませんか？
あれは対戦サーバーが変わって、対戦相手の特徴が変わったのではないかと考えています。
例えば、対戦サーバーのリフレッシュ前は日本人の多いサーバーに放り込まれてたけど、いきなりヨーロッパ地域の多いサーバーに放り込まれたとか。
各国の配信者の影響で流行が変わったりしているので。
そしてパーティ変更後、妙に対戦相手がハッキリと勝ちやすいor負けやすいパーティになることが多いのは、そこで対戦相手がリフレッシュされてロジック側が対戦相手を探しやすくなったのでは？
という仮説です。
マッチングに使われる要素の整理
ここも妄想ですが、ナイアンティックがマッチングで取得していそうな値等を考えていきます。
私はマッチング操作の仮説としては、セット毎に前回の勝率を参照して不利な対戦・有利な対戦を作っていると思いますので、以下を記録して参照していると思っています。
- 現在の対戦サーバー情報
- 個人識別ID
- 今回のパーティ情報
- 前回のセット5戦の勝敗
ナイアンティックがマッチング操作をしているという前提の話なので、パーティ情報と前セットの勝率くらいはまず保存していると考えています。
そもそも使われたポケモンの統計を取っていますからね、パーティ情報自体は取得が効いている筈です。
個人識別IDは取得しておき同じ人と当たりにくくする為、また単純にユーザーデータの照合などにも使われます。
対戦サーバーは先ほどの通り1カ所だとは思えないので、現在地の確認用に対戦前後も情報を保存。
あとはこのセットでレート平坦化の為にどれくらい勝たせたいかというフラグですね。
ただし1日以内でも同じ対戦相手と当たることはありました、私自身も何度も体験しています。
そもそも国を跨いでいるので、1日の定義も曖昧ですしね。
なぜマッチング操作もどきがあると考えたのか
本記事では対戦時に取得していそうな値と、レートの平均化の表面的な対応について書いていきました。
ではそそもそも何故、こんな記事を書こうと思ったのかというと、２つの点があります。
まず第一に、運営は不意のトラブルが発生した時の為に対戦をいじれるロジックを積んである方が安全。
例えば、どこかの対戦サーバーが物理的に落ちてしまった時に、そこのID達を強制的に移動させる為『対戦相手の発見に連続で失敗した場合』対戦サーバーを強制的に移動する。とか、要するに保険の為。
そして第二のこちらが本命ですが、ナイアンティックが引き起こすバグはちょっと理解に苦しむものが多かったからです。
例えば過去にあった特におかしな事例を並べてみます。
- レイド卵が近くで割れるとGBLで敗北する
- フィールドアップデートが主なのに、何故かレイドの受け取り画面のスキップ機能が消える
- 直近出現テーブルしか弄っていないのにARタスク機能が突然使えなくなった
などなど。
レイドとGBLの勝敗判定、関係があるように見えますか？
レイドの受け取り画面のスキップ禁止、一体どこをいじったら生成されるのでしょうか？
これらの事象から考えられることは、対戦の有利不利の項目でも触れた通り『全く別の機能から無理やり値を参照しているのではないか？』というものです。
共通化してある値を流用して、アプリ全体のデータの軽減を図ろうとする。
しかしそれが逆に細かいバグや余計なマッチング操作を引き起こしているのではないか？
果ては「もしかしたら意図していないマッチング仕様が出てしまっているのでは？」と考えられたのです。
つまり今回妄想した様な、例えば『このプレイヤーにはこのセットでは3敗させたい』というロジックが実在していたとしても実在していないとしても、そもそもマッチング自体が当初の設計通りに働いているかどうかはナイアンティック自身も把握していない。
実はかなり偏りがあるのでは？
と言った感じです。
変なバグが発生する理由を考えると数値の共通化をしているか、ロジックを別のところから無理に参照している(例えばレイドバトルの相性算出など)のは何となくそうなんだろうなと思える程度にはあるので、実際にやっていそうです。
そして、IDごとに偏りがあるなとも考えています。
例えば個別IDから乱数を取得していて、その提供先が対戦の……。っと長くなりすぎましたのでこれは次回へ。
次回part 3ではどんな無駄機構の悪さ、意図しない動きが考えられるかについての妄想を書いていきます。
妄想レベルはさらに上がりますので、限界の方は読むのはこの記事までとしてください。
コメント