n00b question: does PUN support peer-to-peer co-op?

I'm working on adding co-op to an open world game. Architecturally, I'm thinking we will first try peer2peer, where each player locally simulates a radius of objects around them and one-way sends their owned object state to others. So no centralized authoritative server. Is PUN suitable for this? It seems to be, with support for ownership and global IDs.

Comments

  • Yes, this is a good use case for PUN.
    You need to be a bit careful maybe: PUN tries to make things easy for you and handles lots of things internally for a game. On the downside, this means you can't really have thousands of GOs synced and it only works for a smaller number of players. We don't impose limits for anything, so you should experiment and test what works for you.

    However, you can optimize things where needed. PUN offers you more control where needed. You could use PhotonNetwork.RaiseEvent() to send your own events about controlled GOs, etc.
  • OK, just to clarify: Do the clients *actually* send data to eachother directly, or does it still go to the PUN server? This isn't strictly necessary, but it'd be good to know.

    We are only aiming for 4 players tops, so a small number is OK for now. We might well have 1-4 thousand of game objects synced between players, however. But some latency is OK on these syncs. Is there any way to control how often a given view is synced? For example, if two players are far apart, then their objects need to be synced eventually but not immediately.
  • Any communication in Photon always goes through a server.
    This adds a bit of lag (but not much) and is some indirection, but virtually any client can connect and communicate with the others. Mobile clients are really bad for hosting and I'm sure you heard of NAT issues - neither is a problem this way.

    1-4 thousand objects are quite a lot. You will need to make sure that the least amount of those actually get updated and that each is small.

    The PhotonView viewIDs have a default limit of 1000 per player. You will need to change this or work around it by syncing several entities as one object (and one PhotonView).
    If you implement OnPhotonSerializeView() to sync positon, etc, you can simply not put anything in the PhotonStream and this won't send anything for that update.
    PUN does not offer a lot of control out of the box because the idea was that it's simple. We can expose more and more of the control that Photon offers on demand.
  • OK good to know. I imagine even if I don't write anything to the stream, it will still count against the 1000 limit?
  • Although, 1000 per player may be OK.