Situation déclenchante

L’enseignant se connecte sur son compte Scratch et ouvre le projet Platformer_V04_demo. C’est une copie conforme du programme achevé à la séance précédente, sauf que le paysage a été simplifié : il y a seulement une plateforme continue vers le bas de la scène. L’enseignant explique qu’il souhaiterait y intégrer le lutin « Joueur », qui se trouve dans la version V02. Pour cela, distinguons deux cas :

•  Si l’enseignant et la classe travaillent avec Scratch en ligne, l’enseignant montre comment utiliser le « sac à dos » de Scratch. Il ouvre la version V02 du projet, puis il déploie le sac à dos, par un clic sur la petite flèche grise située sous la zone de programmation. Il y glisse le lutin « Joueur », qui sera dorénavant accessible à cet endroit. Puis il retourne sur la version V04 du projet et déploie le sac à dos. Le lutin « Joueur » s’y trouve effectivement, il suffit de le glisser dans la zone des lutins pour l’intégrer au projet, avec tous ses scripts et costumes. Les élèves s’installent aux ordinateurs et se connectent sur leur compte Scratch, puis effectuent immédiatement le même travail, y compris la simplification du paysage à une simple plateforme (un « trait » horizontal). Ils enregistrent le programme obtenu sous le nom Platformer_V04_nom_du_groupe.
•  Si l’enseignant et la classe travaillent avec Scratch installé en local, l’enseignant montre comment exporter et importer un lutin. Il ouvre la version V02 du projet, fait un clic droit sur l’icône du lutin et choisit « enregistrer localement comme fichier ». Puis il ouvre la version V04 du projet et importe le lutin qu’il vient d’enregistrer localement, grâce à l’icône « Importer le lutin depuis un fichier ».

L’enseignant demande aux élèves d’exécuter le programme, et de se préparer à dire ce qu’ils en pensent. Les élèves soulèvent notamment le problème suivant : le lutin passe à travers les dalles !
L’objectif principal de cette séance est d’éviter ce problème, et donc de programmer cette fonctionnalité de la carte mentale :

•  Avatar : se pose sur les plateformes.
•  Elément de plateforme standard : est impénétrable par l’avatar (par le dessus)

Un autre problème peut être identifié par les élèves : le « Joueur » commence sa chute avant même que le paysage soit habillé de dalles.  Si nécessaire, l’enseignant fait remarquer cela, et la classe ajoute les fonctionnalités correspondantes dans la carte mentale pour les programmer à la séance suivante :

•  Niveau : informe l’avatar de sa mise en place.
•  Avatar : apparaît et démarre une fois le paysage habillé de dalles.

Créer la feuille de route de programmation (par binômes)

L’enseignant propose aux élèves de créer eux-mêmes leur feuille de route. L’enseignant peut ponctuellement guider la réflexion d’un binôme, mais il n’intervient pas outre mesure. Les élèves passent à l’activité de programmation proprement dite au fur et à mesure qu’ils achèvent leur listing de tâches.

Mettre en œuvre la programmation (par binômes)

Les élèves se lancent, en autonomie, dans la réalisation des tâches qu’ils ont listées, tandis que l’enseignant passe de groupe en groupe pour échanger avec les élèves sur l’avancement de leur travail. L’enseignant rappelle que les élèves doivent sauvegarder régulièrement leur projet.

Notes pédagogiques :

•  La constitution du listing des tâches en autonomie par les groupes est une source de diversité dans les démarches, mais aussi une source de difficultés de programmation. C’est pourquoi cette séance se limite à la programmation d’une seule fonctionnalité d’apparence assez simple.
•  L’enseignant peut suggérer aux élèves de s’inspirer des feuilles de route de programmation des séances précédentes.
•  Il peut demander aux élèves de quelles variables et de quelles fonctions ils auront besoin.

Mise en commun

L’enseignant identifie un groupe qui se heurte à une difficulté courante et lui demande de partager son programme sur Scratch. Ce groupe se rend au tableau et montre le problème à la classe, pour la recherche collective d’une solution.
Prenons un exemple concret : un groupe d’élèves explique que le « Joueur », au lieu de stopper net sa chute lorsqu’il atteint une plateforme, s’enfonce de plusieurs pixels dans la plateforme et reste enfoncé ! Les élèves ont modifié le sous-programme qui contrôle la chute du joueur, en y intégrant une instruction conditionnelle, comme ceci :

Pourquoi ce problème ? Manifestement, le « Joueur » détecte bien la dalle, puisqu’il cesse sa chute, mais au lieu de s’arrêter à la surface de la dalle, il s’y enfonce. Pour mieux voir ce qui se passe, on peut demander l’affichage sur la scène de la valeur de la variable « vitesse verticale » et/ou introduire une petite pause avant les déplacements verticaux, « attendre 0.1 secondes ». On constate alors que l’enfoncement dans la dalle est dû à la discrétisation des déplacements : le « Joueur » descend par exemple de 10 pixels d’un coup, et se retrouve enfoncé dans la dalle. Juste avant ce déplacement, il ne touchait pas la dalle, donc il est normal qu’il soit descendu de « vitesse verticale » pixels. Il touche dorénavant la dalle, donc sa vitesse verticale a pris une valeur nulle. Logiquement, il reste enfoncé. La première conclusion de ces observations est que le programme fait bien ce qu’on lui a demandé. Reste à trouver un moyen de faire remonter le « Joueur ».

Note scientifique :
 Ce problème ne peut avoir lieu que si les élèves ont choisi de placer leurs « Dalles » par « clonage ». Dans le cas de la méthode par « estampillage », les collisions sont exclusivement gérées par détection de couleur. L’estampillage est la méthode la plus fluide pour gérer les collisions.

Plusieurs méthodes, ou algorithmes, peuvent être envisagés et testés collectivement, avec un guidage de l’enseignant si nécessaire :

•  Lorsqu’une dalle est touchée, on peut mettre la vitesse verticale à une valeur positive (1 par exemple) au lieu de 0. Ainsi, le « Joueur » remonte. L’implémentation de cette proposition donne un caractère sautillant au « Joueur » : celui-ci effectue en permanence de petits bonds. On aime ou pas … c’est une affaire de goût. Mais en tout cas, cela posera problème pour programmer ultérieurement la fonctionnalité de saut depuis les plateformes, car le saut ne peut avoir lieu que lorsque le lutin touche le dessus d’une plateforme, ce qui n’est pas le cas lorsque le lutin vient de remonter.
•  Lorsqu’une dalle est touchée, on peut mettre la vitesse verticale à 0 comme programmé initialement par les élèves, mais faire remonter le « Joueur » pixel par pixel en jouant sur la variable prédéfinie ordonnée Y, jusqu’à ce qu’il ne touche plus la dalle. Malheureusement, là encore, le rendu est sautillant … et on a comme pour l’algorithme précédent le problème des sauts.
  
•  Un autre algorithme consiste à utiliser les capteurs de contacts entre couleurs. Il se trouve que le « Joueur » a une ligne de pixels noirs sur son pourtour, et des pixels rouge foncé au cœur. Si l’on reprend la proposition ci-dessus en conditionnant la remontée pixel par pixel au contact entre la couleur rouge foncé et la couleur de fond des dalles, le « Joueur » remontera jusqu’à avoir seulement la ligne de pixels noire enfoncée dans la dalle. Du coup, il touchera la dalle (donc sa vitesse verticale sera nulle), sans pour autant remonter davantage. Le rendu est cette fois-ci parfaitement stable.
  

Ce dernier algorithme constitue une correction possible de la tâche de programmation de la séance.
Si le temps le permet, un autre groupe vient présenter une difficulté à résoudre. L’approche pour la résolution collective est la même : analyse du programme, ajout de pauses, affichage des valeurs de certaines variables, propositions d’algorithmes à tester.

Un moment est prévu à l’issue de la mise en commun pour que les groupes puissent peaufiner leur programme et tenir compte de ce qui a été appris collectivement.
A l’écran, le jeu montre désormais un lutin capable de tomber puis se stabiliser s’il entre en contact avec un élément de la plateforme :

Conclusion

L’enseignant guide la classe vers la formulation de la conclusion suivante :

•  Un algorithme est une méthode permettant de résoudre un problème. Il se construit en combinant des instructions.
•  Plusieurs algorithmes peuvent permettre de résoudre un même problème.
•  Un bug est une erreur dans un programme. Un bug peut provenir d’une erreur de conception de l’algorithme.
•  Introduire des pauses dans l’exécution d’un programme et observer les valeurs des variables facilitent la résolution des bugs.