PUNでいかにデータの同期をするのか、まさに取らぬ狸の皮算用と言ったところであーでもないこーでもないと悩んでいます。狸は取らねども皮算用はうまくなったもんで、同期用のオブジェクトを用意する方法、ルームとプレイヤーのカスタムプロパティを使う方法、RPC（リモートプロシージャコール）を使う方法の３つが現実的な候補として上がってきました。その中でもトランプゲームのような同期の回数が劇的に少ないものでは、カスタムプロパティが良いという印象を受けたんです。で、今回はそのカスタムプロパティに対するよく分からない誤解と解決のお話です。

そもそも、これは現段階でもそうなんですが、PUN、つまりPhotonのサーバというのが一体どういうもので何をどこまでしてくれるのかがよく分かっていません。おぼろげに、「実のところ通信してくれるだけありがたいと思え、サーバで何か考えさせるなんてもっての他だ！という感じ」なんじゃないかと思ってるくらいです。で、このカスタムプロパティです。いろんな所の説明を見るに「ルーム（とプレイヤー）のカスタムプロパティはすでに用意されている」みたいな感じを受けます。

ここで基本的なカスタムプロパティの説明をします。一時的に持っておけるデータだそうです。一時的ってのは、まさに今この一瞬！という訳ではなく、要はゲーム中はずっと保持するけど、例えばルームが解散とかされたら全部なくなるよ、みたいなことです。データはハッシュテーブル、C#で言うディクショナリー型というものらしく（よく知らない）、キーと値を紐付けて保持するらしいです。わかりやすく言うなら"point"というキーに対して"1500"という値、みたいな感じ？（たぶん合ってる）ルームのカスタムプロパティはその部屋の基本情報、プレイヤーのカスタムプロパティはプレイヤーの基本情報などを入れるのが基本的な使い方みたいです。どのタイミングで部屋に入室しても、これらの情報を取得できるのが利点なんですって。

ってことを知って、僕はひとつの疑問を抱きました。前述したようにPhotonのサーバは何もしてくれないっぽいのに、このカスタムプロパティは保持してくれるの？あとこのカスタムプロパティはどれだけ大きくなっても大丈夫なの？データのやりとりって、変更点がある箇所だけなの？それとも１回１回、全データのやりとりするの？データのやりとり量がめっちゃかさんで、容量オーバーしちゃって料金請求とか来ちゃったらどうしよう！という疑問です。ひとつじゃなかったですね。つまり、この時点での僕のイメージはこんな感じです。

サーバが持ってくれてるんだから、確かにデータはいつでも取り出したり書き込んだりできるけど、さっきのような疑問がぬぐえない。あと、SetCustomProperties()を使わないと同期が行われないよ、という各所でされている説明も、地味にしっくり来ない。そして、僕は決定的な違和感を覚えるオフィシャルの説明にたどり着きます。それは「カスタムプロパティが多すぎると、新たなクライアントが入室した時にしょぼいネット環境とかだとカスタムプロパティを全部送るのに時間がかかってタイムアウトする恐れがあるぜ（脅し的な要約）」というものです。あれ？カスタムプロパティを読み込むのって任意のタイミングとかにできないの？入室したタイミングで読むの？ん？と思った結果、僕は１つの違う概念にたどり着きます。図にすると、こうです。

そう、みんなが全部持ってるってことなんです。サーバ側は保持してないかもしれない（してるかもしれない）ってことなんです。この概念、みんなにとっては常識かもしれませんが、僕はここにたどり着くまでにだいぶかかりました。これなら、今まで思ったすべての疑問は解決されます。通信は変更点のみで、SetCustomProperties()が行われないと同期されないというのもしっくり来ます。新たなプレイヤーが入室した時にカスタムプロパティを全部渡すのも「そりゃそうだわ」と思わざるを得ません。どこから渡す値を引っ張ってきているのかは分かりませんが、もしかしたら保持しているかもしれないサーバ側のデータか、マスタークライアントあたりから引っ張ってくるんでしょう。そこはたいした問題ではありません、そういうのを要領よくやってくれるのがPUNだと思ってるんで。

今更ですが、勝手に納得しているだけですので、この考え方が合ってるかどうかは分かりません。そもそも、こんなことを考える必要は本来無いような気はします。ただ、いざ自分が使うとなった時に基本的な概念みたいなものが分からないと、なかなか自分にゴーサインが出せないという性格なんで、今回この結論に至れたのは非常に助かる状況となりました。というわけで、僕が作る今回のゲームの同期の取り方はカスタムプロパティを基本にしていこうと思います。