お久しぶりです、今回は皆さんお待ちかねの神機能を実装したので、そちらに関するお知らせです。
ついにハンター／レンジャーの抽選処理が、完全なランダムではなく過去の対戦状況を元にした調整を伴う処理に変更されました！
これにより「私、ハンター多すぎ・・・」や「ハンターやりたいのに全然回ってこない・・・」といった不満が解消され、より快適にゲームを楽しむことができるようになります。
なお予めお伝えしておきますが、こちらはゲーム内セーブの機能を用いてプレイヤーの過去の対戦状況を参照することで実現しているため、プレイヤー全員のロードが完了する前に陣営の抽選処理を行っている 「あの頃の風の行方」 と 「あの頃の風の行方 2」 では未対応となります。
現状はステージの抽選を行った後に、プレイヤー全員のロードが完了している状態で陣営の抽選処理を行っている 「あの頃の風の行方！」 のみの対応となりますのでご注意ください。
ただ想像以上に快適になるであろう事が計算やシミュレーションにより分かったので、今後「あの頃の風の行方」と「あの頃の風の行方 2」にも対応させることは検討しています。
改善内容について簡単に説明します。
過去の対戦状況を元にした調整を伴う処理により、以下のように抽選が改善されます！
- 固定の4人でプレイを続けると、必ずハンター1回に対してレンジャー3回の割り当てが繰り返される（脅威の100%）。
- ランダムな相手との対戦でも、ハンターが連続で割り当たる可能性が限りなく低くなる（約0.39%）。
- ランダムな相手との対戦でも、レンジャーを3回以上プレイすると次にハンターが割り当たる可能性が高くなる（約68.36%）。
- 初めて遊ぶプレイヤーはレンジャーになる確率が限りなく高くなる（約99.61%）。
1についてはフレンドと周回する際に威力を発揮します。
今後はハンターは4回に1回必ず割り当てられるため、無駄にリセットを繰り返す必要がなくなりますね。
2、3は野良マッチを行う際の話です。
この機能がリリースされた後、十分な数の対戦が行われてからの理論値となりますが、ハンターが連続で割り当たる可能性は約0.39%まで減少し、レンジャーを3回以上プレイした後にハンターが割り当たる可能性は約68.36%まで増加します。
今まではどんな状況でも常に25%の確率でハンターが割り当てられていたため、これも大きな改善と言えるでしょう。
4については副産物的な効果ですが、初めて遊ぶプレイヤーに対する負担の軽減に寄与します。
というのも風の行方はハンターの負担が大きいゲームであるため、初めてのプレイヤーは可能な限りレンジャーとしてプレイさせてあげた方がゲームとして親切です。
他にも事前にレンジャーをプレイしておくことで、初めてハンターをプレイした際にマップ上の偽装可能オブジェクトを把握した状態で遊べるというメリットがあります（ゲーム内に説明を用意しておけって話ですが）。
以下具体的に何をしたかの紹介です。
同じように非対称型PvPの幻境を作っているクリエイターがいたら良かったら参考にしてください。
- プレイヤーがハンターを何回スキップしたかを表す数値（最大値3）をセーブデータとして保存する。
- 初めてゲームをプレイする（セーブデータが無い）場合、初期値を0とする。
- プレイヤーがレンジャーをプレイすると1となる。
- プレイヤーが連続でレンジャーをプレイする度に+1される。
- 加算を繰り返しても値は3を上限とする。
- プレイヤーがハンターをプレイすると0にリセットされる。
- ハンターはゲームの参加者の中で最大の数値を持つプレイヤーの中からランダムに選出する。
- 例えば、P1・P2・P3・P4が持つそれぞれの数値が0・1・2・3の場合、必ずP4がハンターとなる。
- 例えば、P1・P2・P3・P4が持つそれぞれの数値が1・1・2・2の場合、P3もしくはP4がハンターとなる。
- 例えば、P1・P2・P3・P4が持つそれぞれの数値が1・0・0・0の場合、必ずP1がハンターとなる。
たったこれだけです。
この方法の優れた点はロジックが非常にシンプルであることはもちろんですが、実装するために保存が必要な情報が0～3の数値、つまりたった2bitの情報で済むということです。
星々の幻境のゲーム内セーブデータに使える容量はかなりシビアなので、最適化が必要になった際に2bitでこの機能を実現できるというのはとても大きなメリットです（容量問題に興味のある方は こちらの記事 をどうぞ）。
なお風の行方の場合4人対戦なのでこのような仕様になっていますが、仮に幻境の最大人数である8人を想定しても0～7の情報、つまり3bitあれば対応できます。
実際のノードグラフはこんな感じです。
陣営の抽選を行い、プレイヤー毎に陣営に応じた異なるスキル選択画面を表示しているところを改修しました。
上の方が「ゲームの参加者の中で最大の数値を持つプレイヤーの中からハンターを選ぶ」処理です。
下の方が「プレイヤー毎に陣営に応じたスキル選択画面を表示し、ハンターのスキップ回数をリセットもしくは加算する」処理です。
例えば、P1・P2・P3・P4が持つそれぞれの数値が1・1・2・2の場合、P3もしくはP4がハンターとなりますが、P3がハンターになるとしたらこのような感じで処理が動いています。
- P1・P2・P3・P4が持つそれぞれの数値を格納するリストを作成する。
- リスト：[1, 1, 2, 2]
- 数値毎のプレイヤー群を格納する辞書を作成する。
- 辞書：{1: [P1, P2], 2: [P3, P4]}
- リストから最大値を求める。
- 最大値：2
- 辞書から最大値をキーとしてプレイヤー群を選択する。
- プレイヤー群：[P3, P4]
- プレイヤー群からランダムなプレイヤーを一人選択し、ハンターリストとして作成する。
- ハンターリスト：[P3]
- ゲームの参加者全員（P1・P2・P3・P4）の陣営を割り当てる際、ハンターリストに含まれるプレイヤーはハンター、含まれないプレイヤーはレンジャーとする。
- P1：レンジャー、P2：レンジャー、P3：ハンター、P4：レンジャー
- プレイヤーが持つ数値をハンターの場合は0に、レンジャーの場合は+1された値（最大値は3）に変更する。
- P1：2、P2：2、P3：0、P4：3
せっかくなので、修正の前後でどれだけ変化があるかをシミュレーションした結果も紹介します。
陣営の抽選はランダムに行われるためシミュレーション結果も毎回変わりますから、複数回実行した結果を添付しています。
以下のグラフはランダムなプレイヤーと100回マッチングを行った際に、自分自身（P1）のハンターのスキップ回数（もしくはレンジャーのプレイ回数）がどのように変化するかを可視化したものです。
ハンターのスキップ回数はレンジャーをプレイする度に増えていき、ハンターをプレイすると0にリセットされます。
青い線がハンターのスキップ回数の推移で、赤い点がハンターをプレイした、つまり回数リセットのタイミングです。
例えば赤い点が縦軸の1の位置にあるとき、P1はハンターを1回スキップした後、つまりレンジャーを1回プレイした後にハンターになったと解釈できます。
同様に赤い点が縦軸の10の位置にあるとき、P1はハンターを10回連続でスキップした後、つまりレンジャーを10回連続でプレイした後にハンターになったと解釈できます。
また赤い点が縦軸の0の位置にあるとき、P1はハンターを0回スキップした後、つまりスキップはぜずにハンターを連続でプレイしたと解釈できます。
下の3つのグラフは完全ランダムに陣営の抽選を行った際のものです。
100回程度の試行でもハンターになる確率は約25%になりますが、赤い点の出現、つまりハンターになるタイミングにはかなりの偏りがあり、連続でハンターになる期間もあれば、10回以上レンジャーが続く期間もあることが分かると思います。
これが「私、ハンター多すぎ」や「ハンターやりたいのに全然回ってこない」といった事象の頻出を表しています。
対して下の3つのグラフは、過去の対戦状況を元に陣営の抽選を行った際のものです。
先に説明した通り抽選のために利用するスキップ回数の数値は3を上限としていますが、縦軸自体は自分自身（P1）の純粋なハンターのスキップ回数を表しています。
マッチング相手であるランダムなプレイヤーが保持する数値も、0～3が一様に分布していると仮定しています。
ハンターになる確率は同じく25%ほどですが、先ほどとは異なり連続でハンターになったり10回以上連続でレンジャーになるパターンの発生が完全に抑制されており、非常に公平な抽選となっていることが分かると思います。
せっかくなのでハンターになる確率が旧方式と新方式とでどのように変化するのかも可視化してみました。
横軸は同じくマッチングの回数で500回としています。
縦軸はハンターになる確率で、理論値は25%です。
こういったものは通常万単位で試行しないと確率は収束しないものですが、ハンターのスキップ回数を元に陣営の抽選をおこなう新方式では50～100回くらいの試行で十分収束していることが分かります。
完全ランダムの旧方式の方は収束も遅く、上振れ・下振れがあり不安定であることも分かります。
こうして見ると新方式がいかに優秀かが実感できますね。
という感じですごく単純な改修の割に得られる効果は大きそうという話でした。
これでまた少しは遊びやすくなるはずですが、いつになったら野良マッチが成立するくらい賑わってくれるのか・・・。
