Zelda Koriki Forest

Objectifs pédagogiques :

• Apprendre à analyser un gros projet Scratch sans être noyé dans les blocs.
• Savoir utiliser les blocs personnalisés pour découper un code complexe.
• Comprendre le rôle des variables de comportement (Jumping, Attacking, can move, etc.).
• Identifier clairement le rôle de chaque sprite : Link, HitBox, Level, Level HitBox, Navi2, Thumbnail.
• Être capable de simplifier, nettoyer et réorganiser le projet pour mieux le comprendre.

---

1) Fichiers de départ

Base de travail :
Zelda Koriki Forest – fichier de départ

Modèle de référence :
https://scratch.mit.edu/projects/724226874/editor/

---

2) Méthode générale face à un gros code Scratch

Quand on ouvre un projet comme ce Zelda dans l’éditeur Scratch, on voit tout de suite des scripts longs, plein de conditions, de variables et de messages. Pour ne pas se perdre, on applique une méthode simple :

• Étape 1 – Isoler les rôles : repérer les grands blocs de logique (déplacement, saut, attaque, gestion des niveaux, etc.) et les transformer en blocs personnalisés Scratch.
• Étape 2 – Désactiver le non essentiel : dans un premier temps, on peut désactiver (en mettant de côté ou en masquant) les blocs qui ne sont pas vitaux pour comprendre le fonctionnement de base.
• Étape 3 – Afficher les variables importantes : on affiche à l’écran des variables comme Jumping, can move, Attacking, targeting, pour voir en direct quand elles passent à YES/NO.
• Étape 4 – Chercher “où ça change” : pour chaque variable importante, on repère dans quels scripts elle est modifiée. Cela permet de comprendre quelle partie de code contrôle quel comportement.
• Étape 5 – Comprendre sprite par sprite : on prend chaque sprite, on résume en une phrase son rôle principal, puis on détaille ses grandes fonctions.

Cette méthode permet de transformer un “gros bloc incompréhensible” en plusieurs éléments simples, qu’on peut étudier un par un.

---

3) Rôle de chaque sprite dans Zelda Koriki Forest

- Sprite Link :

Le sprite Link représente le héros visible à l’écran. Son code s’occupe principalement de :

• La gestion des costumes (animations de marche, saut, attaque, etc.).
• L’orientation de Link (vers la gauche ou vers la droite).
• La synchronisation de Link avec le sprite HitBox (Link se pose “par-dessus” la HitBox).

Le code de Link décrit quoi faire :

• 1) Selon les actions de l’utilisateur : flèches gauche/droite pour se déplacer, flèche haut pour sauter, touche d’attaque, etc.
• 2) Selon l’état du personnage : variables comme Jumping, Attacking, can move, etc.

Une variable importante est par exemple frame, qui sert à choisir le costume correspondant à l’image d’animation à afficher (comme une pellicule de dessin animé).

---

- Sprite HitBox :

Le sprite HitBox est invisible pendant le jeu, mais c’est lui qui gère en réalité le déplacement et les collisions. On peut le voir comme le “squelette technique” de Link :

• Il calcule la position réelle du personnage dans le niveau.
• Il teste s’il y a collision avec la carte du sprite Level HitBox (sol, murs, obstacles).
• Il applique les règles du monde (gravité, limites de l’écran, etc.).

Pour simplifier l’étude du code de ce sprite, on commence par réduire à deux blocs principaux :

• Bloc 1 – Gestion des coordonnées Min/Max : que se passe-t-il si le personnage sort de l’écran ? On limite la position pour garder la HitBox dans la zone de jeu.
• Bloc 2 – Mouvement simple sans cible (“no targeting”) : déplacement de base quand le personnage avance, recule, sans suivre un ennemi ou un point particulier.

---

- Sprite Level HitBox :

Level HitBox est une carte invisible qui sert à définir les zones où le personnage peut ou ne peut pas aller :

• Certaines couleurs ou zones signifient “sol” ou “mur” → la HitBox n’a pas le droit de traverser.
• D’autres zones signifient “vide” → la HitBox peut y entrer (air, trou, etc.).

On y trouve aussi un bloc qui prend une valeur en entrée (par défaut 1) pour gérer un zoom sur le niveau. Pour comprendre la logique de base, on peut désactiver ce zoom dans un premier temps.

---

- Sprite Level :

Le sprite Level gère l’affichage des niveaux (le décor visible) :

• Quel décor est affiché ? (forêt, autre zone…)
• Comment le niveau change ou défile ?
• Gestion du zoom sur le décor (là aussi, on peut le désactiver pour commencer).

---

- Sprite Navi2 :

Navi2 est un sprite ornemental : il ne change pas les règles du jeu, mais ajoute de la vie visuelle (par exemple la petite fée qui accompagne Link).

• Il ne modifie pas la position de Link.
• Il gère ses costumes via une variable comme navi frame, de façon similaire à la variable frame pour Link.

---

- Sprite ThumbNail :

ThumbNail est le sprite affiché avant le démarrage du jeu (écran titre, mini-vignette d’introduction). Il ne gère pas la logique du jeu, mais la présentation.

---

4) Étape 1 de simplification : un Zelda “light” pour comprendre

L’objectif de la première étape est d’obtenir une version simplifiée du projet, qui se rapproche de :

Zelda Koriki Forest : étape 1 (version simplifiée)

Pour cela, on applique le plan suivant :

• Afficher les variables d’état : rendre visibles à l’écran Jumping, can move, Attacking, targeting, etc. Cela permet de voir à quel moment chaque variable change.
• Désactiver les fonctions secondaires : pour commencer, on met de côté le zoom, certains effets graphiques, et les comportements avancés (ciblage, attaques complexes).
• Créer des blocs personnalisés : sur le sprite HitBox notamment, on crée des blocs du type “Gérer déplacement simple”, “Gérer collisions horizontales”, etc., pour clarifier visuellement le rôle de chaque portion de code.

---

5) Exemple de simplification du sprite HitBox

Face à un code difficile à comprendre, la bonne stratégie est de créer des blocs pour chaque situation. Le script principal devient alors une suite de blocs lisibles, et non un mur de blocs empilés.

Exemple de réorganisation (capture du sprite HitBox simplifié) :

En simplifiant ainsi, on peut d’abord se concentrer sur le comportement le plus simple, c’est-à-dire le cas où :

• Le personnage peut bouger (can move ? == YES)
• Le personnage n’attaque pas, ne saute pas, ne roule pas (Attacking == NO et Jumping/Rolling == NO)
• Le personnage ne suit pas une cible (targeting == NO)

On peut alors analyser calmement les fonctions de cette partie du code :

1. Mise à jour de la variable moving? : si l’utilisateur appuie sur les flèches, moving? passe à YES, sinon elle passe à NO.
2. Mise à jour de l’orientation du sprite (vers la gauche ou vers la droite).
3. Vérification des collisions avec la carte du sprite Level HitBox (sol, murs, obstacles).

---

6) Petits exercices guidés

• Exercice A – Variables d’état
  Afficher à l’écran les variables Jumping, Attacking, can move, moving?, targeting. Tester le jeu et observer à quels moments chaque variable change de valeur.

• Exercice B – Repérer où ça change
  Pour chaque variable ci-dessus, utiliser la recherche dans Scratch et repérer dans quels scripts elle est modifiée (par exemple “mettre can move à YES/NO”). Noter dans un tableau : Variable / Sprite / Bloc qui la modifie.

• Exercice C – Nettoyage de Link
  Sur le sprite Link, regrouper les blocs liés au changement de costume dans un bloc personnalisé du type “mettre à jour animation”. Le script principal doit alors être plus court et plus lisible.

• Exercice D – Simplifier Level HitBox
  Temporairement, désactiver le bloc qui gère le zoom dans Level HitBox. Vérifier que le jeu reste jouable et que les collisions fonctionnent toujours.

---

7) Mini QCM Zelda – compréhension du code

1. 1. Quel sprite gère réellement les collisions avec le décor ?

   • A. Link
   • B. HitBox
   • C. Level
   • D. Navi2

2. 2. À quoi sert le sprite Level HitBox ?

   • A. Afficher le décor visible.
   • B. Gérer les menus du jeu.
   • C. Fournir une carte invisible des zones où l’on peut marcher ou non.
   • D. Jouer la musique de fond.

3. 3. Quand on simplifie le script de HitBox pour le cas “mouvement simple”, quelles conditions doivent être vraies ?

   • A. can move ? == YES, Attacking == NO, Jumping/Rolling == NO, targeting == NO.
   • B. can move ? == NO et Attacking == YES.
   • C. Jumping == YES uniquement.
   • D. Aucune condition, la HitBox bouge toujours pareil.

4. 4. Pourquoi créer des blocs personnalisés (“définir …”) sur le sprite HitBox ?

   • A. Pour rendre le code plus lisible et séparer les cas (mouvement simple, saut, attaque…).
   • B. Pour que le jeu aille plus vite, même sans comprendre le code.
   • C. Parce que Scratch oblige à utiliser au moins un bloc personnalisé.
   • D. Pour changer la couleur de Link.

5. 5. Le sprite Navi2 est surtout là pour…

   • A. Gérer les collisions.
   • B. Modifier les variables de vie de Link.
   • C. Ajouter un élément visuel (ornement) animé.
   • D. Afficher l’écran titre.

Corrigé :
1) B – HitBox
2) C – Carte invisible des zones de collision
3) A – Mouvement simple, pas d’attaque / saut / roulade / ciblage
4) A – Lisibilité et séparation des cas
5) C – Sprite ornemental animé