Buffered RPC vs Non-buffered RPC (initializing joining players) + design patterns w/ Photon

The whole answer can be found below.

Please note: The Photon forum is closed permanently. After many dedicated years of service we have made the decision to retire our forum and switch to read-only: we've saved the best to last! And we offer you support through these channels:

Try Our
Documentation

Please check if you can find an answer in our extensive documentation on PUN.

Join Us
on Discord

Meet and talk to our staff and the entire Photon-Community via Discord.

Read More on
Stack Overflow

Find more information on Stack Overflow (for Circle members only).

Write Us
an E-Mail

Feel free to send your question directly to our developers.

Buffered RPC vs Non-buffered RPC (initializing joining players) + design patterns w/ Photon

bzonca
2021-06-27 14:19:58

Hello! I'm doing my best to follow any best-practices that exist for Photon, since in my experience networking introduces some not-so-clear architectures compared to offline games.

Buffered RPCs seem like the way to go for most synced actions, but because everything is saved until the player leaves the room (not just the scene for example) this can lead to big load times.

I've found that it's possible to just use non-buffered RPC calls to All, and have the master/owner send new players initialization information when they join. This appears to have the same result as using buffered RPCs, but without the large history. Are there downsides to doing this?

Also, is there a place where I can learn more about Photon/Networking design patterns? Most tutorials for Photon (and Unity in general) highlight how to use specific functions (RPC, observe, etc) but don't show examples of how to scale net code for generic applications to reuse code which results in a lot of concrete code for slightly different implementations. After having learned some OOP design patterns, I can't help but feel like I should be using a more scalable/generic way when handling netcode + designing classes that incorporate RPCs/OnPhotonSerialize.

Comments

hannahmontanna
2021-06-29 00:52:39

MILEYS 3 LAWS OF RPC OR GTFO

  1. THE GAMEOBJECT AND SCRIPT THAT CALLS THE RPC, MUST HAVE PHOTON VIEW ATTACHED TO IT, NOT ITS PARENT/CHILD/OR REFERENCE
  2. SCRIPT THAT CALLS THE RPC, MUST CONTAIN THE RPC aka IF YOU CALL DOSTUFF YOU NEED TO HAVE METHOD [PunRPC] DOSTUFF() IN SAME CLASS, ATTACHED TO SAME GAME OBJECT!
  3. DONT SEND CRAZY BULLSHIT, SEND (SMALLER THE BETTER) NUMBERS. EDIT NOTE: CRAZY BULLSHIT INCLUDES SENDING BUFFERED, SEND ALLVIASERVER FOR LAG COMP, IF YOU THINK YOU SHOULD SEND BUFFERED MAKE SURE YOU REALLY SHOULD AND UNDERSTAND WHY!

So buffered gets cached on the regional photon relay and should almost never be used. Allviaserver is nice though, as it executes locally with lag of sending out to server and back while sending all will execute locally instantly.

Back to top