PostMortem : Ludum Dare 26

Le dernier weekend de Mai 2013, nous nous sommes lancés sur la Ludum Dare numéro 26 dont le thème était : “minimaliste”.

Nous, c’est une petite équipe de huit personnes. Thomas Renault infographiste 3D, Mellany Mohamed El Had étudiante et développeuse ayant déjà participé à une Ludum Dare et une Global Game Jam avec Unity, Heykel Hachiche étudiant et développeur sans expérience sur Unity, Jeremy Bressand étudiant qui a profité de cette Ludum Dare pour s’initier au développement, Bastien Nguyen Duy ingénieur en optoélectronique au sound design, Rémy Andres pour le support (toute la logistique) et les photos, Fabien Dutartre pour le support et moi même, Antoine Seilles qui profitait de l’occasion pour tester Unity. Personnellement, chez NaturalPad je ne touche jamais au développement des jeux. Je n’ai pas vraiment le temps et ce n’est pas ma mission. Même si aujourd’hui je n’ai pas l intention de m’immiscer dans les développements, mon rôle étant plus celui de responsable produit, je pense que mieux connaître cet outil permettra de faciliter la communication avec les développeurs chez NaturalPad.

Le véritable objectif de cette Ludum Dare était pour toute la team de se tester et de s’amuser. Nous cherchions avant tout à créer une équipe avec une bonne ambiance, qui produit quelque chose dans un temps restreint, quoi qu’il arrive. En gros, des gens motivés et qui restent cool malgré la fatigue et le stress. Je reparlerai du moment de la livraison dans ce post mortem, qui est probablement le moment de stress le plus important. Je dois préciser que j’ai rédigé ce post mortem seul, bien que j’ai récolté les avis de mes camarades. Il s’agit donc de ma vision de cette aventure avant tout et je tiens à remercier toute l’équipe pour ce très agréable moment vécu pendant cette Ludum Dare n°26.

 

Ce qui a marché

• La phase de brainstorming limitée en temps pour choisir sur quoi on part

La ludum dare commence à 3 h du matin avec l’annonce du thème, l’horaire est prévu pour les États Unis. C’est toujours un dilemme : rester éveillé jusque 3 heures pour avoir le thème et commencer de suite ou dormir et découvrir le thème au réveil ? Nous avons choisi de se retrouver à 9 heures au local de NaturalPad pour Café, croissants et brainstorming jusqu’à midi et fixer les grandes lignes du projet. Certains d’entre nous avaient quand même mis leur réveil à 3 heures du mat’ pour voir le thème avant, mais dans l’ensemble tout le monde a attaqué le projet en forme et motivé. La réunion s’est faite par phases : pur brainstorming pour avoir un maximum d’idées (une dizaine de pistes évoquées) ; phase de tri où par votes on a commencé à élaguer et supprimer des pistes. Chaque vote a fait l’objet d’un petit débat pour argumenter pourquoi on défend ou non cette piste. Dans l’ensemble, il n’y a eu que de bonnes idées mais les deux arguments les plus avancés étaient « ça ne colle pas au thème » ou  » ça va demander trop de travail vu le délai ». Au final nous avons opté pour un RTS (Real Time Strategy ou Jeu de Stratégie en Temps Réel) minimaliste dans la forme de ses unités et sa gestion des ressources. Dans Gon of War (titre retenu pour notre projet) les unités sont des sphères, des pyramides et des cubes. Il n y a que le temps comme ressource et le nombre d’unités est limité.

• La prise en main d’Unity malgré le manque d’expérience de l’équipe

Je ne suis pas sûr que tout le monde partage complètement mon avis mais je pense que ceux avec le moins d’expérience en code ont peut-être été un peu frustrés de ne pas produire plus de code pour le projet. Et il est vrai que la mise en place de notre modèle a pris un peu de temps, n’a pas pu être bien parallélisée et a retardé leur passage en production. Mais tout le monde a pu produire du source donc s’approprier l’outil malgré une faible expérience. Personnellement, j’ai vraiment pris plaisir à coder. Au démarrage ce n’est pas nécessairement évident de passer d’habitudes de programmation objet à la java au code dans unity en c# avec cette approche composite ou on associe les scripts à un objet dans la scène ou un prefab. Je pense qu’avec ce projet je n’ai pas vu 10% des possibilités d’unity mais en tout cas je n’ai pas eu trop de mal à mettre en place les machines à état, associer des scripts à nos unités et à nos bâtiments.

• Le repos des troupes, le cocooning de la team par Rémy et Fabien, ma sœur qui nous a amené les vivres pour le premier jour

J’ai vraiment eu l’impression que nous étions soutenus par nos proches pour nous faciliter la vie et nous assurer des conditions de production optimales. Un peu comme un sportif en train de réaliser un exploit qui aurait tout un staff à son soutien. Du coup, on a pu coder sans se préoccuper des repas et on a tous pu avoir un quota de sommeil raisonnable durant le week-end. Heureusement que nous avions un jour férié le lendemain de la livraison. Malgré nos bonnes conditions, la deadline était à 4h du matin et l’excitation de ce moment empêche de dormir.

• L’import des modèles 3D dans unity et la facilité d’utilisation de unity pour les graphistes non initiés

La logique d’Unity sur la gestion des modèles, de la scène, des lumières et des shaders est vraiment calquée sur les outils utilisés par un graphiste 3D aujourd’hui. Thomas a même eu la surprise de retrouver exactement les mêmes raccourcis claviers que dans son environnement de production habituel. Unity est fortement documenté en ligne sur les interactions avec les différents outils d’édition 3D.

• La conception avec une vision agents réactifs et la mise en place des machines à état avec un passage au tableau en mode mini cours pour les points théoriques

L’équipe de développement présentait un niveau hétérogène avec notamment un total débutant. Bien expliciter le pattern de la machine à état et les différents comportements que nous allions utiliser pour les unités et bâtiments était vraiment essentiel pour intégrer tout le monde dans le développement. J’ai même pu rediscuter un peu de modèle multi-agent et proposer un modèle basé sur le concept d’agents réactifs. Au final nos unités ne reçoivent pas d’ordres extérieurs et changent d’état en fonction de ce qu’ils perçoivent de l’environnement. Ce qui fait que l’on a du coup une IA (Intelligence Artificielle) minimale sans avoir scripté la moindre stratégie de groupe.

• Le game design avec du papier

Comme pour les passages au tableau, poser sur papier notre game design a permis à toute l’équipe de mieux imaginer le rendu final du jeu. Nous avions aussi l’avantage de tous partager une connaissance commune du RTS de référence à mes yeux, StarCraft2. Sur papier on a décrit la carte avec les positions de départ des unités, on a décrit les différentes actions des unité et on a posé les machines à état, donc les comportements de nos unités.

• La livraison, découvrir ce qu’ont fait les autres et faire parler sur les réseaux sociaux

Ce moment est juste magique. On poste notre jeu, on le reteste dans le navigateur et on envoie sur tous les réseaux sociaux l’annonce de la release. Il y a une certaine fierté à ce moment là. Et découvrir ce qu’ont fait les autres… Waow y a vraiment des idées de malades qui voient le jour le temps d’une GameJam de trois jours. Personnellement en regardant les propositions des autres j’ai trouvé des pistes pour plusieurs commandes clients actuelles et je trouve que c’est vraiment un super plus de ces jams. On partage avec une très grande communauté et ça donne plein d’idées. Pour information, il y a eu plus de 2000 dépôts de jeux au cours de cette ludum dare.

 

Ce qui n’a pas marché

• Git et Unity

J’avais entendu nos développeurs se plaindre au début de Git et Unity. Maintenant je comprends pourquoi. J’ai l’habitude d’utiliser Git sous Linux. Git est bien pensé pour tout ce qui est texte mais pour les binaires… Ce n’est simplement pas prévu pour ça. Dans Unity il y a deux options à cocher pour passer en mode texte et pouvoir vraiment intégrer Git. Par contre, après nous n’étions pas sûrs des fichiers qu’il fallait pousser. Unity en mode texte crée des .meta pour tout, même pour les sources… L’autre difficulté c’est que nous codiosn sur Windows et qu’il faut trouver le bon outil pour Git et Thomas était sous Mac ou là c’est carrément une histoire de trouver le bon OS pour Git… Tous ces outils en mode graphique qui font tout à votre place, je ne savais plus si en faisant un commit il allait automatiquement pousser. Bref, Git sous windows et Mac c’est vraiment pas aussi simple que sous linux.

• La gestion des dépendances entre les développeurs

C’est vrai que pendant un temps j’ai pas mal codé sur les machines à état et pendant ce temps les autres développeurs attendaient un peu quoi faire. J’étais régulièrement interpellé pendant mon code pour leur expliquer quoi faire et ce moment était un peu stressant. Je changeais de contexte en permanence et je sentais que nous perdions en productivité. Par contre, une fois les bases bien posées, le projet a gagné en structuration et partager les tâches est devenu plus aisé.

• L’intégration du son

Manque de temps, de maîtrise du truc (maintenant on a la solution et c’est facile en fait mais sur le coup…) et puis les binaires des fichiers audio ont mis le bordel sur notre repository git…

• Diminuer nos ambitions pour tenir dans les délais

Bien sûr notre première erreur, la plus fondamentale c’est qu’on a vu trop gros. Un RTS en 3 jours c’est beaucoup de travail malgré tout. On aurait du réduire nos ambitions plus tôt dans le projet. On espérait sortir une version avec 3 unités et en réalité seules nos premières unités sont sorties durant la Ludum Dare. On n’a pas su aussi se forcer à finaliser le jeu avec un écran de fin de partie et un minimum d’explication en jeu. En gros, pour l’instant, il n’y a pas de condition de victoire clairement énoncée et les joueurs ne savent pas quoi faire.

• Les deux mecs bourrés au moment de la release

Ah et on les aime beaucoup malgré tout mais nos deux potes qui ont débarqué à 3 heures du mat’ après leur soirée bar pour voir ce qu’on devenait… C’était sympa et ça partait d’une bonne intention. Mais c’est mal tombé, pile poil au summum de la fatigue et du stress. Mais allright on a livré quand même !!! 🙂

 

La suite…

Et maintenant Gon of War va continuer d’évoluer avec une team toujours aussi motivée pour avancer. Premier truc que nous avons fait c’est de se réunir pour débrieffer, corriger le Git, intégrer le son d’ambiance du jeu et les sons en fonction de l’état des unités.

Nous avons prévu de sortir une nouvelle version quand nous aurons finalisé ce qui était prévu pour cette Jam. Ce qui veut dire avancer un peu au quotidien mais aussi reproduire les séances de code intensives comme ce week-end.

Vous pouvez grâce à Rémy et Thomas, de l’association de courts métrages ImagiLAB, revivre nos trois jours de Jam filmés en Timelapse après l’article et sur notre chaîne Youtube.

Et pour avoir un aperçu des projets déposés, visitez le site dédié.