Deuxième expérimentation

Cette deuxième expérimentation a pour objectif de mettre en application le jeu dans un contexte d’enseignement différent de manière à vérifier sa portabilité. Une attention particulière est portée à l’observation de l’enseignant de manière à déterminer l’impact de l’introduction du jeu dans ses activités.

5.2.1

Contexte de l’expérimentation

Cette expérimentation a été réalisée dans le cadre d’un soutien pour les étudiants de l’uni- versité Paul Sabatier (Toulouse III) inscrits en première année de licence STS (Science, Techno- logies, Santé) qui suivent au second semestre la majeure IMM (Informatique, Mathématiques, Mécanique). Ce soutien était organisé de la manière suivante : toutes les deux séances de travaux dirigés (TD), une évaluation (sous la forme de QCM) est distribuée aux étudiants pour jauger la progression de leur apprentissage par rapport à l’évaluation précédente. Les étudiants qui n’atteignent pas la moyenne, sont invités à participer au soutien. Les évaluations proposées sont gérées par l’équipe pédagogique de la formation et n’ont aucun lien avec le jeu sérieux.

Le soutien n’étant pas obligatoire, peu d’étudiants font la démarche de venir aux séances. Dans ce cadre, deux types de soutien leur ont été proposés : un premier classique et un second avec le jeu sérieux.

Pour respecter le contexte d’enseignement utilisé au second semestre de cette formation, les étudiants manipulent le jeu dans un environnement Linux (Mandriva 2008) à l’aide de l’inter- face en langage C et de l’éditeur de texte « Kate ». À l’image de la première expérimentation, la campagne n’est composé que de cinq missions à savoir les missions 1, 3, 4, 6 et 7 présentées page 106.

5.2.2

Intégration du jeu sérieux dans la formation

Dans cette expérimentation, le jeu est intégré à la formation et doit donc s’adapter au calen- drier des enseignements présentés dans le tableau 5.3. Le premier TP a pour objectif de familia- riser les étudiants avec le contenu d’un ordinateur en leur permettant de démonter entièrement une unité centrale (processeur, carte mère, disque dur, mémoire vive, etc.).

Le deuxième TP se concentre sur le système Linux avec la présentation des commandes basiques du shell. La première séance de soutien prend effet à cet instant alors que les étu-

5.2. Deuxième expérimentation

TABLE5.3 – Calendrier des enseignements du L1S2 de l’Université Paul Sabatier.

Semaine TD QCM TP Soutien

...

3 TD1 (Langage algorith-

mique)

4 TD2 (Tableaux de situations) QCM1 TP1 (Architecture)

5 TD3 (Introduction au C) TP2 (Environnement multi-

fenêtre et shell Linux) S1 6 TD4 (Raffinage et sous-

programmes) QCM2

TP3 (Environnement d’exé- cution, compilation et struc- tures de contrôle) S2 7 TD5 (Sous-programmes et tableaux) TP4 (Tableaux de situation et débogage) S3 8 TD6 (Sous-programmes et types simples) QCM3 TP5 (sous-programmes, tableaux et débogage) S4 9 TD7 (Sous-programmes,

types complexes et raffinage) TP6 (Projet) S5

10 TD8 (Développement d’un

cas complexe et raffinage) QCM4 TP7 (Projet) S6

11 TD9 (Recherches et tri

basique) TP8 (Projet) S7

12 TP9 (Projet) S8

diants n’ont pas encore eu de travaux pratiques de programmation. Par conséquent, cette pre- mière séance se consacre à la présentation de l’univers du jeu à travers la réalisation d’une mini compétition. Cette phase correspond à l’étape 1 de l’organisation des enseignements (voir tableau 5.1 page 126) de la première expérimentation. À cette occasion les étudiants manipulent l’environnement Linux et réinvestissent les compétences acquises lors du deuxième TP.

Le troisième TP introduit l’environnement d’exécution et de compilation ainsi que la syn- taxe en langage C des structures de contrôle. Les étudiants ont donc simplement eu une intro- duction au langage C avant la deuxième séance de soutien. D’autre part, s’ils participent au soutien, ils ont théoriquement eu quelques difficultés lors des premières séances de travaux dirigés. Par conséquent, cette deuxième séance de soutien propose de résoudre les premières missions de la campagne à l’aide du langage algorithmique vu en TD. Une surcouche à l’inter- face C de l’API Prog&Play a donc été créée (« PP_ALGO.h » - voir annexe D). Elle définit les mots clés du langage algorithmique ainsi que les opérateurs utilisables pour interagir avec le

jeu Kernel Panic. Les mots clés de ce langage algorithmique sont les suivants : Debut, Fin, Si, Alors, Sinon, FinSi, TantQue, Faire, FinTantQue, Et, Ou, Non, VRAI et FAUX. Les opérateurs disponibles sont présentés dans le tableau 5.4.

TABLE 5.4 – Opérateurs disponibles pour interagir avec le jeu Kernel Panic en langage algo- rithmique.

Opérateur Description

OUVRIR_JEU Ouvre la connexion avec le jeu. Cet opérateur doit être appelé avant tout autre opérateur.

FERMER_JEU

Ferme la connexion avec le jeu. Cet opérateur doit impérativement être le dernier opérateur à être appelé avant la fin du programme.

current_unit Représente l’unité en cours d’utilisation.

PREMIERE_UNITE initialise l’unité courante à la première unité contrôlée par le joueur.

UNITE_SUIVANTE Fait passer l’unité courante à l’unité suivante con- trôlée par le joueur.

DERNIERE_UNITE Fournit la dernière unité contrôlable par le joueur.

EST_UN_BIT Indique VRAI si l’unité courante est un BIT.

EST_UN_BYTE Indique VRAI si l’unité courante est un BYTE.

EST_UN_ASSEMBLEUR Indique VRAI si l’unité courante est un ASSEM- BLEUR.

DEPLACER_VERS(xCible, yCible) Donne l’ordre à l’unité courante de se déplacer vers les coordonnées indiquées.

Grâce à ce langage algorithmique, les étudiants peuvent réaliser les trois premières missions sur les cinq que contenait la campagne lors de cette expérimentation. L’utilisation du langage algorithmique étudié en TD, pour cette séance de soutien, permet aux étudiants de formuler une première solution aux problèmes posés dans les missions et d’observer les résultats dans le contexte du jeu.

Les figures 5.6 et 5.7 présentent les solutions respectives en langage algorithmique des missions 1 et 3 de la campagne telle qu’elle était proposée au moment de l’expérimentation. Pour simplifier la compilation des programmes écrit, un Makefile est fourni aux étudiants et quelques informations sont données sur l’utilisation de la commande make.

Sur les séances suivantes, les étudiants transforment leurs solutions algorithmiques en des programmes écrits en langage C. De cette manière, ils mettent en application les concepts de décomposition de problèmes et de raffinage successif.

5.2. Deuxième expérimentation # i n c l u d e "PP_ALGO . h " /∗ M i s s i o n 1 : d e p l a c e r l ’ u n i q u e u n i t e a l a p o s i t i o n ( 1 9 8 3 , 1 2 7 9 ) p o u r t e n t e r de r e t r o u v e r l ’OCTET p e r d u . ∗ / Debut OUVRIR_JEU ; PREMIERE_UNITE ; DEPLACER_VERS ( 1 9 8 3 , 1 2 7 9 ) ; FERMER_JEU ; Fin

FIGURE 5.6 – Solution de la pre- mière mission en langage algorith- mique. # i n c l u d e "PP_ALGO . h " /∗ M i s s i o n 3 : d e p l a c e r t o u t e v o t r e armee a l a r e n c o n t r e de l ’ASSEMBLEUR ∗ / Debut OUVRIR_JEU ; PREMIERE_UNITE ; TantQue c u r r e n t _ u n i t ! = DERNIERE_UNITE F a i r e DEPLACER_VERS ( 2 5 6 , 1 0 2 4 ) ; UNITE_SUIVANTE ; FinTantQue DEPLACER_VERS ( 2 5 6 , 1 0 2 4 ) ; FERMER_JEU ; Fin

FIGURE 5.7 – Solution de la troisième mission en lan- gage algorithmique.

En raison de facteurs externes à l’expérimentation (mouvement social étudiant avec blocage de bâtiments d’enseignement), la conduite des dernières séances s’est trouvé fortement pertur- bée. Toutefois, il a tout de même été possible de réaliser les observations souhaitées sur les activités de l’enseignant.

5.2.3

Résultats

Pour étudier l’impact du jeu sur les activités de l’enseignant, la troisième séance de soutien a été filmée. Le visionnage de cette vidéo a permis d’identifier trois activités principales dont celles dédiées : au jeu - « utilisabilité du jeu » ; au savoir à enseigner - « contenu d’apprentis- sages » ; et aux autres tâches. Le temps utilisé par l’enseignant pour chacune de ces activités, est détaillé dans le tableau 5.5.

TABLE5.5 – Durée des activités pour une séance d’enseignement.

Activités Durée

Utilisabilité du jeu 22 min 13 s Contenu d’apprentissages 1 h 3 min 42 s

L’activité « utilisabilité du jeu » concerne des explications sur le contrôle du jeu (comment lancer le jeu ? Comment déplacer la caméra ?) et sur l’interaction entre les programmes des étudiants et le jeu (comment accéder ou commander une unité ? Comment vérifier si le pro- gramme est correct ?). L’activité « contenu d’apprentissages » concerne les explications sur les obstacles de programmation tels que les variables (type, affectation, enregistrement), les fonc- tions (appel, passage de paramètres), ou les structures de contrôle (conditionnelles, itératives). L’activité « autres tâches » concerne les tâches administratives (accueil des étudiants, appel), des explications sur l’utilisation du système d’exploitation, etc.

Au regard des activités énoncées précédemment, le cœur de l’enseignement repose sur le contenu de l’apprentissage. Cette répartition est opportune, car, les explications liées au jeu ne doivent pas empiéter de manière excessive sur les activités de l’enseignant. D’autre part, le temps consacré à l’utilisabilité du jeu diminue au fur et à mesure que les étudiants deviennent experts dans la manipulation du jeu. Certaines interventions de l’enseignant sont comptabilisées dans différentes activités ce qui explique pourquoi la somme des durées de chaque activité est supérieure à la durée d’une séance (deux heures).

Toutefois, l’activité « Utilisabilité du jeu » représente une part non négligeable des expli- cations notamment lors des premières séances. Une question se pose alors sur la capacité d’un enseignant novice en jeu de STR à utiliser un tel outil dans ses enseignements. D’autant plus que ces explications contribuent fortement à satisfaire le second niveau de la pyramide des be- soins. Une réponse à cette question peut venir directement des étudiants. En effet, comme le montre la dernière enquête réalisée (voir section 4.1.1), les jeux de STR sont appréciés par 36% des joueurs soit 27% de la population totale. Par conséquent, un certain nombre d’étudiants maîtrisera rapidement le jeu. Une solution consiste alors à inciter ces étudiants à aider leurs camarades à mieux contrôler l’environnement de jeu. Cette solution permet en outre d’initier la communication entre les étudiants et de favoriser l’entraide. Crenshaw et al. [CCMT08] no- tent à ce propos que le manque de communication et d’échange entre les étudiants est un des facteurs favorisant le désintéressement des étudiants pour l’informatique.

Synthèse de la deuxième expérimentation

Malgré les évènements qui ont perturbés les enseignements, cette itération a permis dans un premier temps de valider la portabilité du jeu sérieux dans un contexte différent de la première expérimentation. En effet, tout en respectant l’organisation des enseignements, il a été possible