Projet mis en avant

The Eleventh King of Hell

Brackeys Game Jam 2026.2

Jeu de déduction en cartes développé à cinq en une semaine pour la Brackeys Game Jam 2026.2, sur le thème « Trust No One ». Le joueur siège comme onzième Roi-magistrat des Enfers et fait tomber ses suspects en empilant des preuves vraies : une seule pièce fausse et le suspect objecte, la manche est perdue. Le thème est pris au mot, le chiffre affiché sur une carte ne garantit jamais qu'elle dit vrai. Game design, développement et direction du projet, sur 69 cartes et six affaires bilingues.

#Unity#C##URP#FMOD#Cinemachine#Feel#GoogleSheets
Voir le projet
The Eleventh King of Hell, capture du jeu
Rôle & moteur
Game Designer & Developer
Unity 6 (URP)
Équipe
5 personnes
Code, game design et direction du projet pour moi ; art, narration, audio et VFX par quatre collaborateurs
Période & durée
2026
1 semaine (jam)
Plateforme
Navigateur (export WebGL)

Jouer maintenant

Build web jouable ici, sans rien télécharger. Si le lecteur ne se charge pas, ouvrir le jeu sur itch.io.

Contrôles

  • Choisir une preuveSouris :Survol ou clicManette :Stick gauche ou croix
  • Poser la preuve au dossierSouris :Clic gaucheManette :A
  • Reposer la carte en mainSouris :Clic droitManette :B
  • Vérifier une preuveClavier :FManette :Y
  • Pause et optionsClavier :Échap, P ou TabManette :Start
  • Basculer français / anglaisClavier :F2

Le défi

« Trust No One » pris au mot : le chiffre imprimé sur une preuve ne dit pas si elle est vraie, il qualifie sa source. Un joueur qui lit « 2/3 » comme « 66 % de chances » joue à pile ou face et ne voit jamais la déduction qui est devant lui.

Une semaine, cinq personnes, et un risque qui n'est pas le contenu mais l'onboarding : les jurés d'une jam jouent dix minutes, et un concept qui n'a pas été compris n'est pas noté. Il fallait enseigner trois notions contre-intuitives sans écran d'aide.

Concept du projet

  • Un interrogatoire joué comme un combat : chaque preuve posée entame l'aplomb du suspect
  • Une preuve fausse déclenche l'objection : le suspect réplique et la manche s'arrête net
  • Trois types de preuve : en varier fait monter le multiplicateur, en répéter le remet à zéro
  • Vérifier une preuve coûte la manche en cours et la rend retournée à la suivante
  • Perdre une affaire la rejoue à l'identique : ce qui progresse, c'est ce que le joueur a compris

Mon rôle & mes responsabilités

Game Designer
  • Système à main figée, sans pioche : l'ordre de jeu est libre et c'est le seul vrai choix
  • Règle de lecture centrale : 3/3 garantit le vrai, 0/3 le faux, le piège se pose en 2/3
  • Équilibrage des six affaires : l'aplomb vaut le plancher de deux manches jouées parfaitement
Développeur
  • Quatre assemblies à sens unique, règles du jeu isolées de l'input, de FMOD et du juice
  • Localisation maison en ScriptableObject, FR et EN, sans Addressables ni étape de build en plus
  • Contenu des 69 cartes écrit dans un Google Sheet et importé en un bouton
  • Passe de performance mesurée dans un vrai build WebGL, pas estimée sur le papier
Direction de projet
  • Cadrage du scope et arbitrages de coupe jusqu'à la veille du rendu
  • Découpage du travail pour que l'art, la narration et l'audio n'attendent pas le code

Ce qui a changé en cours de route

Première version

Le jeu s'ouvrait sur sa première affaire, trois notions contre-intuitives posées d'un coup : un clic n'engage rien, la fiabilité n'est pas une probabilité, vérifier met fin au tour.

Version retenue

Une affaire tutoriel scriptée en quatre manches, une notion chacune, jouée pour de bon plutôt que lue dans un panneau d'aide.

Pourquoi : Sur une jam, un jeu qui n'a pas été compris n'est pas noté. Le tutoriel verrouille donc la main sur le geste attendu au lieu de corriger après coup, et n'explique le recoupement qu'une fois le joueur objecté, en lui montrant que l'information était déjà dans sa main. Il ne peut pas être perdu et reste sautable.

Galerie d'images

Une affaire en cours : la main figée de la manche, le suspect, le dossier
Une carte en main : fiabilité de la source à gauche, dégâts à droite
L'objection : le suspect réplique, la preuve était fausse
La vérification : la preuve part face cachée, la manche s'arrête
La preuve vérifiée revient badge vert, sa description réécrite
Suspect confondu : l'aplomb est tombé à zéro

Résultats

  • Jeu terminé et soumis dans les délais : tutoriel et cinq affaires, 69 cartes, six décors
  • Entièrement bilingue français et anglais, interface comme contenu des cartes
  • Jouable à la souris, au clavier-souris et à la manette, libellés d'aide selon le périphérique
  • Build WebGL ramené de 33,2 à 30,9 Mo et la mémoire de textures de 313 à 213 Mo

Ce que j'en retiens

  • L'onboarding n'est pas la dernière tâche d'une jam, c'est une contrainte de design à poser au début : c'est en écrivant le tutoriel manche par manche que les notions vraiment contre-intuitives se sont révélées.
  • Un seul mot mal choisi coûte le jeu entier : tant que l'interface disait « fiabilité », le joueur lisait « probabilité de réussite ». Écrire « fiabilité de la source » sur chaque carte a fait plus qu'un panneau d'aide.
  • Une passe de performance ne vaut que mesurée sur la vraie cible : trois conclusions tirées sur le papier se sont révélées fausses au chronomètre, et le vrai gain n'était pas dans le rendu.

Disponible pour un poste de Game Designer / Developer

Studio indé ou double A, profil polyvalent : design, code, réseau, audio, outillage.

bastienokonski@gmail.com
Télécharger le CV (PDF)Écrire à Bastien