Custom room name from my backend

Oddreams

Hi,
We are using Photon in our multiplayer game.
Our game is designed to have a 4 digit room name.
One approach is :
1. generate a 4 digit number
2. Call CreateRoom()
3. OnPhotonCreateRoomFailed() repeat step one

We know that this approach is not really scalable(we have only 4 digits) due to possible collisions.
Are our concerns valid?
Is there any way to use our backend for issuing room names?

JohnTube

Hi @Oddreams,

Thank you for choosing Photon!

4 digits mean: 10000 possible combinations (0000-9999) or 9000 (no zero to the left: 1000-9999).

First why do you have such a hard constraint? why set your own room names and not let the server generate GUIDs? then why 4 characters only? and why digits only?

Otherwise your approach can be improved by limiting collision if your generated 4 digit number has some factors/seeds like timestamp or UserId or some client hardware Id etc.

Is there any way to use our backend for issuing room names?

Not built-in but you could do that outside of Photon, e.g. a web server that keeps track of used values (active ongoing rooms via WebHooks for instance) and the client sends a HTTP request to query a room name that is locked for some time per UserId until the room is created or released. the client can then attempt room creation.

Oddreams

Hi @JohnTube

First why do you have such a hard constraint? why set your own room names and not let the server generate GUIDs? then why 4 characters only? and why digits only?

This hard constraint is because we want an easy way for players to join the room. This code will be shown in tv and I think it is not ideal to show them a long name.

We implemented webhooks approach and it was very easy when persistent is true because the game was block till it got the response from our server.
Here it is the implementation:
1. in webhook config both SendSync and Persistent are true,
2. host player creates a room and let photon to assign its name.
3. photon synchronously send the webhook to backend and wait for response
4. our backend issues a random code and stores code, game id and region
5. when OnJoinedRoom is called we make a request to our backend with the photon room name to get our code
6. on room close we update our database and release the issued code

Please if you see any problem with our logic let me know.

JohnTube

Hi @Oddreams,

very nice.
I love it.
in step 1 you mean "AsyncJoin" not "SendSync".
you could save the code as a room property (from the client as it's tricky to inject it in the room state using webhooks), this way you don't need to fetch it from you web server in step 5 when room is joined but you already have it as a room property.
step 4, I would maybe save more info to be safe (AppId, AppVersion, creator UserId) maybe you decide to change those later?
step 6, release code only when PathClose, Type=="Close" and not "Save".

Oddreams

Hi @JohnTube
Thank you for your feedback.
Actually for now we are are using this just like a room finder based on a custom property, code in our case.
Regarding step one we have AsyncJoin false and SendSync true.
At last step we thought that close and save are done in one http request.
In my testing I do not see 2 http request one for save and one for close. Please confirm that?
In case of PathCreate we check type and for load we return result code not 0 as we do not support saving state.

JohnTube

Hi @Oddreams,

Regarding step one we have AsyncJoin false and SendSync true.

Not sure how SendSync is relevant here (PathCreate is always sync), it's only relevent in RaiseEvent or SetProperties but not CreateRoom. SendSync is not a webhooks config but a webflag set by the client in the actual method call/request.

At last step we thought that close and save are done in one http request.
In my testing I do not see 2 http request one for save and one for close. Please confirm that?

Yes one HTTP request, PathClose, but the Type is either "Close" or "Save" if you do not support saving room state then you should always get "Close" or simply ignore State sent when Type is "Save". To avoid confusion Close here means room is destroyed, disposed of on the server. When type is "Close" it means the room is destroyed and its State should not be saved (zero inactive actors) so it's not even sent.

Oddreams

Hi @JohnTube
Thank you very much for your clarification on SendSync.
For the second matter since it sends just one webhook PathClose in our case we just set the room free in our backend without considering whether type is save or close.
Thanks