goodgames
TeamControler R0.02
最終更新:
goodgames
-
view
TeamControler R0.02 Beta.1
【本ページは記述中です】
(2012/05/26 20:00 最低限の記述は終了)
(2012/05/26 20:00 最低限の記述は終了)
■忘れないうちに重要な注意事項を記載致します
(2)
新しいモジュールを導入するとProconの仕様により旧バージョン使用時に設定したパラメータが消えてしまうことがありますので、
バージョンアップ前に記録するなどの対応をお勧め致します。
新しいモジュールを導入するとProconの仕様により旧バージョン使用時に設定したパラメータが消えてしまうことがありますので、
バージョンアップ前に記録するなどの対応をお勧め致します。
(3)
R0.01系と比較しパラメータのディフォルト値が一部変更されています。特にアンイーブン判定及び解消処理について御注意下さい。
R0.01系と比較しパラメータのディフォルト値が一部変更されています。特にアンイーブン判定及び解消処理について御注意下さい。
(4)
リリース直前に気づきましたがProconのPluginタブの下部に相当量のログが流れます。
これはプレイヤー毎の能力値がどのように判定されたか、また各チームの戦力合計などを表示していますが、
現時点ではこの機能をDisableにすることが出来ません。
近日中に対応しますので暫くお待ち下さい。
リリース直前に気づきましたがProconのPluginタブの下部に相当量のログが流れます。
これはプレイヤー毎の能力値がどのように判定されたか、また各チームの戦力合計などを表示していますが、
現時点ではこの機能をDisableにすることが出来ません。
近日中に対応しますので暫くお待ち下さい。
(5)
今回リリース分のモジュールではチームバランス用に多数のパラメータが増えていますが、
ディフォルト設定ではプレイヤーのランクを用いて「見た目では無難に」バランスされるようになっています。
今回リリース分のモジュールではチームバランス用に多数のパラメータが増えていますが、
ディフォルト設定ではプレイヤーのランクを用いて「見た目では無難に」バランスされるようになっています。
いわゆる「敵は鷹ばっかり」にならないはずです。「敵も鷹ばっかり」にはなるかもしれませんが。
ディフォルト状態のまま使用する場合、最低限設定して頂かなければならない項目は2つのみです。
接続元GameServerGUID (StatsNowサーバへの接続IDになります)
接続元GameServerPassPhrase (StatsNowサーバへの接続パスワードになります)
接続元GameServerPassPhrase (StatsNowサーバへの接続パスワードになります)
※PassPhraseはこちらよりメール送付致します
まずは上記2項目だけ設定して試験運用してみることをお勧め致します。
■TeamControler R0.02がめざすもの
(こんな話は後で良いので一時的に割愛)
■Proconの事前設定について
このスクリーンショットはProconのメニューより"Option"を実行した際の画面になります。
左側の画面の赤枠部分ではPluginLogをLogファイルの保存するよう設定しています。
この設定は必須ではありませんが、
Plugin詳細表示画面の下部に、各プレイヤーの能力判定結果などが表示され、
その内容がファイルに保存されますのでラウンド終了後に参照したい場合には便利です。
この設定は必須ではありませんが、
Plugin詳細表示画面の下部に、各プレイヤーの能力判定結果などが表示され、
その内容がファイルに保存されますのでラウンド終了後に参照したい場合には便利です。
右側画面の赤枠部分ではPluginが外部ネットワークと通信することを許可するよう設定しています。
これはStatusNowサーバに接続するための必須設定となりますので必ず設定を確認してください。
これはStatusNowサーバに接続するための必須設定となりますので必ず設定を確認してください。
■R0.02.01.176 (既存パラメータの変更について)
- シャッフルアルゴリズム
R0.01まではプルダウンリスト形式でありながら選択肢が"Slot Number"しかありませんでしたが、 R0.02からはStatsNow!!のデータベースより戦績情報を取得しチームバランスの均衡化行う "Cooprate with StatsNow"が選択肢に追加されました。
障害発生時などStatsNow!!サーバとの接続が行えない場合には自動的に"Slot Number"方式でチーム制御が行われます。 そのようなケースでも、このプルダウンリストは"Cooprate with StatsNow"のままとなり、障害復旧後は自動的にサーバ接続が再開されます。
■R0.02.01.165 (追加されたパラメータについて)
TeamBalancer系のパラメータは全て今回追加されました。
尚、前述の通りシャッフルアルゴリズムが"Slot Number"になっているとTeamBalancerは起動しませんので御注意下さい。
尚、前述の通りシャッフルアルゴリズムが"Slot Number"になっているとTeamBalancerは起動しませんので御注意下さい。
以下、数日中に補足情報を追記する予定ですので少々お待ち下さい。
StatsNow Server 接続関連設定
- StatsNow Server IPAddress
- StatsNow Server PortNo
- 送信タイムアウト(ms)
- 受信タイムアウト(ms)
これらネットワーク接続関連項目については障害発生時以外変更する必要がありません。 受信タイムアウトのみ調整していただくことがあるかもしれません。
- 接続元GameServerGUID
これはTeamControlerにて制御する予定のサーバのGuidを設定します。 GUIDはStatsNow!!のDetailInfomationページ上部に表示されていますので、不明の場合はそちらを参照して下さい。 尚、ServerGuidはサーバ名を変更しても変化しませんが「お引っ越し」やRSP変更を行うとGuidも変化しますので御注意願います。
(一般的なシステムに於けるユーザIDに該当するものですので間違えると全く接続出来ません)
- 接続元GameServerPassPhrase
接続パスワードです。別途メールなどで御連絡させて頂きます。 尚、複数台サーバをお持ちの方はそれぞれ別のPassPhraseが必要になり、 ServerGuidと組で登録されているため別々の組み合わせでは接続出来ません。
(一般的なシステムに於けるバスワードに該当するものですので間違えると全く接続出来ません)
※ここまでは一度設定すれば、滅多に変更する必要は無いでしょう
バランス(シャッフル)処理開始指示設定
- バランス処理開始待ち時間(秒)
ラウンド終了後、バランス(シャッフル処理)を開始するまでの待ち時間を秒単位で指定します。 このパラメータはシャッフルアルゴリズムに"Slot Number"を指定している場合はシャッフル開始待ち時間を意味します。 また"Cooprate with StatsNow"を指定している場合にはバランス処理開始待ち時間を意味します。 このパラメータは単純ですが実は重要なパラメータです。 この数値が小さい場合、ラウンド終了直後にバランス処理が開始されるため、バランス処理完了後に切断するプレイヤーが多発する恐れがあります。 しかし、バランス処理の実行時間に余裕が出来るため、次のラウンド開始時にバランス処理が完了していないといった最悪の事態を回避することができます。
尚、ディフォルトでは50秒に設定されており、ラウンド終了後に表示されるスコアボードが消える10秒前にバランス処理が開始されますので、 スコアボード内のプレイヤーがチーム入れ替えされるのが見えることがあります。 ラウンド終了から次のラウンドにて最初のプレイヤーがSpawnするまでの最短時間は70秒となっているため、 このディフォルトの50秒は充分に余裕のある設定となっておりますが、 ネットワークやサーバ負荷が高い場合には次のラウンド開始直後にチーム入れ替えが発生してしまうため御注意下さい。 また70秒とはスコア表示時間60秒とマップロードの最短設定時間10秒を合算していますが、 B2Kマップではマップロード時間が短縮されているとの情報もあり、さらに厳しい状況になっているかもしれません。
もし次のラウンド開始までに間に合わないケースが多発するようでしたら御連絡下さい
バランス用プレイヤー情報取得設定
このブロックは最重要項目になりますので先に概念を解説いたします。
2012/05/25現在、StatsNowが保持している総データ項目数は約12億項目に達します。
4億項目になる大雑把な根拠は下記の通りです。
プレイヤー数約200,000人 × 1プレイヤーあたりの平均実績約30ラウンド × 1ラウンドごとに収集する1人分の情報約2,000種類 = 約1,200,000,000項目になります。
プレイヤー数約200,000人 × 1プレイヤーあたりの平均実績約30ラウンド × 1ラウンドごとに収集する1人分の情報約2,000種類 = 約1,200,000,000項目になります。
しかし、この計算式には統計のアヤが存在しており、既にプレイしていない方やQuickMatchで海外から接続している一見さんなどもいらっしゃるため、
本来の意味での有効プレイヤー数は約1/4の5万人、逆に平均実績ラウンド数が4倍の120ラウンド程度になります。
本来の意味での有効プレイヤー数は約1/4の5万人、逆に平均実績ラウンド数が4倍の120ラウンド程度になります。
バランス処理に於いて上記約12億のデータ項目を活用して、少しでもバランスの取れたゲームを作ろうとする必要がありますが、
当然ながら12億全てのデータ項目を使うことはありません。
当然ながら12億全てのデータ項目を使うことはありません。
激しく簡略化されたイメージ図
プレイヤー名 | プレイ日時 | サーバ名 | マップ名 | Win or Lose | Kill数 | Death数 | 該当ラウンドの総スコア | 命中率 | 接続時のランク |
M61E5 | 2012/05/21 19:20:15 | [JPN]METRO ONLY 1000TICKETS!! | Operation Metro | Win | 36 | 32 | 13260 | 13% | 25 |
M61E5 | 2012/05/21 12:13:18 | [JPN]METRO ONLY 1000TICKETS!! | Operation Metro | Win | 18 | 22 | 7220 | 15% | 25 |
F15EE | 2012/05/22 00:08:40 | [JPN]CQ&RUSH ALL MAPS | Caspian Border | Lose | 3 | 15 | 830 | 7% | 6 |
M1A3 | 2012/05/22 00:08:40 | [JPN]CQ&RUSH ALL MAPS | Caspian Border | Lose | 8 | 8 | 1030 | 10% | 16 |
F15EE | 2012/05/22 00:08:40 | [JPN]CQ&RUSH ALL MAPS | Caspian Border | Lose | 3 | 15 | 830 | 7% | 6 |
T90Z | 2012/05/22 00:10:33 | [JPN]CQ&RUSH ALL MAPS | Caspian Border | Win | 10 | 9 | 1370 | 11% | 36 |
F/A-19 | 2012/05/22 00:12:17 | [JPN]CQ&RUSH ALL MAPS | Caspian Border | Win | 31 | 2 | 6880 | 13% | 72 |
M17A4 | 2012/05/23 22:17:39 | [JPN]HELL HELL HELL | Operation Firestorm | Lose | 2 | 31 | 570 | 1% | 3 |
G4A4 | 2012/05/23 22:48:00 | [JPN]HELL HELL HELL | Operation Firestorm | Win | 10 | 4 | 2810 | 17% | 38 |
F/A-19 | 2012/05/23 22:51:26 | [JPN]HELL HELL HELL | Operation Firestorm | Win | 7 | 2 | 1930 | 15% | 48 |
このようなイメージの巨大な表が存在し、横(列)方向が約2,000、縦(行)方向が6,000,000存在していると考えてください。
まず横(列)方向には2,000種類のデータが並んでいると言っても、実際に使用するのは僅か数項目でしょう。
その使用するデータ項目の種類を下記「プレイヤーの能力計算式」で指定します。
その使用するデータ項目の種類を下記「プレイヤーの能力計算式」で指定します。
また、現在(またはこれから開始される)ラウンドに接続していないプレイヤーさんの戦績は全く使いません。
従って、縦(行)方向は現在接続中のプレイヤーのみデータだけが自動的に選択されます。
従って、縦(行)方向は現在接続中のプレイヤーのみデータだけが自動的に選択されます。
しかし、接続中のプレイヤーであれば、全ての行のデータを使用すべきでしょうか?
例えば、Operation Metro専用サーバなのにCaspion Borderにて記録された戦績は必要なのか?
またコンクエスト専用サーバなのにラッシュの戦績は必要なのか?
例えば、Operation Metro専用サーバなのにCaspion Borderにて記録された戦績は必要なのか?
またコンクエスト専用サーバなのにラッシュの戦績は必要なのか?
このような問題に対応するため、
接続中のプレイヤーに関する戦績を検索(絞り込む)ための条件を後述する下記パラメータで指定します。
接続中のプレイヤーに関する戦績を検索(絞り込む)ための条件を後述する下記パラメータで指定します。
評価対象ServerGUID
評価対象ゲームモード
該当マップの戦績のみ評価する
評価対象マップ名
評価対象期間
評価対象ゲームモード
該当マップの戦績のみ評価する
評価対象マップ名
評価対象期間
それでは具体的な説明に移ります。
・プレイヤーの能力計算式 (ここは詳細追記予定)
最も重要なパラメータです。
プレイヤーの能力(PlayerAbility 以下、PAと表記)を算出するための計算式をここに記入します。
また計算のために必要となるデータ項目はStatsNow!!に記録されている約2,000項目の中から、
まずは200項目程度を抽出しています。
まずは200項目程度を抽出しています。
各データ項目は単独で指定することも可能ですが、括弧と四則演算記号(演算子)を使用して計算式にすることも可能です。
また項目名と演算子の間の空白は必須ではないためお好みで。
また項目名と演算子の間の空白は必須ではないためお好みで。
(例.1) (KILLS_G + DEATHS_G) / TIME_PLAYED_G * 60 この例では各ラウンド毎に記録された1分間あたりのKillとDeathの合計をPAとして用います。
(例.2) (SC_TEAM_G + SC_SQUAD_G) / TIME_PLAYED_G * 60 この例では各ラウンド毎に記録された1分間あたりのチームスコアと分隊スコアの合計をPAとして用います。
(例.3) (SCORE_G - REVIVES_G * 100) / TIME_PLAYED_G * 60 この例では各ラウンド毎に記録されたトータルスコアから蘇生によって得たスコアを減算し、 1分間あたりのスコアを算出することによって蘇生によるスコアを除いたSPMをPAとして用います。 但し、ここでは蘇生のスコアは100としていますが、分隊蘇生の場合は110になりますので上記のPA算出式は正確ではありません。
(例.4) RANK 単純にランクをPAとして用います。
(例.5) NUM_WINS / NUM_LOSSES この例ではいわゆるW/LをPAに用います。
(例.6) SC_VEHICLE_A この例ではいわゆるビークルスコアの累計値をPAに用います。
※最後に60を乗じている計算式はPAを分単位に変換するための固定値ですが、全プレイヤーに同じ値を乗ずることは無意味であるため、秒単位で比較しても同じ結果になります。
・評価対象ServerGUID (評価対象のStatsNowレコードを絞り込むための条件)
「ウチのサーバの戦績しか使わない」とおっしゃる方向けの機能。
PA算出のために使いたいサーバのGUIDを設定するとそのサーバにて記録された戦績しか使わなくなります。
また複数台の指定も可能。
また複数台の指定も可能。
(例.1) 設定無し。この場合全てのサーバで記録された戦績を用いてPAの計算が行われます。
(例.2) 40467f61-a5cd-405c-9cd6-657c83752e93 サーバ1台のみ指定のケースでは対象サーバのGUIDをそのまま記述してください。
(例.3) 40467f61-a5cd-405c-9cd6-657c83752e93 | 037b7c8f-764f-469a-b761-43be8f20486c サーバを複数指定するケースでは複数のGUIDを"|"(パイプ記号)で区切って記述してください。 "|"の前後の空白は必須ではありませんが空白がある方が読みやすいでしょう。 尚、指定可能な台数に上限はありません。
・評価対象ゲームモード (ALL / Conquest / Rush / Team Death Match から選択)
こちらは見たままの機能です。ディフォルトではALLが選択されており、全てのゲームモードの戦績を対象にPAを算出します。
「ウチのサーバはConquestOnlyなんだからRushの戦績は不要」とおっしゃる方はConquestを選択して下さい。
「ウチのサーバはConquestOnlyなんだからRushの戦績は不要」とおっしゃる方はConquestを選択して下さい。
・該当マップの戦績のみ評価する?
ラウンド開始時の初期チーム編成に於いては
これから開始されるラウンドで使用されるマップで記録された戦績のみ、
ラウンド中の接続者に対するチーム配属決定に於いては
現在進行中のラウンドで使用されているマップで記録された戦績のみを使用するか否かについて設定します。
これから開始されるラウンドで使用されるマップで記録された戦績のみ、
ラウンド中の接続者に対するチーム配属決定に於いては
現在進行中のラウンドで使用されているマップで記録された戦績のみを使用するか否かについて設定します。
Noの場合は現在またはこれから使用するマップとは一切関係無く全てのマップで記録された戦績を対象にPAを算出します。 (但し、後述の「評価対象マップ名」にて例外あり)
Yesの場合は現在またはこれから使用するマップで記録された戦績のみ使用してPAを算出します。 (後述の「評価対象マップ名」による指定は無効となり(無視され)ます)
・評価対象マップ名
指定されたマップで記録された戦績のみを使用してPAを算出するための機能です。
前述の「該当マップの戦績のみ評価する?」でYesを選択している場合には無効となる設定項目です。
前述の「該当マップの戦績のみ評価する?」でYesを選択している場合には無効となる設定項目です。
(例.1) 設定無し。 この場合は全てのマップで記録された戦績が使用されます。 但し、「該当マップの戦績のみ評価する?」でYesを選択している場合には現在進行中のマップのみ使用されます。
(例.2) MP_007 「Caspian Border専用サーバなので他のマップで記録された戦績は使わない」と言ったケースでは有効です。
(例.3) MP_007 | MP_012 | MP_017 | MP_018 「ウチは飛行機マップ専用なので」と言ったケースでは飛行機マップのみ複数指定することも可能です。 マップを複数指定するケースでは複数のGUIDを"|"(パイプ記号)で区切って記述してください。 "|"の前後の空白は必須ではありませんが空白がある方が読みやすいでしょう。 尚、指定可能なマップ数に上限はありません。
・評価対象期間(日数)
あまりにも古いデータはPA算出のためには無意味なものかもしれません。
当初はかなりアレだったプレイヤーさんも今では立派な方になっているかも。
当初はかなりアレだったプレイヤーさんも今では立派な方になっているかも。
そのため過去N日以内の戦績のみを対象にPA算出するための条件です。
戦績数過少プレイヤー対応設定
これは実際にあったお話。
SPMをベースにバランス処理を行う試験中にSPM2000オーバーのプレイヤーが接続。
チータかと調べてみたところ戦績が2ラウンドしか存在しておらず、うち1ラウンドがSPM5000超になっていました。
SPMをベースにバランス処理を行う試験中にSPM2000オーバーのプレイヤーが接続。
チータかと調べてみたところ戦績が2ラウンドしか存在しておらず、うち1ラウンドがSPM5000超になっていました。
そのラウンドについて調べてみると、ラウンド終了8秒前に接続しスコアゼロで終了。
コンクエスト参加とコンクエスト勝利のアワードで700点。
確かにSPM5000超になります。
もう一つのラウンドの詳細は忘れましたが、SPM0であっても平均するとSPM2500にはなってしまいます。
コンクエスト参加とコンクエスト勝利のアワードで700点。
確かにSPM5000超になります。
もう一つのラウンドの詳細は忘れましたが、SPM0であっても平均するとSPM2500にはなってしまいます。
このような事態を回避するための機能が下記2つのパラメータになります。
・最低ラウンド数
他の検索条件によってプレイヤーごとに評価対象となる戦績を絞り込んだ結果、
該当する戦績の件数がここで設定した値を下回る場合には全ての戦績を評価対象外とします。
該当する戦績の件数がここで設定した値を下回る場合には全ての戦績を評価対象外とします。
評価対象外となったプレイヤーのPAは次に説明する「プレイヤーのディフォルト能力値」で設定します。
・プレイヤーのディフォルト能力値
下記のケースに該当するプレイヤーのPAはこの項目で設定した値をPAとして使用します。
1.各種検索条件にて絞り込んだ結果、戦績が1件も存在しない場合
2.各種検索条件にて絞り込んだ結果、該当の戦績が「最低ラウンド数」を下回った場合
2.各種検索条件にて絞り込んだ結果、該当の戦績が「最低ラウンド数」を下回った場合
このディフォルト値は全プレイヤーの平均をやや下回る程度を設定するのが無難と考えられます。
プレイヤー別戦績集計方法
前述の通り、「プレイヤーの能力計算式」に基づいて各ラウンド毎のPAを求めますが、
検索条件による絞り込みを行いますが、それでも多数のラウンドの戦績が評価対象となることが一般的です。
(つまり絞り込んでも1件にはならないのが普通)
検索条件による絞り込みを行いますが、それでも多数のラウンドの戦績が評価対象となることが一般的です。
(つまり絞り込んでも1件にはならないのが普通)
各プレイヤー毎に複数の戦績が評価対象になるためPAも各プレイヤー毎にPA算出されます。
これらをどのように集計するかを指定するのが下記「プレイヤーの能力集計方式」です。
Avg 戦績毎に算出された複数のPAの平均値を該当プレイヤーのPAとする方式。恐らくこのパターンを使用するケースが多くなるでしょう。 Max 戦績毎に算出された複数のPAの中から最大の値を該当プレイヤーのPAとする方式。 PA計算式にRankなど減少することの無い値を使用する場合にはこのパターンになることが多くなるでしょう。 Min 戦績毎に算出された複数のPAの中から最小の値を該当プレイヤーのPAとする方式。用途不明。 Sum 戦績毎に算出された複数のPAの総合計を該当プレイヤーのPAとする方式。 サーバGuidで絞り込みを行い、プレイ時間の総合計を求めれば「常連さん指数」が作れますが、バランスが良くなるかどうかは不明。 Last &color(red){未実装} 最後の戦績だけを用いてPAを算出する方式。 Rankなど絶対に下がらない数値をベースとしたPAを算出する場合には、最後の戦績だけを用いるべきですがサーバ負荷の問題により未実装となっております。 多くの場合はLast=Maxの関係が成り立ちますのでMaxを指定して代用してください。
ラウンドの途中で接続したプレイヤーのチーム配属
この点については非常に奥の深い問題が多々存在しており、簡単に最適な方式が見つかりそうに無いのが現状です。
「途中接続プレイヤーのチーム決定方式」を用意しておりますが、ほとんど影響が無いためディフォルトの"Number"を選択して下さい。
尚、現状にて実装されている途中接続者の配属先チーム決定アルゴリズムは後述いたします。
マップごとのチーム編成について
ラウンド開始時に全プレイヤーのPAを算出し、PAの合計に偏りが発生しないよう2チームに配属を行います。
通常では2チームのPA合計値の差は0.1%以内に収まることを確認しています。
通常では2チームのPA合計値の差は0.1%以内に収まることを確認しています。
(例) PA算出式にRankのみ指定し、バランス処理実行時に接続していた全プレイヤーの平均ランクが30だったとします。 この場合、USの平均ランクが29.99、RUSの平均ランクが30.01などになります。
しかし、必ずしもこれでバランスの良いゲームが生まれるとは限りません。
経験的にその理由は大雑把に下記3点と言って良さそうです。
経験的にその理由は大雑把に下記3点と言って良さそうです。
1.プレイヤーの能力計算式が不適切(完全に適切な計算式は恐らく存在しないでしょう)
2.途中切断者及び途中接続者によるバランスの乱れ(この点は今後徐々に改善していく予定です)
3.マップの特性による陣営ごとの有利不利(プレイヤーの能力が50/50なら常にどちらかが勝つように出来ている)
2.途中切断者及び途中接続者によるバランスの乱れ(この点は今後徐々に改善していく予定です)
3.マップの特性による陣営ごとの有利不利(プレイヤーの能力が50/50なら常にどちらかが勝つように出来ている)
ここでは3.のマップ特性による有利不利を補正する方法を解説いたします。
Operation MetroやStrike at Karkandなど著しく一方の陣営の勝率が高いマップでは
陣営ごとの平均(合計)PAをバランスさせてもゲーム進行のバランスが良くなるとは限りません。
陣営ごとの平均(合計)PAをバランスさせてもゲーム進行のバランスが良くなるとは限りません。
そのため意図的に陣営間バランスを「不均衡に安定させる」(一定の差に保つ)ことによってゲームバランスを改善させるための機能です。
・マップ別補正値
このパラメータは使用しない場合でもマップごとに0を設定する必要があります。(ディフォルトで0になっています)
(例) XP1_001 : Strike At Karkand : 1 : 20 パラメータの意味は左から順に下記の通り マップファイル名(修正不要) : マップ名(修正不要) : チーム番号 : 補正係数(+%) ※区切り文字である":"(コロン)は消さないで下さい。 チーム番号は下記の通りです。 0 該当マップではチーム別の補正を行わない 1 US(ATT)側を補正します 2 RUS(DEF)側を補正します 補正係数は0以上の値を設定して下さい。 負の値を設定したい場合はチーム番号に逆のチームを設定して正の補正係数を設定して下さい。 US側を20%補正するとRUSに対しPAの合計が20%高くなるようバランスされます。
PluginLogの表示内容について
ProconのPluginタブを選択すると画面下部に様々なログが表示されますが、
TeamBalance処理に関する重要情報をそちらに表示する機能が実装されていますので内容について解説します。
TeamBalance処理に関する重要情報をそちらに表示する機能が実装されていますので内容について解説します。
[18:24:21 00] TeamControler : Retrieving PlayerAbility : PlayerName = M16A5 (新しいプレイヤーM16A5が接続した) [18:24:21 33] TeamControler : Response PlayerAbility : PlayerName = M16A5 : PlayerAbility = 46.000 : RecordCount = 431 (M16A5のPAは46.000と算出され、絞り込みを行った後の戦績情報は431件だった) [18:24:22 87] TeamControler : NewPlayerJoin : PlayerName = M16A5 : TeamId = 2 (M16A5はTeam1(RUS)へ配属された) [18:24:22 88] TeamControler - TeamAbility : Team1(28) = 369.000 : Team2(29) = 377.000 : Diff = 2.168% (Team1は合計28名となりPAの合計は369.000、Team2は合計29名となりPAの合計は377.000となった)
※上記Diffの値はマップ別補正を行っていない場合は0付近、マップ別補正を行っている場合は補正係数付近の値になります。
■既知の不具合(と言うより未実装機能)
- ゲームサーバがダウンし再起動した場合、再起動直後のラウンドでは正常にバランスされません。
これはダウン直前に接続していたプレイヤーがまだ接続中であると御認識することが原因です。
- ラウンド進行中にProconを再起動すると、次のラウンド開始までは正常にバランスされません。
進行中のラウンドに既に接続していたプレイヤーのPAを測定する処理を実装していないことが原因です。
■次回リリース予定の機能
(後程記載します)