La semaine dernière se terminait la Global Game Jam 2024 (que j’abrévierai en GGJ par la suite), une compétition opposant créatifs et développeurs afin de produire un jeu (ou tout du moins un prototype jouable) en un temps imparti et avec un thème défini.

Un petit groupe d’amis s’est motivé pour participer et m’a proposé de se joindre à eux. Après quelque échanges sur Discord, on a convenu de faire ça à l’aise chez l’un de nous, chacun amenant son ordi et de quoi bosser.

Si le détail de ces trois jours ne vous intéressent pas, vous pouvez directement tester notre jeu en le téléchargeant gratuitement ici : https://fangh.itch.io/snaparazzi

Mais avant de parler du jeu, il faut se présenter, c’est la base de la politesse il parait !

La Dream Team

Fangh

Développeuse et patronne du studio 6freedom, c’est la plus expérimentée du groupe, participant à la GGJ quasiment chaque année depuis 2013.

Vanille

Développeuse ayant déjà un tout petit peu touché à Unity et première GGJ.

Otak

Le seul qui ne soit pas dev du groupe. Première GGJ à lui aussi, mais pas premier évènement du genre car il a participé à plusieurs reprises à des skits (vous remplacez le JV par de la musique et de l’animation et c’est tout pareil).

Xéfir

Votre humble serviteur, développeur web senior qui n’a jamais touché à un moteur de jeu vidéo de sa vie o/

Crépuscule du premier jour

On se retrouve donc chez Otak et Vanille et on découvre le thème de cette année :

En plus du thème, il y a plein d’autres contraintes (« diversificateurs ») que l’on peut s’imposer (mais totalement facultatif) listé sur la page de la GGJ : https://globalgamejam.org/news/ggj-2024-diversifiers-are-here

À partir de là, Fangh, étant rodée à l’exercice, pris le lead afin d’organiser les prochaines étapes de la meilleure manière possible. Partir la tête la première dans du code est le meilleur moyen de se planter alors on range les ordis et on sort les post-it !

Le but est d’y définir trois choses :

• Quel est le but à atteindre à la fin de la GGJ pour toi ?
• Qu’attends-tu de la GGJ ?
• Quelles sont tes limites à ne pas dépasser dans cette GGJ pour toi ?

En synthèse, beaucoup de nos points se sont regroupés et globalement, tout le monde voulait avant tout que ces trois jours soient fun, qu’on s’y amuse et qu’on apprenne tous quelque chose à la fin.

Les limites ont été fixées au niveau des repas et du dodo. Tout le monde devait s’occuper de l’organisation d’un repas et on devait avoir un minimum de temps pour dormir. On a tous la trentaine et les nuits blanches ne sont plus aussi faciles à récupérer qu’avant.

Pour ce qui est du but final, c’est là où les avis divergent. Fangh s’attend à avoir un prototype fonctionnel, Otak et Vanille à quelque chose, même si c’est un peu cassé et moi à rien lol (dans le sens où si j’ai appris quelque chose, mais que l’on n’a rien réussi à sortir dans les temps, ce n’est pas grave).

Pitch, oh mon pitch

Maintenant la question de « qu’est qu’on fait-y donc pas comme jeu en fait lol ». Rebelote, chacun se remet à ses post-it et le but est d’y écrire un maximum d’idée de jeu possible qui répondant au thème.

Ici, chacun sa méthode et chacun ses inspirations. Otak et Fangh sont les plus inspirés, Vanille et moi-même avons plus de mal à trouver des idées.

Bon, pour mon cas personnel, j’ai l’expérience de mon boulot qui a pris le dessus et le seul concept que j’avais, j’en ai écrit un cahier des charges presque complet !!

À la fin, trois concepts furent retenu :

• Un jeu à la Octodad où chacun des joueurs contrôle un membre de la créature, mais en ayant chacun que la vue du membre qu’il contrôle. En gros, c’est comme si on avais un œil sur chaque main et pied et qu’on ne voyait que ça. Ça demande donc de bien communiquer pour avancer et valider les objectifs qui auront été fixés par le jeu.
• Un jeu à la Quiplash mixé avec le jeu « action ou vérité ». Ce serait donc un jeu multijoueur où chaque joueur utilise son smartphone pour prendre une photo ou une vidéo répondant à une « action » à faire ou à répondre à une « vérité » sous forme de texte. Deux joueurs au minimum se voit attribuer la même « action » ou la même « vérité » et on vote pour la réponse la plus drôle, insolite ou débile dans la seconde partie du jeu. Celui qui a reçu le plus grande nombre de votes gagne.
• Un jeu à la Youtuber’s Life où le joueur doit gérer la vie d’une agence de stand-up. C’est donc un jeu de simulation où l’on doit gérer la carrière de comédiens, de leur représentations sur scènes jusqu’à leur pérennité dans l’agence.

On est finalement parti sur le concept du jeu à la Quiplash, mais en simplifiant énormément la formule. Faire un jeu multijoueur est déjà une ambition particulièrement élevé de base, on n’aurait jamais eu le temps de tout faire.

Exit donc la partie « vérité » ainsi que la prise de vidéo dans la partie « action », on fera un jeu où on se prend en photo ou on prends en photo des scènes ou des objets qui collent avec le thème donné par le jeu.

Les bons outils

Comme c’est un jeu multijoueur, en plus du moteur de jeu, on va devoir s’occuper de la partie stockage des photos et serveur multi. Un bon nombre d’entre nous n’avais pas trop touché à Unity et on a ici un jeu qui n’a pas besoin d’un environnement 3D pour fonctionner, autant essayer un autre moteur.

Après avoir joué une grosse demi-heure avec Construct 3, on s’est heurté à un mur qui sera une contrainte qui sera prépondérante sur tous les choix qui seront faits après : LA THUNE. En effet, la version gratuite nous limite à 25 actions maximum sur le projet entier et on ne veut pas dépenser de l’argent pour un jeu qui ne sera jamais vendu à la fin.

Retour donc sur Unity, un moteur que Fangh connais bien et dont la licence, malgré la controverse puis rétro-pédalage d’une taxe à l’installation, nous permet de l’utiliser pour des projets non commerciaux gratuitement.

Concernant la partie serveur, il y a un adage très réel qui dit « ce qui coûte le plus cher sur Internet, c’est le stockage ». Or, il faut bien stocker les photos prisent par les participants. 8 participants par rooms, une photo pesant environ 2mo, chaque personne répondant à minimum 2 propositions : 8*2*2 = 32Mo par rooms. Et il n’y a pas vraiment de limite de rooms vu qu’on peut les créer comme on veut. Bref, ça peux monter très vite et c’est d’ailleurs pour cela que l’on a écarté très vite l’idée de faire de la vidéo (une vidéo, même de quelque seconde, dépasse les 20Mo).

De plus, coder un serveur prend du temps, autant de temps que de coder le jeu en lui-même. Pour autant, notre jeu ne fait pas grand-chose : on doit enregistrer les questions, les associer à des joueurs, enregistrer leurs photos et les points gagnés par les votes. Il nous faut donc une base de données, un serveur de socket (permet l’envoie d’évènements qui seront reçus par l’ensemble des joueurs) et un stockage pour les photos.

Google propose un service nommé Firebase répondant exactement à ce genre de besoin rapide, avec des limitations sur le nombre de requêtes ou une limite sur le stockage. Les limites étant suffisamment haute par rapport à notre projet, on s’est lancé là-dessus.

Aurore du second jour

Après un réveil un peu difficile, on se retrouve en ordre de marche !

On s’est donné une petite feuille de route pour la journée :

• Otak devait inventer au moins 50 propositions de photos funs
• Vanille devait s’occuper de l’interface utilisateur sur mobile
• Fangh devait s’occuper de l’interface de jeu visible par tout le monde ainsi que de l’architecture technique du jeu
• Je devais m’occuper d’intégrer la possibilité de prendre des photos ainsi que d’intégrer Firebase au projet

Nous partageons la même Unity

Après un cours accéléré de Fangh, je mets les mains dans Unity et je dois l’admettre, c’est plutôt intuitif … Une fois qu’on a les deux trois concepts de base.

J’arrive très vite à créer ma première scène qui va accueillir la fenêtre de la caméra et à brancher des scripts C# aux éléments pour que la logique se greffe aux composants graphiques.

Seul bémol toutefois : Unity n’est pas vraiment fait pour collaborer avec Git. En effet, pour se partager nos travaux et garder une trace des modifications, le standard de facto quand on dev, c’est Git. Et là où ça va pêcher, c’est sur comment Unity gère les changements de fichiers.

Quand on édite un fichier en dehors de Unity, celui-ci va se recharger, entraînant par la même occasion un beau gros ralentissement du système à chaque fois … Quand il ne crash pas totalement si un trop grand nombre de choses a été modifié.

Pour autant, avec un peu d’organisation et en se prévenant qu’on allais pousser quelque chose sur une scène sur laquelle quelqu’un d’autre travaillait, ça se passait bien.

Caméra, oh ma belle caméra

Histoire de ne pas avoir à réinventer la roue, on a cherché un plugin tout fait pour exploiter la caméra, que ce soit sur Android ou iOS … Et on a trouvé cette extension.

Je m’en suis très vite séparé. Il fonctionne très bien et agi comme attendu. Le problème vient du fait qu’il fait apparaître la caméra en plein écran, masquant l’interface du jeu et on voulait faire en sorte de voir le temps restant pour prendre la photo en permanence.

Retour à la base donc en utilisant les APIs que proposent Unity … Et elles sont vachement bien !!

En fouillant un peu la documentation, on tombe sur la classe WebCamTexture qui gère l’interface entre la caméra et une texture sur la scène. Seul bémol qui va me prendre une bonne grosse heure à corriger : la webcam de mon PC s’affiche correctement, la caméra avant sur mon Android s’affiche pivoté de 45 degré sur la gauche et la caméra arrière pivoté de la même manière, mais sur la droite … Ce qui n’a aucun sens (enfin si, mais pas les bons !)

Je pensais au début que c’était une erreur de ma part avant de me rendre compte que c’est le comportement attendu par Unity. Résigné, j’ai donc codé de quoi pivoter à la volée l’image en fonction de la caméra.

Firebase et base de données

Firebase nous propose plein de services, comme on pourrait s’attendre d’un système dans le nuage (« cloud »).

Nous n’en avons besoin que de 4 :

• Authentication : Celui-ci est obligatoire et gère l’authentification des utilisateurs et des applications, pour éviter que n’importe qui puisse faire n’importe quoi sur le reste des services
• Firestore : C’est une base de données NoSQL, c’est-à-dire que les données y sont stockées sous forme de collections qui n’ont pas besoin d’une structure de données fixe. C’est très flexible, mais ça peux vite devenir une plaie si on ne se tient pas à un schéma de données précis. On y mettra l’ensemble des énoncés qui seront envoyés aux joueurs.
• Realtime : C’est une base de données évènementielle, c’est-à-dire qu’elle enverra un message à toutes les applications connectées dès que quelque chose y sera posté, modifié ou détruit. On s’en servira pour gérer tous les aspects multijoueurs.
• Storage : Du stockage de fichiers … Tout simplement. On y téléversera les photos prisent par les joueurs.

Très rapidement, Fangh nous donne une structure de base de données qui ne sera que très peu modifié.

Pas grand-chose à dire de plus, à part que j’applaudis le sang froid de Fangh qui a dû gérer sa partie du dev en plus de nous apporter un support régulier aux différents problèmes que nous rencontrions.

Parlons d’intelligence artificielle

Avoir une interface fonctionnelle avec des boutons et des textes en noir sur un fond blanc, c’est bien. Avoir une interface colorée et agréable à l’œil, c’est mieux.

Pour ce qui est des fonds, des textes et du design global, Otak nous a sorti le Photoshop et ça nous donne ça :

Il manque portant deux choses : un logo et une image pour remplacer ce cadre noir si on n’a pas réussi à prendre de photo à temps ou si l’application n’arrive pas à afficher la caméra.

Le temps file et on a encore beaucoup trop de choses à faire, il faut aller au plus simple. On a donc demandé à Leonardo de nous générer quelque chose.

Et là, c’est le moment où je vais devoir clarifier notre position concernant ce sujet brûlant qu’est la génération de contenu à base de modèles de langages, alias ce qu’on appel communément IA.

Je pense que l’IA est un formidable outil de prototypage, permettant de mettre des mots, des sons ou des images sur des concepts, des idées qui, du point de vue de mon cerveau qui n’est absolument pas créatif, me serait tout simplement impossible à réaliser, surtout dans des délais aussi court. Bien entendu, il est impensable pour moi d’utiliser le contenu généré dans un produit commercial et si notre jeu rencontre un succès inespéré … Déjà, on va devoir sortir le chéquier et payer Google 😢 Et surtout, on engagera des artistes pour créer une réelle identité. Ce que nous avons produit pendant cette Game Jam est loin d’être un produit fini et même s’il est « jouable », on est clairement sur un POC (proof of concept, un prototype si vous voulez).

Otak nous a aussi réalisé les musiques du jeu en partant de musique libre de droits et en les modifiant avec Audition pour que ça colle encore plus à l’ambiance que l’on voulait pour le jeu.

Aube du troisième jour

La nuit traîne en longueur et contrairement au Vendredi soir, on pousse jusqu’à trois heures du matin. À ce stade, tout avance bien malgré la montagne de choses qu’il reste à faire.

De mon côté, je m’attaque à l’algorithme qui va associer deux questions à un joueur. Petite subtilité, chaque joueur doit répondre à une question d’un autre joueur (pour pouvoir voter derrière). Ça à l’air trivial comme ça, mais je me suis cassé les dents dessus durant toute la nuit. Et pour vous expliquer simplement, rien ne vaux un schéma !

Ce genre de paradigme, c’est le quotidien d’un développeur. C’est notre métier de trouver des solutions simples à des problèmes qui semblent compliqués au premier abord … Et c’est grâce à une (courte) nuit de sommeil que je suis arrivé à cette conclusion. Comme quoi, même dans une compétition, dormir est essentiel pour nous, simple mortels.

GitHub : Vos cartes bleus s’il vous plaît

Comme je l’ai dit plus haut, on utilise le logiciel Git pour partager notre code. Seulement, ce logiciel à besoin d’un service pour se synchroniser et la plateforme la plus connue et la plus utilisée est GitHub, récemment racheté par Microsoft.

Le service est gratuit pour tout projet public, c’est-à-dire que tout le monde peut voir le code. C’est notre cas, c’est parfait. Sauf que nous avions loupé une petite ligne en bas du contrat.

Pour fonctionner, Git ne va pas enregistrer chaque fichier qui a été modifié, mais plutôt les modifications que l’on va y faire. C’est beaucoup plus léger de stocker le fait que la ligne 5 a changé plutôt que le fichier entier de 6000 lignes par exemple. Bref, quand c’est du texte, c’est bien, mais quand ce sont des images, des binaires, des trucs illisibles, cela devient plus difficile à gérer pour Git.

Pour cela, Git à une extension nommée LFS (pour Large File System) qui permet de sauvegarder efficacement ce qui est lourd et encombrant. Vous le voyez venir, GitHub a une limitation sur cette extension. On ne peut envoyer et récupérer que 1 Go par mois … Autant vous dire qu’on l’a atteint assez vite.

Pour pouvoir continuer à bosser, on a migré sur mon service que j’héberge au même endroit que ce blog : Gitea. C’est globalement tout pareil, mais si mon appartement brûle (ou est inondé, ce qui est plus raccord avec l’état actuel du logement), tout disparaît (en vrai, j’ai des sauvegardes en ligne, mais je n’ai pas l’infrastructure qu’à Microsoft pour m’aider).

La migration a été faite de manière partielle et certains fichiers manquent. Si vous clonez le dépôt chez vous, vous aurez sûrement des erreurs. Cela sera corrigé dans un mois, quand je relancerais une synchronisation entre les deux.

Fini ?

La soirée arrive à grands pas et on met un dernier coup de collier pour boucler le maximum de choses. On sait qu’on n’aura jamais fini. On a l’écran d’accueil et la prise de photo qui fonctionne, mais il nous manque toute la partie du vote et des scores à faire.

On est tous ruiné par la fatigue et on s’est mis d’accord pour lâcher les claviers à 18h, que ce soit terminé ou pas, et le jeu tel qu’il était le 28 janvier est envoyé sur itch.io. Donc non, pas fini, mais c’était ambitieux de se lancer dans un projet aussi fou de faire un jeu multi dès la première Game Jam.

J’ai appris énormément de choses et il m’a fallu quelques jours pour récupérer, mais je suis très content et assez fier de ce qu’on a pu produire en si peu de temps.

Pour autant, Fangh et Vanille ne veulent pas s’arrêter là et on continué à travailler sur le projet sur leur temps libre. Deux semaines plus tard, le jeu sors dans un état jouable du début à la fin. Un gros gros kudo à Fangh pour ça !

J’espère que vous aurez du plaisir à courir photographier du PQ ou votre poubelle en moins de 30 secondes et n’hésitez pas à nous faire part de vos retours ici en commentaires ou sur itch.io.