10-03-2019, 07:42 PM
(Modification du message : 10-03-2019, 07:43 PM par Sephi-Chan.)
J'adore ! C'est tellement cool d'imaginer que son serveur "vit", plutôt que de penser en requête/réponse qui charge les informations et les décharges aussitôt.
J'utilise la librairie Erlang Ranch pour accepter les connexions TCP entrantes. Ça spawn un process tcp_handler par connexion active. Tous les messages échangés sont encodés en JSON. C'est pas forcément optimal en terme de volume de données, mais ça me semble sans importance compte tenu du faible nombre d'échanges.
Une fois connecté, le client envoie un message au serveur dans lequel il s'identifie par un UUID. Quand le handler TCP reçoit ce message, il l'indique au process GenServer players qui stock une liste des joueurs connectés. On push aux autres clients. Quand la connexion est coupée, le process est notifié et vire le joueur de la liste (et on en informe aussi les autres clients).
De la même manière, quand le handler TCP reçoit le message pour ouvrir un lobby, le GenServer lobbies est notifié et le stock dans une map qui associe un UUID de lobby a une map contenant quelques infos. Le joueur sera le joueur 1 de la partie à venir. Si la connexion coupe, on vire le lobbies de la liste. A nouveau, on notifie les autres clients.
Quand un joueur envoie le message pour rejoindre un lobby, on fait quelques tests (le lobby existe-t-il ? est-ce que c'est pas un joueur qui tente de rejoindre le lobby qu'il a créé…) puis on crée la partie grâce au process GenServer Games. Un process GenServer Game est alors créé sous un superviseur (il y en a un par partie en cours). Le PID du process est stocké dans un Registry avec l'UUID de la partie comme clé (l'intérêt est que le Registry est automatiquement nettoyé quand le process de la partie est terminé). Le deuxième joueur arrivé devient le joueur 2 de la partie. Les deux joueurs sont notifiés du démarrage de la partie. Chaque process contient les informations de sa partie.
Ensuite, chaque message qui arrive au TCP handler et qui concerne le jeu est géré (déplacement d'unité, attaque, fin de tour, etc.) jusqu'à ce qu'une attaque mette fin à la partie. L'identité du gagnant est envoyé avec les résultats du combat et le processus est arrêté.
Voilà pour le cycle de vie !
Là je suis en train de faire un Risk en CQRS/Event Sourcing (avec Commanded) et c'est fun. Peut-être que je ferais le client si le développement du serveur se passe bien.
J'utilise la librairie Erlang Ranch pour accepter les connexions TCP entrantes. Ça spawn un process tcp_handler par connexion active. Tous les messages échangés sont encodés en JSON. C'est pas forcément optimal en terme de volume de données, mais ça me semble sans importance compte tenu du faible nombre d'échanges.
Une fois connecté, le client envoie un message au serveur dans lequel il s'identifie par un UUID. Quand le handler TCP reçoit ce message, il l'indique au process GenServer players qui stock une liste des joueurs connectés. On push aux autres clients. Quand la connexion est coupée, le process est notifié et vire le joueur de la liste (et on en informe aussi les autres clients).
De la même manière, quand le handler TCP reçoit le message pour ouvrir un lobby, le GenServer lobbies est notifié et le stock dans une map qui associe un UUID de lobby a une map contenant quelques infos. Le joueur sera le joueur 1 de la partie à venir. Si la connexion coupe, on vire le lobbies de la liste. A nouveau, on notifie les autres clients.
Quand un joueur envoie le message pour rejoindre un lobby, on fait quelques tests (le lobby existe-t-il ? est-ce que c'est pas un joueur qui tente de rejoindre le lobby qu'il a créé…) puis on crée la partie grâce au process GenServer Games. Un process GenServer Game est alors créé sous un superviseur (il y en a un par partie en cours). Le PID du process est stocké dans un Registry avec l'UUID de la partie comme clé (l'intérêt est que le Registry est automatiquement nettoyé quand le process de la partie est terminé). Le deuxième joueur arrivé devient le joueur 2 de la partie. Les deux joueurs sont notifiés du démarrage de la partie. Chaque process contient les informations de sa partie.
Ensuite, chaque message qui arrive au TCP handler et qui concerne le jeu est géré (déplacement d'unité, attaque, fin de tour, etc.) jusqu'à ce qu'une attaque mette fin à la partie. L'identité du gagnant est envoyé avec les résultats du combat et le processus est arrêté.
Voilà pour le cycle de vie !
Là je suis en train de faire un Risk en CQRS/Event Sourcing (avec Commanded) et c'est fun. Peut-être que je ferais le client si le développement du serveur se passe bien.