Blog
Pour ceux qui ne connaissent pas, la Ludum Dare est une Game Jam, c'est-à-dire un concours de création de jeux vidéos dans un temps limité.
Celui-ci se décompose en deux épreuves : une épreuve individuelle en 48h et une épreuve en équipe de 72h. Eh bien MakeYourGame était présent à cette dernière !
Thème de ce Ludum Dare : il faut faire des sacrifices !
Réflexion
Cette 43e édition de la Ludum Dare avait pour thème : Sacrifices must be made. Ce que l'on peut traduire par Des sacrifices doivent être faits. Un thème très intéressant qui nous a occupés pendant les premières heures du concours (samedi 1er décembre de 3h à 6h du matin). À l'issu de ce temps de réflexion, nous avons décidé de nous lancer dans un jeu dont les fonctionnalités elles-mêmes seraient sacrifiées au fur et à mesure de notre progression : Suppression de certaines lumières, de certains inputs, du son, des effets, des couleurs ou encore de l'interface utilisateur.
Histoire et mise en abîme
Parlons un peu de l'histoire. Vous devez créer un jeu pour une Game Jam -tiens-donc- et vous avez un temps limité pour le faire. Vous incarnerez à tour de rôles différents petits robots ayant chacun une fonctionnalité à ajouter au jeu (Mr. Input, Mr. Light, Mr. FX, Mr. Chroma, Mrs. UI et Mr.Sound). Tous ces personnages ont l'air différent mais ils n'ont qu'un seul but : supprimer tous les bugs du jeu de façon à implémenter leur fonctionnalité. Un shooter assez classique mais attention toutefois à ne pas éliminer les Core System. Ils ressemblent à s'y méprendre à des bugs mais les éliminer rendra votre système encore plus instable et provoquera encore plus de bugs.
Si à l'issu des sessions de debugging vous réussissez à implémenter les fonctionnalités, celle-ci sont ajoutées au jeu que vous êtes en train de créer. Sinon, elles manqueront et le note finale de votre jeu chutera. Le but est d'implémenter le plus de fonctionnalités possible et de terminer avec la meilleure note.
3D et Unreal Engine 4
Unreal Engine
Nous avons fait des infidélités à nos moteurs de prédilection pour nous essayer à l'Unreal Engine (et également parce que nos 3D artists ont l'habitude de travailler avec). Encore une fois : peu importe l'outil pourvu que l'on atteigne ses objectifs !
Qui dit travailler avec des 3D artists dit travailler en 3D. Ce que nous avons fait avec grand plaisir. Pour être franc le choix de la 3D et de Unreal Engine n'est pas nécessairement du meilleur choix pour une GameJam dans l'absolu mais il faut savoir s'adapter au contexte. Et le contexte était : on travaille avec des 3D artists possédant une bonne expérience sur Unreal Engine mais pas sur Unity ni Godot, contrairement à nous. Qui doit s'adapter ? Dans le contexte, mieux valait que ce soient les développeurs.
Blueprint
Le moteur de jeux Unreal Engine 4 propose aux développeurs de programmer principalement de deux façons : en utilisant le langage C++ ou en utilisant un langage de programmation visuelle appelé Blueprint. Il est évidemment possible de combiner les deux. Pour cet exercice, nous manquions des compétences nécessaires pour programmer totalement en C++. Nous avons donc opté pour un Blueprint. Notre retour d'expérience est plutôt mitigé sur le sujet car nous restons convaincus que coder en C# ou en GDScript ou dans n'importe quel langage non visuel nous permet d'aller plus vite et d'obtenir un code plus clair et plus optimal. Cependant, le Blueprint a l'avantage d'être beaucoup moins intimidant pour un non-programmeur que ne l'est un langage comme le C#.
Après, comme souvent, c'est le contexte qui dicte la technologie qu'on utilise et non l'inverse.
Intégration des assets : 3D et sons
Pour tout ce qui est 3D, nous n'avons eu que très peu de problèmes. Nos artists connaissaient bien leur affaire et la compatibilité entre le moteur et des outils tels que 3DMax (avec l'utilisation du standard fbx) nous a épargné beaucoup de difficultés : l'avantage d'utiliser un outil bien implanté dans l'industrie. L'intégration des sons a également pu être effectué sans trop accrocs.
Gestion du projet
72h : des sacrifices ont été faits
Le jeu que nous avions en tête -hormis le fait que nous avions tous un jeu différent en tête- était bien sûr différent du résultat final. La raison principale est bien entendu la contrainte de temps 72h, c'est court, trop court ! Mais que c'est bon !
Notre seul vrai regret est de ne pas avoir pu implémenter un gameplay qui nous plaisait beaucoup : nous voulions au départ que notre robot circule sur une sorte de rail électromagnétique lui imposant un mouvement le long d'un chemin aux multiples embranchements. Si l'idée était séduisante, nous avons pas mal galéré à l'implémenter pour finalement laisser tomber et partir sur un mouvement plus libre (bien que contraint par un chemin).
Travail en équipe : svn préféré à git
Pour ce qui est du travail en équipe, nous avons opté pour le logiciel de versionnage le mieux intégré à l'Unreal Engine, à savoir svn. Encore une fois, c'est le contexte qui dicte le choix. Nous aurions travaillé sur Godot, nous aurions probablement choisi git mais svn est plus adapté aux projets liés à Unreal ou encore à Unity.
Notons toutefois que nous avons rencontré pas mal de problèmes (conflits, configuration etc.). Il semble néanmoins que ces problèmes viennent de notre mode d'organisation ainsi que de notre maitrise de l'outil et non de svn en lui-même.
Résultats
Finalement, nous sommes plutôt contents du résultat! Celui-ci est disponible sur itch.io et se nomme Dev Jam et en voici quelques captures d'écran :
[caption align="alignnone" width="640"]
Dev Jam : Menu de choix du personnage[/caption]
[caption align="alignnone" width="640"]
Exemple de gameplay[/caption]
Conclusion
Au final, une expérience très amusante et très instructive que avons l'intention de répéter autant de fois que possible. Si vous n'avez pas déjà gouté aux joies d'une code jam, foncez, vous ne le regretterez pas. Attention, la prochaine Ludum Dare se déroulera en Janvier : restez connectés !
