@gbdivers pour la classe Serverje sentais aussi que je sortais loin du cadre SRP. Qu’il y avait bien d’un côté une classe qui avait pour but la communication réseau, qui devrait s’appeler Server et qui serait responsable de la communication réseau (accepter de nouvelles connexions, recevoir (pas traiter) les données, terminer une connexion, envoyer des données). J’ai même des doutes sur le fait que ça soit SRP de recevoir/envoyer des données et gérer les connexions / déconnexion des clients. Après j’exagère peut-être un peu non ?
Oui, tu auras probablement plus de choses a mettre dans la partie réseau et tu devras découper en plusieurs classes. Mais il faut faire une analyse fonctionnelle plus détaillée de cette partie pour faire la conception.
Pour la classe qui sonne comme Server Discord je ne sais pas du tout comment la nommer. Pour moi il s’agit d’une classe qui s’assimile à une collection. D’expérience je m’abstiens de la nommer RoomsManager car je me suis déjà fait taper sur les doigts pour avoir utilisé un terme si peu concret. En réalité, pour moi, l’ensemble des salles pourrait être contenues dans un std::vector<Room>. Dans ce cas je me pose la question suivante : de quoi serait responsable une telle classe ?
Tu as aussi les fonctions createRoom et removeRoom. Tu auras probablement aussi besoin de chercher la liste des rooms, etc.
Donc tu as assez pour faire une classe indépendante.
Pour les classes room je ne sais pas trop si on essaiera de mettre en place des salles textuelles et des salles vocales. Dans l’optique de ne pas me bloquer je pensais faire une interface RoomInterface et l’implémentation de base TextRoom, laissant la possibilité plus tard d’ajouter VocalRoom. Ceci dit les noms choisis sur le diagramme sont mauvais et mon approche reste peut-être vaseuse.
Si tu design maintenant le support des canaux vocaux, integre ca dans le design.
Par contre, si tu ne fais pas l’analyse fonctionnelle maintenant, alors ne l’intègre pas "au cas où".
Tu as en gros 2 approches pour concevoir un programme : soit l’approche classique (cycle en V), soit Agile. (J’aime simplifier a l’extreme).
Dans le premier cas, tu dois faire complètement l’analyse fonctionnelle, donc cela n’a pas de sens de faire un truc "au cas où".
Dans le second cas, tu fais l’analyse au moment où tu en as besoin. Mais pour cela, il faut avoir un conception qui intègre le fait que la conception et l’implémentation va évoluer.
Pour être clair, cela veut dire qu’on ajoute pas dans la conception quelque chose d’inconnu (une fonctionnalité "au cas où"), mais on intègre une contrainte connue (le fait que la conception va évoluer). C’est tres different.
Sinon, la responsabilité d’une classe Room c’est de lancer une partie pour un ensemble de joueurs (ceux qui ont rejoint la salle, la partie étant gérée par un script donc). À ce titre elle doit avoir une collection de joueurs et être capable de communiquer avec ses joueurs. Dans ce cas, est-ce que l’utilisation d’un singleton Server est appropriée (je peux appeler Server partout dans mon code, ce qui sonne moyennement bien et plutôt comme quelque chose de bizarre) ? Est-ce que la classe devrait avoir un pointeur/une référence vers le serveur dès sa création (dans ce cas, puisqu’il y a sûrement unicité du serveur, ça ressemble à du singleton caché) ? Il existe sûrement d’autres façon plus joli pour communiquer l’état de la partie à travers le réseau.
Le raisonnement est le même pour les données reçues, envoyées par les clients.
C’est quelque chose qui doit ressortir de ton analyse. Il n’y a pas de réponse générique. Créer un singleton veut dire que tu pourras accéder à ta classe partout, mais cela veut dire aussi qu’il faudra un mecanisme de dispatch, pour envoyer les infos aux bons endroits. Au final, tu risques de regler un probleme (l’accès a cette classe partout) mais créer un autre problème (le dispatch des messages).
Une autre approche serait de voir les rooms comme des dispatcheurs en eux même, du type broadcast (communication un vers plusieurs) pour les membres de la room.
Alors si je ne me trompe pas, on aborde là le code métier ? C’est la partie que je pensais attaquer vraiment plus tard. C’est vrai que de coder tout le gameplay en dur est une mauvaise idée je m’en rend compte. Il faudrait que je me renseigne sur comment écrire l’état d’une partie sur un fichier. Pour chaque partie j’essaierai d’ailleurs de garder un historique des états et des communications (enfin je dis ça mais je ne le ferais peut-être pas avant très longtemps).
Si tu le mets dans le design, c’est que tu en a fait l’analyse. Si tu ne veux pas faire l’analyse de cette partie maintenant, ne la mets pas dans le design.
Mais essaie de travailler par partie. Si tu bosses sur l’architecture interne de tes rooms, oublie les fichiers, le reseau, le gameplay pour le moment. Essaie de garder cette indépendance dans ton analyse entre les parties (si tu n’arrives pas a analyser les parties indépendamment les une des autres, comment arriveras tu a avoir concevoir des modules independants au final ?)
Après, chaque partie suit un schéma constant normalement : la nuit, on appelle des rôles chacun leur tour (ordre non aléatoire) pour qu’il réalise une action (tuer un joueur, connaître le rôle d’un joueur etc). Le jour (une fois que tout les rôles de la nuit ont joué) on commence par regarder si certains rôles ont une action à réaliser (le dictateur peut déclencher la nuit un coup d’état ce qui lui permet de tuer un joueur au lever du jour, le chasseur tue un joueur de son choix le jour quand il meurt) puis on invite les joueurs à débattre puis à voter un joueur qui sera pendu. Finalement, j’ai l’impression que la seule partie variable de tout ce système ce sont les rôles. Est-ce que mettre en place un système de plugins pour les rôles ne serait pas suffisant finalement ?
Dans ce que tu viens de dire, tu fais clairement la distinction entre la partie "moteur de jeux" (le concept de role, les différentes fonctionnalités des rôles, etc) et la partie gameplay.
A mon avis, tu n’as pas besoin de créer des plugins, tu peux probablement mettre ca dans du JSON.
Pour le moment, j’aimerai déjà réussir à faire l’aspect réseau et salles. Même pas de chat ou quoi, juste que les utilisateurs puissent se connecter à une salle, voir les autres utilisateurs connecté au serveur et ceux situés dans la même salle qu’eux.
Je pense que tu es dans la bonne démarche pour ton analyse. Continue de bien séparer l’analyse des rooms et du réseau.
mais j’ai réussi à installer le google test framework) mais je pense qu’en se forçant à le faire ça viendra.
). Le module réseau est actuellement fonctionnel dans le sens où :
.
