Je suis Aurélien Defossez, 26 ans, ingénieur R&D dans une start’up le jour, game designer / game developer la nuit.
De temps en temps, je participe à des événements de création de jeux, notamment ceux de la Game Dev Party. J’ai participé aux trois éditions organisées par cette association, toujours en tant que game designer, chef de projet et gameplay programmer, et j’ai réussi à produire trois jeux finis. Par jeu fini j’entends un jeu jouable, avec un début, une fin, un gameplay intéressant, des graphismes et du son. Les liens vers ces jeux sont disponibles en fin d’article.
C’est l’expérience accumulée lors de ces événements que j’aimerais partager en donnant des conseils d’organisation et de design, pour de produire un jeu qui mérite de s’appeler “jeu” en seulement 24 heures.
Ambiance de Game Jam
Un objectif réaliste
Vous avez certainement l’idée du siècle, un jeu de puzzle-aventure-openworld qui combine les meilleures idées de jeux que vous adorez. Vous imaginez déjà un lutin vert sur une jument, armé d’un Portal Gun, lâché au milieu des Vangaas d’Ivalice. Vous avez le scénario, vous avez les idées, et ce jeu déchire déjà avant même de l’avoir fait.
Malheureusement, le temps n’est pas extensible et 24 heures seront certainement insuffisantes pour développer un jeu AAA. Gardez ces idées de jeux complexes pour vos projets personnels, et tentez plutôt de partir sur quelque chose de plus simple. Le but de la Game Jam est de montrer un prototype de jeu au bout de 24 heures de développement, ce qui représente peu de temps.
Évitez donc les jeux avec un trop gros scénario (disons un scénario qui ne tient pas sur un post’it) ou demandant une certaine quantité de level design. Le narrative design et le level design sont deux tâches qui prennent beaucoup de temps.
Le narrative design demande beaucoup de développement spécifique et du temps qui ne pourra pas être mis dans l’élaboration du gameplay, et il arrive souvent qu’il ne soit tout simplement pas présent lors de la démonstration, faute de temps. Pour une Game Jam, le scénario ne doit être qu’un prétexte pour appuyer le gameplay, pas la base de celui-ci.
Le level design quant à lui nécessite que le jeu soit à un niveau suffisant de maturité pour pouvoir être réalisé, car il est impossible de créer un bon niveau sans pouvoir le tester avec toutes les mécaniques de jeu. C’est donc fréquent, lorsque le jeu est basé sur du level design, qu’il n’y ait qu’un début de niveau à la fin du week-end.
Step by step
Une fois que vous avez la bonne idée, découpez le travail en versions. Le but est de faire un développement itératif afin que le jeu évolue harmonieusement.
Pensez également “Intégration continue”. Intégrez dès que vous le pouvez les graphismes et les sons.
Voici comment je fonctionne pour établir les différentes version d’un prototype pour Game Jam :
Version 0 – Une version très basique du gameplay pour apprivoiser le framework / moteur
Version 1 – Un prototype de gameplay basique sans enrobage allant droit à l’essentiel
Version 2 – Le jeu avec suffisamment de features pour qu’il soit agréable à jouer
Version 3..n – Ajout de menus, d’effets spéciaux, d’idées de gameplay supplémentaires…
Les versions 0 et 1 doivent absolument être produites. Le but est de finir la version 2 pour la démonstration. Cette version contient le coeur du jeu et doit être intéressante à jouer.
Les versions suivantes sont des versions dites de “bonus”. Les tâches de ces versions ne sont pas obligatoires pour que le jeu soit bien, mais elles apportent un plus indéniable.
Si possible, donnez des noms à vos versions. C’est plus sympa et ça plaît à tout le monde.
En tant qu’exemple, voici les différentes versions de Kawaii must die, jeu développé lors de la troisième édition de la GDP :
- Version 0 – Adventure Time
- Mise en place de la base du code
- Des lapins apparaissent aléatoirement sur l’écran
- Les lapins disparaissent lorsque le joueur touche le lapin à l’écran
- Version 1 – Happy Tree Friends
- Implémentation de la notion de niveaux (début, fin, vitesse exponentielle)
- Implémentation des points d’apparition des animaux
- Implémentation de la vie du joueur
- Support du Multitouch
- Début d’intégration des assets (graphismes et son)
- Version 2 – Rampage
- Implémentation des 3 types d’ennemis, avec leurs 3 niveaux respectifs
- Détection de tous les types de mouvement tactiles (tap, swipe, longTouch)
- Finition du gameplay
- Ajout des menus
- Version 3 – Fatality
- Ajout des tutoriaux en début de niveau
- Ajout du compteur de score
- Ajout d’ennemis plus résistants
- Ajout de quatre niveaux supplémentaires
- Découpe dynamique des lapins
- Ajout de particules de sang
- Version 4 – Shut up and take my money
- Une version secrète avec pleins de features cool que vous verrez un jour !
Kawaii Must Die
Les noms de versions ont été choisis au début du week-end. Pour ce jeu, nous avons réussi à sortir la version 3 (Fatality) dans le week-end, environ une heure avant la démonstration.
Les versions sont ordonnées, mais il faut tout de même rester flexible. Par exemple, si toutes les tâches pour une version sont déjà en cours d’implémentation, alors un développeur qui s’ennuie peut passer sur la version supérieure. Mais veillez à toujours prioriser les premières versions et ne pas vous lancer dans les tâches des versions hautes trop vite.
Time to play
Une demie-heure, voire une heure avant la fin de l’événement, bloquez le développement du jeu. N’ajoutez plus aucune feature et n’autorisez la modification du code que pour fixer des bugs et faire des finitions.
Et jouez, jouez beaucoup. Testez et faites tester votre jeu. Mettez-le à l’épreuve et faites-le tourner longtemps. Souvent, lors du développement, on ne fait pas tourner le jeu plus de 30 secondes, le temps de trouver le bug ou tester une petite feature. Mais lors de la démo, le jeu va tourner plusieurs minutes. Ce serait dommage qu’un bug se produise en plein milieu car il n’a jamais été testé jusque là !
Le but de cette phase est d’équilibrer le jeu, de corriger les bugs qui pourraient apparaître pendant la démo et surtout d’être sûr de pouvoir présenter une version stable.
C’est souvent la dernière modification ajoutée en vitesse à la fin du développement qui va incorporer le bug qui va survenir pendant la démo.
Quick but not dirty
Le temps réduit de développement qui entoure la Game Jam n’est pas une raison pour écrire du code sale. Car quand nommer une variable “p” vous fait gagner une trentaine de secondes cumulées, cela fait perdre des minutes à vos amis codeurs qui doivent soit essayer de comprendre sa signification par eux-même, soit vous demander directement, ce qui fait au final perdre du temps à toute l’équipe.
Néanmoins, il faut faire attention aux extrêmes. Ici, on ne prône pas la réutilisabilité et la généricité du code. Il faut trouver un juste milieu pour pouvoir fournir quelque chose en 24 heures.
Pour savoir jusqu’à quel point vous devez aller, relisez votre code avant de commiter, mettez vous à la place d’un autre qui découvre le code, et posez-vous ces questions :
- Est-ce que cette variable / cette fonction a un nom suffisamment explicite pour ne pas requérir la lecture du code pour comprendre son utilisation ?
- Est-ce que ce bout de code est compréhensible rapidement sans commentaire ?
- Est-ce que ce hack a besoin d’un commentaire pour expliquer pourquoi ces lignes d’apparence inutile sont importantes ?
- Est-ce qu’il est utile de décrire les paramètres d’entrée et de sortie de ma fonction ?
Pensez que ce que vous écrivez une fois sera relu des dizaines de fois. Une minute utilisée pour la relecture, c’est des dizaines de minutes gagnées par la suite.
Ne pas réinventer la porte NAND
Écrire son moteur de jeu, c’est cool, mais en 24 heures, c’est impossible.
Réutilisez un maximum les moteurs et frameworks existants et ne vous embêtez pas à réécrire un gestionnaire de sprites, un générateur de particules ou un moteur de collision. Ces choses existent déjà très certainement, quelque soit la technologie que vous utilisez.
Pensez que ces librairies externes sont non seulement déjà codées mais déjà testées et ont été mises à l’épreuve de plusieurs autres développeurs. Même si vous ne mettez qu’une heure à développer un générateur de particules, vous allez peut-être en mettre deux pour le débuguer.
Faites une pause !
Pour finir, dormez !
La Game Dev Party est une Game Jam plutôt relax. Elle s’étale sur trois jours, et vous pousse à rentrer chez vous. Profitez-en pour dormir. Vous allez perdre de précieuses heures de développement, mais en contrepartie cela économisera pas mal d’autres choses. Votre cerveau sera plus efficace après une bonne nuit de sommeil et cela se ressentira sur le code. Vos nerfs seront également moins vifs et ça, vos collaborateurs en seront ravis.
Alors Jammers, dormez !
Annexe – Les créations
Comme promis, les différentes créations réalisées durant la Game Dev Party. Pour chacune, j’ai endossé le rôle de Game Designer, Chef de Projet, et Gameplay Programmer.
GDP1 : Monorail Cat – Un jeu à deux joueurs en local dans lequel chaque joueur contrôle un chat et doit tuer l’autre 9 fois grâce à des objets disséminés sur la carte.
GDP2 : Eat’em All! – Un jeu à deux joueurs en local dans lequel chaque joueur contrôle une poupée vaudou pouvant placer des panneaux pour rediriger les zombies de son camp dans le but de les envoyer détruire la forteresse ennemie.
GDP3 : Kawaii must die – Un jeu d’arcade sur mobile dans lequel il faut tuer des animaux mignons à coup de marteau, katana et tronçonneuse, selon le type d’animal.
