Conseil de Guerre en ligne, où en est-on ?

C’est encore le lead dev qui vous parle (voix vadorienne). On a avancé un peu, même si ça paraît toujours trop long pour les utilisateurs qui attendent. On se dit souvent que l’attente fait montre de la qualité du jeu souhaité et de la taille de l’équipe. On peut en effet établir une relation de proportionnalité entre taille d’équipe et vitesse de sortie d’un produit mais uniquement entre ces 2 paramètres, pas avec la qualité du produit. Pour ceux qui aiment les jeux de construction à plusieurs, on peut même aller jusqu’à dire que plus il y a de joueurs moins la construction est solide s’il n’y a pas de contrôle des autres. Il faut donc trouver le bon équilibre. Faisons le point sur notre avancement sur Conseil de Guerre en ligne.

Structure de données et implications connexes

Mathieu, tu bosses un peu ?!

Et bien oui ! Pour les férus de Conseil de Guerre, vous le savez les règles reposent en majorité sur l’adjacence des cartes, leur type et leur catégorie. Pour nous les types sont soit Pion soit Décision et les catégories sont donc Soldat, Héros, Producteur ou encore Administrative, etc. L’un des problèmes de ce jeu est que certains effets transforment des cartes d’une catégorie en une autre (ces effets ne sont pas encore présents dans les cartes de base du jeu, mais arriveront très prochainement).

Où est le problème ?

Une carte Décision peut devenir un Soldat, mais Soldat n’est normalement que pour les Pions donc la Décision devient un Pion et c’est impossible en termes de logique informatique. C’est comme en maths on n’additionne pas carottes et steaks, enfin sauf en cuisine !

On a vu dans l’épisode précédent les associations et héritages. Ils permettent de faire un certain nombre de choses mais pas cela, même conjugués à des mécanismes plus complexe, on a donc dû modifier un peu le diagramme donc recasser un peu de code.

Modifier du code déjà fait s’appelle le refactorer

Ok mais c’est comme faire et défaire à répétition ?

Oui, c’est pourquoi nous ne devons pas faire comme Pénélope d’Ithaque. Nous ne ferons cela que quand c’est absolument nécessaire, pas autrement. Comme en couture ou encore en broderie, en cas de saut d’une maille on la recommence en la défaisant d’abord. Heureusement que le « couper-coller » et un peu de réflexion réparent ça.

Les règles du jeu sont claires, pourquoi ne pas les donner directement à l’ordinateur ?

Pour l’utilisateur c’est l’impression qu’il aura mais pas dans les faits. Par exemple quand on décale les cartes on décale là où il y en a le moins, intelligent mais fainéant. Un ordinateur n’est pas intelligent on doit donc faire avec une numérotation figée ou du moins fixée par la structure de données :

Mais que diable est ce schéma Mathieu ?

Pour faire simple on veut supprimer la carte 1 après avoir joué la 9 qui nous demande de remettre une carte sous sa pile. Pour assurer la règle de continuité du jeu, les joueurs feront simplement le glissement de la flèche orange et diront 0 devient 1.

Mais pas l’ordinateur, pourquoi ?

Les collections dans beaucoup de langages informatique sont numérotées de 0 à (nombre d’éléments -1) et impossible de changer ceci, mais elles permettent de manipuler des grandes quantités. Des listes sont des collections avec un gros avantage à savoir « premier arrivé, premier servi ». Pour vérifier les effets ou pour réorganiser les cartes c’est pratique, il suffit de créer l’une des flèches vertes et de remonter la file en renumérotant la collection au passage.
Ce système paraît intelligent, certains diraient que c’est de l’intelligence artificielle, mais non. L’intelligence artificielle ou IA c’est rendre l’ordinateur capable de faire des choix face à des situations particulières. C’est donc un automate déterministe qui sera nécessaire. On en parlera dans un prochain article. Preuve que l’on en est encore pas à faire Skynet même avec de la volonté et une IA correctement conçue.

Pour résumer, les structures de données sont des outils indispensables pour nos besoins et sont un peu comme les molécules de chaque brique (les classes).

Mais Mathieu, pour la construction d’un mur on n’a pas besoin de savoir en quoi sont les briques ou le ciment !

Ce n’est pas tout à fait vrai, savoir que vous mettez du béton ou du carrelage change pas mal. Et c’est comme ça que le plateau de jeu va fonctionner.

Mécaniques de jeux et informatique

On voit que les mécaniques de jeux ne sont pas très complexes, pour ainsi dire facile à comprendre, difficile à maîtriser. On cherche simplement à maximiser son score, autrement dit le nombre de Tapans. Ce jeu n’est pas jouable pour un enfant ne sachant pas lire correctement, donc au moins 6 ans, de plus il faut une véritable logique, donc 8 ans au moins.

Oui, Mathieu pourquoi nous parles-tu de ça ?

Parce que l’informatique c’est fantastique mais pas du caoutchouc super doux. Un ordinateur c’est comme un enfant qui demande en permanence « C’est quoi ça ? », « Comment on fait ça ? » et vous crache la soupe au visage au moindre problème en disant « J’aime pas ça ! » et avec de la chance « C’est ce truc précis mon problème ». On a vu que classes et fonctions répondent souvent à ces deux interrogations continuelles. On sent le « mais » arriver. Effectivement, tout comme il faut savoir parler aux gens et surtout aux enfants, il en va de même pour l’ordinateur. Les fonctions doivent donc être très précises, on ne met que la pièce carrée dans le carré. Un plateau de jeu ne représente rien pour la machine mais dites lui que c’est une grille de 5×4 elle vous dessinera un tableau régulier de 20 cases allant de 0 à 19. Dites que ce sont des listes, elle vous transtype ça sur parole, à vous de savoir ce que vous faites.

Traduction : vous dites « met mon slip sur la tête », elle le fait sans se poser de question. Donc l’ordinateur est débile ? Seulement si le programmeur le guide mal. En plus, malgré les impression qu’il parle notre langue, ce n’est pas vrai, il faut parler une de ses langues parlées. Par exemple « Bonjour » peut devenir Debug.Log(« Bonjour »);

On doit donc encore simplifier les règles pour lui, ou du moins les découper. Jouer une carte jouable devient :

1. Trouver les cartes jouables.
2. Sélectionner une d’elle.
3. La poser au bon endroit.
4. Appliquer chaque effet.

Avec ce simple exemple on comprend toute la déconstruction à faire pour Conseil de Guerre. Cela prouve que la dématérialisation de jeux de société n’est pas triviale, méfiez-vous de ceux qui vous diront le contraire. Même si j’admets volontiers que l’expérience accélère celle-ci.

Le travail avance bien mais on tombe sur des complications non anticipées. On a appris ce que sont des collections informatique, leurs contraintes et avantages. Les algorithmes décrivant les fonctions doivent en tenir compte et s’y adapter. Puisque les algorithmes sont en réalité des successions d’étapes ordonnées, il est naturel de devoir les décrire suffisamment précisément. On a également vu qu’un ordinateur est semblable à un petit enfant à qui l’on parle uniquement dans sa langue. Il faut donc tout simplifier et décrire pour réussir à faire quelque chose, et plus c’est complexe plus il faut simplifier.

Comme toutes les bonnes choses, cet article a une fin et pour citer notre gouvernator, « I will be back. »