Depuis plusieurs années déjà, et après avoir pu participer à une Ludumdare, j’aimerais apprendre à faire des jeux vidéo. Malheureusement le manque d’occasions ne m’a pas permis de pouvoir y investir le temps que j’aurais voulu. Alors cette fois c’est à moi de provoquer l’occasion, comme pour tout projet, l’important c’est de trouver un objectif.
C’est là que ça m’est venu : pourquoi ne pas se lancer dans une jam ? Une limite de temps, un thème imposé, de quoi se motiver justement ! Je me rends sur itch.io, à la recherche des jams qui commencent bientôt : la voilà ! La DINO JAM 5. Thème principal : les dinosaures, avec en plus un thème secret annoncé le jour du top départ. Je faisais partie de ces enfants-là : incollable sur les dinosaures, une dizaine de visionnages de « Sur la terre des dinosaures » ! Espérons que ça me permettra de partir avec un temps d’avance.
Reste à choisir le moteur :
UNITY : après l’annonce de leur nouvelle politique de tarification, je ne les porte plus tellement dans mon cœur.
UNREAL : les trois semaines de la jam ne me suffiraient pas à apprendre les bases.
GODOT : on en entend de plus en plus parler ces dernières années, présentée comme la solution full open source par rapport à UNITY, le nouveau joujou des devs indépendants… Intéressant…
Qu’est-ce qu’il a de si particulier ce moteur pour attirer les nouveaux développeurs indépendants vers lui ?
Sur son site on peut lire : un moteur par les game devs, pour les game devs. Le moteur étant totalement open source, les développeurs sont encouragés à ajouter eux-mêmes au moteur les fonctionnalités dont ils ont besoin pour leur création. Sous licence MIT, le GODOT engine peut être librement utilisé et redistribué sans payer ni abonnement ni royalties. Si vous créez un jeu dans ce moteur c’est le vôtre, et ce, jusqu’à la dernière ligne de code.
Une librairie d’assets, eux aussi sous licence MIT, est intégrée ; ils peuvent dont être librement incorporés à vos projets. Les assets comprennent des scripts add–ons, outils et autres pouvant être inclus aux projets GODOT.
Le moteur permet de coder le langage de son choix, mais propose également son langage intégré : le GDScript. Le GDScript s’inspire du python dans sa syntaxe, la philosophie de celui-ci : développer des jeux vidéo en tapant le moins de code possible.
Le GDScript est un langage à typage dynamique, et porte donc les avantages de ce dernier :
- plus facile d’accès ;
- plus facile à écrire et modifier ;
- peu d’encombrement et donc plus facile à lire pour les débutants ;
- pas de compilation ;
- temps d’exécution minimal ;
- typage ad hoc.
Mais on y retrouve aussi ses inconvénients :
- moins performant ;
- plus difficile à refactoriser ;
- les erreurs qui seraient normalement captées à la compilation le sont seulement au runtime puisque l’analyse du typage est moins stricte ;
- moindre de flexibilité pour la complétion de code du au typage de certaines variables au runtime.
Maintenant que mon choix est fait, c’est parti pour la jam. C’est un évènement en ligne, donc on se rejoint tous sur Discord, et on attend tous avec impatience le thème secret…
Une fois le top départ donné, j’apprends que le thème de la jam porte sur les dinosaures aquatiques. Pas de chance, sur les quelques sprites et décors que j’ai pu préparer, aucun ne rentre dans le thème… J’ai bien un ptéranodon qui aurait pu pêcher quelques poissons mais je n’avais pas du tout ce genre de jeu en tête. On repart donc de zéro.
Première étape : trouver un concept. Je commence à plancher sur un concept d’aquarium interactif, à produire quelques sprites, à imaginer les différentes interactions entre eux.
Je me lance sur un tuto de base de jeux en 2D, rien à voir avec mon concept initial mais je me dis que je trouverai bien un moyen.
Au bout de quelques jours les autres participants commencent déjà à parler du core gameplay et de menus terminés. De mon côté j’arrive à prendre l’outil en main assez rapidement, le tuto a vite été assimilé. Je prends conscience néanmoins que ce qui va me prendre le plus de temps, ce sont la production des sprites et les différentes animations pour rendre tout ça vivant.
L’heure tourne et je n’ai toujours pas pu sortir de première version du jeu… De l’autre côté, les autres ont déjà commencé leurs premières soumissions. Les personnes bossant en équipe sortent même des projets assez ambitieux, que vous pouvez retrouver [ici](https://itch.io/jam/dinojam5/entries).
Et malgré tous mes efforts, impossible de soumettre mon jeu avant la fin de la jam…
J’ai malgré tout pu apprendre comment développer un jeu en GODOT :
Le moteur fonctionne sur un système de scènes, chacune représentant les différentes entités du jeu. Ça peut être un personnage, un ennemi, un menu ou la scène principale du jeu.
Prenons l’exemple d’un personnage. La scène pourra contenir :
- la hitbox : les limites dans lesquelles on considère que le personnage entre en collision avec une autre entité ;
- le sprite (2D), le modèle (3D) : la partie visible de la scène ;
- la physic box : la représentation physique de la scène, ce qui permettra à la scène d’être influencée par la physique du jeu. Être soumise à la gravité, rebondir sur une surface, en
bref modéliser les forces pouvant être appliquées à l’objet.
Ces différentes entités servent d’interface visuelle ou comportementale à notre personnage
Elles exposent des propriétés qui permettent de configurer ces entités : leur poids, leur position, leur vitesse de déplacement.
Elles exposent aussi des triggers : les façons dont on peut interagir avec ces entités. Par exemple, un trigger de collision appelle une méthode décrivant le comportement de notre entité lorsqu’elle entre en collision avec une autre entité. Cette méthode pourrait par exemple se comporter différemment lors de la collision avec un mur de brique ou un mur de bois.
S’il fallait résumer cette expérience en un mot, c’est très clairement « intense ». On imagine assez difficilement tous les tenants et aboutissants de la création d’un jeu vidéo. Malgré la facilité d’utilisation de GODOT et les fonctionnalités générales pré-implémentées, cela prend quand même pas mal de temps de configurer toutes les interactions possibles entre nos différentes scènes, les comportements internes de chacune. Le fait de participer à une jam en solitaire est un peu décourageant, surtout lorsqu’on doit faire des tâches dont on est loin d’être spécialiste.
Néanmoins, c’est une excellente expérience pour se motiver à apprendre rapidement un nouveau skill, la fenêtre de temps courte obligeant à s’acharner sur le sujet, tout en évitant d’en arriver à se dégouter. Je participerai probablement à une nouvelle jam mais cette fois en équipe, après tout c’était déjà ma deuxième participation !
Liens Utiles :
- [Dino JAM 5](https://itch.io/jam/dinojam5)
- [Submissions](https://itch.io/jam/dinojam5/entries)
- [Jam resuts](https://itch.io/jam/dinojam5/results)
- [Repo du jeu cree](https://github.com/Feuzme/dodge-the-dinos)
