同期タイミングの変更
目次
概要
事前設定
MonobitEngine.MonobitNetwork.sendRate プロパティ
MonobitEngine.MonobitNetwork.updateStreamRate プロパティ
テストモデル
同期通信のタイミングは、自動的にMUNで管理している
MUNの同期通信自体については、その機能がほぼ自動化されています。
オブジェクトの同期については、MonobitView, MonobitTransformView, MonobitAnimatorView
の
３つのコンポーネントを登録さえすれば、あとは自動的に行なってくれます。
RPCや、サーバへの接続・切断、ルーム入室・退室といった各種通信データについても、
「呼び出しタイミング」と「送信タイミング」は、厳密に言えば異なります。
できるだけ通信負荷（オーバーヘッド）を抑えるように、ある程度のメッセージをまとめて、一定タイミングで送信しています。
同期通信のタイミングを調整する
MUNでは一般的なゲームを構成するのに最適となるように同期通信のタイミングを測っておりますが、
作りたいゲームの内容によっては、同期通信のタイミングを調整する必要が出てくるでしょう。
例えば、２人対戦での格闘ゲームであれば、出来る限りフレームレートと一致させた状態で同期を取るべきですし、
多人数が参加するMMORPGのようなゲームであれば、高負荷を抑えるために、１秒間に１回の同期くらいで十分な場合もあります。
このページでは、同期通信のタイミングの調整方法について触れます。
事前設定▲
特に必要ありません
MUNを利用できる環境かであれば、どのクラス・メソッドからも設定可能です。
MonobitEngine.MonobitNetwork.sendRate プロパティ▲
機能
RPC や、各種接続メッセージ（サーバへの接続・切断、ロビーやルームの入退室など）の送信間隔を設定します。
入出力型
| 型 |
内容 |
| int |
１秒間における送信回数を設定します。初期値は20です。
単位は「送信回数÷秒」であり、「送信回数×１秒間におけるフレーム数÷送信フレーム間隔」です。
例えば 60fps のゲームで、１フレームに１回送信するのであれば、この値を 60 と設定します。
同様に、30fps のゲームで、２フレームに１回送信するのであれば、この値を 15 としてください。 |
記述例
// １秒間に60回のタイミングで同期通信を実行します。
MonobitEngine.MonobitNetwork.sendRate = 60;
MonobitEngine.MonobitNetwork.updateStreamRate プロパティ▲
機能
MonobitView, MonobitTransformView, MonobitAnimatorView の３種類の同期通信情報のストリーミング処理、
および、MonobitEngine.MonoBehaviour で宣言している接続コールバック「OnMonobitSerializeView」のストリーミング処理を
実行するタイミングを調整します。
入出力型
| 型 |
内容 |
| int |
１秒間におけるストリーミング処理の実行回数を設定します。初期値は10です。
単位は「送信回数÷秒」であり、「送信回数×１秒間におけるフレーム数÷送信フレーム間隔」です。
例えば 60fps のゲームで、１フレームに１回ストリーミング処理を実行するのであれば、この値を 60 と設定します。
同様に、30fps のゲームで、２フレームに１回ストリーミング処理を実行するのであれば、この値を 15 としてください。 |
記述例
// １秒間に30回のタイミングで、ストリーミング処理を実行します。
MonobitEngine.MonobitNetwork.updateStreamRate = 30;
テストモデル▲
全体的な負荷を考慮して設定する
上記について簡潔に述べれば、sendRate および updateStreamRate の ２つの要素は、以下の同期タイミングを図っています。
・MonobitEngine.MonobitNetwork.sendRate - １秒間における、１クライアントがRPCメッセージを送信する回数
・MonobitEngine.MonobitNetwork.updateStreamRate - １秒間における、１クライアントがキャラクタ同期情報を送信する回数
この２つの要素は、直接「ルーム内における総トラフィック量」に影響を及ぼします。
ネットワークやサーバのリソースは限られていますので、あらかじめトラフィックを意識したテストモデルを考えて設定してください。
テストモデルの一例
一般的なテストモデルとして、例えば「４対４で行なう対戦ゲーム」を作ることを考えてみます。
まず、総トラフィック量について、以下のように定義づけます。
ホストとクライアントが、サーバを介して、互いに情報をやり取りする「メッセージ」を、１単位とする。
１ルームあたりのメッセージ数として、例えば秒間300メッセージまで、としましょう。（これでも十分多い方ですが。）
ここから、「ホスト」および「クライアント」が最大どれだけメッセージを送れるのか、以下の数式から逆算で求めます。
メッセージの総数 = サーバの受信メッセージ数＋サーバの送信メッセージ数
サーバの受信メッセージ数 = クライアントの数 ×（sendRate + updateStreamRate)
サーバの送信メッセージ数 = サーバの受信メッセージ数 × クライアントの数
以上から
メッセージの総数 = （クライアントの数＋１）× (sendRate + updateStreamRate)
が導き出せます。
クライアントの数は「４対４＝８」ですので、
300 ÷ 9 = 33.3333...
となり、sendRate + updateStreamRate の合計値が 33 を超えないように調整します。
sendRate と updateStreamRate の比重
あとは「キャラクタ同期」と「RPCメッセージ」の比重の問題ですが、ユースケースに応じて異なります。
アクションゲームなどの場合であれば「updateSteamRate」に比重を置くべきですし、
逆にチャットなどのアプリケーションであれば「sendRate」に比重を置くべきです。
一般的な対戦ゲームであれば、比重はsendRate:updateStreamRate = 1:2 くらいが
丁度良いかと思いますので、まずはその設定で試してみてください。