Welcome to the prog side

Et oui il y a un nouveau lead dev chez CarTylion ! En charge de la dématérialisation du jeu Conseil de Guerre j’ai l’honneur de présenter ce qui s’annonce comme une aventure ambitieuse : rien moins que son jeu vidéo. Avec Maximilien, stagiaire de 3ème année de Game design & Programming à l’ISART, nous reprenons un travail réalisé par Joéva, stagiaire de 1ère année passée depuis en 2nde année. Quand on arrive à ce niveau il est indispensable de comprendre que les méthodes de travail doivent s’unifier, donc parfois savoir que garder et jeter, et je me sens un peu comme le maire de Thiercelieux qui est en charge de trancher. Suivez-moi dans ce travail.

Classes et architecture logiciel

Bon, concrètement je vous propose quoi comme reworking ?

Commençons par le début, à savoir les classes et les liens entre elles.

L’une des métaphores les plus répandues pour expliquer ceci est celle du maçon faisant un mur de briques. Une classe est une brique, les liens une forme de ciment qui maintient le tout solidement, pour différencier les liens, on parle d’association ou composition. Par exemple « un magasin vend un ou des biens. » est une association et « une maison est composée de 4 murs et un toit. » est une composition, la différence est mince en français et encore plus en informatique.

Pour adapter Conseil de Guerre il faut de nombreuses classes différentes, on aime également mieux que chaque classe ait une seule responsabilité et non plusieurs pour pouvoir assurer un débugage facile et rapide.

Voyons les choses ainsi : il vaut mieux en cas de travail mal ou moyennement fait ne pas être en cause si on ne l’est pas. On connait tous plus ou moins la désagréable sensation de l’écran d’erreur bleu Windows, celui-ci n’expliquant que très peu la cause de son apparition, on est incapable de savoir quelles erreurs l’ont engendré. Un programmeur hors du système ne pourra affirmer qu’une seule chose : Au moins une des classes a produit une erreur.

Ici on veut pouvoir savoir où est l’erreur s’il y en a eu une, dans quelle méthode ou fonction.

Notez que pour un programmeur méthode = fonction.

Le diagramme de classes

La reprise du diagramme de classes, représentant l’architecture du logiciel, nous a permis de préciser le bon début de Joéva mais également certaines insuffisances très certainement liées à la trop courte période de son stage. De plus, bien que nous ne visions pas le jeu « triple A », il faut répondre à une certaine qualité de jeu qui devrait être entre « B » et « A » dépendant de la taille de l’effectif de programmation et de son niveau. Pour l’instant disons pour les amateurs de sports que je suis l’une des plus grosses recrues d’un club de division nationale ou légèrement inférieure. Bref pour l’instant l’effectif de programmation c’est 1 + les stagiaires donc pas énorme pour produire un jeu vidéo entier.

Dans ce diagramme on a également la notion d’héritage, qui peut s’expliquer comme ceci : soient une voiture, un avion et un bateau, on va les regrouper en disant ce sont des véhicules, un véhicule se conduit, la différence de conduite sera faite par les enfants du véhicule. Cela nous permet de spécifier de nouveaux véhicules sans tout refaire. N’oublions pas non plus les événements qui informent les classes de certaines tâches spécifiques, voyez les comme les différents drapeaux de certaines courses de voitures. On les représente avec une enveloppe car ce sont les notifications qui nous intéressent. Cela donne donc le diagramme que voici :

Mais Mathieu pourquoi certaines classes sont en rouge, qu’est-ce qu’un singleton ?

Quand on construit plusieurs diagramme de classes, certains motifs se retrouvent en les comparant, on appelle ça des design patterns ou patrons de conception. Pensez au styliste : quelle que soit l’unicité de ses créations, on trouvera toujours quelque chose qui ressemble, car fait avec le même patron (une jupe portefeuille, un pull col roulé, …). Chez les programmeurs les patrons portent des noms, souvent anglophones que vous pourrez trouver sur le net facilement. Le singleton ici nous permet d’assurer qu’il n’y a qu’un exemplaire de classe qui fonctionne en même temps que ce soit sur vos machines ou les nôtres. Cela évite de surcharger la mémoire RAM, qui finira par l’être quelle que soit la puissance de vos machines si on ne le fait pas. Pour vous en convaincre, ouvrez vos « vieux » jeux vidéo préférés (plus de 10 ans et pas de mise à jour) plusieurs fois si possible, voyez le ralentissement brutal de votre machine (même si vous avez un ordi gamer dernière génération), et si vous insistez encore vous aurez soit un écran bleu soit une demande de Windows de fermer des programmes.

Le réseau

Bien, mais d’où viennent donc les 2 bulles client et serveur ?

Tout simplement du fait que les utilisateurs vont vouloir jouer entre eux et non contre une IA (intelligence artificielle), qui finira par devenir limitée à un moment ou un autre. On va donc passer par le réseau, d’où une classe dédiée, à noter que celle-ci n’est pas complète et est à l’étude donc pas encore fonctionnelle, en effet elle est peu prioritaire car les premières fonctionnalités permettront seulement de jouer contre l’IA. Nous allons quand même l’intégrer tôt pour mieux gérer ceci en SCRUM, qui peut être décrit comme une succession de sprints pour évaluer la stabilité. Nos problèmes consistent à savoir gérer le débit et la latence. Pensez à cette image :

Comme quoi, les maths ça sert à plus que seulement compter. Je ne rentrerai toutefois pas dans les formules mathématiques lourdes et resterai sur des « maths avec les doigts ».

Le débit est le diamètre du robinet et la latence le temps que mettra celui-ci à remplir le verre (on néglige ici les débordements éventuels). On n’a pas de prise directe dessus à moins de refaire toutes les lignes et les fonctions de traitement du signal, en gros d’être un opérateur téléphonique. Mais on peut et on doit maitriser le flux, en gros on cherche la taille maximale des paquets à envoyer dans vos lignes.

Alors oui on va ajuster sur la connexion la plus lente, mais vous n’y verrez rien sauf problème de ligne. En effet le système de tour par tour permettra de synchroniser les données. Les stagiaires n’ayant pas encore eu de cours de réseaux informatiques je leur ai fait un cours d’introduction à ce sujet, je n’ai pas la prétention d’en être spécialiste donc je vais juste vulgariser quelques notions utiles ici.

Le débit est déterminé par votre abonnement internet c’est la quantité d’eau versée dans le tuyau par seconde en o/s.
La latence on la mesure en s mais on ne l’obtient que par le ping qui est la mesure de temps d’un paquet aller-retour donc environ 2 fois la latence.
Réduire la latence c’est donc réduire la distance entre x machines (x >= 2).

En gros si l’on veut le minimum de latence pour tous en France on met un serveur au milieu de la France si les lignes sont toutes équivalentes, et pas en Allemagne ou ailleurs. Le fait est que toutes les lignes ne sont pas équivalentes donc on ne le placera pas au centre mais plus vers les lignes « faibles » pour l’équité ou plus souvent « fortes » pour raisons économiques. Ce qui explique le plus souvent le choix « Paris-Lyon-Marseille » plutôt que « Centre-Savoie-Bretagne ».

Depuis le début de cette partie je vous ai parlé de débit et latence mais du coup qu’est-ce que mon eau qui coule ?

Des paquets, des paquets de données qui peuvent se voir comme vos colis tant attendus, dans ce colis seul le ou les objets de commande vous importent et si tout s’est bien passé emballages et autres finissent à la poubelle. Ici tout est pareil. Oui mais la poste connaît l’adresse pour la boîte au lettre et si le paquet ne rentre pas, il faut aller le chercher au bureau de poste. Ici c’est votre adresse IP qui est utilisée et si le paquet est trop gros c’est retour à l’envoyeur qui le découpe et le renvoie sans intervention du destinataire (et sans dégâts sur le colis).

Bon, mais comment je sais le mode de transport ?

Dans un paquet, l’information consiste à savoir si vous avez été livré en main propre ou boîte au lettre avec acquittement, ceci est indiqué par le protocole utilisé, TCP/IP ou UDP. Le premier est en main propre, il certifie que le paquet accepté est en parfait état sinon retour et renvoi, l’autre ne le fait pas donc moins d’emballage. Le premier a l’inconvénient d’être en mode connecté uniquement, c’est à dire que le destinataire doit obligatoirement être présent et répondre. L’autre n’a pas ce problème. Il est raisonnable de penser que tous les joueurs d’une partie de Conseil de Guerre seront présents aux mêmes moments et ne voudront pas d’erreur sur les cartes posées ou en main, donc ici TCP/IP s’impose.