goodgames
TeamControler R0.04
最終更新:
goodgames
-
view
(また、いつも通り手抜きで差分説明のみになりました。ごめんなさい)
■忘れないうちに重要な注意事項を記載致します
モジュール構成について
モジュールが1本追加され今回より3本構成となります。
- CTeamControler.cs (TeamControler本体)
- DebugLog.inc (デバッグログ出力用サブモジュール)
- ExecuteServerCommand.inc (Proconを介さずに直接ゲームサーバを制御するためのサブモジュール) 今回追加
全て上書きで導入して下さい。
設定パラメータの変更について
設定パラメータにつきましては
アンイーブン解消処理及び分隊編成関連にて一部互換が無いものが存在します。
アンイーブン解消処理及び分隊編成関連にて一部互換が無いものが存在します。
必要に応じ、事前に設定値の保存をお願い致します。
セキュリティ関連情報
R0.04にはTDMのラウンド終了時チケット(キル)数を取得する必要上、
Proconを介さずにゲームサーバと通信を実施する処理が実装されています。
Proconを介さずにゲームサーバと通信を実施する処理が実装されています。
その接続に際しゲームサーバ側の認証を得る必要があるため、
Proconに保存されているパスワードをTeamControlerが読み取りゲームサーバに送信する処理が含まれます。
Proconに保存されているパスワードをTeamControlerが読み取りゲームサーバに送信する処理が含まれます。
当該処理につきましては暗号化通信処理が実装されているため特段のリスクは無く、
またパスワードをStatsNowサーバやGoodGamesに送信することはありませんが、
あらかじめ御了承願います。
またパスワードをStatsNowサーバやGoodGamesに送信することはありませんが、
あらかじめ御了承願います。
※R0.04にてゲームサーバと通信する処理はゲームモードがTDMの場合のみ発生いたしますが、
R0.05など今後のリリース時に日本語メッセージの送信処理などを実装する際などにも使用する予定です。
R0.05など今後のリリース時に日本語メッセージの送信処理などを実装する際などにも使用する予定です。
■追加修正内容一覧
項番 | カテゴリ | 追加/修正/廃止 | UI項目名 | 機能 | 備考 |
1 | チームバランス制御 | 追加 | (内部実装) | ラウンド開始前のチームバランス処理時にReadAhaed処理を追加 | |
2 | チームバランス制御 | 修正 | バランス処理開始待ち時間(秒) | ディフォルト値を50に変更 | |
3 | チームバランス制御 | 追加 | (内部実装) | B2Kマップに於けるバランス処理開始時間を自動補正 | |
4 | アンイーブン解消処理 | 修正 | ラウンド中のアンイーブン解消機能(Conquest)を使用する? | アンイーブン解消処理の有無をゲームモードごとに指定可能 | |
5 | アンイーブン解消処理 | 修正 | ラウンド中のアンイーブン解消機能(Rush)を使用する? | アンイーブン解消処理の有無をゲームモードごとに指定可能 | |
6 | アンイーブン解消処理 | 修正 | ラウンド中のアンイーブン解消機能(TeamDeathMatch)を使用する? | アンイーブン解消処理の有無をゲームモードごとに指定可能 | |
7 | アンイーブン解消処理 | 修正 | アンイーブン状態判定人数差 | アンイーブン判定用の人数差を総プレイヤー数毎に細かく設定可能 | |
8 | アンイーブン解消処理 | 修正 | アンイーブン状態保留時間(秒) | アンイーブン発生時の待機時間を総プレイヤー数毎に細かく設定可能 | |
9 | アンイーブン解消処理 | 修正 | アンイーブン解消処理の必要残チケット数 | アンイーブン解消処理の必要チケット残についてTDM対応 | |
10 | アンイーブン解消処理 | 修正 | 強制チーム移動お詫びメッセージ(全体Chat) | ChatとYellを設定可能なため項目名称を変更 | |
11 | アンイーブン解消処理 | 追加 | 強制チーム移動お詫びメッセージ(個人Yell) | 強制移動の対象者にはChat以外にYellでもメッセージを送信可能 | |
12 | アンイーブン解消処理 | 追加 | 移動対象プレイヤー選択方式 | アンイーブン解消処理処理の即時実行機能を追加 | |
13 | アンイーブン解消処理 | 廃止 | 分隊未所属プレイヤーを優先的にチーム移動させる? | 上記12.に統合 | |
14 | 強制不利Join | 修正 | 強制不利Joinによるプレイヤー数の差を許容する人数 | 強制不利Joinの許容人数を総プレイヤー数毎に細かく設定可能 | |
15 | 強制不利Join | 追加 | (内部実装) | B2Kマップに於ける強制不利Join機能にて陣営別の初期チケット係数を設定 | |
16 | 分隊編成 | 廃止 | 初期接続時に自動分隊所属機能を使用する? | 同様の機能がBF3サーバ本体に実装されたため廃止 | |
17 | 分隊編成 | 追加 | 初期分隊編成方式 | バランス処理時の分隊編成方法を選択可能 | |
18 | 分隊編成 | 追加 | 最大配属先分隊番号 | 分隊関連処理にて使用する最大の分隊番号を設定可能 |
■修正内容詳細(チームバランス制御)
1.ラウンド開始前のチームバランス処理時にReadAhaed処理を追加
2.バランス処理開始待ち時間(秒)のディフォルト値を50に変更
3.B2Kマップに於けるバランス処理開始時間を自動補正
2.バランス処理開始待ち時間(秒)のディフォルト値を50に変更
3.B2Kマップに於けるバランス処理開始時間を自動補正
チームを再編成するバランス処理はラウンド間のマップロード中に実行されますが、
この時間は並行して多数のプレイヤーが切断し、また多数のプレイヤーが新規接続します。
この時間は並行して多数のプレイヤーが切断し、また多数のプレイヤーが新規接続します。
そのため出来るだけバランス処理開始を遅らせることが好バランス化の条件となります。
この点だけに着目すると「バランス処理開始待ち時間(秒)」に出来るだけ大きい値を設定するべきです。
この点だけに着目すると「バランス処理開始待ち時間(秒)」に出来るだけ大きい値を設定するべきです。
しかし、StatsNowサーバの不可などが原因でバランス処理に時間を要した場合、
バランス処理開始が遅ければ次のラウンド開始時にバランス処理が終了していないことも想定されます。
バランス処理開始が遅ければ次のラウンド開始時にバランス処理が終了していないことも想定されます。
このようなトラブルを回避するためには、
バランス処理の結果が多少悪化しても早めにバランス処理を開始する必要がありました。
従って「バランス処理開始待ち時間(秒)」は小さい値の方が安全と言えます。
バランス処理の結果が多少悪化しても早めにバランス処理を開始する必要がありました。
従って「バランス処理開始待ち時間(秒)」は小さい値の方が安全と言えます。
R0.04ではこのジレンマを解消するため、バランス処理を2回実施する方式を採用致しました。
ラウンド終了直後に待ち時間を置かず、その時点のプレイヤー構成で1度バランス処理を実行します。
但し、このバランス処理結果は使用せず破棄します。
但し、このバランス処理結果は使用せず破棄します。
その後、待ち時間を消化した時点で最新のプレイヤー構成による2度目のバランス処理を実行します。
2度目のバランス処理では大部分のプレイヤーに関する情報がサーバのメモリに残されているため、
高負荷時でも安定したレスポンスタイムが期待できます。
2度目のバランス処理では大部分のプレイヤーに関する情報がサーバのメモリに残されているため、
高負荷時でも安定したレスポンスタイムが期待できます。
64スロット機では概ね7~8秒でバランス処理が終了するため、
「バランス処理開始待ち時間(秒)」は50程度程度に設定しても安全になりました。
「バランス処理開始待ち時間(秒)」は50程度程度に設定しても安全になりました。
またB2KマップではBF3標準マップと比較しマップロード待ち時間が10秒程度短くなっていますが、
R0.04では次ラウンドにて使用されるマップにより「バランス処理開始待ち時間(秒)」を自動補正しますので、
BF3標準マップ用の待ち時間を設定しておけば、B2Kマップの場合、自動的に待ち時間が短縮されます。
R0.04では次ラウンドにて使用されるマップにより「バランス処理開始待ち時間(秒)」を自動補正しますので、
BF3標準マップ用の待ち時間を設定しておけば、B2Kマップの場合、自動的に待ち時間が短縮されます。
■修正内容詳細(アンイーブン解消処理)
4.設定パラメータ「ラウンド中のアンイーブン解消機能(Conquest)を使用する?」の追加
5.設定パラメータ「ラウンド中のアンイーブン解消機能(Rush)を使用する?」の追加
6.設定パラメータ「ラウンド中のアンイーブン解消機能(TeamDeathMatch)を使用する?」の追加
5.設定パラメータ「ラウンド中のアンイーブン解消機能(Rush)を使用する?」の追加
6.設定パラメータ「ラウンド中のアンイーブン解消機能(TeamDeathMatch)を使用する?」の追加
R0.03まではアンイーブン解消処理の使用有無を指定出来るだけでしたが、
R0.04ではゲームモードごとに使用有無を指定可能と致しました。
R0.04ではゲームモードごとに使用有無を指定可能と致しました。
7.アンイーブン判定用の人数差を総プレイヤー数毎に細かく設定可能
例えば、総プレイヤー数が59人、各チームのプレイヤー数が31対28となっているとします。
この時、プレイヤー数の差は3名になります。
アンイーブンなのは間違いありませんが、これを速やかに解消すべきか、
放置して自然解消を待つかは管理者によって判断が異なるところでしょう。
この時、プレイヤー数の差は3名になります。
アンイーブンなのは間違いありませんが、これを速やかに解消すべきか、
放置して自然解消を待つかは管理者によって判断が異なるところでしょう。
次に、総プレイヤー数が5人、各チームのプレイヤー数が4対1となっているとします。
この場合もプレイヤー数は3人差になりますが、この状況を望ましいと考える管理者の方はいないでしょう。
この場合もプレイヤー数は3人差になりますが、この状況を望ましいと考える管理者の方はいないでしょう。
R0.03では前者のケースをアンイーブンと判断しない場合、
3人差を許容することになりますので、
同じ3人差である後者のケースもアンイーブンとは判断されませんでした。
3人差を許容することになりますので、
同じ3人差である後者のケースもアンイーブンとは判断されませんでした。
R0.04ではこのような問題を解消するため、
総プレイヤー数ごとにアンイーブンと判断される人数差を設定する方式を採用しました。
総プレイヤー数ごとにアンイーブンと判断される人数差を設定する方式を採用しました。
(設定参考例。総プレイヤー数0人の場合の設定があることに注意)
総プレイヤー数0人の場合の設定を行う理由ですが、
ProconUIの構成により複数行の入力を行う場合、先頭行は必ず0から開始されるためです。
そのため先頭に何らかの無用な行を入力することにより、
行番号と総プレイヤー数が一致するため入力しやすくなります。
(この方式にしなければ、1ずつずれて入力することになる)
ProconUIの構成により複数行の入力を行う場合、先頭行は必ず0から開始されるためです。
そのため先頭に何らかの無用な行を入力することにより、
行番号と総プレイヤー数が一致するため入力しやすくなります。
(この方式にしなければ、1ずつずれて入力することになる)
従って、64スロット機では0~64の65個の値を設定する必要があります。
8.アンイーブン発生時の待機時間を総プレイヤー数毎に細かく設定可能
こちらのパラメータも上記7.と同様の理由により
総プレイヤー数によってアンイーブンの自然解消を待つ時間を変化させるべきとの考えにより実装いたしました。
総プレイヤー数によってアンイーブンの自然解消を待つ時間を変化させるべきとの考えにより実装いたしました。
設定方法についても上記7.と同様で先頭には無用ですが総プレイヤー数0人の場合の値を設定して下さい。
9.アンイーブン解消処理の必要チケット残についてTDM対応
Conquest及びRushではラウンドの進行と共にチケットが減少し、
チケット数が0になった時点でラウンドが終了します。
チケット数が0になった時点でラウンドが終了します。
しかし、TDMでは0から開始されラウンドの進行と共にチケット(キル数)が増加し、
規定のチケットに達したときにラウンドが終了するルールとなっていました。
規定のチケットに達したときにラウンドが終了するルールとなっていました。
そのため残チケット数の計算方法が逆転してしまい、
正しく稼動していないことが判明したため修正を行いました。
正しく稼動していないことが判明したため修正を行いました。
本件は内部修正のみですので使用方法などに変更はございません。
10.強制チーム移動お詫びメッセージのUI名称変更
後述の「強制チーム移動お詫びメッセージ(個人Yell)」機能が追加されたため、
既存パラメータである「強制チーム移動お詫びメッセージ」を
「強制チーム移動お詫びメッセージ(全体Chat)」に変更しました。
既存パラメータである「強制チーム移動お詫びメッセージ」を
「強制チーム移動お詫びメッセージ(全体Chat)」に変更しました。
設定方法などに変更はありませんが、
パラメータ名が変更されたためProconの仕様により過去の設定が消えてしまいます。
パラメータ名が変更されたためProconの仕様により過去の設定が消えてしまいます。
御手数ですが再度設定願います。
11.強制チーム移動お詫びメッセージ(個人Yell)
アンイーブン解消目的でのプレイヤー強制移動では、
R0.03までChatによってお詫びメッセージを送信していました。
R0.03までChatによってお詫びメッセージを送信していました。
R0.04では管理プレイヤーによるキル(正式名称不明)を伴う即時移動機能を追加したことにより、
お詫び機能を強化し、対象者のみにYell送信する機能を追加いたしました。
お詫び機能を強化し、対象者のみにYell送信する機能を追加いたしました。
管理プレイヤーによるキルが発生した直後と、
その後のRespawnから10秒間、設定した文字列が該当者にYell送信されます。
その後のRespawnから10秒間、設定した文字列が該当者にYell送信されます。
尚、このYellは即時移動ではなくDeathを待ってから移動するケースでも表示されます。
12.アンイーブン解消処理処理の即時実行機能を追加
特殊な設定が行われているサーバや「クランのクランによるクランのためのサーバ」など一部のサーバにて
アンイーブン発生時にプレイヤーのDeathを待たずに即時強制移動を行いたいとの要望があったため
本機能を追加いたしました。
アンイーブン発生時にプレイヤーのDeathを待たずに即時強制移動を行いたいとの要望があったため
本機能を追加いたしました。
これによりUIに「移動対象プレイヤー選択方式」が追加されています。
「移動対象プレイヤー選択方式」選択肢は下記の通りとなります。
選択肢 | 設定の効果 |
Wait for the Death | R0.03同様にプレイヤーのDeathを待つ方式です |
No Squad Join | 上記"Wait for the Death"によるDeath待ちの前に分隊未所属者のDeathを待つ処理を追加します |
Latest Connection | 最終接続者を即時移動します |
Lowest Score | 最低スコアのプレイヤーを即時移動します |
尚、どの方式を選択しても最初に規定時間の新規接続待ちを行います。
"Latest Connection"及び"Lowest Score"についてはプレイヤーの状況を確認せずに強制的なキルが発生するため、
一般的にプレイヤーからは不評なサーバ設定となりますので、基本的にはお勧めいたしません。
一般的にプレイヤーからは不評なサーバ設定となりますので、基本的にはお勧めいたしません。
また、BF3サーバ本体の仕様変更により新規接続者は自動的にいずかの分隊に所属する仕様となったため、
最近の傾向として、分隊未所属者はほとんど発生しなくなっています。
最近の傾向として、分隊未所属者はほとんど発生しなくなっています。
そのため"No Squad Join"を選択しても分隊未所属者のDeathが発生せず、
アンイーブン解消の時間が延びるだけに終わるケースが多くなっているため、
"No Squad Join"を用いる設定は推奨致しません。
アンイーブン解消の時間が延びるだけに終わるケースが多くなっているため、
"No Squad Join"を用いる設定は推奨致しません。
従いまして、一般的なサーバに於ける推奨設定は"Wait for the Death"になります。
■修正内容詳細(強制不利Join)
14.強制不利Joinの許容人数を総プレイヤー数毎に細かく設定可能
上記7.と同様の理由により、総プレイヤー数によって強制不利Joinの許容人数を
変更可能であるべきとの考えから機能を追加いたしました。
変更可能であるべきとの考えから機能を追加いたしました。
設定方法についても上記7.と同様で先頭には無用ですが総プレイヤー数0人の場合の値を設定して下さい。
■修正内容詳細(分隊編成)
16.初期接続時に自動的に分隊に所属される機能の廃止
同様の機能がBF3サーバ本体に実装されたため、TeamControlerからは本機能を廃止いたしました。
17.初期分隊編成方式
バランス処理終了時の分隊編成方式を下記3種類から選択します。
- Random
名前は"Random"ですが意図的に各分隊員を入れ替えるような処理は行いません。
チーム移動の対象とならなかった分隊員はそのままの分隊に残されますので、
4名ともチーム移動しなかった場合にはそのまま分隊が残されます。
チーム移動の対象とならなかった分隊員はそのままの分隊に残されますので、
4名ともチーム移動しなかった場合にはそのまま分隊が残されます。
また、チーム移動によって4名未満となった分隊にはチーム移動してきた新しい分隊員が所属しますが、
どのプレイヤーが所属するかは特に規定していません。(この点は実質的にランダムになります)
どのプレイヤーが所属するかは特に規定していません。(この点は実質的にランダムになります)
- PA Order
PAによる評価が優秀な順に4人ずつAlphaから順に分隊編成します。
理論的にはAlphaが最高の分隊でBeta, Charlieと順になります。
(過去のブログにて「猛者分隊」と称していたモードです)
理論的にはAlphaが最高の分隊でBeta, Charlieと順になります。
(過去のブログにて「猛者分隊」と称していたモードです)
- PA Balance
PAによる能力が均等になるように分隊を編成します。
PAの値そのものでバランスを取るのではなくPAのチーム内順位を用います。
各分隊に所属されるPA順位は下記の通りです。
(以下、1チーム32名の場合。他の場合は後述の「最大配属先分隊番号」に依存)
PAの値そのものでバランスを取るのではなくPAのチーム内順位を用います。
各分隊に所属されるPA順位は下記の通りです。
(以下、1チーム32名の場合。他の場合は後述の「最大配属先分隊番号」に依存)
分隊番号 | 分隊員1の順位 | 分隊員2の順位 | 分隊員3の順位 | 分隊員4の順位 |
1 | 1 | 16 | 17 | 32 |
2 | 2 | 15 | 18 | 31 |
3 | 3 | 14 | 19 | 30 |
4 | 4 | 13 | 20 | 29 |
5 | 5 | 12 | 21 | 28 |
6 | 6 | 11 | 22 | 27 |
7 | 7 | 10 | 23 | 26 |
8 | 8 | 9 | 24 | 25 |
このPA Balance方式ではPAの順位が1~8位のプレイヤーがそのまま各分隊番号の分隊長になります。
18.最大配属先分隊番号の追加
64スロット機以外の場合に分隊配属時の最大分隊番号を指定することが可能になりました。
64スロット機でも9番目以降の分隊に自動配属することも可能です。
64スロット機でも9番目以降の分隊に自動配属することも可能です。
御不明な点がございましたら何なりとお問い合わせ下さい。
添付ファイル