Apprendre à jouer, ou jouer pour apprendre

22/03/2011 un commentaire

Dés de Mohenjo-Daro

Dés de Mohenjo-Daro, 2300 av. J.C.

Il est probable que les hommes préhistoriques jouaient déjà, certainement à des jeux d’adresse. Les premiers dés apparaissent à la fin du 3ème millénaire (voir ci-contre), et les premières références écrites à ces derniers chez les égyptiens. À l’époque, Thot est le dieu de l’écriture et des jeux, et ceux-ci semblent avoir eut une place importance dans divers cultes, notamment à travers la divination. Il n’existe pas de mot, ni en grec, ni en latin, permettant de désigner un « jouet ». Pourtant, Platon ou Quintilien déjà émettaient l’idée que l’on puisse apprendre à travers le jeu, mais seulement lorsque l’on est un enfant.

Selon Caillois, le jeu est une activité « libre, séparée, incertaine, improductive, réglée et fictive ». Dans de nombreux esprits, le jeu et le travail sont des activités antinomiques. Paradoxalement, il existe de nombreuses études pédagogiques visant à réconcilier le monde du jeu et celui de la scolarité, et de nombreuses méthodes d’apprentissage par le jeu. Au sein de l’armée, par exemple, les simulateurs de combats sont de plus en plus proches de jeux vidéo. De nombreuses grandes firmes commencent à s’ouvrir à ce milieu, au travers de ce que l’industrie appelle les « serious games ».

Alors, peut-on réellement placer le jeu d’un côté et le travail de l’autre ? D’un point de vue sociologique, il est certain que les deux univers ne provoquent pas les mêmes réactions. Le travail est rarement perçu comme une activité ludique, et il est même parfois mal vu de s’amuser de son activité professionnelle. La qualité intrinsèque d’un travail est quelquefois jugée à sa pénibilité. On travaille plus « fort » lorsque l’on souffre plus de ce travail. Le jeu, quant à lui, est bien souvent considéré comme une perte de temps, ou comme une activité réservée aux enfants. Même s’il tend à se démocratiser, il existe encore de nombreux milieux où jouer est perçu comme une forme de faiblesse.

Lors du DICE il y a maintenant un an, Jesse Schell a fait le portrait d’un monde où le jeu se serait infiltré partout. Où l’on gagnerait des points en se brossant les dents. Où l’on débloquerait des succès en conduisant de façon éco-responsable. Et où cela ne serait pas seulement amusant, mais également lucratif: un bon brosseur de dents payerait moins cher son assurance dentaire. Un bon conducteur bénéficierai de tarifs privilégiés sur son carburant. On y serait constamment comparé à ses amis, on y serait aussi analysés et décortiqués par des stratégies marketing pointues, localisées, ciblées, pertinentes.

Pourtant, le trait le plus évident du jeu est son opposition à la réalité. Le cœur du jeu, c’est « pour de faux ». C’est ce qui crée l’expérience ludique, et c’est ce qui crée la liberté du joueur : l’échec aussi est « pour de faux ». Le rôle que l’on joue dans un jeu est imaginé, ou au moins imaginaire. On peut être passionné par un jeu, il peut créer de puissantes émotions, mais il est innocent. Vaincre au jeu, ça n’est pas humilier l’adversaire. C’est triompher de ses règles. Le jeu est une parenthèse dans la réalité, et tout se qu’il s’y trouve est oublié lorsque l’on la referme.

Alors, pourquoi joue-t-on ? Pour apprendre. Le jeu crée un contexte favorable à l’apprentissage, puisqu’il se place dans une démarche parallèle à la réalité, dans laquelle on fait semblant. Qu’importe si je rate cent fois ce rocher de ma lance, tant que cela me permettra de toucher ce bison qui me nourrira. Qu’importe si je meurs lors de ce deathmatch, mes réflexes n’en seront que meilleurs.

Il me parait capital, lorsque l’on conçoit un système de jeu, de systématiquement se poser cette question : « qu’est-ce que va apprendre le joueur? » — car une fois qu’il aura appris, le système aura perdu tout intérêt à ses yeux.

Categories: Conception, Hors sujet Tags:

Interpréteur Brainf*** en C++

12/03/2010 6 commentaires

Connaissez-vous le Brainf***? C’est un langage de programmation ultra-minimaliste inventé par un compatriote helvétique dans le but avoué de torturer les neurones des programmeurs de tous poils.

J’ai profité de quelques instants libres pour travailler un peu mon C++ en écrivant un énième interpréteur pour ce langage. Il se veut standard, sans fioritures, et donc sans intérêt par rapport aux nombreuses alternatives déjà disponibles, mais après tout, c’était à but purement éducatif.

Fractale de Mandelbrot générée en Brainfuck
Fractale de Mandelbrot générée en Brainf***

Vous trouverez une solution Visual Studio 2008 contenant du C++ tout ce qu’il y a de plus ANSI à cette adresse. De plus, le script permettant de générer cette jolie fractale est disponible par ici. D’ailleurs, plein de scripts et d’outils liés à ce merveilleux langage sont disponibles sur ce site.

Categories: Code Tags: ,

GameLab ’09 : Slides

03/07/2009 7 commentaires

Hello,

As I said during my speech, you can now download the slides I used during the Gamelab 2009 for the session « Developing DOFUS 2.0 : Overcoming challenges in Flash/AS3 MMOG development ».

This presentation is about two of the many challenges we faced during the DOFUS 2.0 coding : the animation engine (« Tiphon ») and the tooling.

I had a pleasant time being a speaker at this conference ! It was very interesting, and Gijón is a beautiful city. Thank to all of you who woke up so early to attend the session.

Here is the download link !

I’m gonna have another speech at the GamesCom later this year. I’ll be happy to see some of you back there. Thank you again for your attendency, and I’ll see you next year (if not before) !



Bonjour !

Cette année, j’ai participé à la conférence Gamelab, en Espagne, en donnant une conférence sur le thème « Developing DOFUS 2.0 : Overcoming challenges in Flash/AS3 MMOG development » (« Développer DOFUS 2.0 : Dépasser les difficultés dans le développement de MMOG en Flash/AS3″).

Cette présentation portait sur deux des nombreux challenges que nous avons rencontré durant le développement de DOFUS 2.0 : le moteur d’animation (« Tiphon »), et les outils.

Vous pouvez retrouver les slides que j’ai utilisé durant cette présentation par ici.

Si vous faites partie de l’industrie des jeux vidéo, je vous recommande de passer à la conférence de l’an prochain. Les thèmes abordés sont intéressants, et Gijòn est une magnifique ville dans un très beau pays. D’ici là, je vais également participer à la GamesCom à Cologne en août. Cette conf’ promet d’être intéressante, n’hésitez pas a y faire un passage.

Categories: Code, Conception Tags:

Audit de code AS3/Flex automatisé

18/05/2009 Aucun commentaire

L’intégration continue et les méthodologies Agiles semblent de plus en plus intéresser Adobe ces dernières années. Après l’intégration officielle de FlexUnit dans les projets open-source managés par la firme, il semblerait qu’une prochaine étape importante soit sur le point d’être franchie.

En effet, en surveillant Confluence, le Wiki d’Adobe Open Source, une nouvelle catégorie, encore inaccessible par le listing des projets classique, a fait son apparition le 29 avril.

Il s’agit de Flex PMD !

Cet outil permet d’analyser du code source AS3/Flex pour y détecter des problèmes potentiels et des soucis de performance. Il s’agit, tout comme son homonyme PMD (pour Java), d’une solution d’audit et de monitoring de qualité de code automatisée.

Il s’agit là d’une grande avancée d’Adobe sur le chemin du développement flexible et des outils d’intégrations continue, que l’on ne peut que saluer. En plus, il semblerait que ce projet soit mis en place par Adobe France (Xavier Agnetti et Daniel Taborga ont tous deux contribués aux pages du Wiki).

Rien ne semble toutefois accessible au commun du mortel pour le moment, la page de téléchargement étant vide, et le SVN n’étant pas encore accessible en lecture. À surveiller !

[Edition: Le projet FNA sur Google Code contient ce qui semble être une pré-version de Flex PMD ici. ]

Categories: Code Tags:

Raté, essaie encore.

07/04/2009 3 commentaires
Fractale de Mandelbrot

Les probabilités sont la clé de voûte d’un nombre incalculable de jeux. Même dans les systèmes totalement déterministes où le hasard n’existe pas, et où les règles sont statiques, l’imprévu met presque toujours son nez. Je pense que l’on peut même dire que c’est la surprise qui constitue le plat de résistance de l’amusement. Comme jeu où tout est prévisible, il y a le morpion. Et ça n’est drôle que contre un adversaire qui ne sait pas jouer.

Et qui dit imprévu, dit probabilités. Il y a plusieurs façons de mettre en place un système non-déterministe. La plus commune est l’intervention d’un être humain. Nous sommes des merveilleuses créatures dotées d’un schéma de réflexion si complexe qu’il suffit presque que les règles laissent une toute petite place à l’imaginaire pour qu’un jeu à deux devienne stratégique. Presque, car encore faut-il qu’il n’y aie pas d’issue trop évidente.

Un exemple facile serait les Échecs. Une série de règles simples offrant un large éventail de combinaisons, un terrain de jeu limité, mais des adversaires imaginatifs. Et une quasi infinité de parties différentes.

Dans les MMORPGs, et plus encore dans les jeux solos, l’imprévu se manifeste souvent de façon artificielle, par le biais de la génération de nombre pseudo-aléatoires. Pour insuffler un peu de chaos dans les mécaniques trop bien rodées, on décide souvent de transformer nos valeurs en plages. Voir de faire intervenir l’imprévu encore plus directement, en évaluant de temps en temps des conditions aléatoires pour déterminer si le Sort est intervenu.

Un cas frappant est celui des coups critiques. Depuis D&D, on simule une action particulièrement glorieuse du joueur en la portant sur son niveau d’interaction : le jet de dés. Dans les jeux modernes, le principe de réussite critique est très souvent présent. Plus rarement celui d’échec critique, j’y reviens.

C’est une bonne chose : si tout est suffisamment aléatoire pour ne pas pouvoir monter une stratégie autour d’un événement imprévisible, et si l’événement imprévisible favorise un joueur. En revanche, à mon sens, c’est une très mauvaise chose lorsque l’imprévu désavantage le joueur alors qu’il affronte un ennemi virtuel (donc, pas un autre joueur).

N’oublions pas que l’intérêt de tout système de gameplay est de servir le plaisir du joueur. Être surpris de sa propre puissance, c’est fun. C’est encourageant. C’est positif. Être surpris de la puissance de l’adversaire, c’est parfois frustrant, mais lorsque l’adversaire est humain, le sentiment d’injustice est faible : ça aurait pu être nous.

Par contre, lorsqu’il s’agit d’un ordinateur, le sentiment d’être abusé est très rapidement atteint. Comme dans le cas d’une intelligence artificielle (ainsi que décrit dans un excellent article paru récemment sur Gamasutra), les adversaires virtuels sont très vite soupçonnés des plus viles intentions, et cela encore plus lorsqu’il s’agit de hasard, en étant eux même les gardiens.

Il y a pire encore : les ratés aléatoires. Il n’existe pas de situation où un joueur prenne du plaisir à rater son coup par hasard. Surtout pas lorsqu’il n’est pas l’instrument de ce hasard (s’il tire les dés, il peut au moins se dire que c’est un peu de sa faute). Et décidément jamais lorsque c’est l’adversaire qui détermine ce hasard. Félicitations, vous avez réuni toutes les conditions pour effectuer cette action, et … ah, non, vous échouez. Pas de chance. Très amusant.

C’est pourtant un système récurent dans les jeux vidéos. Un peu moins en jeux de plateau ou en jeu de rôle papiers (une question de survie pour le MJ, probablement). Oui, il est logique que si l’on peut réussir quelque chose particulièrement bien, l’on puisse aussi le merder particulièrement fort. Mais qui a envie de ça ?

J’irai encore plus loin. Dans des systèmes aléatoires positifs (comme les coups critiques), le hasard est bien souvent situé en avant-plan. Le joueur peut difficilement compter sur un coup critique, mais il souhaite en faire. Ce genre de sensation est également présente sur les systèmes de répartitions de butins (le loot, quoi). Un élément aléatoire, l’espoir du joueur.

En soit, il ne s’agit pas forcément d’un mauvais système, mais il a la particularité de devenir très vite frustrant. L’aléatoire à cela de particulier qu’il est impossible pour le joueur de le digérer lorsqu’il ne le sert pas. À partir du moment où un facteur chance existe, ce facteur devrait servir le joueur, et son absence, ne pas le désavantager. Et la plupart des systèmes aléatoires ne font pas cela.

Récemment, Blizzard a mis en place discrètement, lors de la sortie de Wrath of the Lich King, un système aléatoire pipé, dans le cadre de la mécanique de calcul du droprate des objets de quêtes dans son MMORPG World of Warcraft. C’est un système qu’ils avaient déjà utilisé, selon l’article, pour le calcul des coups critiques sur Warcraft 3.

Le principe est tout simple : plus on échoue, plus on a de chance de réussir. Jusqu’à, éventuellement, ne plus faire intervenir la chance. Je trouve ça absolument brillant. Et qu’on ne me sorte pas l’éternel couplet « Blizzard n’a rien inventé » ou « c’était juste évident » : ailleurs, ce n’est bien trop souvent pas le cas.

Une solution d’implémentation toute simple consiste à piper son aléatoire. Par exemple, lorsque l’on devrait tirer un nombre entre 0 et 99, on tire un nombre entre n et 99 où n est le nombre d’échecs de suite précédent ce jet. Un échec étant un jet qui ne favorise pas le joueur.

Avec cette solution, on augmente le nombre de réussites totales sur un grand nombre de jets de 1%. Par contre, on diminue le nombre d’échecs d’affilés d’environ 70% : au lieu de faire en moyenne 290 échecs de suite sur 1000 jets, on n’en fait plus que 95 en moyenne. Par contre, le nombre de réussites de suite ne change pas : environ 1. En réalité, il évolue selon la même courbe que le nombre d’échecs de suite, mais les réussites étant bien plus rares que les échecs, l’impact de l’évolution est beaucoup plus réduit.

Ce genre de système « mémorisant » la malchance de joueur pour la minimiser représente à mon sens une énorme évolution dans les systèmes aléatoire, car il permet de palier à leur principal défaut : le sentiment d’injustice.

Un exemple de calcul de probabilités est disponible ici, en Python.

Categories: Conception Tags: , ,