5 leçons que j'ai apprises de l'Open Jam 2020

Les Game Jams sont une façon vraiment amusante de créer quelque chose d’intéressant rapidement, à condition de ne pas succomber aux pièges.

Pour beaucoup de gens, programmer est amusant car c’est un peu comme résoudre un casse-tête. Vous savez qu'en théorie, si vous pouvez simplement organiser les instructions logiques et les conditions dans le bon ordre, en utilisant exactement la bonne syntaxe, vous obtiendrez alors une application qui fait quelque chose d'utile. Le problème, étrangement, est que parfois vous ne savez pas pourquoi vous auriez besoin de l'application que vous obtenez. C'est comme sortir pour une promenade sans nulle part où aller. Tout comme les marathons fournissent un cadre et un objectif pour une circulation piétonnière sans but, il existe des événements sans cause pour les codeurs. Appelés sprints, hackathons, défis ou jams, ces événements de programmation sont d'excellentes excuses pour s'asseoir, éventuellement avec une équipe de vos camarades codeurs, et développer quelque chose d'intéressant.

^{(Open Jam, CC BY-SA 4.0)}

Open Jam est un game jam virtuel annuel d'un week-end qui donne lieu à autant de jeux open source que les participants parviennent à terminer dans les 80 heures d'ouverture de l'événement. J'ai rencontré Open Jam pour la première fois lors de la conférence All Things Open 2018, où les organisateurs du jam disposaient d'une borne d'arcade exécutant le travail de l'année précédente.

^{(Opensource.com, CC BY-SA 4.0)}

J'avais déjà joué à des petits jeux d'autres jams et j'ai toujours pensé que ça pourrait être amusant d'en rejoindre un un jour. Cependant, je n'avais aucun intérêt à contribuer à des projets qui n'étaient pas open source, ni à des projets développés sur des piles non ouvertes. L’idée d’un jam open source était donc suffisamment convaincante pour que je m’engage.

Cette année, j’ai terminé un jeu pour Open Jam et l’expérience a été formidable – et rien du tout à la hauteur de ce à quoi je m’attendais. Si vous êtes tenté par la perspective de gloire et de fortune grâce à un game jam, évitez certains pièges en lisant cinq leçons que j'ai apprises en participant à l'Open Jam.

1. Restez simple

En 2019, je me suis inscrit à Open Jam avec l'intention de programmer un jeu simple en Lua. J'avais de bonnes idées pour un jeu et je pensais que participer semblait une idée simple, alors j'ai réservé le week-end pour coder. Ce jeu n'a jamais été terminé.

Il s’avère qu’il existe des idées simples, puis des idées réellement simples. Pour un game jam du week-end, vous devez permettre à la simplicité d’imprégner tous les aspects de votre jeu.

Vous voulez une histoire dans votre jeu ? Ce doit être une histoire à deux temps. Sautez le deuxième acte et passez directement du premier acte (un problème est présenté) au troisième (problème résolu, partie terminée).

Vous avez besoin de graphiques pour votre jeu. Gardez-les simples. Même si vous trouvez un artiste errant (ils existent et ils convergent vers le serveur de discussion d'Open Jam à la recherche de projets à rejoindre), leur temps est aussi limité que le vôtre. Les graphiques dans les jeux se multiplient rapidement et de manière exponentielle lorsque vous utilisez l'animation.

Si vous voulez des effets sonores et de la musique, restez simple. Vous trouverez peut-être des compositeurs, mais un week-end ne laisse pas beaucoup de temps pour la composition, l'interprétation et la prestation. Vous devrez probablement choisir de la musique existante qui pourrait ne pas correspondre parfaitement à votre jeu, ou utiliser des morceaux simples et rapides à diffuser. Les boucles sont probablement idéales, et laisser votre compositeur gérer les effets sonores garantit que la musique et les effets sont bien intégrés.

Pour mon jeu de cette année, j'ai abandonné la simplicité et adopté le minimalisme extrême. J'étais une équipe composée d'une seule personne (ce qui, je me suis rendu compte plus tard, n'était pas nécessairement dans l'esprit d'un game jam collaboratif), j'ai donc opté pour aucun graphisme au-delà des blocs colorés et j'ai utilisé principalement des morceaux de musique à une seule note (composés sur LMMS) – et une grande partie de la musique est composée par l’utilisateur en fonction de ce qu’il fait pendant le jeu.

2. Commencez depuis le début

Lorsque j'ai commencé à écrire mon jeu, j'ai commencé avec mon plateau de jeu et j'ai travaillé sur les mécanismes en grande partie dans le but de découvrir si j'avais réellement un jeu. Pendant plusieurs heures, je n’étais pas entièrement convaincu que je n’écrivais pas simplement un Etch-A-Sketch numérique sans aucun élément de jeu en vue. J'ai finalement trouvé un jeu dans le code que j'écrivais, mais lorsque j'ai terminé ma première ébauche, j'ai découvert que j'avais un jeu qui devait être relancé à chaque fois que vous vouliez jouer à nouveau. Je n’avais ni écran de démarrage, ni écran de fin, ni classement, ni aucun moyen de choisir de rejouer.

La résolution de ces problèmes a nécessité une refactorisation, et même dans son état actuel, le code n'est pas aussi optimisé qu'il pourrait l'être. Dans mon code utilitaire, cela ne me dérange généralement pas d'avoir un code plus verbeux que nécessaire afin de documenter la logique pour moi-même et pour les autres qui veulent la comprendre. Cependant, il ne s'agit que d'un jeu relaxant, donc je pense qu'il serait bien d'avoir un code optimisé et bien organisé plutôt que des fonctions après réflexion mélangées à des classes importantes et des variables globales ajoutées à la hâte.

Une partie de cela peut être excusée par le fait que mon code a été écrit lors d'un game jam frénétique, mais à l'avenir, je préférerais commencer depuis le début, même s'il ne s'agit que de modèles passe-partout. Je commencerai par un écran de démarrage où le joueur peut définir les niveaux de difficulté, je veillerai à ce qu'il y ait un écran de fin avec la possibilité de quitter ou de rejouer, et ainsi de suite.

3. Concentrez-vous sur une mécanique de jeu

Je ne suis pas un game designer, mais cela ne m'empêche pas d'essayer de l'être. Dans les meilleurs grands jeux vidéo comportant de nombreux niveaux, une partie de l’expérience consiste à découvrir de nouvelles mécaniques de jeu. Imaginez un jeu dans lequel vous commencez par découvrir, grâce à des invites subtiles, que vous pouvez arrêter le temps. Ensuite, vous obtenez le pouvoir non seulement d’arrêter le temps, mais aussi de le rembobiner d’un certain nombre de secondes. Plus tard, vous obtenez la possibilité d’avancer rapidement. Et ainsi de suite.

Cela semble amusant et ressemble à quelque chose que vous ne devriez jamais essayer de faire dans un game jam.

Dans la version originale de mon jeu, j'ai commencé à écrire des actions automatisées que l'ordinateur devait entreprendre contre le joueur pour tenter de perturber le plateau de jeu. Cela m'a conduit sur un chemin de calculs complexes, de détection d'état, d'anticipation de virage et de probabilité. J'ai passé plusieurs heures à essayer de trouver un bon équilibre entre offrir une bonne aggravation et être tout simplement ennuyeux et aussi avoir du mal à imiter des décisions intelligentes.

En fin de compte, j'ai tiré une ou deux leçons de mon expérience en tant que Dungeon Master™ : l'adversaire le plus menaçant du joueur est le joueur. J'ai abandonné l'idée de perturber l'état du jeu et j'ai plutôt permis à l'espace des joueurs de trop réfléchir.

C’était le bon choix tant du point de vue de la conception que du point de vue du code. Après tout, plus vous avez de mécanismes dans votre jeu, plus vous devez écrire de code. Plus vous devez écrire de code, plus vous devez déboguer.

4. Choisissez soigneusement votre langue

Je n'ai pas tant choisi Python et Pygame pour mon projet cette année que Python et Pygame m'ont choisi. Je venais de montrer à quelqu'un comment créer une grille (un simple tableau bidimensionnel) à l'aide de boucles imbriquées, et il se trouve que le langage qu'ils utilisaient était Python. J'ai utilisé Pygame au lieu de quelque chose de plus moderne comme Arcade parce que je connais Pygame. Après avoir démontré la tâche, j'ai réalisé que c'était le week-end Open Jam et qu'avec "juste quelques" lignes de code supplémentaires, je pouvais créer un jeu à partir du tableau que j'avais créé. Sans surprise, ces quelques lignes supplémentaires se sont avérées être au nombre d’environ 200.

Python est génial car il est multiplateforme, mais fournir une application Python sur toutes ses plates-formes possibles peut être un autre problème en soi si vous n'avez pas planifié à l'avance (et je n'avais pas planifié à l'avance). Vous pouvez absolument pouvoir proposer Python aux systèmes d'exploitation de bureau, Android, iOS, etc., mais pour de meilleurs résultats, vous devez développer en gardant cela à l'esprit en utilisant Kivy ou BeeWare ou un framework similaire. Ce ne sont pas des processeurs par lesquels vous exécutez votre code comme par magie et vous obtenez instantanément des packages pour toutes les plates-formes ; ce sont des frameworks avec lesquels vous devez travailler du début à la fin. Parce que je n'avais pas prévu mes objectifs en tête, j'ai terminé Open Jam avec un jeu qui fonctionne bien sous Linux, Windows et macOS mais nécessite toujours un packaging et ne fonctionne pas du tout sur les plateformes mobiles.

Si je devais répéter le game jam avec une meilleure prévoyance, j'aurais utilisé Java ou Processing, qui proposent tous deux des solutions de packaging simples pour les ordinateurs de bureau et les mobiles.

En fin de compte, gardez votre objectif à l’esprit et travaillez vers le résultat souhaité. Ne programmez pas tout le week-end pour constater que la livraison finale nécessite un autre week-end.

5. Utilisez ce que vous savez

Supprimer les obstacles à l'achèvement est l'un des meilleurs moyens de vous assurer de terminer votre partie. Même si Pygame n’était peut-être pas le meilleur choix selon certaines mesures, c’était le meilleur choix compte tenu des résultats. Comme je me l'ai démontré l'année dernière, il est facile de ne pas terminer un game jam, donc m'assurer d'avoir toutes les chances de le terminer en utilisant un cadre que j'ai enseigné aux enfants et aux adultes au cours des dernières années était une bonne stratégie.

Cela s’étend également à d’autres aspects. Un game jam n’est probablement pas la meilleure occasion d’expérimenter quelque chose d’inconnu. N'essayez pas de composer de la musique sur une application à laquelle vous n'avez presque jamais touché. Ne concevez pas vos graphiques avec une nouvelle application sympa dont vous avez entendu parler sur Internet mais que vous n'avez ouverte qu'une seule fois. Il est déjà assez difficile de terminer un jeu en deux jours, vous voulez donc que tout ce que vous utilisez pendant le développement facilite l'atteinte de l'objectif final.

Planifier pour la prochaine fois

J'étais une équipe composée d'une seule personne, donc je n'ai pas profité (ni contribué à) l'aspect social d'Open Jam, et pourtant c'était quand même une expérience satisfaisante et amusante. Il y a beaucoup d'élan lorsque de nombreuses personnes se rassemblent pour un objectif unifié, et la promotion du jeu open source par Open Jam est quelque chose qui suscite facilement l'enthousiasme, tant du point de vue de l'open source que du point de vue des joueurs. Si vous avez déjà pensé à rejoindre un game jam, je vous recommande fortement de vous inscrire à l'Open Jam l'année prochaine !