réalisé par Luna et Xuan.

 Couac.GG

“Vous êtes un jeune canard, séparé de sa famille par un énorme courant. Votre but est de remonter la rivière tout en esquivant les obstacles dangereux que vous rencontrerez durant votre chemin. Par la force de vos cordes vocales, Coincoin esquivera les obstacles en slalomant entre eux. Le but étant de survivre le plus longtemps possible !”  

Luna et Xuan, les créateurs 

Qu’est ce que Couac.GG ?

Couac.GG est un jeu utilisant un seul et unique capteur, le capteur sonore ou aussi le microphone. Ce dispositif interactif, dans la continuité de notre précédent projet Fruto no Katana, s’inspire de deux jeux phares disponible sur téléphone cellulaire et navigateur internet : Flappy Bird et Scream Go Hero.
 Le premier jeu est un side-scroller vers la gauche où le joueur incarne un petit oiseau aux grosses lèvres. Le joueur a pour but d’esquiver des tuyaux apparaissant, en faisant voler l’oiseau par le biais de tapotement sur l’écran tactile. Le but étant de faire le plus de point, sans toucher aucun tuyau.
 De l’autre côté, Scream Go Hero est un jeu utilisant le microphone de l’ordinateur. En effet, le joueur utilise le volume de sa voix pour contrôler le ninja. Plus le joueur crie fort, plus le personnage saute haut. Le but étant de finir le niveau sans toucher un ennemi ou tomber dans le vide.

Couac.GG est l’enfant direct de la combinaison de ces deux jeux. Nous avons par l’intermédiaire de Max réaliser un jeu, style rétro 8-bit, dans lequel un petit canard, du nom de Coincoin, doit esquiver des vilains obstacles tels que des lianes, des troncs d’arbres, et crocodiles assoiffés de sang. Le pauvre…

Le personnage navigue sur la rivière pour esquiver ces menaces en ajustant plus ou moins fort le son de la voix du joueur, par l'intermédiaire d'un capteur sonore. Comportant une bande sonore et des effets sonores, le joueur doit porter le capteur à sa bouche. Ainsi la scénographie du dispositif ne dépend que du joueur et de sa position.

La réalisation de ce code a été fastidieuse vu les différentes mécaniques différentes présentes pour le fonctionnement. En effet, comparé à Fruto no Katana, nous comptions faire l'entièreté de la création et de l'affichage de nos fichiers visuels, que ce soit par les dessins du canard, du background, du logo, ainsi que de la typographie du chrono et du score. Nous ne voulions plus superposer un timer laid comme l'année précédente. Bien sûr les musiques ont été trouvées sur le net, nous ne sommes pas encore compositeurs hélas.

Répartition du travail :

En ce qui concerne le rôle de chacun dans la réalisation du projet, Luna était à la tête de la direction artistique du projet, ayant défini les bases du style graphique par un premier jet, en combinant des éléments du net, permettant la création du support de travail et de ses bases, mais aussi de la vidéo explicative, permettant de vous, lecteurs, faire comprendre l'entièreté, vous avez le droit de dire merci. De l'autre côté, Xuan (c'est moi, grand rédacteur en chef) s'est chargé de la création des mécanismes par la programmation entière du code Max, permettant le bon fonctionnement du jeu, pour votre plus grand plaisir. De plus, Xuan s'est occupé à recréer en pixel art, toutes les différents assets visuels, permettant une cohérence graphique propre. Le choix des musiques est un mélange des deux cultures des créateurs. Quel bon goût, nous le savons déjà.

Schéma fonctionnel :

Liste des capteurs :

Lors de la réalisation du travail à domicile, les données de capteur ont été remplacées dans un premier temps par un mtr, faisant un playback sur de la respiration. Évidemment dans un jeu où il faut éviter des objets apparaissant aléatoirement, il n'est pas précis de pouvoir jouer avec. De ce fait, les touches du clavier UpArrow, DownArrow et & ont permis la simulation d'événements liés au capteur originellement utilisé : le capteur sonore.

Explication technique et organisation du patch

NB : Il est important de noter la différence de propreté de ce patch, de sa belle structure, comparé à Fruto no katana, qui était, sans être trop méchant, immonde (j'ai le droit de critiquer mon travail). Oui, un travail doit être propre, c'est normal, mais c'est assez rare chez moi pour le noter ! Bref !

 Lors de la réalisation du code Max de ce jeu, nous avons dû subdiviser en nombreuses parties les mécaniques du jeu. On note 5 subpatch majeurs, clés dans le fonctionnement. Chacun gère l’affichage d’un élément du jeu qu’il envoie dans ses propres jit.gl.layer, qui seront rassemblés dans un ordre précis, dans un jit.world permettant l’affichage du jeu. Les jit.gl.layer fonctionnent de la même manière que les calques photoshop, permettant une superposition de couches d'images. Il est donc intéressant d'utiliser des png et non pas des jpg pour jouer sur des effets de superpositions dans le jit.world.

 Commençons cependant avec les subpatch permettant des interactions nécessaires avec le jeu, ainsi que des actions nécessaires dès l’initialisation du programme.
Ainsi, on a le subpatch initialisation dans l

Le patch keypressed permet la captation des input du claviers afin de simuler le capteur. En effet, si le joueur n'a pas de capteur à proximité, il peut utiliser les flèches directionnels pour se mouvoir. On peut aussi utiliser des enregistrements de capteurs par le mtr et le playback. Ces deux procédés passent par le même objet [key] qui détecte et attribue une valeur selon la touche appuyé sur le clavier. De ce fait, lié à un [sel ] on peut vérifier si une touche précise est appuyé pour déclencher un évènement. Il permet par ailleurs de récupérer la valeur du capteur placé sur l'entrée 48 puis envoyé dans tout le programme pour divers raisons, par [s capteur1].

Il peut servir de lancement du jeu, si le joueur crie assez fort, par l'objet [if $i1 >= 114 then bang], remplaçant la touche 1. Ces deux manières de lancer le jeu déclenche le 1 dans le [s play] permettant l'actionnement de tous les mécaniques nécessaires au bon fonctionnement du jeu.

Pour finir avec la partie facile et abordable de ce code, un subpatch appelé MusicPannel, permet la gestion aléatoire d'une bande sonore tout au long de la partie. Par le loadbang, tous les paramètres sonores sont lancés par exemple de dac~, permettant l'activation de la sortie sonore (j'ai eu cependant des soucis au niveau de la sortie audio, pensez à vérifier les paramètres liés à votre application). Par la même occasion, le loadbang active un random allant de 1 à 5, changeant la musique de fond du jeu, géré par un coll. En branchant la deuxième sortie du sfplay à au t lié au loadbang, cela permet de lancer une nouvelle musique dès que la précédente est terminée. De l'autre côté, on retrouve la partie permettant l'effet sonore lorsque le joueur perd une vie, transmis par le r gethit.

Maintenant passons aux choses sérieuses, les patchs restants concernent l'affichage du canard et sa position dans le jit.world, l'apparition des obstacles et leur mouvement, la gestion du score, et enfin la pire des parties, la gestion de la hitbox du canard et des obstacles, permettant de savoir si le joueur est en conflit avec un des obstacles.

La position du canard est contrôlé par le patch duckposition. Dans ce dernier, on récupère la valeur sortant du capteur, mais aussi par la simulation avec les touches du clavier. Par la suite, on va filtrer les données et faire une moyenne des données sortantes pour limiter les pics d'informations, avec le bucket 6, le pack i i i i i i i et le mean. Le scale 0 127 260 -300 permet la transformation des valeurs du capteur en données utilisables pour le déplacement du canard de manière vertical. A sa sortie, on le branche donc à un send position coin, utilisé pour gérer la hitbox, ainsi qu'au paramètre offset_y, qui permet d'ajuster le décalage de l'image en passant par le jit.rota. Ainsi, chaque changement de valeur cause une translation vertical du canard. J'ai rajouté aussi un effet de scintillement lorsque le canard prend un dégât, indiqué par le r gethit. On envoie un bang dans un t b b b b qui permet de désafficher le canard en le remplaçant par l'image vide.png et de le réafficher par la suite.

La gestion des obstacles s'active et se désactive par un toggle en fonction de l'état du jeu, signalé par le r play et le r endgame. Ce toggle est un interrupteur pour un metro $f1, dont la valeur de base est 3000. De ce fait, toutes les 3 secondes le metro envoie un bang dans t b b b qui active en premier un counter allant de 0 à 5, un random 4 allant de 1 à 4, relié au coll coll_tuyaux qui comme son nom l'indique permet l'affichage des 4 différents obstacles (je les ai appelés tuyaux en référence à Flappy Bird, bien que nous avons aucun tuyau dans notre jeu.) Le trigger envoie aussi un bang pour afficher ce que demande le message. Notons que la valeur aléatoire est récupéré par le r varRandom, utile pour la gestion de la hitbox des obstacles.

Par la suite, bien que nous avons affiché l'objet, il faut bien faire bouger l'obstacle pour rendre le jeu difficile. Le counter 0 5 permet donc tous les 5 obstacles de changer la valeur du metro $f1, en divisant à chaque fois la valeur courante par 1,125 (une valeur totalement arbitraire) Au chargement, la valeur 3375 est directement divisé pour obtenir un metro 3000. C'est par cette boucle que le jeu devient de plus en plus rapide, le metro étant de plus en plus court, les obstacles apparaissent de plus en plus vite.

Le metro $f1 est aussi relié à un t b b 1400, qui accélère, non pas l'apparition des obstacles mais leur vitesse de déplacement, car sans cette partie, à une vitesse constante les objets resteraient bloqués au milieu. En utilisant la fonction line, les obstacles vont de la coordonnée 1400 jusqu'à -2000 à une vitesse dépendant de la division, deux valeurs bien en dehors de l'écran ce qui permet le désaffichage de tous les obstacles sans problème. La valeur sortant du line permet par le s valuePositionObs de modifier la propriété offset_x des images d'obstacles, ainsi lié au jit.rota. Notons que le counter est reset à 0 par le r play

La mécanique de score dépend du patch chrono : cette fonction s'active par le capteur ou les touches, comme pour tous les autres parties in-game. Au lancement, cela désaffiche le précédent score. Par la suite, cela allume un toggle pour une metro 1000 qui toutes les secondes active un counter 9. (Le patch ci dessous n'est pas optimisé du tout, il marche mais n'est pas totalement propre, pardonnez moi) Sur la première sortie, on branche un integer pour avoir la valeur des unités que l'on envoie dans un coll display_timer dans lequel il y'a toutes les images affichants les unités pour les secondes. Par contre, la gestion des dizaines a été pour moi plus difficile. En partant du même counter, il a fallu pour afficher le chiffre des dizaines quand le counter est au minimum. La quatrième sortie permet d'afficher le nombre de fois le counter a fait le tour, lorsqu'il passe le maximum soit 9. Par exemple, lorsque le jeu a passé 9 secondes, il va stocké le 1 dans le integer en dessous, et va être additionné à un 0 pour avoir la valeur des dizaines, uniquement lorsque le counter réaffichera le 0, soit quand 10 secondes au total se seront écoulés, de cette manière, on va récupérer lorsque le counter affiche 0 la valeur des dizaines que l'on va injecter dans le coll display_mintimer, contenant tous les messages pour l'affichage des images des dizaines de secondes. De la même manière que pour les secondes, on met ces images dans un jit.rota puis dans un jit.gl.layer, dont la valeur du layer dépend de la priorité que l'on veut donné à l'image.

Notez que le chronomètre n'est pas affiché tout au long du jeu mais uniquement à la fin sur l'écran de menu : le chronomètre se désactive lorsque le joueur a perdu toutes ses vies, symbolisé et envoyé par le r endgame, qui affiche le score en envoyant un bang sur les messages modifié tout le long du jeu par les deux coll

.

Et enfin la dernière partie, la plus costaud de toute, concerne la partie des points de vies ainsi que la gestion des hitbox, c'est à dire de la zone de détection de collision entre les obstacles et le canard. Ce patch est divisé en 2 grosses parties réunis à la fin en une seule.

Dans la première on retrouve la partie permettant la vérification du moment où l'obstacle dont la valeur aléatoire est récupéré à gauche par le varRandom est relié au gswitch2, atteint des coordonnées précises.

En d'autres termes, on cherche à récupérer le moment où l'obstacle peut être en contact avec le canard. Les obstacles n'étant pas tous pas disposés de la même manière ainsi que de tailles différents, il faut donc des vérifications différentes pour chacun d'eux, que l'on contrôle avec le gswitch2, qui ouvre uniquement le passage pour l'obstacle concerné. Si l'obstacle est le numéro 1, le gswitch2 ouvre la sortie qui concerne uniquement l'obstacle 1, donc la sortie à tout à gauche. Ainsi, lorsque la valeur X de l'obstacle se trouve dans un certain intervalle, il donne un nombre premier unique, associé à l'obstacle. Ce nombre va être envoyé dans la 3eme partie de ce patch.

Dans la seconde, on retrouve la partie permettant de vérifier se trouve au niveau de la coordonné Y des obstacles.
De la même manière que dans la première partie, pour chaque obstacle, est attribué à une sortie qui donne à une condition propre à lui-même. Ainsi, on vérifie l'offset_Y du canard en fonction de l'intervalle attribué à l'obstacle actuel. Si la condition est vérifiée, elle en sort un nombre premier unique à elle.

La troisième partie est l'association des valeurs que l'on a récupéré. En effet, quand on réfléchit à la manière dont le système de hitbox fonctionne, on comprend que c'est une addition de deux conditions distinctes. On vérifie dans un premier temps si le joueur est à la hauteur Y de l'obstacle, puis dans un second temps si l'obstacle est à la position latéral X du canard. Si les deux conditions sont vérifiés, on prend un dégât.

Les deux parties précédentes permettent la vérification de ces 2 conditions. En ajoutant les deux nombres premiers, on peut alors savoir si le joueur doit prendre des dégâts ou non. Ainsi, on met 4 conditions, dont les valeurs de vérifications correspondent à l'addition des 2 nombres premiers nécessaires, associés à l'obstacle. Ces additions permettent le filtrage et d'éviter de valider des points de dégâts alors que le joueur ne remplit pas les deux conditions.

A chaque fois que le joueur valide ces deux conditions, il prend donc un dégât : il déclenche l'animation de scintillement décrite dans le patch duckposition ; il déclenche aussi un counter 4 qui se réinitialise par l'implémentation du message 1 au niveau de sa troisième entrée, activé lorsque le jeu se relance ainsi qu'au chargement du patch. Le counter permet d'envoyer la valeur actuelle des points de vies manquant au coll HP, qui s'occupe à chaque changement d'afficher en bas à droite de l'écran le montant de points de vie actuelles.

Schéma du branchement du dispositif et démonstration du projet