RPC の詳細(旧)
ネットワークのインスタンス化(旧)

状態同期の詳細(旧)

(Unity 5.1 からは UNET の使用を推奨しています。下記の情報は旧ネットワークシステムのものです。)

特定の Network View で状態同期を有効にするには、State Synchronization のドロップダウンで Reliable Delta CompressedUnreliable を選択します。次に同期するデータの種類を Observed プロパティーとして設定します。

Unity は Transform、Animation、Rigidbody および MonoBehaviour コンポーネントを同期できます。

Transform は位置、回転、スケールを格納することによりシリアライズされます。親子情報はネットワークを通して渡されることはありません。

アニメーション は各アニメーション実行の状態をシリアライズします、すなわち time、weight、speed および有効化されたプロパティーです。

リジッドボディ は位置、回転、速度および回転速度をシリアライズします。

スクリプト( MonoBehaviours)は OnSerializeNetworkView() 関数を呼び出します。

信頼性と帯域幅

Network View には 2 つの信頼性レベル、すなわち Reliable Delta Compressed と Unreliable、があります。

どちらにも長所、短所があり、このゲームの詳細により何を使用するのがベストか決まります。

帯域幅を最小化するための追加情報については、ネットワーク帯域幅の最小化(旧) を参照してください。

Reliable Delta Compressed

Reliable Delta Compressed モードによりデータは最後にクライアントで受信したデータと現在の状態のデータを自動的に比較します。もし最後の更新からデータが変更されてない場合データは送信されません。しかしデータはプロパティーごとに比較されます。例えば、もし Transform の位置が変更されているが回転は変更されてない場合、位置のみがネットワーク上送信されます。変更データのみ送信することで帯域幅は節約されます。

Unity はすべての送信されたパケットが受信されていることを、UDP パケットが受信されるまで再送信を繰り返すことにより、信頼性を保って送信します。言い換えると、パケットが受信できなかった場合、その後に送られるパケットは受信できなかったパケットが、再送信されて到着するまで、適用されないとうことです。それまでは、それ以降のパケットはバッファで待機します。

Unreliable

Unreliable モードにより、Unity はパケットが受信されたかどうかを確認することなく送信します。これによりどの情報が受信されたか判断できないため、変更データのみを送信することは安全ではなく、毎回の更新ごとに状態のすべてが送信されます。

使用すべき手法の決定

ネットワークレイヤーでは UDP、すなわち信頼性がなく順序がないプロトコルが使用されますが、TCP のように信頼性があり順序のあるパケットを送信することもできます。内部的に ACK や NACK を使用してパケットの送信を制御しパケットが受信されることを保証します。信頼性があり順序のあるパケットを使用するデメリットはパケットが受信されないか遅延した場合、そのパケットが安全に到着するまですべてが停止されてしまうことです。これはタイムラグの大きいネットワークでは遅延が認識されることにつながります。

信頼性のない送信はデータがどうせ毎フレーム変更されることが分かっている場合に便利です。例えば、レーシングゲームで、プレイヤーの車は必ず動いているといえるので、パケットを逃したとしてもすぐに次のパケットで修正されます。

一般的には、「 Unreliable 」(非信頼)を、素早く頻繁な更新を行うことが重要であって、パケットを逃して問題ない場合に使用します。反対に、データがそれほど頻繁に変更されない場合は、「 Reliable Delta Compressed 」(信頼差分圧縮)を、帯域幅の節約のために使用します。

予測

サーバーがゲーム世界の状態に対して 完全な権限 を持つ場合、クライアントはサーバーから受信する更新にもとづいてのみゲーム状態を変更します。ひとつ問題となるのは、サーバーの反応を待つことによって遅延が発生し、ゲームプレイに影響が及ぶことです。例えば、プレイヤーがキーを押して前に進む場合、実際には更新された状態がサーバーから受信しないかぎり動きません。この遅延は接続の待ち時間に依存するため、接続が悪いほど、制御系がきびきびと動作しなくなります。

この問題に対する解決策のひとつは Client-side Prediction (クライアント側予測)であり、この意味はクライアントがサーバーから渡される動作を、ほぼ同一モデルをしようすることによって予測することです。プレイヤーは直ちに入力に反応するもののサーバーは最後の更新からの情報をみます。状態の更新がサーバーから到着したとき、クライアントは必要な情報だけ認識します。予測の誤りは判明の都度修正され、連続的に修正されれば結果はよりスムーズとなりより気づかないものとなる。

推測航法あるいは、内挿/外挿

クライアント側予測の基本原理をプレイヤーの相手に適用することもできます。Extrapolation (外挿)は相手の位置、速度、角度について最後に知っている複数の情報を格納して、近い将来にいる場所を予測するプロセスです。次の更新がようやく受信されたときに正しい位置が判明し、クライアントの状態は正確な情報で更新され、この場合に予測が悪かった場合はキャラクターの位置が飛んで見えてしまいます。FPS ゲームにおいてプレイヤーの動作は一貫性がないことが多く、この種の予測がうまく行くことは難しい。遅延が十分に大きくなってしまうと予測のエラーが蓄積するにつれ相手の位置がひどく飛ぶようになります。

Interpolation (内挿)はパケットがクライアントへの送信後に受信されない場合に使用できます。通常、これは NPC の動作がポーズし、新しいパケットが受信されたときに新しい位置にジャンプすることにつながります。ゲームの世界の状態を一定の量だけ(例えば 100ms )遅延させて、それから最後に知られた位置と新しい位置の間に内挿することで、このパケットが受信できなかったタイミングでの、二点間の動作はスムーズになります。

RPC の詳細(旧)
ネットワークのインスタンス化(旧)