The set of participant identifiers is guaranteed to be the same for everyone who is in the room (but not in different matches). However, their order in the list is not guaranteed. Therefore, if you want to make easy choices (for example, to establish who goes first, etc.), you must rely on a set of participant identifiers, but not in order. Some of the ways you can do this are:
- The identifier of the first player to enter in alphabetical order is the first player to play
- The identifier of the participant, who comes in alphabetical order first, is responsible for randomly selecting a player to begin with. The rest of the clients will wait until the participants send a reliable message in real time containing the identifier of the selected participant.
Method (2) is preferred since it does not contain a possible bias.
Why? Although we do not indicate what the structure of the participant identifier is (it is just a string), the truth is that it encodes the information, so if you use the participant identifier, as a rule, you may encounter a strange distribution of who comes first. For example, you may find that a particular player always comes first, but this is because, coincidentally, their member ID is generated in such a way that this always happens. Therefore, it is definitely better to use the participant ID to choose who is the authority for the random decision, who comes first, and not who actually comes first.
Bruno oliveira
source share