Design advice needed: turn based multiplayer

I got my turn-based game working with RPCs. 2-4 players are allowed. However, I want to allow users to participate in multiple matches and switch between them as desired. Much like Draw Something or other social games.

A couple of ways seem feasible. Can anyone make a recommendation which way would be better, or ill advised, or something I haven't thought of?

a) Save all game states in the customProperties of the Lobby. Then the users would never actually enter a room, they would just poll the customProperties of the Lobby for games they are participating in.

b) Have the clients enter and exit each game room periodically, polling each room for changes in the game states. I actually don't think this would work because if all players exit a room, the Room ceases to exist, right?

I guess I'm leaning towards a) unless it would be considered dis-abusing Photon?


  • c) have all players of all games in 1 room, and RPC to match's opponents only instead of broadcast to all players in room.

    Actually c) sounds the best, no?
  • a) You can't change a game's properties unless you are in it. Also a big waste of bandwidth for anyone not interested in "your" games, as any game is listed.
    b) Right, rooms are disposed when all players leave.
    c) That will work up to some limit but not for any number of users. Anything done in a room is basically single-threaded and that's counter productive.

    I don't think your usecase is covered by PUN. It would be much healthier if you would use the Server SDK and modify it into something that stores the data you need to persist.
    You can do this in the "Loadbalancing" application's Game class.
    Also, you could use the Unity Client SDK directly. This exposes operations better and you can do your own without the overhead of Unity-look-alike PhotonView components.

    It's more work but with a game like this possibly worth the effort.
  • Tobias, thanks. I was really hoping to use the cloud, so just a suggestion: add some kind of room-persistence that would enable my kind of use case of turn-based-multiplayer with multiple matches. In the meantime I will look into modding server SDK.
  • If I mod the Server SDK (and running my own server) can I also use the Photon Unity Networking plugin? Maybe it's only for use with the Photon Cloud? Or should I be looking strictly at the examples and docs in Photon-Unity3D_v3-0-1-2_SDK and ExitGames-Photon-Server-SDK_v3-0-24-3243-RC9.
  • Ah never mind. I found an old reply from dreamora
    PUN is exclusively targeting the cloud & loadbalancing, while the Photon Unity 3D SDK targets the regular (Instance1) ie the Lite and MMO
  • Ah but wait. In a PUN project I can do
    Window | Photon Unity Networking | Setup | Switch to own host
    and the PUN docs say
    If you run your own Photon server, use the setup wizard, to switch your settings for it. Open it in the Menu: Window, Photon Unity Networking.
    I like the PUN API, so there is nothing preventing me from developing my custom server logic, and using the PUN client to connect to it, correct?
  • correct :)
    All thats required is that you work with the LoadBalancing instance
  • We will always keep the options to either use Photon Cloud or use our Server SDK for self-hosting.
    The "Loadblancing" application is a simplified but compatible variant of what we run in the cloud. It also uses a "Master Server" and one or more "Game Servers". To start hosting this yourself, a single license is just fine: MasterServer and GameServer as just apps and can be run in a single Photon process.

    Use the latest v3 releases, even if they are RCs. PUN is not compatible with Photon v2.
  • PUN requires the LoadBalancing instance, it does not support Lite / LiteLobby / MMO, which actually would be the only thing supported by Photon v2 so luckily that should normally not be a problem there :) (unlike the Unity Photon SDK + Photon Server where the mixup indeed can happen and along the Bootcamp demo happened several times in the past)
Sign In or Register to comment.