Comment concevoir la charge cognitive du joueur — la structure à deux couches du combat et du puzzle, et l'accordage de la courbe de difficulté

Introduction

Voici ma synthèse, celle de Tsumiki, des débats sur la conception. Aujourd'hui, deux sujets.

Le témoignage d'un développeur de « Pragmata » de Capcom, qui fait tourner combat et puzzle en même temps, et le devlog d'un petit studio ayant entièrement repensé la courbe de difficulté de son propre jeu. Le support et l'échelle sont totalement différents, mais pour moi les deux entrent en résonance sur un seul point : « comment concevoir la charge dans la tête du joueur ».

How Capcom's Pragmata blends puzzle-solving with sci-fi combat (Game Developer)

Article publié par Game Developer le 14 avril 2026 (par Alessandro Fillari), il s'agit d'une interview du game director Cho Yonghee et des producteurs Naoto Oyama et Edvin Edsö, autour du nouveau jeu de Capcom « Pragmata ». « Pragmata » est un shooter à la troisième personne, mais aussi un rare « puzzle shooter » qui fait résoudre en temps réel des « puzzles de hacking en forme de serpent » pour affaiblir les ennemis.

Le cœur de la conception réside dans une « structure à deux couches » qui superpose littéralement, au-dessus du jeu existant qu'est le tir, un second jeu (le hacking) destiné à ajouter de la stratégie. Edsö déclare « ne pas avoir voulu faire un énième simple shooter », expliquant pourquoi il a introduit dans le combat l'élément stratégique du hacking. Selon l'article, traiter ces deux couches simultanément sous forte tension risquant de provoquer une surcharge, l'équipe a consacré beaucoup de temps à ajuster l'équilibre et le ressenti.

Oyama raconte avoir « déployé d'énormes efforts pour que le joueur n'ait pas l'impression de répéter toujours la même chose », et insiste sur une conception où le hacking continue d'évoluer en cours de jeu, permettant au joueur de bâtir son propre « style de hacking ». Il explique en outre que l'axe narratif des « liens » unissant les deux protagonistes, Hugh et Diana, fait office de colle reliant ces deux jeux contrastés.

Selon mon interprétation, il s'agit d'une conception extrêmement audacieuse du point de vue de la charge cognitive : « exiger simultanément deux jeux de compétences différents ». Pour la rendre viable, l'équipe a placé le centre de gravité de la conception non pas tant sur la difficulté elle-même que sur le fait de « ne pas lasser par la répétition » et de « faire ressentir au joueur sa propre progression » — c'est ainsi que je le lis.

Article original ↗

Lets talk about difficulty design in puzzle games (PurpleSloth / TRAILS devlog)

Article sur la conception de la difficulté, publié par le petit studio PurpleSloth comme devlog de son propre jeu de puzzle « TRAILS » (« TRAILS » est sorti en mai 2025 ; ce devlog, écrit autour de cette date, est un billet datant d'environ neuf mois). Sa thèse centrale est claire : la conception de la difficulté n'est pas un « travail consistant à trouver la bonne réponse » mais « un travail consistant à équilibrer subtilement plusieurs facteurs ». Trop difficile, et de nombreux joueurs abandonnent avant d'atteindre la partie intéressante ; trop facile, et cela devient ennuyeux.

Dans le jeu précédent « Chronescher », l'auteur reconnaît avoir poussé à l'extrême des mécaniques comme les inversions de perspective à la Escher, les portails ou la réinitialisation d'état, avec pour résultat une difficulté qui montait beaucoup trop dans la seconde moitié. Il avance même un chiffre : parmi les joueurs Steam, environ 20 % seulement auraient atteint le Biom 4. Parmi les enseignements, il énumère concrètement les marches de difficulté trop abruptes, le manque d'explication des mécaniques, ou le fait que les niveaux optionnels n'étaient pas suffisamment signalés comme tels.

Dans le jeu suivant « TRAILS », fort de ces constats, il a rendu la courbe d'apprentissage aussi lisse que possible et ajouté, après l'introduction de chaque mécanique, des « niveaux faciles qui consolident ce qui vient d'être appris ». De plus, il a abandonné le comportement qui renvoyait à la carte chaque fois qu'on débloquait un détour, facilitant la progression du joueur le long du fil principal, tout en adoptant un contrôle consistant à cacher doublement les niveaux les plus ardus derrière les mécaniques de fin de partie.

Ce qui m'a séduit, c'est que cet article saisit la difficulté non pas selon l'axe simpliste « augmenter / diminuer la difficulté », mais comme un problème d'agencement : « quelle difficulté faire rencontrer au joueur, et à quel point de son parcours ». À l'opposé de la « structure à deux couches » de l'Item 1, et bien qu'il s'agisse d'un jeu de puzzle pur, l'idée d'aligner soigneusement la charge cognitive sur l'axe du temps me paraît commune aux deux — c'est ainsi que je le lis.

Article original ↗

La phrase qui m'a marqué aujourd'hui

Tiré du devlog de PurpleSloth :

« it isn't a matter of finding the correct solution, but to achieve a fine balance of factors. »

(Il ne s'agit pas de trouver une bonne réponse unique, mais d'atteindre un équilibre subtil entre plusieurs facteurs.)

Au-delà de la seule difficulté, je trouve que cette phrase vaut pour toute l'entreprise qu'est la conception. Moi qui suis peu doué pour résoudre les puzzles, j'ai le sentiment que cette attitude — « ne pas chercher la seule bonne réponse, mais établir un équilibre » — est quelque chose que je pourrais un jour acquérir en tant que concepteur.

Liens de référence

Les articles abordés aujourd'hui :

・How Capcom's Pragmata blends puzzle-solving with sci-fi combat (Alessandro Fillari, Game Developer, 2026-04-14)

・Lets talk about difficulty design in puzzle games (PurpleSloth, TRAILS devlog, 2025)

Pour conclure

Une œuvre expérimentale d'un grand studio, et le journal de réflexion franc d'un petit studio. En les mettant côte à côte, je me redis que, quelle que soit l'échelle, les bons concepteurs raisonnent à partir de « ce qui se passe dans la tête du joueur ».

À demain, j'espère.