Tutoriel pas à pas : créer un jeu de labyrinthe avec Scratch

Le jeu de labyrinthe est l'un des tout premiers grands projets que l'on propose aux élèves de collège une fois les bases de Scratch acquises, et ce n'est pas un hasard. Il mobilise à lui seul presque toutes les notions fondamentales de la programmation par blocs : le mouvement, la détection de collision, les conditions, les variables et parfois même les boucles de temporisation. Contrairement à un exercice isolé, il offre une vision d'ensemble d'un vrai petit programme fonctionnel, du décor jusqu'à la condition de victoire. Ce tutoriel détaille chaque étape de la construction de ce projet, dans un ordre pensé pour être suivi en classe sur plusieurs séances, ou en autonomie à la maison.

Étape 1 : préparer le décor et le personnage

Tout projet commence par la préparation de ses éléments visuels. Dans Scratch, il faut d'abord choisir ou dessiner un arrière-plan représentant le labyrinthe : des murs en noir ou d'une couleur vive, un chemin bien dégagé en blanc ou dans une couleur claire, un point de départ et une zone d'arrivée clairement identifiable, par exemple par une couleur différente ou un élément graphique distinct comme une étoile. Il est fortement recommandé de dessiner ce labyrinthe directement dans l'éditeur de costumes/arrière-plans de Scratch, plutôt que d'importer une image externe, car cela permet de contrôler précisément les couleurs utilisées, ce qui sera essentiel pour la détection de collision plus tard.

Le personnage, ou lutin, doit ensuite être choisi ou importé depuis la bibliothèque de Scratch : une petite bille, un fantôme, ou tout autre élément suffisamment petit pour circuler dans les couloirs du labyrinthe sans les toucher au moindre mouvement. Il faut veiller à réduire sa taille via le bloc « taille » ou le paramètre correspondant, afin qu'il puisse effectivement se déplacer dans un couloir de largeur raisonnable sans provoquer de fausses détections de collision. Cette étape de préparation graphique, bien que non technique, conditionne directement la réussite des étapes suivantes : un labyrinthe mal dessiné, avec des couloirs trop étroits par exemple, rendra le jeu injouable même avec un code parfaitement correct.

Étape 2 : programmer le déplacement du personnage

Une fois le décor prêt, il s'agit de programmer le déplacement du lutin à l'aide des touches directionnelles du clavier. La méthode la plus robuste, et la plus couramment enseignée, consiste à utiliser quatre scripts séparés, chacun déclenché par l'événement « quand la touche [flèche] est pressée », contenant un bloc de mouvement correspondant : « changer x de -5 » pour la flèche gauche, « changer x de 5 » pour la droite, « changer y de 5 » pour le haut, et « changer y de -5 » pour le bas. Cette approche par changement de coordonnées, plutôt que par les blocs « avancer » couplés à une orientation, est préférée dans un labyrinthe car elle garantit un déplacement toujours horizontal ou vertical, sans risque de rotation intempestive du personnage.

Une variante plus avancée, adaptée aux élèves de 4e déjà à l'aise, consiste à englober ces déplacements dans une boucle « répéter indéfiniment » couplée à des blocs « si la touche… est pressée, alors », ce qui permet un déplacement continu et fluide tant que la touche reste enfoncée, plutôt qu'un déplacement par à-coups à chaque pression. Cette variante introduit une nuance importante entre les événements ponctuels (« quand la touche est pressée ») et les tests continus dans une boucle (« si la touche est pressée »), une distinction qui mérite d'être explicitement discutée en classe.

Étape 3 : détecter les collisions avec les murs

C'est ici que se situe le cœur technique du projet, et la principale difficulté pour un élève de collège. Scratch propose un bloc capteur « touche la couleur… » qui renvoie vrai ou faux selon que le lutin touche ou non une couleur précise sélectionnée par une pipette sur la scène. La logique du jeu consiste donc à vérifier en permanence, dans une boucle « répéter indéfiniment », si le lutin touche la couleur des murs du labyrinthe : si c'est le cas, le personnage doit revenir à sa position de départ, ce qui simule un échec et oblige le joueur à recommencer son parcours.

Le script correspondant associe donc une boucle infinie, une condition « si… alors » testant le contact avec la couleur des murs, et à l'intérieur de cette condition, des blocs « aller à x: [valeur] y: [valeur] » qui replacent le lutin à son point de départ. Il est pédagogiquement intéressant de faire tester aux élèves une version sans cette gestion de collision, pour qu'ils constatent par eux-mêmes que le personnage traverse alors les murs sans aucune contrainte, avant d'ajouter le script de collision et d'observer le changement de comportement. Cette démarche expérimentale ancre bien mieux la compréhension du rôle de chaque bloc que la simple lecture d'une solution toute faite.

Étape 4 : gérer la victoire et ajouter un chronomètre

Un jeu de labyrinthe complet doit également détecter la victoire, généralement en testant le contact avec la couleur de la zone d'arrivée, selon le même principe que la détection des murs : un bloc « si touche la couleur [arrivée], alors » déclenche l'affichage d'un message de victoire, l'arrêt du programme via le bloc « stop tout », et éventuellement un son de célébration. Pour enrichir le projet, il est courant d'ajouter une variable « chrono » qui s'incrémente automatiquement grâce à une boucle contenant un bloc « attendre 1 seconde » suivi de « ajouter 1 au chrono », ce qui permet de chronométrer la performance du joueur et d'introduire une dimension de défi et de rejouabilité.

Cette étape est également l'occasion d'introduire une variable « nombre d'essais », incrémentée à chaque fois que le personnage touche un mur, ce qui permet de comptabiliser les échecs du joueur et d'ajouter une dimension de scoring au-delà du simple chronomètre. Ces ajouts, bien que facultatifs, transforment un exercice technique en un véritable petit jeu abouti, avec lequel les élèves prennent généralement grand plaisir à jouer et à faire jouer leurs camarades.

Étape 5 : complexifier le projet pour aller plus loin

Une fois la version de base fonctionnelle, plusieurs pistes permettent d'approfondir le projet selon le niveau de la classe. On peut ajouter plusieurs niveaux de labyrinthe, chacun sur un arrière-plan différent, avec un système de variable « niveau » qui détermine quel arrière-plan afficher et qui progresse à chaque succès. On peut également introduire des obstacles mobiles, comme un ennemi qui se déplace automatiquement dans le labyrinthe et qu'il faut éviter en plus des murs, ce qui mobilise à nouveau la détection de collision, mais cette fois entre deux lutins plutôt qu'entre un lutin et une couleur d'arrière-plan.

Pour les élèves de 3e ayant déjà une bonne maîtrise de Scratch, une piste supplémentaire consiste à intégrer un capteur physique externe, comme une manette micro:bit connectée via l'extension officielle, pour contrôler le déplacement du personnage par inclinaison plutôt qu'au clavier, ce qui fait le lien entre programmation logicielle et objet technique, une compétence particulièrement valorisée lors de la présentation de projets à l'oral du brevet.

Conclusion

Le jeu de labyrinthe constitue un projet de synthèse idéal pour clore un cycle d'apprentissage de Scratch au collège, car il assemble de manière cohérente et motivante l'ensemble des notions travaillées séparément lors des séances précédentes : mouvement, détection de collision, conditions, variables et boucles. En suivant une progression en cinq étapes claires, du décor jusqu'aux fonctionnalités avancées comme le chronomètre ou les niveaux multiples, chaque élève peut avancer à son rythme tout en produisant un résultat concret et gratifiant, qu'il pourra fièrement présenter à ses camarades ou même réutiliser comme support de projet pour l'oral du brevet en classe de 3e.

FAQ : questions fréquentes sur le jeu de labyrinthe en Scratch

1. Pourquoi mon personnage traverse-t-il les murs sans être bloqué ?
Cela signifie que le script de détection de collision, utilisant le bloc « touche la couleur… », n'est pas correctement configuré ou n'est pas placé dans une boucle qui s'exécute en continu. Il faut vérifier que la couleur sélectionnée avec la pipette correspond exactement à la couleur des murs du labyrinthe.

2. Quelle taille donner au personnage pour qu'il passe bien dans les couloirs ?
Il n'existe pas de valeur universelle : cela dépend directement de la largeur des couloirs dessinés dans l'arrière-plan. La règle générale est de réduire la taille du lutin jusqu'à ce qu'il puisse circuler confortablement sans toucher les murs en ligne droite, ce qui demande souvent quelques ajustements par tâtonnement.

3. Faut-il utiliser les blocs « avancer » ou « changer x/y » pour le déplacement ?
Pour un labyrinthe classique avec des déplacements horizontaux et verticaux, les blocs « changer x de » et « changer y de » sont recommandés, car ils évitent toute rotation involontaire du personnage, contrairement au bloc « avancer » qui dépend de l'orientation actuelle du lutin.

4. Comment ajouter plusieurs niveaux de labyrinthe différents ?
Il faut créer plusieurs arrière-plans distincts dans l'onglet correspondant, puis utiliser une variable « niveau » associée à un bloc « basculer sur l'arrière-plan… » pour afficher le bon labyrinthe selon la progression du joueur, généralement déclenché après la détection de la zone d'arrivée du niveau précédent.

5. Ce projet convient-il à un élève de 5e ou faut-il attendre la 4e ?
La version de base, sans chronomètre ni niveaux multiples, est tout à fait accessible à une classe de 5e ayant déjà travaillé les notions de boucle et de condition. Les fonctionnalités avancées, comme les niveaux multiples ou les obstacles mobiles, sont davantage adaptées à une classe de 4e ou de 3e.

6. Peut-on présenter ce projet à l'oral du brevet ?
Oui, ce type de projet constitue un excellent support de présentation à l'oral du brevet, en particulier s'il est enrichi d'une réflexion sur les difficultés rencontrées et les solutions techniques apportées, comme la gestion des collisions ou l'ajout d'un capteur physique externe.

0 commentaire

Laisser un commentaire

Veuillez noter que les commentaires doivent être approuvés avant leur publication.