「TeamControler R0.03」の編集履歴(バックアップ)一覧に戻る
TeamControler R0.03 - (2012/06/15 (金) 19:31:17) のソース
【本ページは記述中です】 (2012/06/14 21:30 記述開始) ***■忘れないうちに重要な注意事項を記載致します &b(){(1)R0.03の主要機能は下記2点になります} ・マップ別補正値の自動修正機能 ・プレイヤー能力計算式のマップ別設定 &b(){(2)その他の修正は下記3点になります} ・通信関連パラメータのディフォルト値変更 ・PluginLogへの出力抑制を可能に ・ラウンドの途中でProconまたはPluginを再起動した場合に既接続プレイヤーの全PAを自動取得 ・途中接続者のチーム配属方法にて「強制不利Join」を利用可能に ・プレイヤー能力計算式に入力した+記号がProcon再起同時に消えてしまうProconの不具合に対応 &b(){(3)一部の項目にてR0.02とはパラメータの互換性がありません} 下記のパラメータはR0.02とは互換性がありません。 ・プレイヤー能力計算式 ・評価対象マップ名 パラメータ名称は変更されていないため、 &color(red){Proconの仕様によりR0.02用の設定値を自動で読み込みますが、} &color(red){そのままでは正常に稼働しませんので後述の手順に従ってR0.03用に適宜変更して下さい。} &b(){(4)新DLC Close Quarters対応について} 2012/06/12に新しくリリースされたDLC「Close Quarters」では4種類のマップを3種類のゲームモードでプレイ出来ます。 TeamControlerでは新DLCに対する特別な修正及び試験は行っておりませんが 既に多数の鯖管様より情報が寄せられておりますので、 下記の通り纏めさせて頂きます。 ・新マップは4種類とも正常稼働するがゲームモードによっては使用不可 ・Conquest Dominationの場合は問題なく稼働する ・Gun Masterの場合はチケットの内部的な扱いが不明なため強制不利Join機能の稼働状況が未確認 ・Team Death Match Close QuartersについてはTeamControlerが3チーム以上のゲームモードに対応していないため稼働しない 従って、詳細な試験は未実施であるものの、&color(red){ゲームモードがConquest Dominationの場合は使用可能}と考えられます。 ---- ***■TeamControler R0.03リリースの趣旨 様々なプレイヤーの特性を数値化するためのパラメータが「プレイヤーの能力計算式」ですが、 R0.02では全てのマップ共通で一つのパラメータとなっていたため、 一台のサーバで特性の異なるマップをローテーションさせる場合には 適切なパラメータを見出すことが難しいものとなっていました。 そのためR0.03ではマップ別にプレイヤーの能力計算式を設定出来るよう改修を行っています。 また、マップ別補正値に適切な値を設定するためには相当量の戦績データを収集する必要があり、 そのための手間も時間も多大なものになりがちです。 そこで、ラウンド終了毎に自動で補正値を修正する機能を追加しました。 ---- ***■Pluginログの出力抑止について &image(TC_R3_0002.png) R0.02ではPluginタブの画面下部に大量のPA(プレイヤー能力値)に関する情報が出力されました。 この情報が不要な場合には「プラグインログを出力する?」で"No"を選択することにより、出力を抑止することが出来ます。 ---- **■R0.03.01.218 (パラメータ設定画面イメージ) &image(TC_R3_0001.png) ---- **■サーバ接続関連パラメータのディフォルト値変更について ・送信タイムアウト(ms) ・受信タイムアウト(ms) StatsNowServerが高負荷状態の際、希にTimeoutが発生していたためディフォルトタイムアウトを延長しています。 Timeoutが発生しやすいのは朝(午前中)となっており、 データベースの整合性確認やバックアップ処理など大容量の一括処理が実施されていることが原因です。 ・バランス処理開始待ち時間(秒) Timeoutの発生を考慮するとバランス処理の開始はやや早めの方が適切となるため、 ディフォルトの待ち時間を若干短縮しています。 ---- *バランス用プレイヤー情報取得設定 &color(red){このブロックは最重要項目になりますので先に概念を解説いたします。} 2012/05/25現在、StatsNowが保持している総データ項目数は約12億項目に達します。 4億項目になる大雑把な根拠は下記の通りです。 プレイヤー数約200,000人 × 1プレイヤーあたりの平均実績約30ラウンド × 1ラウンドごとに収集する1人分の情報約2,000種類 = 約1,200,000,000項目になります。 しかし、この計算式には統計のアヤが存在しており、既にプレイしていない方やQuickMatchで海外から接続している一見さんなどもいらっしゃるため、 本来の意味での有効プレイヤー数は約1/4の5万人、逆に平均実績ラウンド数が4倍の120ラウンド程度になります。 バランス処理に於いて上記約12億のデータ項目を活用して、少しでもバランスの取れたゲームを作ろうとする必要がありますが、 当然ながら12億全てのデータ項目を使うことはありません。 &color(blue){激しく簡略化されたイメージ図} |プレイヤー名|プレイ日時|サーバ名|マップ名|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| &color(blue){このようなイメージの巨大な表が存在し、横(列)方向が約2,000、縦(行)方向が6,000,000存在していると考えてください。} まず横(列)方向には2,000種類のデータが並んでいると言っても、実際に使用するのは僅か数項目でしょう。 その使用するデータ項目の種類を下記「&color(red){プレイヤーの能力計算式}」で指定します。 また、現在(またはこれから開始される)ラウンドに接続していないプレイヤーさんの戦績は全く使いません。 従って、縦(行)方向は現在接続中のプレイヤーのみデータだけが自動的に選択されます。 しかし、接続中のプレイヤーであれば、全ての行のデータを使用すべきでしょうか? 例えば、Operation Metro専用サーバなのにCaspion Borderにて記録された戦績は必要なのか? またコンクエスト専用サーバなのにラッシュの戦績は必要なのか? このような問題に対応するため、 接続中のプレイヤーに関する戦績を検索(絞り込む)ための条件を後述する下記パラメータで指定します。 &color(red){評価対象ServerGUID} &color(red){評価対象ゲームモード} &color(red){該当マップの戦績のみ評価する} &color(red){評価対象マップ名} &color(red){評価対象期間} &color(blue){それでは具体的な説明に移ります。} &b(){・プレイヤーの能力計算式 &color(red){(ここは詳細追記予定)}} 最も重要なパラメータです。 プレイヤーの能力(PlayerAbility 以下、&color(red){PA}と表記)を算出するための計算式をここに記入します。 また計算のために必要となるデータ項目はStatsNow!!に記録されている約2,000項目の中から、 まずは200項目程度を抽出しています。 &sizex(+1){&b(){&color(blue){[[使用可能な項目についてはこちらを参照願います>>http://www45.atwiki.jp/goodgames/pages/366.html]]}}} 各データ項目は単独で指定することも可能ですが、括弧と四則演算記号(演算子)を使用して計算式にすることも可能です。 また項目名と演算子の間の空白は必須ではないためお好みで。 (例.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を分単位に変換するための固定値ですが、全プレイヤーに同じ値を乗ずることは無意味であるため、秒単位で比較しても同じ結果になります。 &b(){・評価対象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を"|"(パイプ記号)で区切って記述してください。 "|"の前後の空白は必須ではありませんが空白がある方が読みやすいでしょう。 尚、指定可能な台数に上限はありません。 &b(){・評価対象ゲームモード (ALL / Conquest / Rush / Team Death Match から選択)} こちらは見たままの機能です。ディフォルトではALLが選択されており、全てのゲームモードの戦績を対象にPAを算出します。 「ウチのサーバはConquestOnlyなんだからRushの戦績は不要」とおっしゃる方はConquestを選択して下さい。 &b(){・該当マップの戦績のみ評価する?} ラウンド開始時の初期チーム編成に於いては これから開始されるラウンドで使用されるマップで記録された戦績のみ、 ラウンド中の接続者に対するチーム配属決定に於いては 現在進行中のラウンドで使用されているマップで記録された戦績のみを使用するか否かについて設定します。 Noの場合は現在またはこれから使用するマップとは一切関係無く全てのマップで記録された戦績を対象にPAを算出します。 (但し、後述の「評価対象マップ名」にて例外あり) Yesの場合は現在またはこれから使用するマップで記録された戦績のみ使用してPAを算出します。 (後述の「評価対象マップ名」による指定は無効となり(無視され)ます) &b(){・評価対象マップ名} 指定されたマップで記録された戦績のみを使用してPAを算出するための機能です。 前述の「該当マップの戦績のみ評価する?」でYesを選択している場合には無効となる設定項目です。 (例.1) 設定無し。 この場合は全てのマップで記録された戦績が使用されます。 但し、「該当マップの戦績のみ評価する?」でYesを選択している場合には現在進行中のマップのみ使用されます。 (例.2) MP_007 「Caspian Border専用サーバなので他のマップで記録された戦績は使わない」と言ったケースでは有効です。 (例.3) MP_007 | MP_012 | MP_017 | MP_018 「ウチは飛行機マップ専用なので」と言ったケースでは飛行機マップのみ複数指定することも可能です。 マップを複数指定するケースでは複数のGUIDを"|"(パイプ記号)で区切って記述してください。 "|"の前後の空白は必須ではありませんが空白がある方が読みやすいでしょう。 尚、指定可能なマップ数に上限はありません。 &b(){・評価対象期間(日数)} あまりにも古いデータはPA算出のためには無意味なものかもしれません。 当初はかなりアレだったプレイヤーさんも今では立派な方になっているかも。 そのため過去N日以内の戦績のみを対象にPA算出するための条件です。 ---- *戦績数過少プレイヤー対応設定 これは実際にあったお話。 SPMをベースにバランス処理を行う試験中にSPM2000オーバーのプレイヤーが接続。 チータかと調べてみたところ戦績が2ラウンドしか存在しておらず、うち1ラウンドがSPM5000超になっていました。 そのラウンドについて調べてみると、ラウンド終了8秒前に接続しスコアゼロで終了。 コンクエスト参加とコンクエスト勝利のアワードで700点。 確かにSPM5000超になります。 もう一つのラウンドの詳細は忘れましたが、SPM0であっても平均するとSPM2500にはなってしまいます。 このような事態を回避するための機能が下記2つのパラメータになります。 &b(){・最低ラウンド数} 他の検索条件によってプレイヤーごとに評価対象となる戦績を絞り込んだ結果、 該当する戦績の件数がここで設定した値を下回る場合には全ての戦績を評価対象外とします。 評価対象外となったプレイヤーのPAは次に説明する「プレイヤーのディフォルト能力値」で設定します。 &b(){・プレイヤーのディフォルト能力値} 下記のケースに該当するプレイヤーのPAはこの項目で設定した値をPAとして使用します。 1.各種検索条件にて絞り込んだ結果、戦績が1件も存在しない場合 2.各種検索条件にて絞り込んだ結果、該当の戦績が「最低ラウンド数」を下回った場合 &color(red){このディフォルト値は全プレイヤーの平均をやや下回る程度を設定するのが無難と考えられます。} ---- *プレイヤー別戦績集計方法 前述の通り、「プレイヤーの能力計算式」に基づいて各ラウンド毎のPAを求めますが、 検索条件による絞り込みを行いますが、それでも多数のラウンドの戦績が評価対象となることが一般的です。 (つまり絞り込んでも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%以内に収まることを確認しています。 (例) PA算出式にRankのみ指定し、バランス処理実行時に接続していた全プレイヤーの平均ランクが30だったとします。 この場合、USの平均ランクが29.99、RUSの平均ランクが30.01などになります。 しかし、必ずしもこれでバランスの良いゲームが生まれるとは限りません。 経験的にその理由は大雑把に下記3点と言って良さそうです。 &b(){1.プレイヤーの能力計算式が不適切(完全に適切な計算式は恐らく存在しないでしょう)} &b(){2.途中切断者及び途中接続者によるバランスの乱れ(この点は今後徐々に改善していく予定です)} &b(){3.マップの特性による陣営ごとの有利不利(プレイヤーの能力が50/50なら常にどちらかが勝つように出来ている)} ここでは3.のマップ特性による有利不利を補正する方法を解説いたします。 Operation MetroやStrike at Karkandなど著しく一方の陣営の勝率が高いマップでは 陣営ごとの平均(合計)PAをバランスさせてもゲーム進行のバランスが良くなるとは限りません。 そのため意図的に陣営間バランスを「不均衡に安定させる」(一定の差に保つ)ことによってゲームバランスを改善させるための機能です。 &b(){・マップ別補正値} このパラメータは使用しない場合でもマップごとに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処理に関する重要情報をそちらに表示する機能が実装されていますので内容について解説します。 [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を測定する処理を実装していないことが原因です。 ***■次回リリース予定の機能 (後程記載します)