Art of War

Préparez-vous pour le combat !

Art of War est un jeu de stratégie créé par Takashi SAKAUE et Souya NAITO. Utilisant un système de champ de bataille et de royaume, l’objectif est simple : terrassez l’armée de votre adversaire et remportez le combat.

Cet exercice est un projet d’algorithme dans le cadre des cours présents à Polytech Montpellier.
Ce projet à été réalisé en binôme avec mon cher ami Thomas Falcone (dont le petit lien vous renverra sur son LinkedIn)

Pour les curieux, le code est ouvert sur GitHub en fin de page

 

Des règles multiples, un code organisé

Les règles du jeu sont assez denses pour tout néophyte à ce type de jeu et la retranscription sous forme de code n’en est que plus complexe à organiser. Chaque joueur possède une ligne de front, une ligne arrière, un royaume (ou il peut extirper ses cartes), une réserve (militaire) et la pioche. À chaque tour, plusieurs actions sont possibles : le joueur peut attaquer s’il en a envie, ne rien faire ou mettre des troupes en réserve.

Programmé en python, sans interface graphique:

Réalisé dans le cadre des cours d’initiation à la programmation, ce projet permet de prendre en considération de nombreuses règles de la programmation dite procédurale. En effet, elle demande de manipuler les concepts de type abstraits, les types généraux (tableau, listes, files, piles, etc.), mais aussi et surtout d’apprendre à organiser son code et à bien prévoir l’ensemble des règles à prendre en compte.

Comment retranscrire un jeu de société en code ?

Pour pouvoir retranscrire l’ensemble des règles du jeu (version basique, absence de certains personnages) il nous a fallu, dans un premier temps, réécrire les règles sous forme de code. Il ne sait alors que d’une retranscription des actions dans un ordre chronologique. Les éléments de syntaxes des règles du jeu (SI, ALORS, POUR TOUTES LES CARTES) nous permettent alors de commencer à hiérarchiser les informations (boucle if, boucle for, etc.). Les personnages et les éléments « globaux » du jeu « Royaume, Reserve, Cimetière, etc. » permettent alors de définir des types, des « entités » de notre code.

Une fois cette première phase développée, il faut commencer à construire le code et essayer de desceller au plus vite les actions répétitives, les fonctionnalités qui se détachent avec les entités que l’on a déjà trouvées. (piocher(), attaquer(), etc.).
Les types de jeu se dégagent d’autant plus que les fonctionnalités apparaissent, c’est-à-dire que l’ensemble des fonctionnalités répertoriées pour une seule et même entité permettent de définir le « type » lui correspondant.

Par exemple, l’ensemble des fonctionnalités liées au royaume nous permettent de comprendre que l’on aura besoin d’un type royaume, c’est à dire d’un ensemble de fonctionnalités et de variables liées à ce concept.

 

Une fois les règles retranscrites, c’est bien beau, mais on fait quoi ?

Une fois l’ensemble des règles et des petites parenthèses retranscrites, il suffit de transformer le contenu en langage de programmation (python dans notre cas). La réécriture préalable de ces règles permet d’avoir un code propre, déjà commenté (les actions sont écrites juste au-dessus en français) et lisible.

Et si on pimentait la complexité ?

Dans le cadre de ce projet, le développement se faisait en deux phases:

  • Écriture du programme principal (les règles retranscrites en lignes de code et de fonction)
  • Écriture de l’ensemble des fonctions

Pour ce faire, nous devions écrire l’ensemble des noms de fonctions, expliquer à quoi elle devait servir, mais ne pas en écrire le contenu. C’est alors à un autre binôme de remplir le contenu et de faire fonctionner le programme.

Alors, oui, d’accord, mais pourquoi ?

Pourquoi ? Bah parce que les gars… Le véritable objectif est de nous permettre d’apprendre à coder l’ensemble d’un projet de la façon la plus propre possible, c.a.d apprendre à écrire du code destiné à des variables quelconques. ATTENDEZ, je m’explique.

Imaginons que vous ayez besoin d’enregistrer une dizaine de films sur votre disque dur, vous ne vous intéressez pas à la façon dont elle est enregistrée (disque magnétique, système SSD, etc.) , vous souhaitez juste que les données soient accessibles, peu importe la façon dont les choses sont construites. La programmation avec les types abstraits fonctionne de la même façon : vous devez construire quelque chose qui fonctionne pour tout. Et dans le cadre de notre projet, c’est le second binôme qui récupère notre code qui décide de la façon dont les choses vont être organisées, c’est eux qui décident de mettre un disque magnétique ou un SSD.

Bien les cernes ?

Je vous répondrais ça va merci. Bien que ce projet n’a été que purement théorique (pas d’interface graphique de jeu, etc.). Il permet de bien se rendre compte de l’importance d’avoir un code clair, propre et adapté pour que dans un futur (pas si lointain) d’autres personnes puissent le récupérer pour avancer dessus.