Situation déclenchante

L’enseignant  lance le programme Platformer_V07_demo, qui correspond au travail issu des séances 1 à 6, avec dans le paysage des éléments de plateforme formant un mur. L’enseignant met en évidence des dysfonctionnements, si ceux-ci n’ont pas déjà été signalés par les élèves :

•  lorsque le lutin « Joueur » saute et touche une plateforme par un bord vertical, il rentre dans la plateforme et remonte jusqu’à être posé sur elle.
•  lorsque le lutin « Joueur » rencontre un mur de dalles par le côté, il le traverse.

Il s’agit donc de programmer la fonctionnalité suivante de la carte mentale :

•  Avatar : rebondit sur les murs.
•  Elément de plateforme standard : est impénétrable par l’avatar (par les côtés)

Les élèves vont devoir régler ces problèmes, après la production d’une feuille de route de programmation collective.

Gérer le rebond sur le bord vertical des plateformes (collectivement puis par binômes)

L’enseignant demande aux élèves de réfléchir à la façon dont ils vont gérer le rebond du lutin « Joueur » sur les bordures verticales des plateformes. Pour cela, il leur conseille d’analyser comment ils ont programmé le repos du lutin « Joueur » sur les plateformes et son rebond sur les plafonds, et de se demander si, dans l’état actuel des choses, ils peuvent procéder de même pour les bordures verticales. Une mise en commun aura lieu après quelques minutes de réflexion des binômes.
Certains groupes d’élèves auront certainement remarqué que le repos sur les plateformes et le rebond sur les plafonds est obtenu en manipulant la variable « vitesse verticale ». Si ce n’est pas le cas, l’enseignant guide la classe vers cette observation :

•  pour sauter, on met la valeur de la variable « vitesse verticale » à 7 :
  
•  pour reposer sur une plateforme, on met cette valeur à 0.
•  pour rebondir sur un plafond, on change le signe de cette valeur :
  
•  pour accélérer vers le bas, on y ajoute la valeur de la variable gravité (le signe négatif vient de la convention choisie de prendre une valeur positive de la gravité alors qu’elle entraîne le Joueur vers le bas et doit donc diminuer, via « vitesse verticale »,  son ordonnée) :
  

Puis on met à jour la position selon l’axe des ordonnées par l’instruction :

Or, il n’y a pas pour le moment de variable « vitesse horizontale » : les déplacements droite/gauche sont obtenus en modifiant directement la valeur de l’abscisse « x » du lutin « Joueur ». C’est d’ailleurs pour cela que le lutin a des trajectoires peu réalistes lorsqu’il saute : si on cesse d’appuyer sur la flèche droite ou sur la flèche gauche, en cours de saut, le lutin cesse brutalement son déplacement droite/gauche. Il peut aussi changer de direction en plein saut … comme dans les dessins animés (et comme dans le jeu de plateforme montré à la séance 1), mais pas comme dans la réalité !

L’enseignant encourage les élèves à introduire une nouvelle variable « vitesse horizontale », à l’utiliser pour gérer les déplacements droite/gauche (ce qui supposera de modifier un sous-programme existant du lutin « Joueur ») puis à l’utiliser pour gérer les rebonds sur les bordures verticales. Cela correspond à la feuille de route de programmation suivante, construite collectivement (sauf la tâche 6 que les élèves n’anticiperont certainement pas) :

Après avoir créé une copie V07 du fichier issue de la séance précédente, les élèves se lancent, en autonomie, dans la réalisation des tâches de la feuille de route, 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.

Ci-dessous, des éléments de correction pour les tâches 1 à 6 :

Tâche 1 : créer et initialiser une variable « vitesse horizontale »

La création et l’initialisation de variable a déjà été décrite à l’Étape 2 (correction des tâches 1 et 3). Il est judicieux de placer l’initialisation de la variable « vitesse horizontale » au même endroit que celle de la variable « vitesse verticale », c’est-à-dire dans le sous-programme des initialisations du lutin « Joueur ».

Tâche 2 : gérer les déplacements horizontaux du Joueur

On utilise la variable nouvellement créée « vitesse horizontale » pour commander les déplacements droite/gauche du lutin « Joueur ». Les modifications du sous-programme écrit à la séance 1 sont assez mineures :

Pour le moment, les déplacements peuvent être commandés aussi bien lorsque le lutin est « en l’air » que lorsqu’il repose sur une plateforme. De plus, son déplacement ne cesse pas lorsqu’on arrête de presser les touches flèche droite/gauche.

Tâche 3 (facultative) : empêcher les changements de direction pendant les sauts

Lorsque le lutin « Joueur » repose sur le dessus d’une plateforme, il touche la couleur verte spécifique du dessus des plateformes. Pour résoudre la tâche 3, on peut donc ajouter cette condition de contact dans le sous-programme qui contrôle les déplacements droite/gauche du lutin « Joueur », comme ceci :

La mise à jour de la position du lutin selon l’axe des abscisses doit être effectuée que la condition de contact soit vraie ou fausse. L’instruction « ajouter vitesse horizontale à x » ne doit donc pas dépendre de cette condition : on la place hors des mâchoires du « si … alors ».

Tâche 4 (facultative) : prendre en compte les frottements sur le sol

La résolution de la tâche 4 suppose de rapprocher la valeur de la variable « vitesse horizontale »  de zéro si le lutin « Joueur » touche le dessus de plateforme (donc la couleur verte correspondante) et que les flèches droite/gauche ne sont pas pressées. Pour obtenir ce résultat, on peut multiplier la valeur de la vitesse par un « coefficient de frottement » plus petit que 1, ce qui suppose au préalable de créer une variable « frottement » et de l’initialiser (par exemple à la valeur 0.5).
On doit également agencer des instructions conditionnelles « si … alors » et « si … alors … sinon », ce qui est conceptuellement difficile. La proposition suivante n’est pas la plus courte possible, mais elle est la plus simple à comprendre :

Si on affiche la valeur de la variable « Vitesse horizontale » sur la scène, on s’aperçoit qu’en phase de ralentissement du lutin, cette variable prend des valeurs très petites : 0,00000 … . Ce n’est pas très malin : autant assimiler cette valeur à 0 dès lors qu’elle est faible, par exemple comme ceci :

Tâche 5 : rebondir sur les murs

Pour programmer cette tâche, on est amené à tester le contact du lutin avec la couleur des bordures verticales des dalles et à changer le signe de la vitesse horizontale seulement si ce contact a lieu, par exemple ainsi :

Mais où positionner ces instructions dans le programme du lutin « Joueur » ? La plupart des façons de faire que peuvent tester les élèves donnent des résultats peu satisfaisants, car il y a des conflits entre contacts sur/sous/par le côté des plateformes. De plus, ce n’est pas très commode de réorganiser les sous-programmes pour tester l’effet de différents agencements : on s’y perd ! Moralité : il est grand temps de créer des fonctions correspondant à chacun de ces blocs d’instructions, comme on l’a appris en Étape 4. On pourra ainsi, sans modifier les fonctions, changer la façon dont on les appelle, et choisir l’option qui correspond le mieux à ce que l’on recherche.
On peut ainsi créer deux fonctions pour les déplacements vers la droite et vers la gauche (seule la fonction permettant les déplacements vers la droite est illustrée ici, l’autre se construit de la même façon) :

Et aussi créer une fonction pour le contrôle des sauts, une autre pour le repos sur les plateformes, une autre encore pour le rebond sur les plafonds et pour le ralentissement progressif du lutin :

Enfin, une fonction s’impose pour les rebonds sur les murs :

Reste à trouver comment agencer efficacement l’appel de ces fonctions. Mieux vaut certainement effacer les deux sous-programmes qui géraient jusqu’ici les déplacements horizontaux et verticaux, et repartir à zéro, « from Scratch » comme on dit en anglais !
Le programme suivant fonctionne plutôt bien, mais ce n’est certainement pas la seule possibilité :

Tâche 6 : améliorer la non-pénétration des murs

Un gros problème persiste toutefois : le lutin peut traverser les murs, s’il se déplace latéralement sur une plateforme. C’est normal si on analyse le programme dans le détail ! Comme d’ordinaire, le programme fait ce qui est demandé …

La modification suivante de la fonction de rebond sur les murs permet de rendre les murs réellement impénétrables :