De la boucle de gameplay au réseau de mécaniques – Partie 1

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 ?

00 _ FPS boucle micro + Rocket Jump

[ 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).

01 _ Identification verbe action

[ 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.

02 _ Groupement verbes action

[ 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).

 

Catégorie

Nom de l’action

Conditions

(Etats)

Conditions

(Variables)

Modifications

(Etats)

Modifications

(Variables)

Mouvement

Se déplacer

Joueur : Au sol

Joueur : Position

Sauter

Joueur : Au sol

Joueur : En l’air

Courir

Joueur : Au sol

Joueur : Endurance > 0

Joueur : Vitesse (+)

Joueur : Endurance (-)

Air Control

Joueur : En l’air

Joueur : Position

Visée

Viser (regarder)

Joueur : Orientation

Viser épaule

Arme : Viseur

Camera : Angle de vue (-)

Camera : Overlay viseur

Combat (arme à feu)

Tirer

Arme : Chargeur Munitions > 0

Arme : Chargeur Chargeur (-)

Recharger

Joueur : Réserve Munitions > 0

Arme : Chargeur Munitions (+)

Joueur : Réserve Munitions (-)

Interaction (avec l’environnement)

Activer

Objet : Activable

Joueur : Distance à l’objet

Joueur : Regard sur objet

A préciser

A préciser

(etc)

[ 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

03 a _ Conditions et modifications

[ 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).

03 b _ Conditions et modifications sous forme de blocs

[ 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.

Catégorie

Action

PC / Clavier

PC / Souris

Gamepad

Mouvement

Se déplacer

ZQSD

Stick Gauche

Sauter

Espace

A

Courir

Majuscule

A définir

Visée

Viser (regarder)

Déplacer Souris

Stick Droit

Viser à l’épaule

Souris Droite

Bouton Gauche

Combat (armes à feu)

Tirer

Souris Gauche

Gachette Droite

Recharger

R

X (si Chargeur vide)

Interaction avec l’environnement

Ouvrir / Fermer

E

X (si Objet à portée)

(Autre)

E

X (si Objet à portée)

Pick-up

(Auto)

(Auto)

Etc

[ 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”.

04 _ Contrôles utilisés

[ 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

05 a _ Relations mutuellement exclusives entre actions

[ 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).

05 b _ Relation de succession entre actions

[ 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).

 

Est-ce que [ action de la colonne ] interrompt [action de la ligne ] ?

Tirer

Recharger

Lancer grenade

Echanger arme

Tirer

-

Non

Oui

Non

Recharger

Oui

-

Oui

Oui

Lancer grenade

Non

Non

-

Non

Echanger arme

Oui

Non

Oui

-

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 à 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

 

Action

Priorité

(Bas = 0 ; Haut = 10)

Notes

Lancer Grenade

8

A partir du moment où le joueur décide de lancer une grenade, l’action (animation) s’exécute entièrement

Tirer

6

Echanger arme

4

Recharger

2

L’action de recharger ne doit pas être interrompue par une autre action pour être terminée

Les valeurs minimales et maximales de la priorité sont arbitraires, et dépendent du nombre d’actions considérées.

[ En réalité, la situation est plus complexe car une action se déroule sur plusieurs frames, et bien souvent le “droit d’interrompre” n’est pas le même selon la frame où on se trouve ; ce sujet sera a priori abordé dans le prochain article ]

Mise à jour du schéma

En conservant l’exemple des actions de combat, le schéma pourrait être mis à jour en inscrivant la priorité de chaque action dans le bloc.

05 d _ Relations d'interruption entre actions

Toutefois, il existe une ambiguïté entre la priorité (basse à haute) et le rang (premier à dernier) ; en effet, une action avec une haute priorité (10) aura un rang faible (1), et donc il est possible qu’une erreur d’interprétation soit faite.

Enfin, il peut être souhaitable d’établir les priorités non pas pour toutes les actions les unes par rapport aux autres, mais entre les actions d’une même catégorie (donc qui sont susceptibles de s’interrompre).

E / La question de l’évidence des choix

En accompagnant mes élèves lors de la conception de leurs projets de jeu vidéo, j’ai remarqué que cette étape permettait de mettre en lumière les potentielles différence de vision sur le fait que certaines actions pouvaient être ou non simultanées ; ou que certaines actions pouvaient être ou non interrompues.

Bien que je laisse les élèves trancher ces questions par eux-même, le plus surprenant reste que chaque “parti” utilise l’évidence comme justification de son choix. Or, en game design, il n’existe pas de choix évident.

Ainsi, je pense qu’il est important que l’ensemble de choix relatifs à la simultanéité et l’interruption soient argumentés au regard de l’expérience ludique visée.

06 / Combinaison des actions

Dans le cas d’actions spéciales issues de combinaisons ou enchaînement d’actions, il peut être utile de les faire figurer dans un tableau à part.

06 a _ Combinaison des actions

[ Dans ce schéma, l’utilisation d’un diagramme de Venn permet de mettre en avant l’action Rocket Jump qui exige l’exécution de 3 actions simultanées (Viser ses pieds, Tirer une roquette et Sauter) ]

Notez qu’il n’y a pas de réponse “évidente” à cette question comme le montre l’exemple suivant :

06 b _ Courir et S'accroupir

07 / Abstraction des actions

Certaines actions gagnent à être représentées de manière “abstraite” ou “synthétique” ; comme par exemple l’action “Se déplacer” qui est en fait un réseau composé de 4 actions différentes (Avancer, Reculer, Aller à gauche, Aller à droite) chacune associée à un contrôle spécifique (Z / S / Q / D sur clavier ou bien Stick Gauche sur gamepad) et qu’il est possible de représenter en détail de façon isolée et aussi “en résumé” dans le schéma principal.

07 _ Abstraction des actions

[ L’action Se déplacer utilisée dans les schémas est une “abstraction” qui encapsule le réseau d’actions composée des verbes Avancer, Reculer, Pas à Gauche, Pas à Droite ; tout comme l’action Regarder interprète 4 mouvements de souris différents ]

08 / Etats et variables du joueur

Il peut être pertinent de mentionner, en marge du schéma, les états et variables usuels du joueur. La distinction peut être faite entre variables “intrinsèques” au personnage (santé, endurance) et variables “extrinsèques” au personnage – ou “ressources” (or, munitions, etc).

08 _ Etats et variables du Joueur

09 / Changement de mode de gameplay

Si parmi les actions disponibles pour le joueur, certaines permettent d’aller et venir entre différents mode de gameplay ; alors séparer formellement chaque mode de gameplay afin de faire apparaître les actions disponibles pour chaque mode ; ainsi que les entrées (inputs) pour aller et venir d’un mode à l’autre.

Par exemple : appuyer sur I pour ouvrir un inventaire, et avoir des actions pour naviguer dans l’inventaire et équiper / déséquiper ou utiliser / améliorer un objet etc.

10 / Post-it-ification

Bien évidemment, il est possible d’utiliser des Post-it pour construire le réseau de mécaniques sur un tableau blanc. L’avantage étant que l’on peut y inscrire toutes les informations significatives, les relier avec un trait sur le tableau, et les repositionner si nécessaire.

10 _ Post-it

[ Voici ce à quoi pourrait ressembler une partie du schéma précédent s’il était réalisé avec des Post-it sur un tableau blanc. ]

La première partie de l’article s’arrête ici. La seconde partie traitera des mécaniques monde (comme les ennemis) / système (comme la caméra). La troisième partie présentera des cas d’étude, empruntés à des jeux vidéo classiques, modernes et des projets étudiants.

 

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>