コメントはあんまり書かなくていい!」1とごねていたのですが、自分が書いたPhotonのRaiseEventのラッパーの使い方がみんなよくわからなかったっぽいので、反省して説明を書きます。PUN1でも要領は一緒なので適宜読み替えてください。RES継承元のSingletonMonoBehaviourはみんな知ってるとこからコピペしてきたやつ。gistにも置いておきました3これだけでわかる人は使い方のコツだけ読んでください。}}作った理由RPCでいいじゃん、と思う人もいるかと思いますが、なんかやばいこと書いてあるのでRaiseEvent使ったほうがいいと思います。そもそもRPCめんどくさい。4やばいこと最適化のヒントターゲットGameObjectのあらゆるコンポーネントはRPCを実装することができるので、PUNはリフレクションを使用して適切なメソッドを見つけます。いう人はRPCとRaiseEventを読んでください。公式ではイベントを受信する方法として以下2つを提示しています。IOnEventCallbackコールバックLoadBalancingClient.EventReceivedこれをそのままやるとたいへんめんどくさいです。実際にどう動くかを見たほうが早いと思うのでコード書きます。シーン構成こんなシーンです。押したボタン毎にCubeの色が変わります。その色の変更がRaiseEventを通じて相手に共有されます。ちなみにですがPhotonViewはこのシーン内に存在していません。5GameManagerに以下の管理スクリプトを貼り付けます。どこでもいいですが、RER/RSRも同じオブジェクトに貼り付けておきます。変化させた色が共有されます。EventCaching.AddToRoomCache,Roomにキャッシュしているため、後から来た人にもRaiseEventが届いています。受信側追加ボタンがどのように押されたかを見たいため、右側にログを出します。右の白いところに操作ログが文字で出ます。}}RER/RSR(イベント送受信者)にもPunSampleManager(イベント受信側)にもいっさい変更を加えることなく、イベントを受信するクラスを増やすことができました。送信側せっかくなのでCubeを回転させましょう。}}回転を共有できました。既存のCubeの色を変更する箇所には影響がありません。使い方のコツイベントを発行したのが自クライアントか他のクライアントか意識しない送信側を例にすると、RER/RESでCubeの回転を他クライアントに送信した後に自分でCubeを回したりしない、ということ。イベント受信時に実行する操作はイベント受信時のみに行ってください。送信するデータのサイズに気をつけるobjectはシリアライズできるものならなんでもいいです。PUN1の時代は一部のStringが文字化けしてたような気がしたので気をつけたほうがいいかも。画像のような大きめのデータを送受信していて速度が気になる場合はMessagePackで圧縮かけると少しマシかもしれません。6パフォーマンスチューニングは百人百様なので各自がんばりましょう。DontDestroyOnLoadしないActionに登録されたオブジェクトのライフサイクルの管理めんどくさいすぎるので想定していません。RER/RESはシーンのオブジェクトとして使い捨てする運用でよいと思います。それでも複数のシーン間で使いたいとかだったら、インスタンス破棄時にOnDestroyでリスナ解除とかUniRxでうまいことするとか。あとがきRaiseEventOptionsによるキャッシュの話は長くなりすぎるので割愛。ここ極めるとPUN2の自由度がぐっと上がります。インタレストグループに対応するのもそう難しくないので需要がある人はてきとうに改造してください。記事書き終わって気がついたんですけどコードにまったくコメント書いてなくて反省の色がねえなって思いました。全ての人が刺身にタンポポを乗せなくてよくなる時は遠い......。余談ですがこの記事を書いた人ってすごく初学者にやさしく接した人ですよね。「他人がなにを考えてそうしているのか」を言語化するためには辛抱強く話を聞いてあげる必要があります。自分はそんなに優しくはできない。upLoginユーザーは見つかりませんでした。