Route du Rhum
Dans cette activité, les makers vont réaliser un jeu autour de la célèbre course de la Route du Rhum. Ils vont coder les déplacements d’un voilier ainsi que les vents qui vont influencer ses déplacements, en s’inspirant des vents réels qui guident les décisions des navigateurs lors de cette course légendaire.
Objectifs pédagogiques
Compétences techniques
- Conditions et boucles
- Gestion des collisions et hitbox
- Variables
- Orientation et déplacements des sprites
- Créer un effet de poussée avec le vent
- Changer d’arrière-plan selon une condition
- Créer un chronomètre
- Arrêter et déclencher différents comportements dans un même sprite
Compétences design
- Personnaliser les sprites et les décors
- Améliorer l’apparence et l’expérience de jeu
- Ajouter des éléments ou fonctionnalités bonus à son projet
Compétences projet
- Récupérer et remixer un projet existant
- Décomposer une mécanique complexe en plusieurs étapes
- Tester et débugger son jeu
- Améliorer son projet en autonomie
- Présenter et faire tester son projet
3 séances de 1h30
Jour 1
Jour 2
Jour 3
Jour 4
Jour 5
1h
30 min
30 min
1h
Ressources
- projet exemple : à remixer, projet jour 1, projet complet, projet avec bonus
- ressource pas à pas makers
Matériel
- Un compte scratch
- Les comptes scratch makers que tu as créés pour les activités précédentes
- Un studio
Déroulé de l'activité
Segmentation de l’activité
- Segment 1 (1h) : Récupération du projet et déplacement
- Segment 2 (30 min) : Hitbox
- Segment 3 (30 min) : Déplacement du Vent de Saint malo
- Segment 4 (1h) : L’Atlantique
- Segment 5 (1h) : Terminer la course
- Segment 6 (30 min) : Amélioration et partage de projet
Détail de l’activité
Segment 1 (1H) : Récupération du projet et déplacement
1/ Présentation et récupération du projet (20 min)
Oui, tu me l’avais bien demandé. Je te le remets directement ici :
Commence par présenter le projet aux makers et demande-leur ce qu’ils connaissent déjà de la Route du Rhum.
Tu peux compléter leurs réponses avec quelques informations simples :
- La Route du Rhum est une course internationale de voile qui traverse l’océan Atlantique.
- Les bateaux partent de Saint-Malo, en Bretagne.
- Les skippers doivent rejoindre Pointe-à-Pitre, en Guadeloupe.
- Chaque skipper navigue seul, sans équipage.
- Pour avancer le plus efficacement possible, il doit observer les vents et choisir sa trajectoire.
Présente ensuite le projet que les makers vont réaliser : un jeu dans lequel ils vont programmer un voilier et reproduire certaines contraintes rencontrées pendant la course, notamment l’influence du vent sur sa trajectoire.
Fais-leur récupérer le projet à cette adresse et demande-leur d’en créer un remix. En atelier présentiel, si tu peux arriver un peu en avance, tu peux préparer les remix directement sur les ordinateurs des makers.
Explique-leur que le projet contient déjà les principaux sprites et décors. L’objectif n’est pas de passer du temps à chercher des images, mais de se concentrer sur la programmation du jeu.
À eux maintenant de rendre ce projet fonctionnel en programmant progressivement les déplacements du bateau, les collisions, les vents et le passage de Saint-Malo à l’Atlantique.
2/ Déplacements du Bateau (40 min)
Explique aux makers qu’ils vont commencer par programmer les déplacements du voilier.
Dans notre jeu, le bateau pourra :
- tourner à droite ou à gauche pour changer de direction ;
- avancer dans la direction vers laquelle il est orienté ;
- reculer pour pouvoir se dégager lorsqu’il rencontre un obstacle.
Précise que cette marche arrière est surtout une mécanique de jeu : dans la réalité, un voilier ne recule évidemment pas de cette manière.
Commence par leur demander comment l’ordinateur peut savoir qu’une touche du clavier est utilisée. Amène-les progressivement à comprendre que le programme doit vérifier en permanence si une touche est enfoncée, puis déclencher l’action correspondante.
Profite de cette étape pour introduire ou rappeler deux notions importantes :
- la boucle infinie, qui permet de vérifier continuellement les actions du joueur ;
- les conditions, qui permettent de déclencher une action seulement lorsqu’une touche précise est pressée.
Demande d’abord aux makers de programmer la rotation du bateau avec les flèches droite et gauche.
Une fois cette première étape réussie, fais-leur ajouter les déplacements vers l’avant et vers l’arrière. Ils découvriront ainsi qu’une valeur positive permet au bateau d’avancer, tandis qu’une valeur négative permet de le faire reculer.
L’objectif est de construire les déplacements progressivement afin que les makers comprennent le rôle de chaque bloc avant de passer à la gestion des collisions.
Segment 2 (30min) : Hitbox
1/ Explication (10 min)
Demande aux makers s’ils connaissent le terme hitbox et s’ils savent à quoi elle peut servir dans un jeu vidéo.
Explique leur qu’une hitbox est une zone invisible utilisée pour détecter les collisions. Elle peut être placée autour d’un personnage, d’un objet ou d’un élément du décor afin de permettre au programme de savoir quand deux éléments se touchent.
Dans notre projet, une hitbox a déjà été créée autour du port de Saint-Malo. Elle est nécessaire car le port fait partie de l’arrière-plan : Scratch ne peut donc pas détecter directement une collision avec lui.
Montre cette hitbox aux makers et explique-leur que son rôle est uniquement de représenter la zone dans laquelle le bateau ne doit pas pouvoir entrer.
Précise qu’ils n’auront pas besoin de modifier son code. Le script déjà présent sert simplement à rendre la hitbox invisible lorsque la partie commence.
Explique leur qu’ils vont maintenant utiliser cette hitbox pour programmer la réaction du bateau lorsqu’il touche les limites du port.
2/ Réaction à la collision (20 min)
Demande aux makers ce que le bateau devrait faire lorsqu’il touche la hitbox.
Laisse-les d’abord proposer leurs idées. S’ils ne trouvent pas, aide-les à raisonner à partir du mouvement qui vient d’être effectué.
Explique-leur que si le bateau touche la hitbox, c’est qu’il vient d’entrer dans une zone interdite. Il faut donc annuler son dernier mouvement pour le replacer juste avant la collision.
Demande-leur comment ils pourraient faire cela.
Amène-les progressivement à comprendre qu’il suffit d’effectuer le mouvement inverse :
- si le bateau vient d’avancer, on le fait légèrement reculer ;
- s’il vient de reculer, on le fait légèrement avancer ;
- s’il vient de tourner à droite, on le fait tourner dans l’autre sens ;
- s’il vient de tourner à gauche, on effectue la rotation inverse.
Les makers peuvent ensuite ajouter cette vérification après chacun des déplacements du bateau.
L’objectif est qu’ils comprennent qu’une collision ne bloque pas automatiquement un sprite dans Scratch : c’est à eux de programmer la réaction qui permettra de simuler cet obstacle.
Segment 3 (30min) : Déplacement du Vent de Saint malo
1/ Déplacement du vent (30 min)
Demande aux makers ce que le vent devra faire dans leur jeu. Amène-les à identifier deux éléments importants : le vent doit se déplacer et il doit pouvoir pousser le bateau lorsqu’il le rencontre.
Avant de programmer son déplacement, demande-leur de réfléchir à une autre question : de quelle information le bateau aura-t-il besoin pour savoir dans quelle direction être poussé ?
L’objectif est de leur faire comprendre que le bateau devra connaître la direction du vent, c’est-à-dire son angle.
Demande ensuite aux makers de programmer le déplacement du vent en décomposant le problème en plusieurs étapes :
- placer le vent à sa position de départ ;
- l’orienter dans la bonne direction ;
- enregistrer sa direction ;
- le faire avancer ;
- répéter ce déplacement pour lui faire traverser la zone.
Pour que le bateau puisse utiliser la direction du vent plus tard, il faut maintenant conserver cette information.
Explique aux makers que nous allons pour cela utiliser une variable. Une variable permet de mémoriser une information qui pourra ensuite être réutilisée ou modifiée pendant le fonctionnement du programme.
Crée avec eux une variable pour enregistrer l’angle du vent, puis montre-leur comment y stocker sa direction grâce au bloc direction.
Précise que cette valeur ne sera pas utilisée immédiatement. Elle sera récupérée dans l’étape suivante pour permettre au bateau de savoir dans quelle direction il doit être poussé lorsqu’il touche le vent.
Une fois ce premier déplacement testé, demande aux makers d’observer ce qui se passe : le vent avance bien, mais seulement sur une très courte distance.
Profite-en pour introduire le bloc répéter X fois. Demande-leur ce qu’ils pourraient faire pour éviter de recopier plusieurs fois le même bloc avancer.
Explique que cette boucle permet de répéter automatiquement une même action un nombre défini de fois. En plaçant le déplacement du vent à l’intérieur, ils peuvent ainsi lui faire parcourir toute la distance souhaitée.
Enfin, fais-leur remarquer que l’ensemble est placé dans une boucle répéter indéfiniment : une fois son trajet terminé, le vent revient à son point de départ et recommence.
S’il reste du temps, laisse les modifier sa position, son orientation, sa vitesse ou la longueur de son trajet pour observer l’effet de leurs changements.
Segment 4 (1H) : L’Atlantique
1/ Poussé le bateau (20 min)
Explique aux makers que le vent est maintenant capable de se déplacer et que sa direction est enregistrée dans une variable. Il faut à présent programmer le bateau pour qu’il réagisse lorsqu’il touche le vent.
Commence par leur poser la question :
Comment faire pour que le bateau soit poussé dans la même direction que le vent ?
Amène-les à comprendre qu’il faut :
- détecter si le bateau touche le vent ;
- mémoriser la direction actuelle du bateau ;
- orienter temporairement le bateau dans la direction du vent ;
- le faire avancer pour simuler la poussée ;
- lui redonner ensuite sa direction d’origine.
Pose-leur ensuite une nouvelle question :
Mais si on tourne le bateau dans la direction du vent, comment pourra-t-il retrouver son orientation précédente ?
C’est ici que tu peux réintroduire la notion de variable.
Explique qu’une nouvelle variable va permettre de conserver temporairement la direction du bateau avant de le tourner.
Décortique ensuite le code avec les makers :
- Dans une boucle infinie, vérifier si le bateau touche le vent.
- Enregistrer la direction actuelle du bateau dans une variable.
- Orienter le bateau dans la direction enregistrée par la variable du vent.
- Le faire avancer de quelques pas pour simuler la poussée.
- Réorienter le bateau dans sa direction d’origine grâce à la variable enregistrée au début.
Fais ensuite tester le résultat aux makers et demande-leur d’observer ce qui se passe lorsqu’ils rencontrent le vent sous différents angles.
Tu peux aussi leur faire modifier légèrement la distance de poussée pour voir comment cela influence le comportement du bateau.
2/ Sortir de Saint Malo pour l’altantique (15 min)
Explique aux makers qu’ils vont maintenant quitter la zone de Saint-Malo pour passer à l’Atlantique. Demande leur d’abord de réfléchir à la condition qui pourrait déclencher ce changement : que doit-il se passer lorsque le bateau touche la flèche rose ?
Laisse les proposer leur solution avant de les guider.
Ils devront utiliser une condition pour détecter le contact avec la flèche, puis changer l’arrière-plan de Saint-Malo vers l’Atlantique.
La plupart des makers devraient pouvoir retrouver seuls les blocs nécessaires à partir de ce qu’ils ont déjà utilisé dans le projet. Profite de cette étape pour laisser davantage d’autonomie à ceux qui sont à l’aise, tout en accompagnant ceux qui en ont besoin.
C’est aussi un bon moment pour faire un petit point rapide avec les makers qui rencontrent encore des difficultés sur les conditions ou les changements d’arrière-plan.
3/ Vent de l’Atlantique (25 min)
Explique aux makers que le comportement du vent va maintenant changer.
Dans l’Atlantique, le vent ne traversera plus simplement l’écran en ligne droite : il va tourner en continu pour créer une nouvelle contrainte de navigation.
Avant de programmer ce nouveau mouvement, fais-leur remarquer un problème : le vent possède déjà un script de déplacement utilisé à Saint-Malo.
Demande-leur ce qui risque de se passer si ce premier script continue de fonctionner en même temps que le nouveau.
Amène-les à comprendre qu’il faut d’abord arrêter l’ancien comportement pour éviter que les deux déplacements se mélangent.
Montre-leur comment utiliser le bloc stop autres scripts dans sprite, puis fais repositionner et orienter le vent à son point de départ dans l’Atlantique.
Demande ensuite aux makers comment ils pourraient faire pour que le vent tourne en cercle.
Laisse-les proposer leurs idées, puis amène-les à identifier deux actions simples :
- avancer ;
- tourner légèrement.
Explique qu’en répétant ces deux actions en continu, le vent va progressivement dessiner une trajectoire circulaire.
Les makers peuvent alors placer ces blocs dans une boucle répéter indéfiniment.
Attire enfin leur attention sur la variable AngleVent : contrairement au vent de Saint-Malo, la direction change maintenant en permanence.
Il faut donc mettre à jour la variable à chaque tour de boucle pour que le bateau connaisse toujours la direction actuelle du vent lorsqu’il le touche.
Fais-leur tester le résultat et, s’ils ont le temps, modifier la valeur du déplacement ou de la rotation pour observer comment cela change la forme et la vitesse du trajet.
Segment 5 (1H) : Terminer la course
Chrono (15 min)
Explique aux makers qu’il reste maintenant un dernier élément important à ajouter pour transformer leur projet en véritable course : le chronomètre.
Demande-leur d’abord à quoi peut servir un chrono dans ce type de jeu. Amène-les à comprendre qu’il permet de mesurer le temps mis par le joueur pour rejoindre l’arrivée et donc de comparer plusieurs tentatives.
À ce stade du projet, les makers ont déjà utilisé des variables, des conditions et des boucles. Propose-leur donc de chercher eux-mêmes comment construire ce nouveau mécanisme avant de leur montrer la solution.
Ils devront :
- récupérer la valeur du chronomètre de Scratch ;
- l’enregistrer dans une variable ;
- vérifier en permanence si le bateau atteint l’arrivée ;
- afficher l’écran de victoire lorsque la course est terminée.
Tu peux réaliser cette étape avec eux en partageant ton écran, tout en leur demandant régulièrement quel bloc ils utiliseraient ensuite
L’objectif est de leur permettre de réinvestir les notions déjà vues dans le projet et de constater qu’ils sont maintenant capables de construire une mécanique complète avec davantage d’autonomie.
Projet libre (45 min)
Les principales mécaniques du jeu sont maintenant terminées. Laisse les makers prendre davantage d’autonomie pour améliorer et personnaliser leur projet.
Ils peuvent par exemple :
- modifier certains éléments graphiques
- ajouter des obstacles ou des éléments de décor
- ajuster la difficulté
- améliorer l’écran de victoire
- ajouter de nouvelles fonctionnalités ou des bonus
L’objectif n’est pas forcément d’ajouter beaucoup de choses, mais de leur laisser le temps de faire des choix, de tester leurs idées et de rendre leur projet plus personnel. Encourage les à tester régulièrement leur jeu pendant cette phase afin de vérifier que leurs modifications fonctionnent correctement.
Tu peux t’appuyer sur la liste de bonus proposée ici pour accompagner ceux qui manquent d’idées.
Segment 6 (30min) : Amélioration et partage de projet
Projet libre – suite (15 min)
Continue à circuler entre les makers pour observer leurs projets et les aider en cas de difficulté. Profite de ce temps pour les accompagner dans leurs derniers tests, leur débogage et la gestion du temps avant la présentation finale.
Valorise également leurs initiatives : une mécanique originale, une amélioration bien pensée, un choix graphique intéressant ou une difficulté qu’ils ont réussi à résoudre seuls.
Préviens les quelques minutes avant la fin afin qu’ils puissent terminer proprement leur projet et préparer ce qu’ils souhaitent montrer aux autres.