Le propos de cet article est de vous apprendre à utiliser le “réseau de mécaniques”, un outil pouvant servir autant à la conception de jeu vidéo qu’à la communication entre le designer et le développeur avant le prototypage.

Pour la petite histoire, la version initiale de cet outil a été développée par mes soins et a ensuite évoluée avec l’aide de mes étudiants en game design, après avoir rencontré le problème suivant : comment exprimer la boucle de gameplay à l’échelle micro (enchaînement d’actions ingame) dans un jeu qui repose essentiellement sur le “rocket jump” – autrement dit les actions Viser / Tirer / Sauter réalisées simultanément ?

[ Note : le schéma de la boucle de gameplay micro s’inspire ici du modèle proposé par Emmanuel Guardiola, qui distingue les actions principales des actions secondaires ]

Avant d’entrer dans le vif du sujet, je tiens à préciser qu’il est possible que l’utilité du “réseau de mécaniques” se limite au jeu vidéo, et en particulier le jeu vidéo en temps-réel, pour lequel les actions simultanées sont possibles.

Toutefois, parmi les premiers bénéfices retirés par les élèves, j’ai recensé ceux-ci :

• il permet d’avoir une vue d’ensemble des mécaniques du jeu et à l’équipe de partager une même carte mentale

• il permet d’anticiper les relations entre les différentes mécaniques avant le prototypage, au lieu de les découvrir “par hasard” pendant le prototypage

Enfin, je précise que cet article a été aussi construit et finalisé en collaboration avec deux de mes étudiants : Mathias Gonot et Virgile Sadon ; et relu par plusieurs de mes étudiants, notamment Alexandre Tournois et Tony Taysse. Je les remercie à nouveau de leur soutien.

1 / Comment réaliser un réseau de mécaniques ?

Le parti-pris qui a été retenu ici est d’organiser cette section sous forme de didacticiel, mettant en scène les différentes règles et principes établis avec les étudiants au cours du temps.

01 / Identification des verbes d’action

Identifiez / listez tous les verbes d’action du joueur (en tous cas ceux qui vous viennent à l’esprit) et inscrivez chaque verbe dans une forme simple (par convention un carré – ce qui simplifie l’utilisation des outils de création de schémas et permet d’utiliser des post-it).

[ En poursuivant sur l’exemple précédent, voici quelles pourraient être les premières actions qui viennent à l’esprit concernant – par exemple – un FPS ]

02 / Groupement “thématique” des verbes actions

Triez les verbes d’actions par catégorie et regroupez-les au même endroit. Vous pouvez aussi entourer les verbes d’une ligne pointillée afin de délimiter la catégorie, et nommer celle-ci si nécessaire.

[ Dans ce schéma, les verbes d’actions sont réunis en 4 catégories arbitraires : Mouvement, Visée, Combat et Interaction avec l’environnement . ]

03 / Identification des conditions et modifications liées aux actions

Comme cette étape demande un peu de réflexion, il est recommandé :

• d’une part de la débuter par un tableau récapitulatif pour ensuite mettre à jour le schéma ;

• d’autre part de la réaliser à deux, avec une personne exposant le point de vue du joueur (par exemple le designer) et une autre personne exposant le point de vue du système de jeu (par exemple le développeur).

Réalisation du tableau

Ainsi, pour chaque action, identifiez d’une part si sa réalisation est conditionnée par une variable ou un état (le plus souvent lié au joueur) ; et d’autre part si sa réalisation modifie des variables ou états (qui peuvent être liés au joueur ou au système de jeu).

 

[ Dans cet exemple, ce qui est exprimé est aussi important que ce qui ne l’est pas : les conditions et modifications associées aux actions ne sont pas “évidentes” ou mises “par défaut”. Ainsi, s’il y a – ou non – de l’Air Control ; ou bien si Courir consomme – ou non – de l’Endurance, constitue un choix de design. ]

Mise à jour du schéma

Une fois ceci fait, vous pouvez mettre à jour le schéma de la façon suivante :

• Si une condition ou une modification ne concerne qu’une seule action, alors inscrivez-la dans directement le bloc d’action

• Si une condition ou une modification concerne plusieurs actions à la fois, alors inscrivez-la dans le cadre entourant les blocs d’action

• [Eventuellement] Si une condition ou une modification est susceptible d’influencer, où d’être influencée par, alors isolez-la en l’inscrivant dans un bloc distinct, placé à proximité des blocs d’action concernés (cette option est plus complexe mais facilitera plus tard la connection entre les différents éléments du tableau)

Quoi qu’il en soit, et par convention :

• Une condition est à le signaler en amont de l’action, avec un “?” devant la variable ou l’état

• Une modification est à signaler en aval de l’action, avec un “>” devant la variable ou l’état

[ Dans cet exemple, les conditions et modifications issues du tableau ont été placées sur le schéma selon qu’elles sont associées à ou plusieurs actions. L’option “Air Control” et “Endurance” a été ajouté par souci didactique. Enfin, constituer ce schéma permet de mettre en lumière certaines choses, par exemple la nécessité de détailler quelles sont les actions possibles lors d’une “activation”, la dénomination étant trop générale. ]

Autre option pour le schéma

Comme précisé, vous pouvez isoler les variables et états des actions en les représentant aussi sous forme de blocs, de manière à pouvoir suivre – par exemple, comme s’opère le passage d’un état à un autre (ce qui est pertinent dans la mesure où un jeu vidéo est une machine d’états) ou bien s’il existe des boucles de rétroaction entre les différents blocs (ce qui est pertinent d’un point de vue systémique).

[ Dans cet exemple, les états du joueur (Au sol, En l’air) et les variables du joueur (Position, Vitesse, Endurance) ont été isolés et connectés aux différentes actions. Ainsi il apparaît que pour être “En l’air” le joueur doit soit d’abord être “Au sol” puis Sauter, soit être au dessus du vide ; et aussi que c’est la Gravité (mécanique du système de jeu) qui ramène le joueur “Au sol”… Il apparaît aussi qu’il existe une boucle de rétroaction négative entre l’action Courir et la ressource Endurance. ]

Cette représentation peut être très puissante mais aussi très “complexe” : imaginez un instant les connexions pouvant exister autour d’un Souls-like avec l’Endurance comme ressource principale…

04 / Contrôles utilisés

Les contrôles sont une catégorie “spéciale” de conditions car ils font l’objet d’une interprétation par le système de jeu.

L’objectif de cette étape est double :

• S’assurer que les contrôles proposés sont accessibles (soit parce qu’ils sont ergonomiques, soit parce qu’ils correspondent à l’usage)

• S’assurer que les actions qui sont conçues pour être réalisées simultanément peuvent effectivement l’être en fonction du mapping des contrôles

Mise à jour du tableau

Pour commencer, ajoutez tout d’abord au tableau de référence une colonne par contrôleur (clavier, souris, gamepad, écran) voire par plateforme (PC, Console, Mobile…) puis inscrivez le ou les contrôles associés à chaque action.

[ Dans cet exemple, les interactions avec l’environnement ont été détaillées du point de vue des contrôles, mais aussi du point de vue des conditions et modifications – ce qui se verra dans le schéma ; et les actions qui sont réalisées automatiquement par le joueur (sans l’utilisation de contrôles) sont aussi répertoriées ]

Mise à jour du schéma

Ensuite, si vous le souhaitez, inscrivez le ou les contrôles sur le schéma :

• soit de la même manière que pour les conditions (variables et états)

• soit en dessous du verbe d’action

Par usage, les actions qui partagent des conditions et contrôles similaires constituent “un répertoire”.

[ Dans cet exemple, seuls les contrôles PC (clavier, souris) sont pris en compte. Comme les actions de mouvement ont des contrôles différents, ceux-ci sont inscrits en dessous du verbe d’action ; mais comme la plupart des interactions avec l’environnement partagent le même contrôle, alors celui-ci est inscrit à l’intérieur du cadre qui contient les blocs d’action.  ]

05 / Identifications des relations entre les actions

Cette étape est peut-être la plus importante, surtout pour les jeux en temps-réel.

A/ Principe de simultanéité “par défaut” des actions

Afin de simplifier cette étape, le principe est que toutes actions du jeu, à moins qu’il n’en soit précisé autrement, sont réalisables simultanément – et à fortiori successivement – si leurs conditions d’exécution sont respectées.

Ainsi il n’est pas nécessaire préciser sur le schéma que les actions sont simultanées.

[ Par exemple, dans notre exemple de jeu de tir à la première personne, les actions Se déplacer, Viser et Tirer sont toujours réalisables simultanément ]

B / Exclusion mutuelle entre les actions

Toutefois, dans le cas où deux actions – ou groupe d’actions – ne peuvent (ou ne doivent) pas être réalisées simultanément, alors elles sont dites mutuellement exclusives.

En ce qui concerne la représentation sur le schéma, deux cas usuels se présentent :

• Soit les actions n’ont pas les mêmes conditions ou contrôles ; et l’exclusion mutuelle sera représentée par un trait reliant les actions, avec le symbole Croix-dans-Rond visible sur le trait

• Soit les actions ont les mêmes conditions ou contrôles ; et l’exclusion mutuelle sera représentée par un trait isolant les actions, avec le symbole Croix-dans-Rond

[ Dans cet exemple, les actions Tirer et Recharger sont reliées par un trait et le symbole Croix-dans-rond ; et les interactions avec l’environnement sont isolées par un trait avec le symbole Croix-dans-rond ]

Une fois que les actions mutuellement exclusives ont été identifiées, il peut être pertinent de vérifier si les conditions identifiées (états et variables) rendent bien impossible la simultanéité ; ou bien s’il est nécessaire d’ajouter de nouvelles conditions…

C / Succession entre les actions

Par ailleurs, il est possible que des actions soient mutuellement exclusives parce qu’elles sont nécessairement successives.

La représentation de la succession sur le schéma peut se faire à l’aide d’une flèche (convention usuelle).

[ Dans cet exemple, il est nécessaire de charger un sort avant de le lancer ; ainsi les deux actions Charger sort et Lancer sort sont nécessairement successives, ce sont leurs contrôles qui les rendent mutuellement exclusives ]

D / Interruption entre les actions

Ce cas de figure est assez particulier mais correspond à deux approches différentes en terme de gameplay temps-réel.

Considérons deux actions A et B comme étant mutuellement exclusives (donc il est impossible de les réaliser simultanément) ; il existe deux options :

• soit il est possible d’interrompre l’action A en exécutant l’action B (et inversement)

• soit il est impossible d’interrompre l’action A en exécutant l’action B (et inversement) ; le joueur devant “attendre” qu’une action soit terminée pour en exécuter une autre…

Réalisation du tableau

Pour chaque ensemble d’actions mutuellement exclusives, préciser si elles peuvent interrompre (cancel) une action en cours. Par convention, le tableau se lit de la façon suivante : l’action dans la colonne (de haut en bas) interrompt ou non l’action dans la ligne (de gauche à droite).

 

Il apparaît que plus il existe d’actions différentes liées au combat, plus il peut être complexe d’établir les conditions d’interruptions ou non, et d’en suivre la logique interne.

Éventuellement, la question de l’interruption peut aussi être gérée en attribuant un niveau de priorité à l’action :

• si une action en cours est de priorité supérieure ou égale à l’action demandée, alors cette dernière sera mise en file d’attente ou non exécutée ;

• si l’action en cours est de priorité inférieure à l’action demandée, alors cette dernière interrompra l’action en cours afin de s’exécuter

Mise à jour du tableau