← Tous les projets

Étude de cas

+4, un jeu de cartes en temps réel

Un jeu de défausse façon Huit américain, jouable seul contre des bots ou à six en ligne. Le défi : des règles maison que chacun peut activer, sans que le serveur devienne un tas de cas particuliers.

TypeScriptReactFramer MotionSocket.IONode.jsVitestPlaywright
240tests automatisés
6joueurs par salon
0règle côté client

Le point de départ

Je voulais un jeu où l’on peut tricher aussi peu que possible, et où changer une règle (empiler les +2 et les +4, jouer plusieurs cartes, échanger sa main avec le 7…) ne demande pas de réécrire le jeu.

Les choix qui comptent

Le serveur décide, le client demande

Le navigateur n’envoie que des intentions (« je joue cette carte »). Le serveur vérifie, applique et renvoie à chaque joueur sa propre vue : sa main en clair, les autres réduits à ce qui est public. Un client modifié ne voit pas les mains des adversaires, parce qu’elles ne lui sont jamais envoyées.

Un moteur pur et déterministe

Le moteur de règles est une bibliothèque sans réseau, avec un générateur aléatoire à graine. Mêmes entrées, même partie : c’est ce qui rend les 240 tests possibles, et ce qui m’a laissé développer les règles avant d’avoir la moindre interface.

Les règles sont des réglages, pas du code branché partout

Chaque variante est une option du salon, lue à un seul endroit du moteur. Ajouter une règle revient à ajouter une option et ses tests, pas à toucher dix fichiers.

Des bots qui ont du caractère

Chaque niveau de difficulté est un profil de probabilités et de temps de réaction : un bot facile oublie parfois de dire « Uno » et joue une carte au hasard, un bot fort joue stratégiquement et réagit vite. Les délais de réflexion sont volontairement irréguliers pour que ça ne ressemble pas à une machine.

Ce qui a été difficile

Les actions hors tour : l’interception (poser une carte identique à celle du dessus hors de son tour), la contestation d’un +4, le « Uno » oublié qu’on peut faire payer. Tout se joue à la milliseconde entre deux joueurs, donc l’état du serveur doit trancher dans un ordre clair, et le client doit rester cohérent même quand sa demande arrive trop tard.

L’animation sans mentir : la carte qui vole de la main au centre ne doit jamais montrer quelque chose que le serveur n’a pas décidé.

Ce que je ferais autrement

Les salons sont gardés en mémoire (un redémarrage les perd) et je n’ai pas de mode spectateur. Les deux se feraient sans casser l’architecture, mais je ne les ai pas encore faits.