Atlantis Aquarium Madrid visite : quels blocs Scratch choisir ?

Atlantis Aquarium Madrid visite: quels blocs Scratch choisir?

Il ne s’agit pas d’un algorithme.

Pour modéliser une visite de l’Atlantis Aquarium Madrid avec Scratch, il faut d’abord définir les données, puis les déplacements, puis les interactions. L’aquarium réel, situé dans le centre commercial intu Xanadú à Arroyomolinos, offre une base concrète: environ 6 000 m², 20 bassins ou écosystèmes, environ 150 espèces et plus de 10 000 animaux marins. La simulation ne reproduira pas toute cette installation. Elle en représentera la structure.

Le choix des blocs dépend donc de la fonction attendue:

• les blocs Événements démarrent le programme;
• les blocs Mouvement déplacent le visiteur ou les animaux;
• les blocs Contrôle organisent les répétitions et les conditions;
• les blocs Apparence modifient les décors et les dialogues;
• les blocs Capteurs détectent les contacts;
• les blocs Variables mémorisent les billets, les bassins visités et le score.

Dans une simulation Scratch, le décor représente l’espace. Les variables représentent l’état du système. Sans état mémorisé, il n’y a pas de visite programmée.

Structurer les 20 écosystèmes de l’Atlantis Aquarium dans Scratch

Une visite virtuelle doit être discrétisée. Le terme est technique. Il signifie que l’espace continu de l’aquarium est remplacé par un nombre fini de zones.

Ici, le modèle peut utiliser 20 écosystèmes. Chaque écosystème devient un arrière-plan, une zone du décor ou une étape numérotée. Le choix dépend du niveau de détail recherché.

Trois modèles possibles

Modèle 1: un arrière-plan par écosystème

Chaque bassin est associé à un arrière-plan différent:

• Écosystème 1
• Écosystème 2
• Écosystème 3
• jusqu’à Écosystème 20

Le lutin du visiteur reste visible. Lorsque le joueur atteint une sortie, le programme bascule vers l’arrière-plan suivant.

Ce modèle est simple. Il convient à une première simulation. Il ne représente pas les déplacements à l’intérieur d’un bassin. Il représente seulement l’ordre du parcours.

Modèle 2: un seul plan avec 20 zones

Le décor contient l’ensemble du parcours. Les 20 écosystèmes sont dessinés sur une même image. Chaque zone possède une position ou une couleur de référence.

Le lutin du visiteur se déplace avec les coordonnées x et y. Une zone peut être considérée comme visitée lorsque le lutin entre dans une région donnée.

Ce modèle demande davantage de conditions. Il permet toutefois de simuler un déplacement libre.

Modèle 3: un arrière-plan par grande étape

Les 20 écosystèmes sont regroupés en quelques séquences. Par exemple:

• entrée et présentation;
• milieux d’eau douce;
• espaces marins;
• espèces particulières;
• sortie et bilan.

Le nombre exact de décors est alors inférieur à 20. Une variable indique le numéro précis du bassin dans le décor courant.

Ce modèle réduit le nombre d’images. Il conserve une numérotation complète. Il est adapté à un projet qui doit rester lisible.

La variable ecosysteme

Créer une variable ecosysteme pour tous les lutins.

Au début du programme, sa valeur doit être définie:

1. cliquer sur le drapeau vert;

2. mettre ecosysteme à 1;

3. basculer sur l’arrière-plan de départ;

4. placer le lutin du visiteur à l’entrée.

En notation algorithmique:

• si le drapeau vert est cliqué;
• alors ecosysteme ← 1;
• et le décor devient Entrée.

Dans Scratch, le bloc de départ est « quand le drapeau vert est cliqué ». Il appartient à la catégorie Événements. Sans ce bloc, le script ne possède pas de déclencheur principal.

Faire progresser le numéro du bassin

Lorsque le visiteur atteint la zone de sortie, la variable augmente de 1:

• si le visiteur touche la sortie;
• alors ecosysteme ← ecosysteme + 1;
• puis le décor change;
• enfin le visiteur est placé à la nouvelle entrée.

Il faut éviter une erreur classique: augmenter la variable à chaque répétition de la boucle tant que le contact existe. Le programme pourrait passer de l’écosystème 4 à l’écosystème 5, puis 6, puis 7 en une fraction de seconde.

La correction repose sur une condition supplémentaire. Après le changement, le programme doit attendre que le visiteur ne touche plus la sortie.

Exemple de logique:

1. vérifier si la sortie est touchée;

2. augmenter ecosysteme;

3. changer de décor;

4. attendre jusqu’à ce que la sortie ne soit plus touchée.

La répétition ne doit pas confondre un contact unique avec une suite de contacts.

Programmer les déplacements avec les blocs Mouvement

Le déplacement est une transformation de coordonnées. Le lutin possède une position:

• x pour l’axe horizontal;
• y pour l’axe vertical.

Dans Scratch, les blocs de la catégorie Mouvement permettent d’agir sur ces coordonnées. Les deux blocs essentiels sont:

• « aller à x:... y:... »;
• « avancer de... pas ».

Le premier impose une position. Le second modifie la position en fonction de l’orientation du lutin.

Déplacement dirigé

Pour un parcours imposé, il est préférable d’utiliser des positions précises:

1. aller à l’entrée;

2. avancer vers le premier bassin;

3. tourner;

4. atteindre la zone d’observation;

5. rejoindre la sortie.

Le bloc « aller à x:... y:... » donne un résultat déterministe. Le lutin commence toujours au même endroit. Cette propriété est utile pour tester le programme.

Le bloc « avancer de... pas » produit un mouvement plus progressif. Il convient lorsque le joueur contrôle le lutin avec les touches du clavier.

Un script de déplacement peut suivre cette logique:

• quand le drapeau vert est cliqué;
• aller à la position de départ;
• répéter indéfiniment:
• si la touche flèche droite est pressée, avancer de quelques pas;
• si la touche flèche gauche est pressée, avancer de quelques pas avec une orientation opposée;
• si la touche flèche haut est pressée, modifier la coordonnée y;
• si la touche flèche bas est pressée, modifier la coordonnée y.

Les blocs de détection des touches appartiennent aux Capteurs. Le déplacement reste cependant une opération de la catégorie Mouvement.

Orientation du lutin

L’orientation crée une autre source d’erreur. Si le lutin regarde vers la droite, avancer de 10 pas augmente généralement sa position horizontale. Si le lutin regarde vers la gauche, le déplacement s’effectue dans l’autre direction.

Deux solutions sont possibles:

• régler le sens du lutin avant chaque déplacement;
• modifier directement x et y.

Pour une simulation pédagogique, la seconde solution est souvent plus contrôlable. Le programme peut imposer:

• x ← x + 5 pour aller vers la droite;
• x ← x - 5 pour aller vers la gauche;
• y ← y + 5 pour monter;
• y ← y - 5 pour descendre.

Scratch utilise ses propres blocs pour modifier les coordonnées. L’idée algorithmique reste la même: chaque touche produit une variation calculée.

Limiter le visiteur à la scène

Un lutin peut sortir de l’écran si aucune condition ne limite ses coordonnées. Il faut donc empêcher les valeurs trop grandes ou trop petites.

Par exemple:

• si x est supérieur à la limite droite, alors fixer x à cette limite;
• si x est inférieur à la limite gauche, alors fixer x à cette limite;
• appliquer la même règle à y.

La structure conditionnelle est toujours identique:

• si la condition est vraie;
• alors appliquer la correction.

Le mouvement n’est pas seulement une suite de blocs avancer. Il doit respecter les limites du modèle.

Gérer les interactions avec les blocs Capteurs

Un aquarium simulé devient interactif lorsque le programme détecte une action. Le visiteur peut toucher un animal, une sortie, un panneau ou une zone d’observation.

La catégorie Capteurs fournit le bloc « toucher le [lutin/pointeur de souris]? ». Ce bloc renvoie une valeur logique:

• vrai si le contact existe;
• faux dans le cas contraire.

Cette valeur doit être placée dans une condition.

Collision avec un animal marin

Créer un lutin pour un animal marin. Le visiteur se déplace sur la scène. Le script de l’animal peut vérifier le contact:

1. répéter indéfiniment;

2. si le visiteur touche l’animal;

3. alors modifier le score;

4. afficher une information;

5. attendre la fin du contact.

La variable score évite de compter plusieurs fois le même contact. Sans protection, la boucle peut ajouter des points à chaque tour de répétition.

Une méthode robuste consiste à utiliser une variable animal_deja_observe:

• au départ, mettre animal_deja_observe à 0;
• si le visiteur touche l’animal et que animal_deja_observe = 0, alors augmenter le score;
• mettre animal_deja_observe à 1;
• attendre que le visiteur ne touche plus l’animal.

Le point essentiel est l’état mémorisé. Le contact est un événement temporaire. La variable conserve l’information selon laquelle l’animal a déjà été comptabilisé.

Collision avec la sortie

La sortie peut déclencher le passage à l’écosystème suivant. Le principe est analogue:

• si le lutin du visiteur touche le lutin Sortie;
• alors augmenter ecosysteme;
• changer d’arrière-plan;
• déplacer le visiteur vers la nouvelle zone de départ.

Il faut également traiter la limite finale:

• si ecosysteme < 20, passer à l’écosystème suivant;
• sinon, afficher le bilan de la visite et arrêter le parcours.

La comparaison avec 20 n’est pas décorative. Elle empêche le programme de demander un vingt-et-unième bassin qui n’existe pas dans le modèle.

Détection d’un clic

Le bloc « quand ce lutin est cliqué » convient à une interaction directe. Un clic sur un animal peut:

• afficher son nom;
• modifier une variable;
• déclencher un son;
• changer de costume;
• afficher une question.

Cette méthode ne simule pas un déplacement physique. Elle crée une interaction par sélection. Le choix dépend donc de la consigne.

Utiliser les variables pour simuler les billets et les flux

Le mot billets peut désigner plusieurs données. Il faut choisir une définition précise. Une variable ne doit pas recevoir une valeur vague.

Pour une simulation simple, utiliser:

• billets_adultes;
• billets_enfants;
• prix_adulte;
• prix_enfant;
• total.

La variable total est calculée. Elle ne doit pas être saisie manuellement après chaque modification.

Calculer le prix

Les tarifs observés pour un billet adulte peuvent varier selon le revendeur et le format, avec une fourchette indiquée entre 9,90 € et 16,89 €. Cette donnée peut servir d’exemple de modélisation. Elle ne constitue pas une valeur fixe à afficher comme tarif universel.

Dans Scratch, le calcul suit la priorité opératoire habituelle:

total = billets_adultes × prix_adulte + billets_enfants × prix_enfant

Les multiplications doivent être effectuées avant les additions. Si l’expression est construite avec les blocs opérateurs de Scratch, il faut conserver cette structure.

Étapes:

1. mettre billets_adultes à une valeur initiale;

2. mettre billets_enfants à une valeur initiale;

3. définir prix_adulte;

4. définir prix_enfant;

5. calculer total;

6. afficher le résultat.

Si le projet ne dispose pas d’un tarif enfant vérifié, ne pas inventer une donnée présentée comme officielle. Utiliser une valeur pédagogique clairement définie dans l’exercice, ou limiter le modèle aux billets adultes.

Vérifier la capacité simulée

Le nombre réel d’animaux marins et le volume d’eau ne représentent pas directement la capacité d’accueil des visiteurs. Il ne faut donc pas déduire un nombre maximal de personnes à partir des 2 000 000 de litres d’eau ou des 10 000 animaux.

Pour simuler un flux, créer une variable indépendante:

• visiteurs_entres;
• visiteurs_sortis;
• visiteurs_dans_aquarium.

La formule est:

visiteurs_dans_aquarium = visiteurs_entres - visiteurs_sortis

Le programme doit empêcher un résultat négatif. Si visiteurs_sortis devient supérieur à visiteurs_entres, le modèle contient une erreur de séquence.

Une autre variable peut représenter une limite choisie pour l’exercice:

• capacite_simulee.

Cette valeur n’est pas une capacité officielle de l’Atlantis Aquarium Madrid. C’est un paramètre du modèle. La distinction doit rester visible dans le projet.

Décider l’accès à la visite

Le programme peut utiliser une condition:

• si visiteurs_dans_aquarium < capacite_simulee, alors autoriser l’entrée;
• sinon, afficher un message d’attente.

La logique devient:

1. compter les visiteurs entrants;

2. calculer le nombre présent;

3. comparer avec la capacité simulée;

4. autoriser ou refuser l’entrée;

5. mettre à jour le nombre.

Cette structure permet de travailler simultanément les variables, les opérateurs et les conditions.

Éviter le double comptage

Un clic maintenu ou un lutin placé sur une zone peut déclencher plusieurs fois le même ajout. Il faut donc créer un verrou logique.

Variable:

entree_comptee

Séquence:

1. si le visiteur touche la zone d’entrée et entree_comptee = 0;

2. alors ajouter 1 à visiteurs_entres;

3. mettre entree_comptee à 1;

4. attendre que le visiteur quitte la zone;

5. remettre entree_comptee à 0.

La variable joue le rôle d’un état binaire. Elle vaut 0 avant le comptage et 1 pendant le contact. Donc une seule entrée est enregistrée par passage.

Animer le parcours avec Apparence et Contrôle

Les blocs Apparence rendent l’état du programme visible. Ils ne remplacent pas les calculs. Ils les affichent.

Les blocs utiles sont notamment:

• « basculer sur l’arrière-plan... »;
• « costume suivant »;
• « dire... pendant... secondes ».

Les blocs Contrôle déterminent le rythme et la répétition:

• « répéter indéfiniment »;
• « si... alors »;
• « attendre... secondes ».

Changer de décor

Le décor peut changer lorsque ecosysteme est modifié. Deux méthodes sont possibles.

Méthode directe

Créer 20 conditions:

• si ecosysteme = 1, basculer sur Écosystème 1;
• si ecosysteme = 2, basculer sur Écosystème 2;
• continuer jusqu’à 20.

Cette méthode est longue. Elle est néanmoins lisible pour un premier exercice.

Méthode par message

Le script principal modifie la variable, puis envoie un message:

• écosystème suivant.

Le décor reçoit ce message et effectue le changement. Cette organisation sépare les responsabilités:

• le script du visiteur gère la progression;
• le script de la scène gère l’affichage;
• les lutins marins gèrent leurs propres interactions.

La séparation réduit les erreurs. Un seul script ne doit pas gérer simultanément les déplacements, le score, les billets et les décors.

Faire parler un guide virtuel

Un lutin-guide peut expliquer la zone courante. Le texte peut dépendre de la variable ecosysteme.

Exemple de logique:

• si ecosysteme = 1, dire une présentation de l’entrée;
• si ecosysteme = 2, dire une information sur le deuxième espace;
• si ecosysteme = 20, annoncer la fin du parcours.

Le bloc « dire... pendant... secondes » est adapté à une phrase courte. Une durée trop faible rend le message illisible. Une durée trop longue bloque le déroulement si elle est placée dans une séquence principale.

Pour éviter ce blocage, le guide peut recevoir un message séparé. Le mouvement du visiteur continue alors pendant que le texte s’affiche, selon la structure du projet.

Utiliser attendre

Le bloc « attendre... secondes » sert à contrôler le rythme. Il peut:

• laisser le temps de lire une information;
• empêcher une répétition trop rapide;
• séparer deux changements de costume;
• éviter que plusieurs messages se superposent.

Il ne doit pas être utilisé pour corriger une condition mal construite. Si un animal est compté plusieurs fois, ajouter une attente ne règle pas nécessairement le problème. Il faut mémoriser l’état du contact.

Animer un animal

Un animal marin peut posséder plusieurs costumes. La structure suivante permet une animation simple:

1. répéter indéfiniment;

2. avancer de quelques pas;

3. rebondir si le bord est atteint;

4. attendre un court instant;

5. passer au costume suivant.

Les blocs de mouvement et d’apparence sont ici combinés. La boucle répéter indéfiniment assure la continuité.

L’ordre des blocs produit un résultat différent:

• si le costume change avant le déplacement, l’animation accentue le mouvement;
• si le costume change après l’attente, le déplacement paraît plus lent;
• si aucun temps d’attente n’est présent, le changement peut être trop rapide.

L’algorithme doit donc être lu comme une séquence d’instructions, pas comme une simple liste de blocs.

Construire le programme par étapes

Un projet complet doit être construit progressivement. Ajouter tous les lutins dès le début rend le diagnostic difficile.

Étape 1: initialiser le système

Créer les variables:

• ecosysteme;
• score;
• billets_adultes;
• billets_enfants;
• total;
• visiteurs_dans_aquarium.

Au clic sur le drapeau vert:

• remettre toutes les variables à leurs valeurs initiales;
• afficher le décor d’entrée;
• placer le visiteur;
• masquer les éléments qui ne doivent pas encore apparaître.

Test immédiat: le projet doit toujours démarrer dans le même état.

Étape 2: ajouter le déplacement

Programmer les touches du clavier. Tester chaque direction séparément.

Vérifier:

• le lutin avance dans le bon sens;
• les limites de la scène sont respectées;
• le déplacement ne modifie pas ecosysteme;
• aucune collision n’est encore nécessaire pour faire avancer le projet.

Test immédiat: le visiteur doit pouvoir atteindre la zone de sortie.

Étape 3: ajouter le premier bassin

Ne pas créer les 20 écosystèmes immédiatement. Commencer avec deux décors:

• Entrée;
• Écosystème 1.

Programmer le contact avec la sortie. Si le mécanisme fonctionne, ajouter les décors suivants et remplacer la valeur limite par 20.

Cette progression évite de reproduire 20 fois une erreur présente dans le premier script.

Étape 4: ajouter une interaction

Créer un seul animal marin. Lorsqu’il est touché:

• augmenter score;
• afficher une information;
• empêcher le double comptage.

Tester le contact avant de créer d’autres espèces.

Étape 5: ajouter les billets

Les billets sont des variables numériques. Le programme doit accepter une entrée, enregistrer les quantités et calculer le total.

Vérifier la formule avec des valeurs simples:

• zéro billet;
• un billet adulte;
• deux billets adultes;
• un mélange de catégories.

Un résultat faux avec des valeurs simples indique généralement une erreur d’opérateur ou de priorité.

Étape 6: ajouter les animations

Les costumes, les messages et les déplacements autonomes viennent à la fin. Ils améliorent la représentation. Ils ne doivent pas masquer un défaut de logique.

Erreurs typiques dans une simulation Scratch d’aquarium

Confondre un lutin et un arrière-plan

Un lutin peut se déplacer, être cliqué ou détecter un contact. Un arrière-plan change l’apparence de la scène. Il ne se déplace pas comme un personnage.

Donc:

• utiliser un arrière-plan pour représenter un écosystème;
• utiliser un lutin pour représenter le visiteur;
• utiliser un autre lutin pour représenter une espèce marine ou une sortie.

Mettre toutes les variables pour tous les lutins

Scratch permet de créer une variable pour tous les lutins ou seulement pour un lutin donné.

La variable ecosysteme doit généralement être commune. Elle décrit l’état général de la visite.

Une variable comme animal_deja_observe peut être propre à chaque animal. Sinon, observer un poisson pourrait empêcher le comptage d’un autre poisson.

Le périmètre de la variable doit correspondre à sa fonction.

Oublier la valeur initiale

Une variable non initialisée peut conserver une valeur inattendue pendant les tests. Le programme ne doit jamais dépendre d’un état précédent.

Au démarrage:

• mettre ecosysteme à 1;
• mettre score à 0;
• mettre les compteurs à 0;
• définir les prix utilisés par l’exercice.

L’initialisation est une étape obligatoire, pas une amélioration facultative.

Utiliser une mauvaise priorité opératoire

Pour calculer un total, la multiplication doit précéder l’addition. L’expression correcte est:

quantité × prix + quantité × prix

Une parenthèse mal placée peut modifier le résultat. Les blocs opérateurs doivent être imbriqués selon la formule, puis testés avec des nombres faciles à contrôler.

Répéter une action au lieu de détecter un événement

Une boucle vérifie régulièrement une condition. Elle ne sait pas automatiquement si l’action vient de commencer.

Pour distinguer:

• le visiteur touche l’animal;
• le visiteur reste contre l’animal;

il faut une variable d’état ou une attente jusqu’à la fin du contact.

Cette distinction est fondamentale en algorithmique. Un état durable ne doit pas être traité comme un événement unique.

Dépasser l’écosystème 20

La variable ecosysteme doit rester dans l’intervalle prévu:

1 ≤ ecosysteme ≤ 20

Si le visiteur atteint la sortie du dernier bassin:

• afficher le bilan;
• désactiver le déplacement ou arrêter les scripts concernés;
• ne pas augmenter encore la variable.

Le programme doit gérer la condition finale explicitement.

Version minimale de l’algorithme

La structure suivante résume le fonctionnement général:

1. initialiser ecosysteme à 1;

2. initialiser score à 0;

3. initialiser les compteurs de billets;

4. afficher l’entrée;

5. placer le visiteur;

6. répéter le déplacement tant que la visite n’est pas terminée;

7. si le visiteur touche un animal non observé, augmenter le score;

8. si le visiteur touche la sortie et que ecosysteme < 20, augmenter ecosysteme;

9. changer l’arrière-plan;

10. placer le visiteur dans le nouvel écosystème;

11. si ecosysteme = 20 et que la sortie finale est touchée, afficher le bilan;

12. arrêter la visite.

Chaque étape possède une fonction unique. Si un bloc semble accomplir plusieurs opérations sans relation claire, le script est probablement trop chargé.

Test de vérification rapide

Le test final doit utiliser un parcours court et contrôlé.

1. Cliquer sur le drapeau vert.

2. Vérifier que ecosysteme = 1 et score = 0.

3. Déplacer le visiteur vers un animal.

4. Vérifier que le score augmente une seule fois.

5. Quitter l’animal, puis le toucher de nouveau.

6. Vérifier que le programme applique la règle prévue.

7. Atteindre la sortie.

8. Vérifier que ecosysteme augmente de 1, et non de plusieurs unités.

9. Recommencer jusqu’à l’écosystème 20.

10. Vérifier qu’aucun écosystème 21 n’est créé.

11. Modifier le nombre de billets.

12. Recalculer le total avec une opération simple.

13. Comparer le résultat affiché avec le calcul manuel.

Si un résultat est incorrect, ne pas ajouter immédiatement un nouveau bloc. Identifier d’abord la catégorie en cause:

• mauvais déclencheur: Événements;
• mauvaise position: Mouvement;
• boucle ou condition incorrecte: Contrôle;
• décor ou message incorrect: Apparence;
• contact non détecté: Capteurs;
• valeur mal conservée: Variables.

La simulation Scratch de l’Atlantis Aquarium Madrid devient alors un véritable exercice d’algorithmique. Les 20 écosystèmes fournissent la structure, les déplacements fournissent les coordonnées, les capteurs produisent les événements et les variables conservent l’état. Le programme exécute ensuite les règles, sans interprétation et sans correction spontanée. C’est précisément ce que le test final doit vérifier.