Clair Obscur: Expedition 33 : quand la création dépasse la technique
Avec Blueprint, Clair Obscur: Expedition 33 montre qu’un petit studio peut livrer un RPG ambitieux. La vraie rupture : déplacer le centre de gravité du code vers la conception.
Un RPG ambitieux, une petite équipe, peu de programmeurs : derrière Clair Obscur, une manière de produire qui pourrait changer les règles du jeu.
Je suis tombé sur Clair Obscur: Expedition 33 un peu par hasard, et honnêtement, ma première réaction a été assez classique : “ok, encore un RPG ambitieux, sûrement développé par une grosse machine bien huilée”. Puis je vois passer une interview des devs… et là, petit bug dans la matrice. Ils expliquent tranquillement qu’ils ne sont “pas de grands développeurs” et que leur équipe est plutôt limitée côté programmation.
Attends, quoi ? Comment tu fais un jeu de cette envergure sans une armée d’ingénieurs derrière ?
C’est exactement la question qui m’a donné envie de creuser. Et plus j’avance, plus je me rends compte que ce jeu n’est pas juste intéressant pour ce qu’il montre à l’écran, mais pour comment il a été fabriqué.
Comprendre le truc sans jargon
Au cœur de tout ça, il y a un outil que beaucoup de studios utilisent déjà : Unreal Engine. Mais ici, ce n’est pas juste “le moteur graphique”. C’est surtout un environnement rempli d’outils qui permettent de créer sans forcément coder.
Et notamment un système appelé Blueprint.
Si je devais simplifier à l’extrême, Blueprint, c’est un peu comme faire de la programmation… sans écrire de code. À la place, tu relies des blocs entre eux, comme des Lego. Chaque bloc représente une action, une règle, un comportement.
Tu veux qu’un personnage saute quand on appuie sur un bouton ? Tu relies deux blocs. Tu veux déclencher un effet visuel quand un ennemi attaque ? Encore des blocs.
C’est presque plus proche d’un logiciel de montage ou d’un outil 3D que d’un langage informatique classique.
Quand le code devient secondaire
Ce qui m’a vraiment surpris, c’est que chez Sandfall, le code n’est plus au centre.
L’idée, c’est plutôt : “on n’a pas beaucoup de programmeurs, donc arrêtons de tout reposer sur eux”.
Du coup, ils déplacent la complexité ailleurs. Ils créent des outils visuels, et ensuite, tout le monde peut s’en servir.
Les designers, les artistes, les level designers… chacun peut intervenir directement sur le gameplay. Pas besoin de passer par un développeur à chaque idée.
Et ça change complètement la dynamique.
J’imagine assez bien la différence : au lieu d’avoir une file d’attente de demandes techniques, chacun peut tester ses idées presque en direct. Ça doit être beaucoup plus fluide, mais aussi beaucoup plus… chaotique.
Des objets qui deviennent vivants
Un autre point que j’ai trouvé assez parlant, c’est la manière dont ils utilisent les assets.
Un asset, à la base, c’est juste une ressource : un modèle 3D, une animation, un son. Normalement, c’est quelque chose de plutôt “figé”.
Mais avec leur approche, ces assets deviennent presque des objets vivants.
On peut leur donner des comportements, les réutiliser dans plein de contextes différents, les adapter sans les recréer. Un même élément peut exister sous plusieurs formes selon la situation.
C’est un peu comme si tu avais une boîte de pièces, et qu’au lieu de construire un objet fixe, tu pouvais reconfigurer ces pièces en permanence pour raconter autre chose.
La carte du monde du jeu est un bon exemple de ça : elle réutilise énormément d’éléments déjà existants, mais les assemble différemment. Et au final, ça donne quelque chose de riche sans forcément repartir de zéro.
Tester, casser, recommencer
Là où ça devient vraiment intéressant, c’est sur la vitesse.
Avec ce système, ils peuvent tester des idées très rapidement. Modifier un comportement, ajuster une mécanique, essayer une variante… tout ça sans devoir replonger dans du code complexe.
Et ça change une chose fondamentale : on peut se permettre d’expérimenter davantage.
Je me dis que beaucoup de jeux doivent être limités non pas par le manque d’idées, mais par le coût de leur implémentation. Ici, ce coût est réduit, donc mécaniquement, la créativité peut prendre plus de place.
Mais tout ça a un prix
Évidemment, en creusant, on se rend compte que ce n’est pas une solution miracle.
Moins de code, ça veut aussi dire moins de contrôle fin. Les systèmes visuels sont puissants, mais ils peuvent vite devenir difficiles à maintenir si tout le monde y touche.
Il y a aussi une forme de dépendance à l’outil. Si tout repose sur Unreal et ses systèmes, tu es un peu enfermé dans cet écosystème.
Et puis, je me demande aussi ce que ça donne à long terme. Quand le projet grossit, quand les interactions se multiplient… est-ce que ça reste aussi fluide ou est-ce que ça devient un énorme plat de spaghetti version visuelle ?
Ce que ça raconte vraiment
Au fond, ce qui m’intéresse le plus dans cette histoire, ce n’est pas Blueprint en lui-même.
C’est la direction que ça suggère.
On voit la même chose un peu partout : des outils qui simplifient la technique, qui permettent à plus de profils de créer, qui déplacent le centre de gravité du “savoir coder” vers le “savoir concevoir”.
Le jeu vidéo, qui était historiquement très technique, commence peut-être à suivre la même trajectoire que le web avec le no-code.
Et du coup, ça me fait me poser une question assez simple, mais pas si anodine : si demain la barrière technique devient de plus en plus basse… est-ce que ce qui fera vraiment la différence, ce sera encore la maîtrise des outils ? Ou simplement la capacité à avoir de bonnes idées, et à les assembler intelligemment ?