C’est un projet qui m’a occupé pendant le premier confinement; j’aimais beaucoup l’idée d’un jeu qui ressemble à ce qu’on peut avoir face à des vrais joueurs : de la tricherie, la possibilité de regarder les cartes rapidement, et surtout pas de règles. Je bosse dessus quand j’ai un gros moment à tuer, c’est à dire plus souvent.
J’ai axé toute la logique du jeu sur quelques actions simples:
- déplacer une carte
- retourner une carte
- faire pivoter une carte
- piocher une carte
En gros… c’est tout. Pas d’indications sur l’endroit ou placer les cartes, pas d’écran qui indique “bravo, vous avez une quinte flush en main”… Le jeu doit être suffisamment intuitif pour que n’importe qui puisse jouer à la souris. Passé ce cap, c’est aux joueurs de se parler (via skype, ce qu’ils veulent) et de se dire “à quoi on joue ?”
“Game design” avec des guillemets
Si je suis plutôt à l’aise avec l’informatique de gestion et tout ce qui est backend, gérer des évènements en temps réel sur un canvas 2D relève du défi. Même en utilisant un moteur de jeu 2D (phaser.io), il m’a fallu me replonger dans des bouquins de maths pour bien comprendre comment opérer des rotations sur des éléments.
Une des fonctionnalités que je voulais absolument intégrer était la capacité que chaque participant ait son propre point de vue sur la table de jeu.
Au début de la partie, le deck est posé face cachée face au premier joueur (le créateur de la partie). Le deuxième joueur est “assis” à la gauche du joueur 1, et ainsi de suite jusqu’à ce qu’il y ait 4 joueurs. Chaque joueur voit donc la même carte mais de son propre point de vue. Si un autre moteur de jeu m’aurait permis de gérer cette subtilité facilement en associant à chaque joueur une “caméra”, phaser ne gère à ma connaissance pas cette fonctionnalité. Donc pour chaque joueur, et en fonction de sa position autour de la table, on applique une transformation sur tous les éléments affichés afin que le jeu lui soit présenté comme voulu. De même, lorsqu’un joueur interragit avec un élément, on recalcule les coordonnées et la rotation de l’élément par rapport au joueur de référence afin que chaque joueur puisse exactement voir ce que vient de faire un autre joueur.
Technique
L’appli est composée d’un frontend réalisé avec Vue, dans lequel j’ai intégré phaser pour le jeu en lui même et socket.io pour la partie multijoueurs. Le backend est une appli nodejs avec express qui expose à la fois une API REST pour la création de salons et une API websockets pour les interactions au sein d’une partie (“joueur X bouge la carte 1337 à la position X/Y”, “joueur Y retourne la carte Z”). Les données sont stockées dans une MongoDB sur le free tier de mongo Atlas et tout ça est déployé chez heroku sur un merge develop depuis la CI du projet chez Gitlab.
Hormis quelques tests unitaires pour valider le fonctionnement du backend (essentiellement le traitement des events), j’ai utilisé Cypress pour tester le comportement du front. Je me suis arrété au moment le plus intéréssant, c’est à dire les tests du jeu en lui même : faute de trop savoir comment faire, d’après ce que j’ai compris j’aurais du exposer une API en JS que j’aurais pu appeller depuis cypress pour aller bouger des cartes, les retourner… mais ça faisait pas mal de taff. J’y pense encore de temps en temps, c’est vraiment un truc que j’aimerais terminer. Autant tester des formulaires via des outils comme Panther, webdriver ou Cypress j’ai l’habitude, autant tester un jeu, multi de surcroit, c’est autre chose !
C’est le premier projet ou j’essaie d’avoir un makefile vraiment polyvalent; que je sois en CI ou sur mon poste, je lance les mêmes targets
Si vous voulez tester, c’est par ici et le code est sur gitlab https://gitlab.com/ROUKIEN/the-ruleless-cards-game