En bref

Le défi

Le premier joueur joue au Snake sur la console : il dirige un serpent au joystick, mange pour grandir, et perd s’il heurte un mur ou son propre corps.

Le second joueur ne tient pas de manette : il rejoint la partie depuis son téléphone, connecté au Wi-Fi de la console, sur une page web servie par la console elle-même. Il ne joue pas au même jeu que le premier : c’est un multijoueur asymétrique. À vous d’inventer son rôle. Il peut aider le serpent, lui tendre des pièges, parier contre lui, arbitrer la partie… tant que ses actions changent vraiment le cours de la partie, et que chacun des deux joueurs a une raison de jouer.

flowchart LR
  J1["Joueur 1\njoystick + boutons"] --> C["Console XIAO\nrègles du jeu + écran"]
  C <-->|"Wi-Fi + WebSocket"| N["Navigateur du joueur 2\nrôle à inventer"]

Ce que la console doit faire

Ces exigences sont communes à tous les binômes. Elles se vérifient pendant la démonstration.

Ce que le joueur du navigateur doit pouvoir faire

Le rôle est libre, les exigences techniques ne le sont pas.

Des pistes, pas une liste

Pour vous lancer, quelques rôles possibles. Vous pouvez en reprendre un, les combiner, ou (mieux) inventer le vôtre :

• Le maître du jeu pose la nourriture et des obstacles sur la grille, affichée dans sa page.
• Le saboteur dispose de pouvoirs à recharge : accélérer le serpent, inverser ses commandes quelques secondes, brouiller une zone de l’écran.
• L’allié guide le serpent vers des bonus et peut le sauver une fois par partie.
• Le parieur mise ses points sur le moment où le serpent va perdre.

Un bon rôle asymétrique se reconnaît à deux questions : chaque joueur peut-il gagner ? et les deux joueurs ont-ils quelque chose à faire à chaque instant ? Testez votre idée sur papier, en jouant les deux rôles à la main, avant d’écrire la moindre ligne de code.

La carte de la console

Le projet commence par la carte. Chaque binôme conçoit le PCB de la console sous KiCad, en deux étapes validées par l’encadrant : d’abord le schéma, puis le routage. Pour éviter les délais de fabrication, l’encadrant vous remet ensuite sa carte finale, déjà fabriquée, que vous soudez et testez. C’est sur cette carte que vous écrivez ensuite le code du Snake. Son brochage est celui des TD : votre Pong y tourne sans modification.

flowchart LR
  S["Votre schéma"] --> V1{"Validation 1"}
  V1 --> R["Votre routage"]
  R --> V2{"Validation 2"}
  V2 --> F["Carte finale fournie
par l'encadrant"]
  F --> SO["Soudure et tests"]
  SO --> C["Code du Snake
sur la carte"]

Rien ne vous empêche de réfléchir au jeu (sur papier) et à votre rôle asymétrique pendant que vous concevez la carte : c’est même conseillé. Mais le code du projet s’écrit et se teste sur la carte soudée.

Se former : la transition est à vous

Contrairement au Pong, aucun tutoriel pas à pas ne vous mène au Snake. C’est volontaire : passer d’un jeu que l’on vous a guidé à construire à un jeu que vous concevez vous-mêmes est le cœur du projet. Cherchez, essayez, comparez des solutions, et gardez trace de vos choix.

Quelques questions à vous poser, auxquelles vous trouverez vos réponses :

• Comment représenter la grille, et comment passer d’une case à des pixels de l’écran ?
• Comment mémoriser le corps du serpent, sachant qu’il grandit ? Que se passe-t-il en mémoire à chaque déplacement ?
• Le serpent avance-t-il à chaque image (16 ms) ? Sinon, comment le faire avancer à sa propre cadence dans la même game loop ?
• Que faut-il redessiner quand le serpent avance d’une case ? (Indice : beaucoup moins que tout le serpent.)
• Comment lire le joystick en quatre directions, et que faire d’une diagonale ?
• Comment tirer une case libre au hasard, même quand le serpent occupe presque toute la grille ?
• Quels états ajouter à la machine à états du Pong, et quels événements réseau déclenchent leurs transitions ?

Une démarche qui marche :

1. Sur papier : la grille, les structures de données, la machine à états, le protocole réseau.
2. Un prototype minimal : un serpent de longueur fixe qui avance tout droit. Puis la direction, puis la croissance, puis les collisions. Validez chaque étape avant la suivante.
3. Le réseau à part : faites marcher le tutoriel WebSocket seul, puis écrivez votre protocole, avant de le brancher sur le jeu.
4. L’intégration, puis la robustesse : déconnexions, messages invalides, parties qui s’enchaînent.

Les ressources de l’atelier

Côté navigateur, la documentation de référence est celle de MDN : l’API WebSocket et l’élément canvas pour dessiner une grille.

Les étapes du projet

Un découpage indicatif, à transformer en jalons et en issues dans votre repo :

Livrables

Le projet se rend dans un repo créé depuis le template du MakerSpace, suivi sur GitHub tout au long du projet. Les tutoriels de l’atelier Méthodologie de projet détaillent chaque partie :

La démonstration finale se fait en direct : les deux joueurs enchaînent au moins une partie complète, puis le navigateur se déconnecte et se reconnecte pendant le jeu.

Évaluation

L’évaluation porte sur :

• Le jeu sur la console : les exigences C1 à C8 tenues pendant la démonstration ;
• Le rôle du joueur 2 : son originalité, l’équilibre entre les deux joueurs, et l’intérêt réel de l’interaction ;
• La robustesse : déconnexions, messages invalides, parties qui s’enchaînent sans redémarrer la carte ;
• La qualité du code : modules, machine à états, absence de delay(), lisibilité ;
• La carte : la conception (schéma et routage validés, choix justifiés), puis la soudure et les tests de la carte fournie ;
• Le repo : documentation, protocole, tests, journal de bord ;
• L’oral : chacun des deux membres du binôme sait expliquer l’ensemble du projet, y compris la partie qu’il n’a pas codée.

La pondération de ces critères vous est communiquée en début de projet.