Il y a aussi la solution (outre de réorienter le gameplay pour ne pas faire de temps réel) de WebRTC. Sur le principe:
- Joueur A => Serveur: je suis arrivé au lieu dit ("trempé par un orage") et voici mon token RTC
-- Réponse du serveur: Ok, ben, y'a personne
- Joueur B => Serveur: je suis arrivé au lieu dit, et voici mon token RTC
-- Réponse du serveur: Ok, y'a déjà Joueur A, dont voici le token RTC
- Joueur B => Joueur A: Coucou, j'ai ton token, je suis dans le même lieu que toi!
- Joueur A => Joueur B: Salut! On s'fight?!
Dans l'idée, le serveur laisse les joueurs se démerder entre eux pour savoir qui est où, combattre, etc. Il sert éventuellement juste "d'arbitre", si besoin (genre, pour sauver les actions de combat).
Ca nécessite 0 spécificité côté serveur, mais cela implique d'avoir, d'une part, des navigateur à jour, et d'autre part, de réussir à gérer les connexions WebRTC entre les clients. C'est pas toujours gagné de ce point de vue là, à cause des NAT (les box quoi).
J'avais déjà essayé de faire une démo WebRTC https://xenos.reinom.com/webrtc/ (datartc te servirait dans ton cas), mais je crois n'avoir jamais pu la faire marcher en dehors de mon réseau local...
-----
Il y a sinon la Push API (cf démo https://serviceworke.rs/ ), qui devrait permettre de faire un mécanisme type :
- Joueur A va dans le lieu, il dit au serveur "envoie-moi une notif quand un autre arrive dans ce lieu", et le serveur le note dans sa DB
- Joueur B va dans le même lieu, le serveur voir que Joueur A y est, il envoie un push au joueur A à partir des infos dans la DB du serveur
- Le joueur A reçoit la notif, de là, 2 cas possibles:
-- Le joueur A ne joue plus: la notification va être reçue, mais le client va répondre au serveur "en fait, je m'en fous des notifs, je ne joue plus, ne m'en envoie plus" (histoire de ne pas envoyer des push inutiles au client, car c'est limité cf https://developer.mozilla.org/en-US/docs...I/Push_API ) => Quand joueur A reviendra dans le jeu, il renverra l'information au joueur qu'il accepte de nouveau de recevoir des Push
-- Le joueur A joue encore, il reçoit l'information et notifie l'humain derrière l'écran (notif classique, affichage in game, reload de page, qu'importe)
Ca doit pouvoir se jouer ce genre d'approche, mais je ne l'ai jamais testée. Dracca sera probablement une bonne occasion : ) Ca m'a l'air très agnostique vis-à-vis de la techno serveur, donc, applicable sur n'importe quel type de serveur potentiellement (bien que je n'ai pas encore assez de connaissances sur la façon d'envoyer le Push; de ce que j'ai compris, c'est simplement une URL à contacter, mais j'ai quelques doutes sur le fait d'avoir bien compris?!)
- Joueur A => Serveur: je suis arrivé au lieu dit ("trempé par un orage") et voici mon token RTC
-- Réponse du serveur: Ok, ben, y'a personne
- Joueur B => Serveur: je suis arrivé au lieu dit, et voici mon token RTC
-- Réponse du serveur: Ok, y'a déjà Joueur A, dont voici le token RTC
- Joueur B => Joueur A: Coucou, j'ai ton token, je suis dans le même lieu que toi!
- Joueur A => Joueur B: Salut! On s'fight?!
Dans l'idée, le serveur laisse les joueurs se démerder entre eux pour savoir qui est où, combattre, etc. Il sert éventuellement juste "d'arbitre", si besoin (genre, pour sauver les actions de combat).
Ca nécessite 0 spécificité côté serveur, mais cela implique d'avoir, d'une part, des navigateur à jour, et d'autre part, de réussir à gérer les connexions WebRTC entre les clients. C'est pas toujours gagné de ce point de vue là, à cause des NAT (les box quoi).
J'avais déjà essayé de faire une démo WebRTC https://xenos.reinom.com/webrtc/ (datartc te servirait dans ton cas), mais je crois n'avoir jamais pu la faire marcher en dehors de mon réseau local...
-----
Il y a sinon la Push API (cf démo https://serviceworke.rs/ ), qui devrait permettre de faire un mécanisme type :
- Joueur A va dans le lieu, il dit au serveur "envoie-moi une notif quand un autre arrive dans ce lieu", et le serveur le note dans sa DB
- Joueur B va dans le même lieu, le serveur voir que Joueur A y est, il envoie un push au joueur A à partir des infos dans la DB du serveur
- Le joueur A reçoit la notif, de là, 2 cas possibles:
-- Le joueur A ne joue plus: la notification va être reçue, mais le client va répondre au serveur "en fait, je m'en fous des notifs, je ne joue plus, ne m'en envoie plus" (histoire de ne pas envoyer des push inutiles au client, car c'est limité cf https://developer.mozilla.org/en-US/docs...I/Push_API ) => Quand joueur A reviendra dans le jeu, il renverra l'information au joueur qu'il accepte de nouveau de recevoir des Push
-- Le joueur A joue encore, il reçoit l'information et notifie l'humain derrière l'écran (notif classique, affichage in game, reload de page, qu'importe)
Ca doit pouvoir se jouer ce genre d'approche, mais je ne l'ai jamais testée. Dracca sera probablement une bonne occasion : ) Ca m'a l'air très agnostique vis-à-vis de la techno serveur, donc, applicable sur n'importe quel type de serveur potentiellement (bien que je n'ai pas encore assez de connaissances sur la façon d'envoyer le Push; de ce que j'ai compris, c'est simplement une URL à contacter, mais j'ai quelques doutes sur le fait d'avoir bien compris?!)