Introduction
La raison d’être de cet article vient de la difficulté de mes étudiants à s’approprier le flowchart (organigramme de programmation) pour schématiser les règles des jeux de société – jeux créés en atelier, comme approche du game design.
L’objectif de cet article est de leur fournir une approche pas à pas de l’utilisation du flowchart, en partant des situations les plus simples, vers les situations les plus complexes, afin de faciliter leur prise en main.
Je tiens à remercier les relecteurs : Quentin Bétemps, Tony Taysse et Alexandre Tournois
I / Utilisation basique du flowchart
1.1 / Rappel de la symbolique et de la structure
Un flowchart est composé de :
- blocs symboliques représentant les étapes du processus
- flèches connectant les blocs pour représenter la structure de leur mise en séquence.
Les blocs les plus utiles pour le jeu de société sont les suivants :
| Symbole | Nom | Utilité |
 | Terminaison | Symbole de capsule ou de cercle indiquant soit le début (start) soit la fin (end) d’une procédure. Par exemple, le début et la fin du jeu. |
 | Processus | Symbole de rectangle contenant une série d’opérations modifiant des variables. Par exemple l’état du jeu (game state). |
 | Décision | Symbole de diamant contenant (usuellement) une question avec une réponse oui / non ; ou bien un test de condition avec une réponse vrai / faux. Par exemple une décision du joueur ou un test logique. |
 | Processus prédéfini | Symbole de rectangle barré signalant que cette partie de la procédure appelle (renvoie à) un flowchart annexe – ce qui permet faciliter l’organisation et la lecture de flowcharts complexes. |
 | Commentaire | Symbole de bloc ouvert indiquant un commentaire. (Nous verrons plus tard que son utilité sera développée) |
En guise d’exemple, voici le flowchart des règles du 8 Américain :
La figure se lit de gauche à droite. Tout d’abord un flowchart de premier niveau qui appelle les procédures de Mise en place, Déroulement et Fin de partie. Puis un groupe de trois flowcharts de second niveau correspondants aux appels précédents ; avec notamment dans le Tour de Jeu un appel vers la procédure de Pioche. Et enfin un flowchart de troisième niveau, décrivant la procédure de Pioche. Attention, le flowchart ne contient pas toutes les règles du 8 Américain pour des raisons de lisibilité.
1.2 / Issue variable d’une action unique
De nombreux jeux assez classiques comme le Jeu de l’Oie reposent sur la mécanique de roll & move (lancer le dé et avancer le pion du nombre de cases indiqué par le dé) et proposent de déclencher un effet en arrivant sur la case.
Cela signifie qu’il faudrait, à l’issue du mouvement, vérifier à quelle case correspond celle sur laquelle se trouve le pion, et selon la nature de la case, quel effet appliquer ou non. Voici à quoi devrait ressembler le flowchart :
(Les connecteurs sont ajoutés pour faciliter la lecture et la double barre -| |- indique que le processus se répète à l’identique entre B et Z)
L’un des souci majeur de cette structure (pourtant correcte) est que chaque vérification demande au moins un test et une action, et que plus il y a de cases différentes, plus le flowchart s’agrandit.
Une solution plus compacte consisterait non pas à tester chaque type de case (oui / non), mais à identifier la case en amont, et ensuite faire un branchement (A, B, … Z) pour chaque option. Voici à quoi pourrait ressembler le flowchart condensé :
Tout d’abord, à l’étape de vérification, il procède d’abord à la lecture de la liste des cases du jeu (placée à gauche de l’étape et connectée par une flèche pointant sur l’étape pour indiquer une simple lecture) puis procède ensuite la modification du Nom de la Case (placée à droite de l’étape et connectée par une flèche pointant sur la variable pour indiquer la modification)
Ensuite le test n’effectue pas un branchement Oui / Non, mais “propage” le Nom de la Case comme variable.
(Cette structure est très semblable à la structure Case / Default en programmation).
L’avantage de cette structure est qu’elle permet d’adresser la problématique des options multiples, à condition qu’elles soient mutuellement exclusives.
1.3 / Choix unique parmi plusieurs options
Toujours en poursuivant sur la question des options multiples, certains jeux proposent au joueur de choisir une option parmi un ensemble d’options disponibles (et valides). Cet ensemble d’options peut être fixe ou variable.
Attention ! Par “option” nous entendons plutôt une “action” décrite dans les règles, qu’un “choix stratégique” lors d’un tour.
Dans le cas d’un ensemble d’options fixes, donc toujours disponibles, en suivant la même logique que le schéma suivant, on aurait par exemple la structure suivante :
Comparativement au précédent, la particularité de ce flowchart est de faire un appel à un flowchart de niveau inférieur pour chaque option, au lieu d’essayer de décrire la procédure de chaque option au même niveau que le test initial. Cela améliore la lisibilité.
Dans le cas d’un nombre d’options variables, la structure est presque similaire, mais il faut ajouter en amont du choix de l’option par le joueur, la création de la liste des options disponibles – donc valides pour le tour. C’est assez épineux parce que cela revient à modifier dynamiquement certaines variables et donc branches du flowchart.
Voici à quoi pourrait ressembler un flowchart dont les options disponibles dépendent par exemple d’un tirage de cartes, d’un lancer de dés personnalisés ou d’un placement d’ouvriers :
A noter que la liste des options disponibles à ce tour est mentionnée deux fois : une fois lors de la création, et une autre fois comme référence.
Dans le cas d’un jeu de cartes avec certaines cartes à effet comme le Uno, il serait possible de remplacer “option” par “carte” et l’on aurait alors une liste de cartes en main et un choix de cartes à jouer. Une précaution toutefois parce que certaines cartes ont des effets sur les règles du jeu (faire sauter un tour, changer le sens de la partie, etc).
Dans le cas d’un jeu de placement d’ouvriers comme Agricola, il serait possible de remplacer “option” par “case” ou “tuile” et soit appliquer immédiatement l’action offerte par la case / tuile, soit établir la liste des actions offertes par la case / tuile et ensuite faire un choix parmi ces actions.
On pourrait aussi discuter le formalisme de la structure car la liste des options disponibles lors d’un tour se présente de facto au joueur, et celui-ci fait automatiquement le tri entre celles qui sont valides ou non. Toutefois, en l’état, seules les décisions du joueur peuvent figurer dans le schéma et pas ce qui se passe dans la tête du joueur.
1.4 / Choix multiple parmi plusieurs options
En poursuivant l’idée de choix parmi plusieurs options, certains jeux proposent de réaliser plusieurs choix (en général successifs) à travers une liste d’options (fixe ou variable), que cela prenne la forme d’un nombre de coups ou actions disponibles durant le tour, ou bien d’un nombre de points d’actions à dépenser durant le tour.
En supposant que le joueur puisse réaliser plusieurs coups (ou actions), il faudrait en principe vérifier s’il reste des coups à jouer (ou bien si tous les coups disponibles ont été joués), voire garder en mémoire le nombre de coups disponibles.
Voici à quoi pourrait ressembler un flowchart avec une série de coups à jouer :
Les coups ne sont pas détaillés, et sont remplacés ici par un simple appel de procédure.
A noter que la diminution du nombre de coups est sortie de la procédure précédente, mais dans la pratique, elle pourrait en faire partie.
L’option de ne pas jouer tous les coups est aussi implémentée.
Dans l’exemple précédent, le joueur peut jouer plusieurs coups successifs (2, 3 ou plus) et dispose de la totalité des options à chaque fois. Toutefois, certains jeux font la distinction entre d’une part les options qui sont accessibles à chaque fois, et les options qui ne sont accessibles qu’une fois. Dans ce cas, cela revient à mettre à jour la liste des options disponibles pour chaque coup, exactement comme à la section précédente.
Voici à quoi pourrait ressembler un flowchart avec une série de coups à jouer, dont certains seraient limités et d’autres non :
1.5 / Conclusion partie 1
À ce stade, avec les outils disponibles, il est possible de schématiser la majorité des jeux existants.
La seconde partie de l’article s’intéresse aux cas particuliers et à l’usage avancé de l’outil.
II / Utilisation avancée du flowchart
2.1 / Le passage d’arguments
Une situation souvent rencontrée par les élèves lors de l’appel d’un processus prédéfini, est que son exécution varie selon une ou plusieurs variables qui ne sont pas définies dans le processus appelé, mais en amont.
Ainsi, pour souligner les variables pertinentes à garder en mémoire lors de la lecture d’un flowchart prédéfini, il est possible de les lister en tant qu’argument dans le bloc d’appel. Voici à quoi pourrait ressembler un bloc du flowchart :
2.2 / Les capacités liées aux rôles
Dans les jeux modernes, les joueurs ont parfois des rôles (établis en début de partie, ou pouvant changer en cours de partie), qui leur offrent des capacités supplémentaires, qu’elles soient mécaniques ou paramétriques.
Ainsi, à chaque rôle correspond un tour de jeu (légèrement) différent, qui pourrait faire l’objet d’un flowchart unique… mais il y aurait beaucoup de redondance et donc cela ne serait pas efficace. Il serait ainsi préférable de n’avoir qu’un seul flowchart de tour de jeu valable pour tous les rôles, dont certaines options ne seraient disponibles qu’en fonction du rôle du joueur.
En nous appuyant sur l’outil précédent, il serait possible d’une part de passer le rôle du joueur actif comme argument du flowchart prédéfini, et ensuite de préciser dans le flowchart si un paramètre doit changer en fonction du rôle ou si une action est disponible en fonction du rôle. Voici à quoi pourraient ressembler des sections de flowchart :
Dans cet exemple, au moment du passage au flowchart du Tour d’un Joueur, l’information sur le rôle du joueur actif est conservée.
En parcourant le flowchart de niveau inférieur, le lecteur saura ainsi combien de cartes tirer selon son rôle, ou bien entre quelles options choisir en fonction de son rôle.
Si le nombre de rôles est limité, il est tout à fait possible de convenir d’un symbole (voire d’une couleur) pour identifier chaque rôle et étiqueter les blocs associés.
2.3 / Le jeu simultané à règles similaires
Pour l’instant, nous n’avons discuté que de situations où les joueurs jouent les uns après les autres, et réalisent leurs actions les unes après les autres. Toutefois certains jeux permettent aux joueurs de jouer ou bien de réaliser des actions simultanément.
Signifier la simultanéité dans un flowchart par nature séquentiel peut être challengeant, mais pas insurmontable. Voici à quoi pourrait ressembler un flowchart :
2.4 / Le jeu simultané à règles distinctes
Dans l’exemple précédent, il était sous-entendu que les joueurs jouaient de la même manière. Ainsi, le cas serait possible qu’au moins deux joueurs jouent simultanément, mais de manière différente.
Cela demanderait donc de signifier un processus en parallèle. Voici à quoi pourrait ressembler un flowchart :
A noter que dans cette situation, le Tour de Jeu se termine lorsque les deux joueurs ont terminé leur tour, mais les règles pourraient stipuler autrement…
2.5 / L’interruption de processus
Dans la continuité de l’exemple précédent, nous pourrions supposer lorsque les joueurs jouent simultanément (en parallèle donc), la fin de tour ne soit pas atteinte lorsque tous les joueurs ont terminé leur tour, mais dès que l’un des joueurs termine son tour.
Cette situation revient à introduire dans le flowchart un mécanisme d’interruption de processus, comme par exemple, un sablier qui détermine la fin d’un tour de jeu. Voici à quoi pourrait ressembler un flowchart :
2.6 / Conclusion partie 2
A l’issue de cette partie (qui mériterait sans doute d’être complétée au fil du temps), une grande majorité de structures modernes de tour de jeu sont transposables en flowchart.
Il était initialement prévu que l’article s’arrête ici, mais l’opportunité s’est présentée d’ajouter une section sur l’utilisation du flowchart dans le domaine du jeu vidéo, qui fait l’objet de la troisième partie.
III / L’extension au jeu vidéo
3.1 / Présentation des blocs associés au jeu vidéo
Les flowcharts de jeu vidéo suivent les mêmes conventions que ceux du jeu de plateau, mais doivent intégrer des blocs supplémentaires, notamment pour :
- les entrées (en particulier celles du joueur sur le contrôleur)
- les sorties (en particulier les feedbacks sonores et visuels sur l’UI)
- la modification des variables en mémoire…
| Symbole | Nom | Utilité |
 | Action du joueur | Symbole de chevron indiquant les inputs du joueur sur le contrôleur (clavier, souris, gamepad, écran tactile…) |
 | Mouvement de données | Symbole de rhomboïde indiquant la la modification d’une donnée en mémoire. |
 | Affichage | Symbole de parallélépipède rectangle indiquant les changements de caméra, d’interface utilisateur (UI) et n’importe quel signe ou feedback du jeu sur l’écran |
Précisons que, contrairement aux flowcharts de jeu de société qui sont utilisés principalement pour réfléchir à la rédaction des règles, les flowcharts de jeu vidéo sont utilisés en amont de l’implémentation et doivent ainsi répondre à des exigences techniques.
3.2 / Empilage et présentation en ligne
Une des particularités du jeu vidéo est de réaliser toute une série d’opérations entre deux rendus d’image, et ainsi plusieurs étapes peuvent se “superposer”.
Pour éviter l’allongement inutile du flowchart de haut en bas, celui-ci est présenté de gauche à droite (sens de lecture) et les étapes similaires sont empilées (stacked). Voici à quoi pourrait ressembler un flowchart utilisant ce principe :
Comme l’action du joueur mène à la modification de plusieurs éléments affichés, ceux-ci sont empilés (déroulés vers le bas).
S’il y avait plusieurs variables modifiées, celles-ci aussi seraient en bloc empilés.
3.3 / Activation / désactivation des éléments d’interface
Une des particularités du bloc Affichage, est qu’il peut contenir différents types d’informations, dont celles relatives à l’Interface Utilisateur (UI).
Dans la pratique, les éléments de l’UI peuvent être affichés ou effacés, ce qui se traduit dans le schéma par la mention activé / désactivé. Voici à quoi pourrait ressembler un flowchart utilisant ce principe :
3.4 Conclusion de la partie 3
J’espère que cette petite section “bonus” consacrée au flowchart adapté au jeu vidéo vous aura intéressé.
Conclusion
Nous voici arrivés au terme de la première édition de cet article. Il me paraît assez complet comparativement aux différents problèmes rencontrés par les étudiants. Toutefois, si à l’avenir de nouveaux problèmes étaient soulevés, cet article serait très certainement mis à jour !