Les nouvelles technologies pour l’enseignement des mathématiques
Intégration des TICE dans l’enseignement des mathématiques

MathémaTICE, première revue en ligne destinée à promouvoir les TICE à travers l’enseignement des mathématiques.

Développer un jeu au collège à l’aide du moteur PACMAN
Article mis en ligne le 13 mai 2016
dernière modification le 10 juillet 2016

par Jean-Philippe Vanroyen

PLAN

INTRODUCTION

A) La réforme et l’arrivée de l’algorithmique et de la programmation au collège

  • 1) Pourquoi ?
  • 2) Comment ?

B) Présentation du moteur « PACMAN »

  • 1) Qu’est ce qu’un moteur ?
  • 2) Le cas particulier du moteur PACMAN.
  • 3) Les différents modules du moteur PACMAN.

C) Mise en œuvre en classe

  • 1) Compte rendu de l’expérimentation en classe
  • 2) Mise en œuvre envisagée l’année prochaine

CONCLUSION


Introduction

Travailler l’algorithmique et la programmation au sein d’un projet est intéressant à plus d’un titre : travaux de groupe, autonomie, responsabilité, recherche, décomposition d’un problème en sous problèmes plus simples, auto-correction…

Mais comment procéder concrètement avec des élèves qui ne connaissent rien à la programmation, à l’algorithmique et encore moins aux logiciels ?
C’est la question que je me suis posée, comme de nombreux collègues.

Quand j’ai découvert Scratch, après avoir étudié des exemples du site https://scratch.mit.edu/ et développé quelques applications simples, j’ai commencé par développer un jeu de labyrinthe. Puis j’ai programmé d’autres variantes. Rapidement je me suis retrouvé à faire tout le temps à peu près la même chose. C’est là que l’idée du moteur m’est venue : un moteur à la fois puissant et souple, permettant de développer des jeux de ce type, du très simple au très complexe.

Mon objectif a été alors de voir dans quelle mesure ce moteur, cette idée de moteur, pouvait être utilisée pour accompagner les élèves dans le développement de leur projet (j’ai eu l’occasion de présenter cette idée à Amiens le 15 janvier 2016, lors d’une journée nationale sur l’algorithmique et la réforme du collège).

Pour cela, je n’ai disposé que de trois séances avec des élèves de quatrième, c’est donc très peu. Malgré tout, cette expérimentation me semble prometteuse et riche d’enseignements. Elle m’a donné une idée assez précise sur la façon dont je pourrais organiser cette conduite de projet l’année prochaine.
C’est ce que je vais tâcher d’expliquer dans cet article.

Retour au sommaire

A) La réforme et l’arrivée de l’algorithmique et la programmation au collège

Il me semble nécessaire de rappeler quelques aspects importants concernant l’arrivée de l’algorithmique dans les nouveaux programmes.

1) Pourquoi ?

L’algorithmique permet de développer des compétences de décomposition de tâches complexes, de généralisation et d’abstraction, compétences recouvrant en partie les six compétences visées en mathématiques.

Les activités « débranchées » (activités algorithmiques sur papier) permettent de travailler sur des thèmes importants du monde numérique : notion d’algorithme, cryptage et compression de données, codage et tri des données, automates et arbres, algorithmes de stratégies gagnantes... Ces activités fournissent aux élèves quelques clefs leur permettant de mieux comprendre certains enjeux importants du monde numérique actuel (pensez par exemple à la polémique fbi-apple concernant le débloquage d’un iphone).

Le développement d’un programme se prête bien à la pédagogie de projet. Il stimule la créativité et l’autonomie. L’interdisciplinarité, ajoutant du sens au développement, est facilitée.

La notion d’erreur, et plus largement l’essai-erreur, a un statut particulier. Lors d’un développement dans Scratch, la machine ne signale jamais une erreur (à moins d’avoir développé un code spécifique les signalant) puisqu’elle fait simplement ce qu’on lui demande de faire en appliquant l’algorithme saisi. C‘est donc l’élève qui, de lui même, constate qu’il s’est trompé et qui, de lui même, tâche de se corriger immédiatement. On peut parier que ce comportement déteigne dans une certaine mesure sur les démarches mises en œuvre lors de la recherche d’un problème en mathématiques, ou ailleurs d’ailleurs.

2) Comment ?

L’attendu de fin de cycle est : « Écrire, mettre au point et exécuter un programme simple. » C’est donc vague, mais en même temps très concret puisque cela exige de la part de l’élève de nombreuses nouvelles capacités.

Je pense que les activités débranchées doivent couvrir tout le cycle 4, en réservant à la classe de troisième les thèmes les plus délicats. Je distingue assez nettement les activités débranchées de la programmation sur machine mais il y a des exceptions puisqu’un travail en classe sur papier peut être suivi de la programmation correspondante en salle informatique. Attention toutefois. S’il est possible par exemple d’expliquer sur papier un algorithme tri, en écrivant l’algorithme en langage naturel, son implémentation dans Scratch est souvent hors de portée.

En ce qui concerne les techniques algorithmiques, voici quelques remarques qui n’engagent que moi. D’une manière générale, ce serait à mon avis une erreur de trop cloisonner, par exemple en réservant exclusivement les variables aux classes de 4eme et 3eme, ou en réservant les boucles à une classe donnée.

Particulièrement, les variables gagnent à être introduites dès la cinquième, en commençant toutefois par des variables globales comme un score ou la variable réponse prédéfinie dans Scratch. Progressivement, les autres variables (variables locales de boucle par exemple) pourraient apparaître à partir de la quatrième.

Il en est de même des structures de contrôle. À la fin du cycle je traiterais par exemple une imbrication de structure de contrôles avec variables alors qu’en début de cycle, les élèves se contenteraient de répéter un nombre constant de fois plusieurs tâches simples.

De la même manière, la gestion des événements doit, toujours selon moi, être présentée immédiatement. Mais cette gestion pourra devenir progressivement plus complexe avec les années.

Enfin je présenterais certaines notions délicates, comme les événements personnalisés, les variables locales et le clonage (qui a été sorti du programme dans la dernière version) en dernière année du cycle.

J’ai donc suivi les recommandations officielles et ai choisi le logiciel Scratch, en fidèle exécutant. Il reste que je n’ai pas attendu les recommandations officielles pour apprécier ce logiciel. A la fois ludique, stable, visuel et puissant, il me semble effectivement être un très bon outil pour l’enseignement de l’algorithmique au collège.
Ce n’est pas le seul c’est vrai, mais il faut bien en choisir un.

Il y a plusieurs aspects de Scratch je j’apprécie beaucoup (et certains qui m’agacent et dont j’attends les améliorations dans les versions ultérieures). Le fait que la communauté scratchienne soit très importante en est un : l’enseignant « chercheur et développeur de ressources » trouvera facilement de très nombreux exemples couvrant des thèmes très variés et parfois surprenants. De plus, malgré tous mes efforts, je ne suis pas parvenu à faire « planter » Scratch (pardon pour l’expression). C’est vraiment appréciable car cette solidité sécurise les manipulations des élèves. Comment ferions-nous sinon ? Quand je pense à la susceptibilité de certains langages, l’écart est vraiment impressionnant.

En ce qui concerne la mise en œuvre pédagogique, je choisis de diversifier : des travaux de groupes certes, dans le cadre de projets par exemple, mais également des travaux individuels en salle informatique ou à la maison. De la programmation sur machine certes, mais également des séances de travail sur papier et sur des thèmes variés de notre monde numérique.

Par rapport à l’article présent, le travail sur le moteur pacman permet évidemment de traiter de nombreux aspects présentés ci-dessus. La question fondamentale : « Comment concrètement puis-je faire cela en classe ? » reste ouverte et il faudra du temps pour distinguer les pratiques prometteuses et efficientes des autres.

Il semble toutefois que le développement d’un projet apparaisse comme une bonne façon de procéder, même si cela ne doit sans doute pas être la seule, ni sans doute qu’elle doive à elle seule, remplir tous les objectifs cités plus hauts.

Je profite de ce paragraphe pour rappeler le lien vers les documents d’accompagnement de l’algorithmique :

http://cache.media.eduscol.education.fr/file/Algorithmique_et_programmation/67/9/RA16_C4_MATH_algorithmique_et_programmation_N.D_551679.pdf

C’est un document intéressant qui mérite d’être lu.

Enfin, je me permets un conseil pour les enseignants qui ne connaissent pas Scratch. Commencez par étudier des exemples simples (une seul lutin, peu de code) et re-programmez ces exemples. Cherchez d’autres exemples de programmes sur le web (il y en a des milliers) et étudiez leur fonctionnement. Rapidement, vous commencerez par les modifier, puis vous créerez vos programmes personnels. En ce qui concerne la programmation, rien de tel que de chercher à programmer soi-même pour progresser.


Retour au sommaire

B) Présentation du moteur « PACMAN »

1) Qu’est ce qu’un moteur ?

Si on considère les jeux de type « shoot’em up » (https://fr.wikipedia.org/wiki/Shoot_%27em_up) comme celui-ci :

on peut comprendre que le développement complet d’un jeu de ce type permet au programmeur d’acquérir de nombreuses compétences, dont beaucoup seront spécifiques à cette classe de jeux. Si il développe à l’avenir un second, puis un troisième jeu, alors il se rendra compte très vite que certaines des techniques utilisées sont analogues, comme par exemple la délicate question de la gestion des collisions. Il se dégagera donc une technologie générale pour cette classe de jeu ; une communauté naîtra, commencera à échanger, et la technologie progressera alors sans cesse.

Face à ce constat, et afin de ne pas tout reprogrammer à chaque fois, le développeur (ou cette communauté) tâchera de développer des modules indépendants qui pourront être ré-utilisés dans tous les jeux de cette catégorie.

Le moteur d’un tel jeu est constitué de l’ensemble des modules qui apparaissent de manière récurrente. Un moteur ici n’est donc pas pour moi le cœur du jeu, comme le serait par exemple une fonction d’évaluation d’un jeu d’échecs associée à un algorithme min-max. Après avoir programmé tous les modules d’un ensemble de jeux de type « stoot’em up », on constatera nécessairement que certains modules sont souvent présents : ils constituent le moteur, du moins c’est comme cela que je le définis empiriquement.

2) Le cas particulier du moteur PACMAN

Le pacman est l’archétype d’une classe de jeu très spécifique :

Nous avons un « lutin » (je privilégie à présent le vocabulaire scratchien) que l’on pilote afin de remplir un objectif, objectif contrarié par la présence d’obstacles divers.
Dans ce type de jeu, la partie est gagnée quand l’objectif est atteint (dans le pacman il faut manger tous les points), et avec des contraintes optionnelles supplémentaires diverses comme le respect du temps imparti, la récupération obligatoire de clefs spéciales etc.

Les obstacles peuvent être de nature différente :

  • obstacles fixes (murs)
  • obstacles mobiles dont les modalités de déplacement peuvent être très variés.

Voici quelques exemples (parmi d’autres !) qui relèvent de ce moteur :

JEU 1

https://scratch.mit.edu/projects/108610231/

Un jeu de pacman plutôt basique, mais qui fonctionne. Il est sans doute un peu difficile pour les élèves de collège à moins qu’on ne les aide sérieusement pour un point particulier : le module permettant le déplacement aléatoire des ennemis croix bleues dans le labyrinthe. Mais cela mis à part, cet exemple suffit pour développer autant de niveaux que l’on veut du jeu pacman, avec l’ajout éventuel de variantes comme le temps, le score, la gestion de la vitesse, le son, le pacman qui devient glouton pendant quelques secondes... Autant d’ajouts que l’on retrouvera dans d’autres jeux de ce type, et qui donnent du sens à cette idée de moteur.

JEU 2

https://scratch.mit.edu/projects/108610308/

Le lutin perroquet doit atteindre le papillon, c’est à dire la sortie de labyrinthe. S’il touche un mur, on le retourne à la case départ. J’ai ajouté deux obstacles décrivant des aller-retours cycliques mais ils sont optionnels. C’est une variante plutôt abordable et constitue une bonne idée de projet pour les élèves. Elle permet de mettre en place de nombreuses notions très importantes et se prête très bien aux améliorations progressives du jeu.

JEU 3

https://scratch.mit.edu/projects/108610326/

Ici, le lutin Arrow doit échapper pensant un temps donné à la poursuite de la chauve-souris (la barre espace permet de déplacer le lutin). Cette dernière accélère à un moment donné et il est nécessaire pour s’en sortir de récupérer également des clefs afin d’accroître notre vitesse de déplacement. La version basique est très simple à programmer. La possibilité d’accroître progressivement la vitesse du poursuivant, ou la vitesse de notre lutin, est riche d’un point de vue algorithmique.

JEU 4

https://scratch.mit.edu/projects/108611042/

Un jeu plus complexe que les deux précédents puisqu’on y trouve les différents types d’obstacles mobiles. La chauve-souris poursuit le papillon de gauche, notre lutin que l’on pilote au clavier, sans pour autant traverser les murs de couleur grise. Les quatre petites chauve-souris se déplacent aléatoirement, selon des paramétrages différents. Enfin les deux fusées décrivent chacune un cycle. Le papillon de gauche doit libérer son amie, comme il se doit, en prenant soin de récupérer auparavant les ballons.

Avant de poursuivre, je dépose ici le didacticiel complet décrivant les différentes phases de développement de ce jeu.

Didacticiel
Détails des modules du moteur PACMAN pour les enseignants.

C’est un tutoriel détaillé de 14 pages. Il pourra éventuellement vous être utile.

Je ne donne pas un tel document aux élèves, je procède différemment, comme vous le lirez plus loin.

Certes, ces jeux se ressemblent un peu mais le « game play » peut être très différent.

Par exemple si on considère le jeu 2, il est possible de proposer un labyrinthe beaucoup plus complexe où l’objectif serait de découvrir le chemin menant à la sortie en un temps le plus court possible.

Le jeu 3 est beaucoup plus de type « arcade » puisqu’il n’y a aucun obstacle fixe, mais seulement un poursuivant qu’il faut absolument éviter et dont la vitesse augmente.

Cependant les techniques mises en œuvre pour leur programmation sont analogues même si certains modules du jeu 4 sont absents dans les jeux 2 et 3.

En tout cas, les différents modules intervenant dans ces exemples constituent donc ce que j’appelle le « moteur pacman », tout simplement parce que nous retrouverons ces modules très souvent dans les jeux de la classe « pacman ».

Le moteur ainsi défini n’est cependant pas complet puisqu’il est probable que d’autres jeux de ce type nécessiteront souvent un autre module absent des exemples ci-dessus. Heureusement, nous pourrons toujours ajouter si nécessaire ce module au moteur.

Quand j’ai réfléchi à des exemples de jeu de type pacman, je me suis longuement posé la question suivante : faut-il ajouter un module de tir ? J’y ai finalement renoncé pour deux raisons. La première est qu’un tel ajout élargirait beaucoup trop la classe de ce type de jeu puisqu’elle inclurait par exemple les jeux de tirs (« shoot’em up » ). La seconde est que la programmation d’un tel module dans Scratch est très délicate. Pour y parvenir, j’ai utilisé le clonage à un niveau non basique, qui me semble trop difficile pour les élèves.

Pour les lecteurs ou lectrices intéressé(e)s par ce point, je mets cependant un lien ici illustrant la technique utilisée :
https://scratch.mit.edu/projects/93777445/#editor
Attention toutefois car il demande une bonne maîtrise de Scratch et je ne voudrais surtout pas vous décourager ! Si d’aventure il y a des questions sur ce projet, j’y répondrai volontiers.

3) Les différents modules du moteur PACMAN

Les modules suivants se sont dégagés naturellement :

Module 1 Création du lutin que l’on pilote et du lutin cible.
Module 2 Création de l’arrière-plan et des éventuels obstacles fixes (les murs par exemple).
Module 3 Initialisation du jeu. Emplacement initial des lutins et initialisation des variables.
Module 4 Gestionnaire clavier, gestion optionnelle des costumes, gestion des obstacles (un lutin ne peut pas traverser un mur).
Module 5 Définition de la condition principale de gain de la partie.
Module 6 Définition des conditions supplémentaires et optionnelles de gain de la partie (temps limite, nombre de vies épuisées...)
Module 7 La variable score, qui peut dépendre du chronomètre, des collisions. Elle peut nécessiter la création d’une variable supplémentaire « malus » s’incrémentant quand des obstacles sont touchés.
Module 8 Récupération éventuelle de clefs. Cette récupération peut être envisagée comme optionnelle ou non.
Module 9 Création et gestion des lutins obstacles mobiles qui sont de trois types : déplacement aléatoire, déplacement de type circuit, déplacement de type poursuite.
Module 10 Gestion des collisions avec les obstacles mobiles.
Module 11 Création optionnelle d’une variable vitesse (modifiant le déplacement des lutins) et qui peut dépendre des clefs collectées, de touches du clavier, des collisions, du chronomètre...
Module 12 Les sons pour une musique de fond, le déplacement de notre lutin, les collisions...
Module 13 Écrans de démarrage et de finalisation.

Ce découpage en modules, qui reste à affiner, et qui est sans doute discutable, présente plusieurs avantages. Tout d’abord, il correspond à une réalité du monde de la programmation puisque le développement d’un projet réclame un cahier des charges réfléchi comportant si possible des modules indépendants et rendant possible le travail en équipe ainsi que des améliorations ultérieures éventuelles.

Ensuite il clarifie bien des choses. Quand on considère un jeu de type pacman donné, ce découpage aide à distinguer rapidement les différents modules nécessaires et en conséquence à exclure un jeu donné si un des modules utilisés semble trop complexe pour les élèves.

Enfin, ce découpage revient à décomposer un problème vaste (la programmation d’un jeu) en plusieurs sous problèmes permettant la résolution du problème initial, ce qui rejoint la démarche analogue utilisée pour de nombreux problèmes de mathématiques.

Retour au sommaire

C) Mise en œuvre en classe

1) Compte rendu de l’expérimentation en classe (2015-2016)

Première séance

En premier lieu, il est évidemment nécessaire que les élèves aient compris certaines bases du logiciel Scratch. Cette année, lors de la première séance dédiée à ce projet, j’ai donc présenté Scratch en classe entière (une quatrième) pendant un quart d’heure : interface, principe du lutin, arrière-plan. Puis nous nous sommes rendus en salle informatique où les élèves ont travaillé sur les deux activités suivantes :

Déplacements : activité 1
Document élève
Déplacements : activité 2
Document élève

C’est selon moi une des premières activités à faire faire aux élèves car elle permet de comprendre le système de coordonnées et travailler un premier type de déplacement dans Scratch. Presque tous les groupes (les élèves travaillaient en binôme) sont parvenus au bout de cette activité. Notons un fait intéressant : je n’ai jamais donné la solution (c’est simple, il suffit d’expliquer pourquoi leur programme ne donne pas le résultat demandé), ce sont les élèves qui, à l’aide de nombreux essais parfois, sont parvenus à la solution, parfois non sans mal d’ailleurs.

Certains groupes ont eu le temps de travailler sur l’activité 2.

Deuxième séance

Lors de cette séance, pendant une dizaine de minutes, j’ai repris les activité 1 et 2, puis j’ai présenté le second type de déplacement dans Scratch avancer de et tourner de, c’est à dire les déplacements relatifs, que certains binômes avaient donc découvert à la séance précédente. J’ai également expliqué, toujours dans ma salle, le principe d’un événement, en commençant par l’événement Quand drapeau cliqué, que chacun avait donc déjà utilisé sans savoir qu’il s’agissait d’un événement, puis j’ai donné un exemple où le lutin avançait de 100 quand je cliquais sur une touche particulière. Cette présentation, et les échanges correspondants, ont permis d’introduire du vocabulaire comme « événement » , « déplacement relatif », « écouteur », etc.

Enfin j’ai montré comment on changeait le fond d’écran et comment on créait un mur sur ce dernier. Et là j’ai insisté lourdement pour avoir l’attention aiguisée de chacun. Sans cela, je sais que je vais passer mon temps à courir dans la salle informatique pour construire des murs...

En salle informatique, les groupes ont ensuite travaillé sur les activités suivantes :

Déplacements : activité 3
Document élève
Labyrinthe
Document élève

La première activité explique comment déplacer un lutin au clavier. On en profite pour dessiner des figures et pour ajouter des événements permettant de changer la couleur ou l’épaisseur du crayon, ou encore de relever ou baisser le crayon.

La seconde activité propose de développer un jeu de labyrinthe dans sa version de base. Cette activité met donc en place certains concepts très importants comme créer un obstacle ou comment gagner la partie.

J’ai bien entendu parfois eu droit à des labyrinthes étranges et à des lutins saugrenus, mais l’essentiel a été fait, pour la majorité des groupes.

Cette séance a donc permis aux élèves de développer, ou de commencer à développer, un jeu particulier du moteur pacman, sans jamais bien évidemment que je n’évoque à ce stade ce moteur. Certains groupes n’ont pas eu le temps de finir leur programme. Je leur ai dit qu’ils poursuivront leur travail à la séance suivante.

Troisième séance

Lors de la troisième séance (et la dernière à ce jour), des élèves de cette classe étaient en voyage, nous étions donc moins nombreux, peut-être une vingtaine d’ élèves, et nous disposions d’un peu plus de temps que les 55 minutes habituels car une douzaine d’élèves n’avaient pas cours après (et moi non plus). La séance a peut-être duré 1 heure et quart. Je commence donc en classe entière.

Là j’ai présenté les jeux 1, 2, 3 et 4 ci-dessus puis j’ai demandé en quoi ils se ressemblaient. Lors des échanges j’ai pu parler enfin parler de modules. J’ai insisté sur le fait que les techniques étaient les mêmes mais que les élèves pouvaient créer le jeu qu’ils voulaient. Une fois leur jeu choisi, ce sera à eux de déterminer les modules nécessaires à leur projet et de les développer eux-mêmes. Par conséquent attention à ne pas être trop ambitieux.

Fort heureusement pour eux, je leur ai expliqué qu’ils avaient à leur disposition un certain nombre de fiches expliquant les différents modules.

Je leur ai alors présenté rapidement les fiches suivantes :

Obstacles mobiles
Document élève
Temps limite
Document élève
Créer un score
Document élève
Vitesse de déplacement
Document élève
Obstacle mobile poursuivant
Document élève
Obstacle avec déplacement aléatoire
Document élève

Je n’ai donc pas proposé tous les modules : pas de module son, pas de module écran de démarrage et de finalisation par exemple. Je réserve ces modules pour l’année prochaine. Il faut consacrer plus de temps à ces activités pour pouvoir les inclure.

L’idée à ce stade est donc que les groupes reprennent leur projet (puisqu’ils ne disposaient pas du temps nécessaire pour reprogrammer entièrement un nouveau jeu) et ajoutent les modules qu’ils souhaitent en utilisant une ou plusieurs fiches parmi les fiches précédentes.

C’est ce qu’ils ont fait. J’avais donc les fiches en copie couleur en plusieurs exemplaires (que j’ai évidemment gardées) et les élèves sont allés chercher des fiches.

La séance s’est bien passée dans l’ensemble. Cependant certains groupes ne sont pas parvenus à obtenir un jeu opérationnel dans ce laps de temps trop court. Au moins deux séances semblent nécessaires à ce stade.

Voici deux exemples de projets d’élèves :


https://scratch.mit.edu/projects/109566017/
Un projet relativement complet. On y trouve deux obstacles glissants, un score, un labyrinthe et un temps limite. Elles n’ont évidemment pas disposé du temps nécessaire pour aller plus loin.


https://scratch.mit.edu/projects/109566618/
Dans ce projet, surprenant quand on le lance, les deux élèves voulaient faire, sans s’en rendre compte, un jeu de plateforme (à la donkey kong ou encore mario bros).

Effectivement, quand on se déplace vers la droite, on rencontre la couleur rouge et le lutin revient à sa place initiale. Tout se passe donc comme si il était bloqué par la plateforme bleu clair surélevée. Quand je leur ai dit qu’il manquait un événement pour la touche fléchée vers le bas, les élèves m’ont répondu qu’ils ne le voulaient pas car leur lutin devait être capable de sauter et d’atterrir sur les plateformes bleu clair ! J’ai dû leur dire que c’était très ambitieux puisqu’un tel module consistait à implémenter de la gravité (P=mg) dans leur jeu et que c’était difficile à programmer. Malgré tout j’ai trouvé leur démarche d’autant plus intéressante qu’elle s’éloignait un peu des exemples de jeux que j’avais présentés.

Implémenter de la gravité pourrait d’ailleurs faire l’objet d"un module supplémentaire. Il existe sur le site communautaire de Scratch des exemples sur ce sujet.

Beaucoup de projets ressemblaient au jeu du labyrinthe (jeu 2), mais avec des labyrinthes variés. Un seul binôme a programmé un petit jeu de poursuite.
Trois binômes n’ont pas réussi a programmer un jeu fonctionnel (dont l’exemple ci-dessus). Dans l’ensemble donc, les élèves ont réussi à programmer un jeu de type pacman dans une version de base.

Faute de temps, je n’ai pas pu consacrer à ce jour une quatrième séance à ces développements. Sans doute pourrai-je le faire en juin. Il reste plusieurs modules importants à faire travailler : le score, le temps limite, le son (!),...

Très souvent le temps limite, le score, la partie perdue une fois le temps limite atteint, n’ont pas été implémentés correctement, ce qui tout à fait normal étant donné le temps imparti.

Cela dit mon objectif initial était de tester l’idée du moteur afin de voir ce que cela donne dans l’ensemble. De ce point de vue, cette expérimentation m’a beaucoup aidé.

Retour en début de partie

2) Mise en œuvre envisagée l’année prochaine

Je commencerai par deux séances de prise en main de Scratch afin de découvrir l’interface, réaliser l’importance des couleurs, changer le lutin ou l’arrière-plan , déplacer un lutin à l’aide du clavier...

Lors de la troisième séance, les élèves travailleront sur un jeu basique de labyrinthe : travail sur l’arrière plan, sur les murs, collisions avec les murs, partie gagnée quand la cible est atteinte.

Enfin les trois séances suivantes seront consacrées au développement du projet.

Pour cela je commencerai par une « plénière » en classe afin de présenter des jeux de type pacman et afin de dégager les notions de moteur et de modules.

En salle informatique, les élèves devront écrire sur papier le cahier des charges de leur projet, c’est à dire tout simplement ce qu’ils souhaitent développer dans les grandes lignes, ainsi que les modules qu’ils pensent nécessaires pour leur développement.

S’ensuivra alors le développement. Pour cela, je vais plastifier les fiches modules en couleur, et en plusieurs exemplaires. Les élèves se déplaceront d’eux-mêmes pour aller chercher la ou les fiches modules dont ils ont besoin.

À la fin, nous pourrions consacrer une séance afin de présenter les différents programmes. Ce sera l’occasion de demander à chaque groupe de préciser les difficultés rencontrées, les abandons de tel ou tel module, bref de raconter leur projet.


Retour au sommaire


Conclusion

En guise de conclusion, nous pouvons aborder la question de la progression verticale sur les trois années puisqu’il est en effet nécessaire d’établir une progression globale sur le cycle. En effet si un tel projet est par exemple mis en oeuvre en classe de quatrième, que faisons nous en classe de cinquième et en classe de troisième ? De nombreuses organisations sont envisageables. Par exemple un projet chaque année, avec des modules réservés à certains niveaux. Ou encore des programmes simples en cinquième, un premier projet en quatrième pour terminer avec un projet plus vaste en troisième.

En outre, d’autres moteurs sont envisageables : un moteur de QCM (proposant des questions issues d’autres matières pourquoi pas) ou encore un moteur de jeu d’aventure, ce dernier nécessitant un module expliquant comment programmer un jeu comportant plusieurs scènes.

Ces questions sont encore ouvertes pour moi et rien n’est encore arrêté. Les discussions prévues avec mes collègues à la fin de l’année sur ce sujet devront préciser ces points importants.

Retour au sommaire