Au cours des deux dernières années et demie, j’ai travaillé comme chef de projet IT dans les domaines du secteur public et de la santé. Même si j’aime organiser les choses et rassembler des personnes autour d’un projet, j’ai progressivement réalisé que ce métier ne me correspondait pas vraiment.

Les grands projets institutionnels s’accompagnent de beaucoup de structure. Les processus sont bien définis, les rôles clairement séparés, et de nombreuses personnes ont déjà tracé le chemin avant vous. D’une certaine manière, c’est rassurant : on est accompagné, guidé, et les choses sont prévisibles.

Mais cela signifie aussi qu’on touche rarement à des aspects créatifs.

En tant que chef de projet, on dépend souvent de nombreuses autres personnes pour avancer. On coordonne, on planifie, on suit l’avancement. Et même si j’aime travailler avec les autres, il me manquait cette sensation de construire quelque chose moi-même.

J’ai toujours été attiré par les jeux. Enfant, j’ai joué à d’innombrables jeux de société, j’en inventais avec mes frères, on passait des après-midis à recréer des mondes imaginaires ensemble. Plus tard, j’ai failli travailler dans l’industrie de l’esport juste avant le COVID. Finalement, la vie m’a orienté vers l’IT et je m’étais éloigné du monde du jeu depuis.

Jusqu’à récemment.

Ce projet est né en partie par curiosité, en partie par obstination, et peut-être aussi à cause d’une petite crise existentielle du quart de vie. Je voulais essayer de créer quelque chose selon mes propres règles : quelque chose de créatif, de ludique, un terrain d’expérimentation libre.

Et si je devais le faire, je voulais tout faire moi-même : programmation, graphismes, musique, tests, documentation… tout.

Je ne sais toujours pas si le développement de jeux sera la voie que je suivrai à l’avenir. Mais je savais une chose : je voulais essayer.

Avant de commencer le projet, je savais que j’avais besoin du bon outil.

Les moteurs de jeu modernes sont incroyablement puissants, mais ils viennent aussi avec une grande complexité. Comme il s’agissait de mon premier jeu , je cherchais quelque chose de plus simple, avec des contraintes qui m’aideraient à garder le projet sous contrôle.

C’est là que j’ai découvert Pico-8.

Pico-8 est souvent décrit comme une fantasy console. L’outil recrée la sensation de programmer sur du matériel ancien avec de fortes limitations : une résolution fixe, une palette de couleurs réduite, une mémoire limitée, et des outils intégrés pour tout.

Et c’est précisément ce qui le rendait attirant.

Tout est inclus dans un seul environnement :

• un éditeur de code

• un éditeur de sprites

• un éditeur de carte

• un tracker musical

• un éditeur d’effets sonores

On peut l’ouvrir, commencer à créer immédiatement, et partager facilement ses jeux avec d’autres via la communauté Lexaloffle.

Les limitations se sont révélées extrêmement utiles. Au lieu de me perdre dans des possibilités infinies, j’avais des contraintes claires. Cela m’a beaucoup aidé à aller au bout du projet.

Mon premier réflexe a été de créer quelque chose d’entièrement original.

J’ai commencé à expérimenter différentes mécaniques et idées, mais je me suis rapidement heurté à un problème classique des projets créatifs : l’augmentation incontrôlée du périmètre, le scope creep. Chaque idée en amenait une autre, puis encore d’autres fonctionnalités, plus de complexité, et au final… un projet impossible à terminer.

À un moment, j’ai essayé de créer un petit shooter inspiré de Enter the Gungeon. C’était amusant à prototyper, mais il est vite devenu évident que cela demanderait bien plus de travail que ce que je pouvais raisonnablement gérer le soir et le week-end.

J’ai donc changé de stratégie.

Au lieu de tout inventer, j’ai décidé d’adapter quelque chose qui fonctionnait déjà.

Ma copine et moi jouions beaucoup au jeu de société Botanik. C’est un jeu sympa de placement de tuiles où les joueurs construisent des machines à vapeur en assemblant tuyaux, fleurs et mécanismes, tout en se disputant les meilleures pièces.

C’était un candidat parfait.

Les règles existaient déjà. Le gameplay de base était solide. Il ne me restait qu’à le traduire en version numérique.

Bien sûr, adapter un jeu de société à une petite fantasy console implique ses propres contraintes. J’ai dû simplifier certaines choses :

• J’ai supprimé une catégorie de tuiles (les scientifiques).

• J’ai réduit le nombre de tuiles disponibles sur le plateau.

• J’ai légèrement ajusté le système de score.

• J’ai modifié certaines règles pour qu’elles fonctionnent mieux dans une interface numérique.

Le résultat, c’est BotaPic :

un jeu de stratégie local 1v1 au tour par tour, où les joueurs s’affrontent pour construire la machine à vapeur la plus efficace en plaçant des tuiles sur un plateau partagé et en gérant les pièces disponibles.

Une partie dure environ 20 minutes, ce qui en fait un jeu idéal à jouer avec un ami sur le même canapé.

J’ai commencé à travailler sur le jeu fin novembre, principalement le soir, le week-end, et dès que j’avais assez d’énergie après le travail.

Mon processus était assez simple :

1. Construire les mécaniques d’abord

J’ai commencé par implémenter les règles de base et la logique du gameplay.

1. Créer des visuels temporaires

Les premiers graphismes étaient très simples, juste assez pour comprendre ce qui se passait à l’écran.

1. Itérer sur les visuels après les retours

Une fois que les premiers tests ont commencé, il est devenu évident que les visuels devaient être améliorés.

1. Tester et affiner

J’ai invité des amis à tester le jeu, recueilli leurs retours, et ajusté le design.

1. Ajouter le son et peaufiner.

Enfin, j’ai travaillé sur les effets sonores, la musique, la documentation et la présentation globale avant la sortie.

Ce n’était pas toujours un processus linéaire, mais cette structure m’a aidé à garder le projet gérable.

La programmation est probablement la partie avec laquelle j’étais le plus à l’aise au début du projet.

Je crée des sites web depuis environ 2017, même si mon travail récent de chef de projet ne m’a pas beaucoup amené à coder. Mon dernier vrai projet de programmation avant celui-ci était une petite initiative appelée La Pépite.

J’avais déjà expérimenté de petits prototypes de jeux, mais je n’avais jamais terminé un jeu complet.

Même si la partie technique était mon point fort, il y a eu de nombreux défis. Les limitations de Pico-8 obligent à réfléchir attentivement à la structure du code et à la gestion de la mémoire.

Avec le recul, il y a clairement des choses que je ferais différemment aujourd’hui. Mais pour un premier projet complet, je suis assez satisfait du résultat technique.

La première version du jeu… était horrible.

Les sprites étaient ternes, peu colorés, et il était parfois difficile de comprendre ce que l’on voyait.

Les retours des premiers testeurs étaient clairs : les visuels devaient être retravaillés.

C’était le retour à la case départ pour moi.

Plus je dessinais, plus je m’améliorais à travailler avec les contraintes de Pico-8. Ajouter des couleurs plus marquées, améliorer les contrastes, et expérimenter avec des techniques simples d’ombrage a fait une énorme différence.

Je ne suis clairement pas un artiste aujourd’hui, mais ce projet m’a appris quelque chose d’important : on progresse simplement en faisant.

Pour être honnête, certains sprites, notamment les fleurs et les fruits, sont fortement inspirés du travail d’autres artistes. Mais la plupart des autres éléments ont été créés de zéro, et j’en suis fier.

Les tests ont été ma partie préférée de tout le processus.

Au total, sept personnes ont participé aux tests. Elles ont joué à la fois à la version numérique et au jeu de société physique, ce qui a facilité la comparaison entre les deux expériences.

La majorité des retours portait sur la clarté :

• À qui est le tour ?

• Où puis-je placer des tuiles ?

• Que vient-il de se passer sur le plateau ?

Ce sont des éléments souvent évidents dans un jeu physique, car les joueurs interagissent naturellement avec les pièces et entre eux. Dans un jeu numérique, tout doit être communiqué via l’interface.

Les sessions de test m’ont aussi rappelé à quel point j’aime jouer avec d’autres personnes dans la même pièce. C’est toujours ma manière préférée de vivre le jeu : être ensemble, discuter, réagir, partager le moment.

Un autre bénéfice inattendu des tests a été la motivation. Partager régulièrement le jeu m’a aidé à garder le rythme et à rendre le projet concret.

La partie la plus difficile du projet a été quelque chose que j’avais complètement sous-estimé : la musique.

Le dessin était déjà un défi, mais j’avais au moins un peu d’expérience. La musique, en revanche, même après dix ans de piano, était un territoire totalement nouveau.

Mon objectif initial était ambitieux : créer une bande-son complète pour le jeu. Cela impliquait d’apprendre le tracker musical de Pico-8 depuis zéro, ce qui s’est avéré plus complexe que prévu.

Plusieurs difficultés sont apparues :

• La musique devait rester agréable sans devenir répétitive ou distrayante.

• Il y avait peu d’inspiration disponible dans la communauté Pico-8.

• Créer des effets sonores individuels était faisable, mais les transformer en motifs musicaux cohérents était beaucoup plus difficile.

• Mes bases en théorie musicale étaient rouillées.

Au début, j’ai abordé le problème de manière très académique, en sur-analysant la théorie au lieu d’expérimenter.

Finalement, j’ai pris du recul et fait un choix pragmatique : pour un premier jeu, les effets sonores suffisaient. Ajouter une musique de fond constante risquait d’alourdir l’expérience plutôt que de l’améliorer.

Après plusieurs mois bloqué sur ce sujet, j’ai accepté qu’il était normal que mon premier jeu n’ait pas de musique, et qu’avancer était plus important que tout rendre parfait.

Avec le recul, il y a encore beaucoup de choses que j’aimerais améliorer.

Si je continue à créer des jeux, je sais que j’aurai besoin d’aide, notamment pour la musique et les visuels finaux. Le game design est aussi un domaine que j’aimerais explorer davantage de manière collaborative.

Ironiquement, j’ai réalisé que ma vraie force est peut-être toujours ce que je faisais en tant que chef de projet : rassembler des personnes pour construire des choses. La différence, c’est que cette fois, je veux aussi participer directement au processus créatif.

Je tiens aussi à souligner le rôle des outils d’IA dans ce projet. Sans eux, terminer le jeu en parallèle d’un travail à temps plein aurait été bien plus difficile. Je les ai utilisés pour m’aider en programmation, pour trouver de l’inspiration visuelle, des idées musicales, et pour l’écriture.

Peut-être que je n’ai pas appris aussi profondément que sans eux, mais ils m’ont permis de construire beaucoup plus en un temps limité.

Il reste encore des bugs connus et des améliorations à apporter. Par exemple, il existe un petit problème lorsque les deux joueurs placent des tuiles en même temps, où l’interface autorise brièvement des placements supplémentaires ; l’animation de pose des tuiles est pour le moins approximative; le design du plateau est… disons artistique ; avec plus d’espace, j’ajouterais probablement un véritable menu d’introduction ; etc.

Mais à un moment donné, il faut savoir s’arrêter.

Un jeu, comme tout projet créatif, n’est jamais vraiment terminé. Il est simplement publié.

Et c’est ici que j’ai décidé de m’arrêter et de le partager.

Pour la suite, je veux continuer à créer des jeux auxquels on joue ensemble dans la même pièce. Les jeux en coop locale et les party games me semblent être la direction la plus naturelle pour moi.

Je prévois aussi d’apprendre Godot. Comme pour ce projet, l’objectif sera de commencer petit et d’aller jusqu’au bout.

Peut-être même participer à une game jam, qui sait, ce serait sûrement une bonne façon de rencontrer des personnes qui partagent les mêmes intérêts.

Pour l’instant, je suis simplement heureux d’avoir enfin terminé mon premier jeu après des années à y penser.

Et bien sûr, merci à toutes les personnes qui m’ont soutenu en testant le jeu, en donnant des retours ou simplement en m’écoutant parler de ce que j’aime :)