Note pédagogique :
Cette séance est la plus difficile du projet. Elle permet d’habiller le jeu en définissant un décor, puis en habillant ce décor à l’aide de dalles. Le résultat est gratifiant, et motivera les élèves. Cependant, devant la difficulté de la tâche, des élèves n’ayant pas un très bon niveau en Scratch peuvent se décourager.
Avec des élèves « moyens » (rappel : ce projet n’est pas du tout adapté à des élèves débutants ou faux débutants, même après quelques séances d’initiation), nous conseillons d’adopter, au choix, l’une des 2 méthodes suivantes :

•  Choix 1 : fournir le programme final corrigé de cette séance, et analyser ce programme avec les élèves. Pourquoi y a-t-il des dalles ? Pourquoi ont-elles ces dimensions ? Quel est le rôle du lutin explorateur ? etc.
• Choix 2 : fournir un décor fixe (sous la forme d’un paysage que l’on importe) et passer aux séances suivantes en utilisant ce décor fixe. En fin de projet, pour les élèves les plus avancés, on pourra peaufiner le programme en définissant un décor personnalisable à l’aide de dalles, comme proposé dans cette séance.

Situation déclenchante

Notre « Joueur » est dorénavant soumis à une gravité virtuelle (il accélère vers le bas de l’écran). Nous pouvons le contrôler à l’aide des flèches et il disparaît lorsqu’il atteint le bas de l’écran, pour réapparaître à une position prédéfinie. Il faudrait maintenant qu’il ait des plateformes sur lesquelles se poser et se déplacer, comme discuté à la séance 2. Pour la séance d’aujourd’hui, les élèves vont travailler avec des éléments de plateforme (ou « dalles ») prédéfinis et un « paysage » fourni. Ce paysage est géré par le(s) costume(s) d’un nouveau lutin. Autrement dit, la fonctionnalité suivante a été programmée par l’enseignant :

•  Niveau : est défini à l’avance sous forme d’un dessin très simple.

 Le travail des élèves va consister à programmer deux nouvelles fonctionnalités :

•  Élément de plateforme : se positionne en début de niveau.
•  Niveau : est habillé de sortes de « dalles » (éléments de plateforme).

Ces deux fonctionnalités sont étroitement liées : c’est le positionnement de plusieurs dalles qui « habille » le niveau.
L’enseignant fait la démonstration du résultat attendu à l’aide du fichier Platformer_V03_demo.  Les élèves pourront à tout moment demander à revoir ce programme s’exécuter.

Le travail va se dérouler en trois temps :

•  définition de la dimension des dalles (l’enseignant montre que plusieurs formats sont possibles en relançant la démonstration avec les dimensions A, B, C et D).
•  découpage de la fonctionnalité complexe recherchée en tâches de programmation simples.
•  mise en œuvre de ces tâches de programmation.

Quelle dimension donner aux dalles ? (par groupes, optionnelle)

Note pédagogique :
 Si l’enseignant ne souhaite pas mener cette activité optionnelle, il impose un format de dalle, par exemple 24 x 24 pixels et peut simplement vérifier avec la classe que ce format permet de paver la scène entièrement. Dans ce cas, pour l’activité suivante, il fournit à la classe un fichier Platformer_V03_dalles_24 (au lieu du fichier Platformer_V03), qui a été nettoyé des scripts et costumes devenus inutiles.

L’enseignant demande aux élèves de s’installer en groupes (constitués de 2 ou 3 binômes de projet).  Les binômes vont devoir décider d’une dimension à donner aux dalles qui constitueront les plateformes de leurs jeux. Il y a quelques contraintes, qui peuvent être discutées avec la classe ou présentées comme un cahier des charges :

•  les dalles doivent être de forme rectangulaires (on imposera même qu’elles soient carrées);
•  une fois juxtaposées en lignes et en colonnes, elles doivent pouvoir couvrir exactement toute la scène (sans déborder ni laisser de blancs);
•  elles doivent être plus hautes et plus larges que le « Joueur » (pour que celui-ci puisse passer entre deux alignements de dalles, au niveau d’une ligne/colonne sans dalle), mais en même temps être assez petites pour que l’on puisse dessiner des paysages intéressants à l’aide des dalles ;
•  la scène fait 480 pixels de large et 360 pixels de haut ;
•  le « Joueur » fourni fait 12 pixels de large et 16 pixels de haut.

Les groupes disposent d’une dizaine de minutes pour réfléchir, après quoi l’enseignant demandera à chaque groupe de faire une (ou deux) proposition(s), en nombre de pixels pour le côté des dalles. Les groupes devront également indiquer combien de lignes et de colonnes de dalles permettent de couvrir entièrement la scène.

Note pédagogique :
Si nécessaire, l’enseignant peut guider les élèves en leur suggérant :

•  de schématiser la scène avec des 480 pixels de large et 360 pixels de haut pour faciliter leur raisonnement.
•  de rechercher des nombres qui divisent à la fois 480 et 360, soit de façon un peu empirique, soit en décomposant 480 et 360 en produits de facteurs premiers (on divise par 2 tant que c’est possible, puis par 3, etc. en égrenant tous les nombres premiers successifs) :
  480 = 2 x 2 x 2 x 2 x 2 x 3 x  5
  360 = 2 x 2 x 2 x 3 x 3 x 5
  Les diviseurs communs de 480 et 360 (1 mis à part) sont des produits de termes communs aux deux décompositions : 2, 3, 2 x 2 = 4, 5, 2 x 3 = 6, 2 x 2 x 2 = 8, 2 x 5 = 10, 2 x 2 x 3 = 12, 3 x 5 = 15, 2 x 2 x 5 = 20, 2 x 2 x 2 x 3 = 24, 2 x 3 x 5 = 30, 2 x 2 x 2 x 5 = 40, 2 x 2 x 3 x 5 = 60, 2 x 2 x 2 x 3 x 5 = 120.

Lors de la mise en commun, les propositions des élèves sont rassemblées dans un tableau de synthèse et évaluées au vu des contraintes :

Trois dimensions de dalle permettent de respecter toutes les contraintes : 20 pixels, 24 pixels et 30 pixels. La suite du projet est décrite dans le cas où les dalles ont 24 pixels de côté, ce qui correspond à 15 lignes et 20 colonnes de dalles pour couvrir toute la scène. En pratique, les groupes n’ont pas obligation de choisir tous la même dimension de dalle, mais une fois leur choix opéré, ils devront s’y tenir.

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

Pour ce travail, les élèves s’installent aux ordinateurs par binômes de projet. Ils récupèrent le fichier Platformer_V03 fourni par l’enseignant (rappel : en cas d’utilisation d’un studio Scratch par l’enseignant, la procédure que doivent suivre les élèves pour remixer le programme fourni est décrite sur la Fiche 1). Ils prennent un moment pour explorer le fichier fourni (onglet Scripts et onglet Costumes de chaque lutin) et lisent les commentaires intégrés au programme. Ces commentaires fournissent des informations importantes. Les élèves peuvent constater que :

•  les costumes du lutin « Paysages » sont minuscules. Ils sont affichés sur la scène avec un très fort grossissement et définissent alors le paysage à l’échelle du pixel : un pixel du costume  correspond à une dalle sur la scène. Les angles du paysage sont repérés hors champ pour faciliter le repérage lors du dessin.
  NB : pourquoi un lutin si petit ? Le paysage a été discrétisé en 15x20 pixels (si les dalles font 24 pixels de coté). Si on le dessine à la taille réelle, il est fort probable que l’on place des éléments graphiques entre deux « pixels finaux » (pseudo pixel de la dimension d’une dalle). La méthode la plus simple pour éviter cela est de dessiner un paysage de 15x20 pixels, puis de l’agrandir d’un facteur 24 pour qu’il occupe toute la scène.
•  le lutin « Dalles » et le lutin « Costumes » ont chacun 3 costumes adaptés aux dimensions 20, 24 et 30 pixels des dalles. Seul un de ces trois costumes est utile pour un binôme donné, selon la dimension choisie pour ses dalles. Le binôme peut éventuellement supprimer les deux autres costumes, et simplifier le script du lutin « Paysages » en conséquence.
•  le lutin « Dalles » comporte un costume nommé « Explorateur », de dimension 2 x 2 pixels, en plus du costume « Dalle ». Lors de la démonstration de l’enseignant, on voyait le costume « Explorateur » parcourir la scène, et les dalles se positionner si l’explorateur passait sur un élément de paysage. Cela fournit une piste de programmation …

Les binômes ont maintenant une quinzaine de minutes pour proposer leur liste de tâches simples, en s’aidant de leurs observations précédentes.

Lors de la mise en commun, un groupe d’élèves présente sa liste de tâches. Puis celle-ci est enrichie ou modifiée sur suggestion d’autres groupes et de l’enseignant. La classe arrive alors à un découpage qui sera mis en œuvre par chaque groupe lors de l’activité suivante. Voici une proposition de découpage très détaillée, mais il n’est pas nécessaire que la classe atteigne ce niveau de détail avant de passer à l’activité suivante :

Les élèves se lancent, en autonomie, dans la réalisation des tâches listées précédemment, 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 travail.
Ci-dessous, des éléments de correction pour les tâches 1 à 9 :

Tâches 1 et 2 : créer une variable « dimension dalle » et initialiser la position du lutin « Dalles »

À l’issue des tâches 1 et 2, le programme du lutin « Dalles » ressemble à ceci :

Le lancement du programme par un clic sur le drapeau vert déclenche l’affectation de la valeur 24 (par exemple) à la variable Dimension_dalle. Le lutin prend son costume « Dalle 24 », puis il se rend à la position d’abscisse – 240 pixels et d’ordonnée – 180 pixels, conformément au repère de position du costume actif. Enfin, le lutin se montre. Les instructions « cacher » et « montrer » évitent que l’on voie furtivement une dalle mal positionnée ou de taille incorrecte, au lancement du programme.
Le repère de position des costumes est visible depuis l’onglet Costumes : il est indiqué par une croix grise (voir illustration ci-dessous). Dans le cas qui nous intéresse, ce repère a été positionné (en amont de la séance) à l’angle en bas à gauche de la dalle. Donc, lorsque le lutin est envoyé à une certaine position, c’est en fait l’angle en bas à gauche de la dalle qui se retrouve à cette position.
N.B. : la position du repère est configurable depuis l’onglet Costumes, grâce à l’icône

Tâche 3: faire déplacer le lutin « Dalles » vers la droite de sa propre largeur

Plusieurs instructions permettent de déplacer le lutin « Dalles » vers la droite de sa propre largeur :

ou

La première produit l’effet recherché seulement si le lutin est déjà orienté vers la droite. La seconde est plus robuste : elle fonctionne quelle que soit l’orientation du lutin. Pour remplir la tâche 3, il suffit en pratique d’ajouter une de ces deux instructions à la fin du sous-programme du lutin.

Tâche 4 : répéter ce déplacement de façon à ce que le lutin termine à l’angle en bas à droite de la scène.

Pour que le lutin atteigne l’angle en bas à droite de la scène, il faut qu’il effectue 19 fois le déplacement demandé à la tâche 3. Il suffit pour cela d’ajouter une instruction de boucle prédéfinie, disponible dans la catégorie « Contrôle ». On obtient alors le programme suivant :

Notes pédagogiques :

•  On peut faire afficher sur la scène la valeur de la variable prédéfinie « abscisse x »,  en cochant la case prévue devant le nom de la variable, tout en bas de la catégorie « Mouvement » :
  
•   Afin que les élèves visualisent mieux ce qui se produit lorsque la boucle s’effectue, on peut ajouter une petite pause avant l’instruction de déplacement, à l’aide de l’instruction « attendre … secondes » disponible dans la catégorie « Contrôle ».

Tâche 5 : faire en sorte qu’une « copie » du lutin « Dalles » reste à chaque position explorée

Les élèves peuvent proposer différents moyens de positionner des « copies » de la dalle aux emplacements qu’elle occupe successivement, y compris la première et la dernière position. Pour vérifier le programme, on peut placer à la fin une instruction « cacher », qui fera disparaître la dalle mobile et révèlera si une « copie » a bien été positionnée.
Une première façon de faire est d’utiliser l’instruction « estampiller », disponible dans la catégorie d’instructions « Stylo » :
Cette instruction doit être placée dans la boucle, si l’on souhaite que l’estampillage se produise à chacune des positions successives de la dalle qui se déplace. Elle doit être associée à une instruction « effacer tout » qui, placée en début de programme, permet que la scène soit « propre » à chaque lancement du programme. Si l’on conserve 19 répétitions comme à la tâche 4, il faut procéder à un estampillage supplémentaire, soit juste avant, soit juste après la boucle (selon que l’estampillage est placé après ou avant le déplacement, dans la boucle). Si l’on souhaite éviter cela, on peut augmenter à 20 le nombre de répétitions de la boucle, mais dans ce cas, il faut positionner obligatoirement l’estampillage avant le déplacement, comme proposé ci-dessous :

Une seconde façon de faire est d’utiliser les instructions de clonage, qui sont propres à Scratch. Ces instructions sont disponibles dans la catégorie « Contrôles ». Elles sont au nombre de trois :

L’instruction « quand je commence comme un clone » est une instruction qui permet, tout comme l’instruction « quand drapeau vert cliqué », de faire en sorte qu’un sous-programme soit déclenché par un événement, ici la création du clone. Le sous-programme en question s’applique alors au clone.
Dans le cas qui nous concerne, il s’agit de créer un clone à chaque itération de la boucle. Les subtilités sur le nombre de répétitions (19 ou 20) décrites pour l’option d’estampillage restent valables, et on obtient par exemple, si l’on fait 20 répétitions :

Notes pédagogiques :

•  Si l’on fait 20 répétitions de la boucle, on aperçoit furtivement la dalle mobile légèrement hors champ, avant sa disparition. Si les élèves trouvent que cela ne fait pas très « pro », on peut leur proposer de rendre la dalle mobile fantomatique à l’aide de l’instruction suivante placée vers le début du programme :
  
  Toutefois, si les élèves ont utilisé des clones, il est alors nécessaire d’annuler cet effet graphique à la création du clone, pour que celui-ci soit effectivement visible :
  
•  Plutôt que de demander 20 répétitions de la boucle, ce qui n’est correct que lorsque les dalles font 24 pixels de côté, on pourrait demander un nombre de répétitions qui dépende de la dimension des dalles, en l’occurrence, la largeur de l’écran en nombre de pixels (480) divisée par la dimension des dalles :
  
  De façon générale, c’est une bonne habitude à prendre que d’éviter au maximum les valeurs numériques dans les programmes, en tout cas pour les « constantes » qui ne sont pas si constantes que cela ! Ici, on peut conserver la valeur numérique 480 car elle ne peut pas changer (toutes les scènes Scratch font 480 pixels de large). Mais mieux vaut utiliser la variable Dimension-dalles que la valeur numérique 24.
•  À ce stade de l’avancement du projet, les deux options – estampillage et utilisation de clones – semblent équivalentes. Elles ne le sont en réalité pas du tout : les dalles estampillées ne peuvent ni être déplacées, ni changer de costume, ni détecter la présence du lutin « Joueur ». Elles sont dorénavant passives. Tout ce que l’on peut faire, c’est les effacer d’un bloc ou détecter leur couleur. Au contraire, les clones peuvent avoir leurs sous-programmes propres, et peuvent donc jouer un rôle actif sur la scène. L’inconvénient des clones est l’espace mémoire qu’ils occupent, risquant de ralentir tout le programme.
•  L’enseignant doit discuter avec les élèves de l’option qui leur paraît la meilleure : souhaite-t-on que les dalles puissent se déplacer ? Qu’elles puissent interagir avec le joueur, et notamment détecter sa présence ? Plus généralement, aimerait-on qu’elles aient leurs propres sous-programmes ? Si la réponse de la classe est positive, l’utilisation des clones s’impose. Ici, la fonction d’estampillage suffit.

Tâche 6 : créer une fonction « Remplissage ligne »

Notes scientifiques

•  Découper le travail de programmation en tâches élémentaires permet de tester les différentes parties du programme au fur et à mesure. C’est beaucoup plus  facile, et plus sûr, que d’écrire un long programme et de le tester à la fin (dans ce cas, on obtient en général de nombreux bugs qu’il est très difficile de résoudre)
•  Travailler à l’aide de fonctions permet, une fois que la fonction est écrite, de passer à autre chose sans avoir besoin de toucher ce morceau de programme.
•  Attention : Scratch souffre d’une limitation importante : les fonctions ne peuvent pas retourner de valeur. Si l’on souhaite qu’une fonction renvoie un résultat, il faut avoir créé une variable ad hoc et faire en sorte que la fonction modifie cette valeur. En informatique, de tels sous-programmes (sans valeur de sortie) sont plutôt appelés des « procédures » : nous employons le mot « fonction » (qui est un abus de langage) par souci de cohérence avec les programmes scolaires.

On souhaiterait que le remplissage d’une ligne par des copies de la dalle mobile puisse être répété pour chacune des lignes de la scène (15 lignes dans le cas de dalles de 24 pixels de côté). On se propose donc de placer les instructions permettant de remplir une ligne dans une fonction « remplissage ligne », qu’il suffira ensuite d’appeler 15 fois. La création de fonctions est disponible dans la catégorie « Ajouter blocs ».
Concrètement, pour remplir la tâche 6, nous devons :

Créer un bloc que nous appelons par exemple « Remplissage ligne »
Dans les options de création du bloc, ajouter une entrée numérique (l’ordonnée Y de la ligne à remplir) puis valider par « OK »
Utiliser ce nouveau bloc pour créer la fonction de remplissage de ligne (en déplaçant certaines des instructions utilisées pour programmer la tâche 5)
Appeler cette fonction dans le programme de la dalle mobile, avec une valeur au choix pour Y (on peut tester plusieurs valeurs, par exemple – 180 pour remplir la ligne du bas)

Tâche 7 : appeler la fonction « Remplissage ligne » autant de fois qu’il y a de lignes

Pour remplir cette tâche, il faut appeler la fonction « Remplissage ligne » 15 fois, avec les valeurs de Y suivantes : - 180, - 156, - 132 … + 132, + 156. Autrement dit, avec des valeurs de Y espacées de 24. Pour cela, on initialise la position en ordonnées du lutin à la valeur – 180, et dans la boucle qui appelle la fonction « Remplissage ligne », on incrémente l’ordonnée du lutin de « Dimension_dalle ». On obtient alors, pour le programme principal du lutin « Dalles » :

Tâche 8 : ne faire poser un clone du lutin « Dalles » que s’il y a un élément de paysage à cet endroit.

Pour résoudre cette tâche, il suffit de placer l’instruction de création de clone dans une instruction conditionnelle : le clone ne doit être créé que si la dalle mobile touche un élément de paysage. La fonction « Remplissage ligne » devient alors :

Tâche 9 : faire effectuer la détection du paysage par le costume « Explorateur »  du lutin « Dalles ».

Cette tâche permet que la détection des éléments de paysage soit faite par le lutin « Dalles » ayant son costume « Explorateur ». Elle n’est pas absolument obligatoire, mais permet d’éviter des problèmes d’habillage du paysage dans le cas où le costume des dalles n’est pas tout à fait calé sur la dimension choisie. On obtient l’effet recherché avec une initialisation du costume et des changements de costume (avant et après la création du clone).
L’initialisation a lieu dans le programme principal à l’aide de l’instruction « Basculer sur costume … » :

Ces mêmes instructions encadrent la création du clone, dans la fonction « Remplissage ligne » :

Note pédagogique :
 Pour mieux visualiser ce qui se passe, on peut demander l’affichage du numéro du costume du lutin « Dalles », en cochant  en bas de liste de la catégorie « Apparence ». Attention, pour que les changements de numéro soient visibles, il faut aussi insérer des instructions « attendre … secondes » après les instructions de changement de costume.

Mise en commun

La mise en commun sert à échanger sur les principales difficultés rencontrées par les groupes, et inclut un temps pendant lequel les élèves peuvent modifier leur programme à la lumière des différents échanges.

Une démonstration montre :
1/ au lancement du programme, le lutin « paysage » est affiché : chaque zone noire, non encore « habillée », correspond à un futur élément du décor.

2/ le lutin « explorateur » parcourt l’écran, et « habille » les dates noires à l’aide du costume prédéfini. La plateforme est ainsi créée.

Conclusion

L’enseignant revient tout d’abord sur la conclusion de la Séance 2, qui se trouve renforcée par cette séance. Puis il guide la classe vers une conclusion concernant les fonctions en informatique :

•  Lorsqu’un même bloc d’instructions doit être utilisé plusieurs fois dans un programme, il est judicieux de l’intégrer dans une fonction. En Scratch, la création de fonctions se fait dans la catégorie « Ajouter blocs ».