Tout le plaisir est pour moi. Je suis un fervent lecteur du Blog et je n’ai pas souvent l’occasion de parler de ce que je fais sur BGA. Merci de m’offrir cette tribune.

D’aussi loin que je me souvienne, j’ai toujours eu un rapport étroit avec le jeu. Je suis né l’année de la sortie de Star Wars et d’Advanced Dungeons & Dragons et je suis un rôliste passionné depuis mes 11 ans.

Dans les années 1998-2000 je collabore avec Multisim (NdB : éditeur de jeu de rôle) sur des jeux de rôle comme Dark Earth, Guildes et surtout Agone. C’est aussi à cette période que j’entends parler d’un certain Bruno Faidutti qui vient proposer le jeu Citadelles à Multisim.

Depuis je fais beaucoup moins de Jeux de Rôle et de plus de jeux de société. Je m’occupe aujourd’hui d’une association de joueurs et je fais des piges pour Ludovox quand le temps me le permet.

Sans rentrer dans les détails, j’occupe actuellement un poste de Product Owner (NdB : littéralement « propriétaire du produit”, une des fonctions clés dans les méthodologies agiles de développement logiciel). Mon rôle est notamment d’exprimer à des développeurs des besoins fonctionnels afin qu’ils puissent les convertir en solutions techniques.

Avant d’en arriver là, j’ai d’abord été développeur autodidacte pendant plusieurs années, notamment pour un grand groupe de e-commerce de l’époque. Mais quand j’ai commencé à développer pour BGA, je n’avais pas touché une ligne de code depuis une douzaine d’années.

La pandémie. Premier confinement : on se retrouve tous bloqués chez nous avec beaucoup de temps libre et sans savoir si nous pourrons retrouver nos tables de jeu un jour.

Je me remets à l’époque sur BGA et Discord pour continuer à faire vivre mon association en attendant de pouvoir jouer à nouveau dans la même pièce.

C’est à ce moment-là (avril 2020) que je vois passer une bouteille à la mer des éditions Banquiiiz qui cherchent un développeur pour adapter Yokai (Julien Griffon, 2019, Bankiiiz Editions) sur BGA. Je me dis alors : « Pourquoi pas ? Le jeu semble simple et ça ne doit pas être si compliqué. Ça risque même d’être amusant à faire ».

L’inteface du jeu Yokai sur BGA

Je contacte l’éditeur et je me renseigne sur la manière de porter un jeu sur la plateforme. Coup de chance, BGA utilise les mêmes technos que j’utilisais à l’époque. Il suffit de se dérouiller un peu et ça va rouler tout seul (spoiler : non).

Yokai a donc été mon premier jeu développé (mais seulement le deuxième accessible au grand public).

En faisant la promo de mon adaptation de Yokai sur les réseaux sociaux (je cherchais des testeurs), on m’apprend que Mushroom Games cherche quelqu’un pour faire l’adaptation de Small Island (Alexis Allard, 2018, MushrooM Games). Je prends contact avec l’éditeur et la relation de confiance s’installe très vite. Mais là on part pour un tout autre niveau de complexité et de nombreux nouveaux défis à relever.

Pour Almadi (Mathieu Bossu et François Gandon, 2021, Funnyfox) je suis directement contacté par Mathieu Bossu, qui connaissait mon activité et avec qui j’avais déjà eu l’occasion d’échanger. Il me met en contact avec l’éditeur et on se met rapidement d’accord pour collaborer.

Là je viens de publier l’adaptation de Scriptoria en version Alpha (uniquement accessible aux testeurs et développeurs). C’est un futur jeu en développement participatif aux éditions du Lion Vert. Pour celui-ci j’ai directement répondu à une offre sur le forum des développeurs BGA.

Développer un jeu sur BGA

Sur ce coup-là j’ai eu énormément de chance. Les technos utilisées par BGA sont les mêmes que j’utilisais il y a 15 ans.

C’est principalement du PHP (pour la partie serveur), du JavaScript (pour la partie navigateur), du CSS (pour la mise en forme) et du MySQL (pour la base de données).

Ce sont des langages qui sont plutôt dépréciés aujourd’hui et qu’aucun développeur digne de ce nom n’utiliserait pour un site moderne. Cependant, l’activité de BGA ne nécessite pas non plus une sécurité démesurée et on s’en sort très bien avec ça.

Côté serveur c’est d’un niveau assez basique. Pas besoin d’être un dieu en PHP pour s’en sortir. Côté navigateur, il vaut mieux être assez à l’aise en Javascript et CSS pour arriver à faire des choses correctes visuellement. Dans mon cas c’était plutôt l’inverse et je continue à me mettre à niveau côté navigateur pour palier mes lacunes.

J’ai envie de dire « Ça dépend… ». Il y a une architecture assez rigide à laquelle on ne peut pas toucher. Les fichiers sont organisés d’une certaine façon et on ne peut que les éditer. Les échanges entre le navigateur et le côté serveur / base de données sont très encadrés, par exemple.

Petit aperçu du code JavaScript pour ceux qui lisent la matrice

C’est un peu comme développer une application mobile. On est contraint par l’architecture de son système d’exploitation mobile (iOS ou Android), mais à côté de ça on fait un peu ce qu’on veut dans notre propre application.

Il y a également des fonctionnalités toutes prêtes pour gérer quelques éléments. Il y a, par exemple, une fonction qui permet de gérer un jeu de cartes du côté serveur / base de données. Mais le côté visuel / navigateur est à développer à partir de zéro.

Mais ces outils sont très incomplets, trop génériques et finalement peu adaptés à nos besoins spécifiques. Avec l’expérience on finit par ne presque plus s’en servir, au profit de nos propres développements.

Je continue à apprendre tous les jours, à pousser le framework (NdI : le cadre de développement mis à disposition par la plateforme BGA) dans ses retranchements. J’ai commencé à apprendre en développant Yokai car je voulais me confronter à de vraies problématiques. Au final, ça a été une vraie galère. J’apprenais en marchant mais la marche était très longue et chaotique.

J’ai passé des jours entiers sur des problématiques qui me semblent aujourd’hui élémentaires. La courbe de progression est assez importante, surtout lorsqu’on reprend le développement après un long vide. Aujourd’hui je prends beaucoup plus de temps à la conception, avant de coder quoi que ce soit.

Ça commence d’abord par une lecture méticuleuse des règles. Pour une adaptation BGA on ne peut rien laisser au hasard. Il ne peut subsister aucune ambiguïté et chaque étape et transition doit être parfaitement claire.

Ensuite je rédige la séquence de jeu : une succession d’étapes et de transitions entre elles. Il y a des étapes pendant lesquelles les joueurs vont jouer chacun leur tour, d’autres où ils agiront en même temps, mais aussi des étapes où le seul acteur sera le jeu lui-même. C’est là où on commence à détecter les premières complexités et que je note toutes les questions à voir avec l’éditeur et/ou l’auteur.

Pendant ce temps, il faut également récupérer les éléments graphiques et les préparer. Car le développeur ne s’occupe pas que du code. C’est aussi lui qui effectue un travail de graphiste assez considérable pour transposer le jeu physique en jeu numérique.

Toutes les tuiles du jeu Almadi regroupés en un seul fichier image

Viennent ensuite toutes les questions annexes qui ont une grande importance sur l’expérience de jeu. Existe-t-il différents modes de jeu ? Si oui, quel sera le mode par défaut ? Si c’est un jeu coopératif, comment sera gérée l’évolution des classements de joueurs ? Que doit-il se passer si un joueur quitte la table de jeu ?…

En général je reprends la séquence de jeu que j’ai dessiné et je décris toutes les tâches nécessaires pour chaque étape. Je fais plusieurs itérations en étant d’abord très macro et devenant de plus en plus précis. Ces différentes tâches deviennent ensuite des lignes de « Todo » dans mon code source.

Ensuite c’est un travail plutôt séquentiel. Je peux difficilement commencer à travailler sur le scoring sans avoir développé la mise en place du jeu. Il y a souvent un long travail un peu en aveugle pour toute la mise en place du jeu. Après, j’avance au fur et mesure et il se passe parfois des semaines avant que je sois capable d’effectuer un tour de jeu complet.

Avec l’expérience, mon analyse de départ devient de plus en plus précise. Mais j’ai toujours des surprises qui m’obligent à revoir la façon dont j’ai vu les choses, parfois de façon très profonde.

J’utilise le logiciel Notion pour gérer mes projets. Ça me permet d’organiser les notes prises pendant les réunions, de faire des check-lists, de centraliser les éléments importants pour le suivi du projet…

J’ai entendu dire que certains développeurs (non joueurs) demandent un cahier des charges à l’éditeur. C’est donc ce dernier qui se charge de tout le travail de conception.

Dans mon cas, je préfère faire une proposition à l’éditeur en fonction de mon expérience de joueur en tenant compte des contraintes techniques que je connais bien.

Les premiers contacts avec l’éditeur sont donc primordiaux pour instaurer une relation de confiance et cadrer l’idée que nous avons de l’adaptation du jeu.

Ensuite c’est très variable. Certains éditeurs délèguent complètement la conception et on se donne rendez-vous à la livraison du jeu. Moi je préfère les éditeurs qui s’impliquent à fond et participent aux prises de décisions nécessaires à chaque étape. L’idéal c’est quand les auteurs sont également impliqués.

Effectivement, c’est un vrai casse-tête. Il ne suffit pas de poser les éléments comme dans le jeu physique comme sur un Tabletop Simulator. Il faut avoir une réflexion sur chaque élément de jeu. Est-il indispensable ? Faut-il en adapter la forme ? Doit-il être visible en permanence ou consultable au besoin ? Comment gérer la visualisation du jeu des adversaires ? Que doit voir un observateur non joueur ?…

Coder les possibilités de jonction entre les tuiles de Small Island passe par une analyse préparatoire sur papier

Au niveau des tailles d’écran je conçois pour une taille standard d’ordinateur portable. Mais il reste la question du mobile. La plupart des éditeurs ne souhaitent même pas qu’on s’occupe de la version mobile. Ils minimisent l’utilisation de BGA sur téléphone ou tablette. Je n’ai pas les chiffres, mais si je me fie aux bugs qui sont remontés, l’expérience de BGA sur mobile est loin d’être négligeable.

La règle est de développer les jeux en anglais. Dès que le jeu est publié en version Alpha je me charge en général de la traduction de l’nglais vers le français.

Dès cet instant, n’importe quel membre de la communauté BGA peut proposer des traductions vers sa langue maternelle. C’est un process qui échappe complètement au contrôle du développeur ou de l’éditeur.

L’avantage c’est qu’on se retrouve avec son jeu disponible au Japon ou en Russie deux jours après la mise en ligne, sans avoir à s’en préoccuper.

Là encore ça dépend beaucoup du type de jeu. Almadi a été très complexe à tester car il y avait énormément de situations différentes à tester au niveau de la disposition des tuiles, des pouvoirs des personnages, des enchaînements d’effets… Certains personnages étaient presque un jeu en soi tellement leur pouvoir cassait la mécanique de base.

Les jeux basés sur un algorithme comme Yokai ou Small Island sont également très laborieux à tester. Dans les deux cas, le programme est censé comprendre les ensembles de tuiles et autoriser ou non un placement, accorder des points de victoires, etc. Il faut tester un nombre incalculable de combinaisons pour s’assurer que l’algorithme est bon.

Quand l’éditeur s’investit et teste beaucoup, c’est facile. Il y a de l’émulation. On fait des parties ensemble et on debug en même temps. Mais quand on est tout seul devant son écran, c’est un travail de titan.

Lorsque le jeu passe en version Alpha et que la communauté commence à tester aussi, c’est encore un autre défi. On reçoit parfois une quinzaine de bugs en une journée. Il faut passer sur chacun, essayer de reproduire le problème. Parfois le testeur n’a juste pas compris les règles. D’autres fois, au contraire, c’est un énorme bug qui nécessite beaucoup de travail.

Pas vraiment. Nous sommes très autonomes. BGA fait confiance à sa communauté de reviewers pour détecter d’éventuels problèmes sur un jeu. Il faut 10 approbations de reviewers pour qu’un jeu passe en version Bêta.

J’ai uniquement reçu de l’aide sur Yokai car je ne savais pas comment gérer le classement ELO sur un jeu coopératif avec différents degrés de réussite.

Il y a principalement des difficultés techniques et humaines.

Techniquement, je me heurte aux mêmes problématiques que n’importe quel développeur. On passe parfois un temps fou sur des problématiques toutes simples. Ça ne marche pas comme on veut et on ne comprend pas pourquoi. C’est très artisanal et ça demande beaucoup de tâtonnement.

Le framework est parfois contraignant et on aimerait avoir davantage de liberté.

Humainement ça s’est globalement bien passé jusque-là. Mais je mesure le risque engendré par des accords de confiance, parfois en marge de tout encadrement contractuel.

Le positionnement de développeur freelance, qui se retrouve entre l’éditeur et BGA, n’est pas toujours facile à tenir. Les éditeurs ne comprennent pas toujours que l’on ait peu de contrôle sur le calendrier de déploiement de la plateforme. Annoncer et tenir une date de publication d’un jeu est tout simplement impossible à mon niveau car BGA reste maître du calendrier.

Le développement pour BGA reste un hobbie pour moi. C’est une activité que je fais sur mon temps libre, le soir, le weekend et pendant mes congés.

Lorsque je commence un nouveau projet, je préviens toujours l’éditeur que l’adaptation d’un jeu est un processus long. Déjà parce que ce n’est pas mon activité principale. Mais aussi parce qu’il y a des délais incompressibles entre le moment où le jeu est déployé en Alpha et le moment où il devient accessible à tous.

Pour un jeu moyen, je compte un délai de 3 mois entre le GO de l’éditeur et le déploiement d’une version Bêta.

Mais là on parle de temps calendaire. J’aurais beaucoup de mal à estimer la charge réelle que cela me prend entre la gestion de projet, le développement et les tests.

Pour mes deux premiers jeux je n’ai pas demandé à être payé (ce qui tombe bien car les éditeurs n’avaient pas d’argent à me proposer) car j’apprenais en même temps et que je voyais ça davantage comme un divertissement et un moyen de servir la communauté des joueurs.

Après l’expérience de Small Island, je me suis dit que ce travail, cette expertise, méritait tout de même un dédommagement. On parle tout de même d’un temps considérable que je passe à développer des jeux au lieu de passer du temps avec ma famille.

Mais le fait d’être rémunéré s’accompagne également de contraintes. Un éditeur qui paie est nécessairement plus exigeant en termes de qualité et de délais. Ça m’oblige à être encore plus professionnel.

Cependant, même si cette rémunération n’est pas négligeable, elle n’est pas encore à la hauteur du travail fourni. Si je convertis ce que je gagne en taux horaire, c’est plus proche du bénévolat que du salaire d’un cadre supp.

C’est un service que peu d’éditeurs sont prêts à payer aujourd’hui, même si c’est en progrès. Et ceux qui sont prêts à payer pour une adaptation n’ont pas encore les budgets en accord ce que cela coûte réellement.

Tout est faisable en informatique, mais à quel prix ? Le code que je produis pour BGA m’appartient, mais il n’est pas applicable en l’état en dehors de l’écosystème de la plateforme.

Il est toujours possible de développer une plateforme web qui puisse émuler le fonctionnement de BGA mais je ne suis pas certain que ça en vaille le coût.

Par contre pour une application mobile il faudrait obligatoirement tout développer à partir de zéro. Même si la conception et certains algorithmes pourraient être récupérés.

Mon expérience avec BGA comble aujourd’hui une lacune que j’ai depuis pas mal d’années. J’ai besoin de faire, de produire quelque chose par moi-même. C’est la plus grande gratification du développeur : réaliser quelque chose qui peut servir à d’autres, générer de la joie et réunir les joueurs autour d’un jeu.

Quand je vois que plus de 50 000 parties de Yokai ont été jouées, que des joueurs ont consacré 2 600 heures à jouer à Almadi au cours du mois de janvier, ça me rend fier de mon travail.

Pour le moment, je suis plutôt satisfait de cette expérience. Elle me permet de contrebalancer la frustration qu’engendre parfois mon “vrai” travail à ne pas faire soi-même et à trouver que les projets n’avancent pas assez vite. Cette activité me permet également d’être un meilleur Product Owner car je continue à développer et cela m’aide à comprendre les problématiques de mes équipes.

Je continuerai tant que j’y trouverai du plaisir. Quand je traînerai des pieds pour terminer un jeu, je réfléchirai probablement à arrêter.

Je tiens à remercier les éditeurs et les auteurs qui m’ont fait confiance. J’ai toujours voulu œuvrer pour le monde du jeu et je l’ai toujours fait, dans la mesure de mes capacités, depuis que je suis en âge de travailler. J’ai aujourd’hui l’opportunité de démocratiser le jeu de société, d’apporter une certaine visibilité à des jeux qui le méritent, tout en satisfaisant mon goût pour les nouveaux défis. Merci à eux pour ça.