Un stage autour de Conseil de Guerre en ligne

Ce stage a pour but de continuer le travail fait sur le prototype en place, notamment sur les effets des cartes encore manquants mais surtout d’aborder la mise en réseau. En effet, Conseil de Guerre pourrait se jouer en solo (contre une Intelligence Artificielle) mais c’est beaucoup plus dur à mettre en place qu’un mode joueur contre joueur (comme l’avait expliqué Mathieu dans son précédent article). Le réseau est la partie centrale de mon stage, et nous avons fait beaucoup de travail de R&D (recherche et développement) avec Mathieu afin de bien comprendre et appréhender le réseau sur un moteur de jeu comme Unity. Pour ma part, c’était plutôt compliqué car je n’avais jamais fait de pratique réseau auparavant et ça a été un gros morceau à digérer pour bien tout assimiler. Bien que je ne souhaite pas continuer à travailler dans le réseau car c’est un domaine de compétences très vaste et que je ne suis pas formé à ça, j’ai pu voir qu’un stage de deux mois était très loin d’être suffisant pour former quelqu’un à ce domaine. Ça reste toutefois une expérience très enrichissante et qui m’a permis d’élargir mes connaissances.

Avant toute chose, il est nécessaire d’expliquer les concepts de serveur et de clients. Un serveur est une entité qui a une vision d’ensemble du programme et va commander (à la manière d’un chef d’orchestre) aux autres entités. Les autres entités quant à elles sont les clients qui réalisent leur rôle de leur côté en suivant les indications du serveur (les concertistes).

Mirror fonctionne de manière simple : il y a un serveur et des clients, chacun possédant ses propres objets (un deck de cartes par exemple) et chacun pouvant avoir l’autorité (ou le contrôle) sur un objet.

Lorsqu’un client se connecte au serveur, il devient un clone de ce dernier. Si on souhaite, par la suite, faire apparaître le même objet sur le serveur et les clients, on peut utiliser une méthode, ou fonctionnalité, qui initialise automatiquement l’objet sur le serveur et le clone sur les clients. On peut alors préciser quel client a l’autorité sur cet objet.

Prenons l’exemple d’un jeu au tour par tour, il y a plusieurs joueurs et un serveur. Chacun a connaissance de l’état actuel du jeu.

Le joueur actif souhaite terminer son tour de jeu. Pour cela, il clique sur un bouton qui active la méthode TourSuivant() qui change le joueur actif. Dans ce cas, ni le serveur, ni les autres clients ne seront informés de ce changement.
Créons alors une nouvelle méthode mais que l’on marque comme une command (avec une balise avant son nom et Cmd dans son nom), cette nouvelle méthode CmdTourSuivant() va être appelée par notre client qui souhaite mettre fin à son tour à la place de TourSuivant(), et tout ce qu’elle fait se fait alors sur le serveur. Une command peut se traduire par “le client demande au serveur d’effectuer une action”.
Dans CmdTourSuivant(), nous voulons que le serveur passe au joueur suivant, on va donc y mettre TourSuivant() (rappelez-vous, ce sont des clones, la méthode existe donc aussi sur le serveur).
Maintenant nous n’avons plus un client qui passe son tour avec les autres clients et le serveur qui ne sont pas au courant mais le serveur qui passe le tour sans que les clients ne soient au courant : il faut donc les informer. Et c’est là qu’arrive le RPC, nous allons donc créer une nouvelle méthode RPC de la même manière que nous avons créé la command, elle s’appellera RpcTourSuivant() et elle effectuera l’action TourSuivant(). Il faut maintenant l’appeler sur le serveur pour qu’elle s’effectue sur chacun des clients. Le meilleur moyen pour ça est de l’appeler dans la command CmdTourSuivant().