Refacto : identification des joueurs

[gaut-b]

Un coup on n'utilise l'index (que le server ne connaît pas, puisqu'il est passé dans subjectivestate), un coup on utilise l'id pour identifier le joueur c'est un peu le bordel. Il faut qu'on choisisse un des deux (je suis pour l'id) et qu'on s'y tienne

[augnustin]

En fait ça ne marche pas si on a des joueurs virtuels (id: null).

Mais je suis d'acc avec toi qu'il faut unifier. Du coup les possibilités que je vois sont :

1. donner un ID à tout le monde et avoir une autre méthode pour déterminer si le joueur est virtuel ou non. (ex: id: BOT_${RANDOM_STRING}`` et isVirtual({id} => id.indexOf('BOT') === 0)

2. faire en sorte que l'id soit une random string pour tout le monde et stocker socketId comme un autre attribut. De toute façon on ne s'en sert plus trop pour raccrocher le joueur, puisqu'on a le fallback sur le nom

3. mais en fait, à mon avis, la solution la plus clean serait un hybride de tout cela:

Ne plus utiliser le nom comme identifiant unique de l'utilisateur, ni le socketId, mais bien un autre identifiant unique, qui à mon avis correspondrait à un sessionId, de telle sorte que:

• si on rafraîchit la page ou l'on ouvre un autre onglet, on soit authentifié comme le même utilisateur, même si on change de pseudo entre temps
• si quelqu'un d'autre prend le même pseudo il soit un autre utilisateur quand même.

Ces posts doivent aider :

• https://stackoverflow.com/questions/9291548/how-can-i-find-the-session-id-when-using-express-connect-and-a-session-store
• https://stackoverflow.com/questions/57726457/how-to-get-persistent-express-session-id-in-socket-io-connection

Reste un cas à gérer : le joueur change de device (pke ça marche pas sur son tel cf #30 ) il faut trouver un moyen de remplacer le joueur déjà inscrit. Mais ça, ça fera l'objet d'une autre issue je pense. 😄

[augnustin]

Finalement j'ai tranché :

On n'utilise pas l'id, ni le name, mais l'index. C'est un identifiant unique des 4 joueurs, si on en redéfinit un autre ça va faire doublon.

Seul inconvénient, la lisibilité car index peut être utilisé dans un autre contexte que celui du player, mais utiliser autre chose est potentiellement source d'autres bugs donc c'est à mon sens le meilleur compromis.

[gaut-b]

ok ça me va ! Par contre l'inconvénient c'est que playerIndex n'est pas défini côté serveur ... de mémoire il est défini côté client ou dans subjective. C'est aps très grave parce que tu le récupère facilement avec findIndex mais du coup c'est pas très homogène je trouve Le mer. 29 avr. 2020 à 09:18, Augustin Riedinger <[email protected]> a écrit :

…

Finalement j'ai tranché : On n'utilise pas l'id, ni le name, mais l'index. C'est un identifiant unique des 4 joueurs, si on en redéfinit un autre ça va faire doublon. Seul inconvénient, la lisibilité car index peut être utilisé dans un autre contexte que celui du player, mais utiliser autre chose est potentiellement source d'autres bugs donc c'est à mon sens le meilleur compromis. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMU2LYEWMNLSCFFC2ZZFU63RO7IFBANCNFSM4MJP77GQ> .

[augnustin]

Bah c'est l'index du player, donc pour avoir le player côté serveur, il suffit de faire state.players[index], non ? Il y a quelque chose qui te dérange là-dedans ?