Peut-on apprendre à programmer en jouant ?
DUPAYRAT Antoine, SCHUM Bastien, Pern Virgil
“Spécialiste de l’apprentissage automatique, vous créez des réseaux de neurones artificiels. Sauf que votre chat est plus doué ! À vous de résoudre des puzzles pour créer un système de traduction chat-humain. Faites fortune, achetez des habits pour chat, et découvrez comment le machine learning fonctionne vraiment !” Tel est le pitch du jeu while true: learn() (Luden.io, 2019).
Ce titre a toutes les apparences du jeu : des graphismes soignés, une narration entraînante. Mais aussi une courbe de progression finement élaborée, avec des mécaniques initialement faciles à prendre en main mais qui se complexifient au cours de l’expérience. Pas de doute, ça ressemble à un jeu vidéo. Et pourtant, à y jouer, le doute me saisit : est-ce que je m’amuse ou est-ce que je travaille ?
Jouer ou travailler, cela sonne comme une contradiction. Mais en jeu vidéo, on a toujours à faire à un programme. Le jeu vidéo ne serait-il pas le médium le plus naturel pour apprendre la programmation ? Est-ce qu’on ne joue pas toujours avec le programme, même à travers l’interface ? La programmation peut-elle être fun ? Ne serions-nous pas en train d’apprendre à programmer en jouant ? Mais peut-on généraliser à partir de while true: learn () ? Ce genre de titre n’est-il pas l’exception ? Les rapports des jeux à la programmation sont multiples. Explorons ce paysage, en nous demandant ce que l’on peut bien apprendre du programme par le jeu.
Le code devenu invisible
Du temps des premiers jeux vidéo, bien avant l’arrivée des consoles et des supports de stockage comme les cartouches ou les cd que l’on connaît si bien, il était impératif de programmer avant de jouer. Les jeux étaient distribués sous forme de code source, souvent en BASIC pour les ordinateurs personnels. Non seulement le joueur devait veiller à ne pas se tromper lors de sa retranscription, mais il pouvait également modifier le code s’il le voulait (modifications des variables, de l’environnement du jeu…). Le jeu constituait alors une passerelle évidente vers la programmation.
Mais au cours de l’histoire, le code source est devenu inaccessible. Il a été dissimulé pour des raisons de confort d’utilisation, mais aussi pour protéger les logiciels du piratage. Mais le programme a-t-il totalement disparu de l’expérience de jeu ? On peut se demander si jouer n’exige pas toujours de comprendre la logique du programme, en particulier quand il s’agit d’optimiser un score ou performance. Une pratique comme le speedrun est le parfait exemple de cette tendance à “lever le voile” sur le programme et à retrouver le code source par delà l’interface. Des logiciels comme le Cheat Engine ou les outils de Tool Assisted Speedrun (T.A.S.) aident à décortiquer la carcasse du jeu et à révéler ses organes, rendant ainsi crûment apparentes les mécaniques de programmations qui sont habituellement dissimulées sous d’épais habillages cosmétiques. La manipulation de mémoire requiert ainsi une connaissance pointue du fonctionnement du logiciel afin d’invoquer les objets voulus ou de provoquer un événement bien précis. De même, le rétro-engineering permet de décortiquer le code source, afin de mieux comprendre le fonctionnement d’un jeu.
Jouer à programmer
Certains jeux incluent cependant de la programmation de manière directe. C’est le cas de while true: learn(), qui n’est pas un exemple isolé. Des jeux comme TIS-100 (Zachtronics, 2015), Human Resource Machine (Tomorrow Corporation, 2015) ou Duskers (Misfits Attic, 2016) appartiennent à la même famille des “jeux de programmation”. TIS-100 propose de programmer dans une sorte de langage d’assembleur. Dans Duskers, nous devons écrire des lignes de commandes (similaires à ce que l’on taperait dans un invite de commande) afin de contrôler des drones. Ce jeu permet de se familiariser avec ce système d’invite de commande que l’on retrouve dans tout système d’exploitation, mais ne nous apprend pas à utiliser un invite de commande particulier. Dans Human Resource Machine, le joueur est amené à résoudre des problèmes en élaborant des algorithmes, afin de transformer certaines entrées numériques en outputs déterminés, en leur administrant le traitement approprié.
Si ces jeux permettent une forme d’apprentissage de la programmation, en habituant l’utilisateur à sa syntaxe et à sa logique, ils restent des jeux. Dans Human Resource Machine, la logique n’est pas présentée de manière abstraite, mais elle se présente comme de jolies boîtes à manipuler, afin de résoudre nos problèmes. Surtout, ces programmes gèrent la courbe de difficulté, en stimulant l’utilisateur avec des petits problèmes qui donnent envie d’être résolus, et en soignant l’information transmise au joueur pour ne jamais le noyer ni le laisser à sec.
Ces jeux ne se cachent pas d’utiliser des mécaniques qui se rapprochent de la programmation. Mais des mécaniques similaires ne sont-elles pas présentes dans nombre d’autres jeux, où l’utilisateur n’aura pas à se frotter à un langage de programmation ? On peut penser au cas de Minecraft, où un élément du jeu appelé la Redstone permet de réaliser des systèmes plus ou moins complexes dont l’utilisation n’est pas sans rappeler les connecteurs logiques utilisés en programmation. Le joueur peut ainsi selon ses envies créer des automates afin de faciliter certaines tâches, notamment la récolte de matériaux par exemple. Mais ce processus peut aller bien plus loin à tel point que certains utilisateurs chevronnés sont allés jusqu’à reproduire un processeur dans le jeu !
Programmer pour jouer
Parmi les joueurs, il y a ceux pour qui le jeu ne suffit pas dans sa forme actuelle. Ces joueurs aimeraient plus : créer leurs propres niveaux, leurs propres mondes. Pour ces joueurs, les éditeurs de niveaux sont nés, développant ainsi l’aspect communautaire de certains jeux, mais aussi permettant aux joueurs de laisser libre cours à leur créativité tout en jouant et en partageant avec d’autres joueurs. C’est ainsi que sont nés des jeux célèbres. Ainsi, DoTA, le moba (Mobile Battle Arena) de Valve (2013), avant de devenir l’un des jeux majeurs de la scène compétitive n’était au départ qu’un mod créé par la communauté de Warcraft 3 (2003).
Les éditeurs de niveaux sont attirants pour les joueurs par leur simplicité de prise en main. Mais ils peuvent à terme les amener à se pencher sur la programmation pour accéder à toute la puissance de l’outil, notamment pour le modding. L’édition de niveau étant plutôt orientée vers une prise en main aisée, les utilisateurs aguerris de ce genre d’outils peuvent se retrouver face à des limites qu’ils ne pourront pas contourner. Mais quand les règles vous restreignent, il suffit de les réécrire. Frustrés et poussés par l’envie de s’exprimer toujours un peu plus, ces utilisateurs ont une raison bien suffisante de vouloir apprendre la programmation. Ils peuvent par exemple se tourner vers les moteurs de jeux, outils leur permettant d’être plus libres dans leurs créations.
Si les grandes entreprises du monde du jeu vidéo utilisent leurs propres moteurs pour le développement de leurs jeux (Anvil pour Ubisoft, RedEngine pour CD Projekt Red), il existe des solutions accessibles à toute personne désirant se lancer dans la création d’un jeu. De Unity à Unreal Engine, en passant par Godot, Construct et autre CryEngine, il y en a pour tous les goûts et chacun peut y trouver son compte en fonction de ce qu’il désire réaliser.
Afin de rendre plus accessible la prise en main de ces logiciels, certains proposent des outils pour débutants pour contourner la programmation. Des modèles de boîtes logiques comme les « blueprint” de l’Unreal Engine remplacent la syntaxe usuelle et intimidante pour certains par une programmation sous forme de puzzle où il suffit de relier les boîtes entre elles pour créer des interactions. Nous retrouvons ici des visuels similaires aux jeux de programmation. Mais l’emploi d’une interface graphique n’est pas la seule manière de faciliter l’accès à la programmation : des tutoriels ciblés comme le propose Unity ou un langage logiciel proche de langages répandus et simples d’accès, comme le langage de Godot qui est dérivé du langage Python sont d’autres alternatives.
Jouer pour apprendre
Il existe enfin des jeux conçus directement pour que l’utilisateur puisse apprendre la programmation. Ici, on peut prendre l’exemple du jeu The elevator Saga (Magnus Wolffelt, 2014), dans lequel le but est de programmer un ascenseur en javascript afin que celui-ci puisse transporter plus ou moins de personnes. On peut s’interroger sur la différence avec ce que nous avons appelé les “jeux de programmation” comme while true learn(). Il nous semble que la différence ne provient finalement que d’une divergence entre les niveaux d’abstractions des mécaniques de programmation. Nous avons dans Duskers un certain niveau d’abstraction, par rapport à l’activité réelle de programmation, plus fort que dans The elevator Saga, mais moins fort que dans des jeux à valeur ludique telle que Human Resource Machine.
La frontière entre éducation et loisir n’est donc pas si nette. Nous pourrions considérer comme jeux éducatifs seulement les jeux apprenant des mécaniques directement applicables dans des cas réels, cependant Duskers reste un jeu considéré comme éducatif alors qu’il ne satisfait pas cette règle. Nous pouvons également remarquer qu’aucun jeu éducatif pour enfant ne serait alors éducatif. En effet, la quasi totalité des jeux éducatifs pour les enfants n’utilisent pas de mécaniques directement utilisables dans la vie réelle, mais des langages simplifiés comme Scratch (MIT, 2007). Plus qu’une réelle distinction entre jeux éducatifs et jeux non éducatifs, les différences résident dans le niveau d’abstraction des mécaniques mises en place, et aussi dans la volonté du créateur de mettre en avant son jeu comme éducatif ou ludique.
Au final, nous pouvons dire que tous les jeux vidéo nous permettent d’apprendre la programmation de manière plus ou moins abstraite. Ce niveau d’abstraction est une fonction linéaire de l’apprentissage de la programmation. Moins les logiques de programmation sont “cachées” dans le jeu, plus l’on apprendra, et plus on sera amenés à se tourner vers la programmation.
