Party Game Engine
Un game show multijoueur où chaque téléphone reste une télécommande privée tandis qu’un écran partagé porte les règles, les reveals et la compétition.
Le point de départ
Le projet devait produire un vrai jeu de soirée, pas une collection de mini-jeux web. L’expérience cible est simultanée et individuelle : chacun répond sur son téléphone, mais la partie se vit ensemble sur un grand écran.
Cette contrainte a progressivement imposé une règle centrale : le téléphone sert à choisir, l’écran partagé sert à comprendre ce qui se passe.
Les contraintes
Une partie doit rester jouable même avec plusieurs appareils, des refreshs, une reconnexion ou un navigateur mobile qui se met en veille. Les joueurs ne doivent pas voir d’informations privées qui appartiennent aux autres, et le grand écran doit rester la vérité publique de la session.
Le jeu est pensé autour de neuf joueurs, tout en permettant des effectifs de playtest plus petits. Il faut également enchaîner plusieurs mécaniques très différentes sans que chacune réinvente la navigation, le scoring, les transitions ou la récupération d’état.
Les choix qui ont compté
Chaque partie possède un code court et un runtime isolé. Les vues Player, Screen et Director partagent un état persistant ; un serveur WebSocket durable sur VPS et des snapshots Neon permettent de récupérer la session après un incident plutôt que de supposer une connexion parfaite.
La V1 regroupe sept modules avant la finale — Precision, Unique, Blind Rank, Overload, Split, Contrat et Synchronisation — derrière des contrats communs de phase. Le Director garde le contrôle des reveals et transitions : le rythme du jeu reste une décision de mise en scène plutôt qu’un simple timeout automatique.
Le contenu a lui aussi fini par devenir un système : Precision et Blind Rank ont été alimentés avec un pipeline déterministe de sourcing, provenance et QA au lieu d’empiler des questions écrites à la main sans traçabilité.
Où le projet en est
La V1 est jouable de bout en bout : lobby, phases, classements, finale et victoire. Les flux multi-appareils, la récupération de session et les principaux modules ont été exercés sur le stack réel, y compris avec des joueurs simulés pour répéter rapidement les états difficiles à atteindre.
Le projet est aujourd’hui davantage dans une phase de réutilisation et de productisation potentielle que de construction de la première boucle.
Ce que j’en retiens
En multijoueur, les bugs les plus importants vivent souvent entre les mécaniques : reconnexion, transition, propriété de l’état, timing du reveal ou différence entre information privée et vérité publique.
J’ai aussi appris que le contenu n’est pas un remplissage ajouté à la fin. Dès qu’un jeu doit être rejouable, sourcing, variété, difficulté et validation éditoriale deviennent une partie du moteur produit.