Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

プロパティレプリケートのタイミング

More than 1 year has passed since last update.

鈴木です。GameOfThronesが面白くて寝不足です。

レプリケーションはアクター単位でサーバーから送信される

アクターのプロパティのレプリケートはTick毎に幾つかのアクターが指名されて送信されます。

SimulateProxyアクターを持つクライアント上での処理で、自分以外の複数のアクター内のレプリケート変数にアクセスするような処理がある場合、プロパティの更新タイミングのズレによって問題が出たりする事があります。
※根本的には次アクター外に強い依存関係があるのは好ましくありません

図解

ThePawnとTheActorのそれぞれが持っているプロパティLastPowerとPowerがシンクロしているのを期待しているとした時の挙動です。
※悪い設計の例です

image.png

サーバー側ではThePawnとTheActorは連続して処理されていますが、
クライアント側ではレプリケートはアクター単位で行われるのでLastPowerとPowerプロパティがアクター間でシンクロしていないタイミングが生まれます。
複数のアクターにまたがるような変数アクセスを行う場合はこのようなタイミングのズレがあるので可能な限り避けるのが懸命です。

サーバー上での処理順序とRepNotifyの処理順序は一致しない

RPCは処理順序が保証されますがRepNotifyは順序は保証されません
例としてサーバーとクライアントでの処理の流れを書いてみます。

  • サーバー

    • Pawn::SetValueA(B)
      • OnRep_ValueB() ※ローカルで呼び出し
    • Pawn::SetValueA(10)
      • OnRep_ValueA() ※ローカルで呼び出し
    • PawnAのプロパティをレプリケート
  • クライアント

    • クライアントでパケット受信
    • プロパティをPawnAにストア(ValueA:10 ValueB:5)
    • PawnAに対してRepNotifyを呼び出す
      • OnRep_ValueA
      • OnRep_ValueB

クライアント側でサーバーRPCの順序でRepNotifyが起こることを期待するとバグの原因になります。
また値が全てストアされてからRepNotifyが呼ばれるため
それぞれのRepNotify中でトリガー対象となった対象の別の変数にアクセスする場合も注意が必要です。

RepNotiyの呼ばれる順序はUClass内のプロパティリストの並び順に依存する気がします。

参考

昔書いたやつ
UE4 MultiPlayer Online Deep Dive: 実践編1

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away