room Id not consistent between peers.

[stolk]

When I set up a quick match, I see that once connected, the room Ids do not match up.

The ShowWaitingRoomUI callback will report back rooms with different Ids per device, e.g.:

I/swaag   (28255): Succesfully showed room [ChoKCQj1jOXnmhsQAhABGAAg____________ARDPjIqL7Oju3NUB] (created by Abraham Stolk): (null)

versus

I/swaag   (18526): Succesfully showed room [ChoKCQj1jOXnmhsQAhABGAAg____________ARDQ15uek-ahpgI] (created by Bram Stolk): (null)

Now the first part of the Ids do match, but they never change between matches.

What I would like is a unique id per match that I can use as a distributed random seed for my matches.

Bram

[claywilkinson]

We really can't guarantee the structure of any internal ids, so I would not recommend relying on any perceived patterns in the data. There is a good stackoverflow answer about how to do things like this using the participants. This is about who goes first, but you could also use the participant id as the seed data since everyone agrees. Alternatively, you code do something like everyone sends a seed, and the min/max of the seeds is used?

http://stackoverflow.com/questions/19087389/how-to-decide-who-is-the-first-player-when-user-plays-quick-game/19101977#19101977

[stolk]

Ok, it looks like I have to solve it in my own layer then, by doing game communication. I was hoping that I could get all this settled before first communication with peers. Mainly because pretty much all my comms use unreliable messages.

I will have each participant send a random seed and XOR that to use as final seed. Unfortunately, that means I have to delay the construction of my game world until I've heard back from all peers, which could have been avoided if Games Services would have distributed a unique ID.

Thanks for the stack overflow link.

PS: There is also the alternative approach of XORing all participant IDs, but unfortunately that means that random seed will be the same if you play repeated matches against same opponent.