Revenir au blog

[Postmortem Ludum Dare] Why Ducks Never Got Wheels

Vous pouvez accéder à la fiche du jeu dans mon portfolio, sur le site de la Ludum Dare, ou même le télécharger sur https://zblah.itch.io/.

J’ai récemment participé à la Ludum Dare 36, au sein d’un groupe de six personnes. Tous étudiant à Aries, nous avions pu travailler plusieurs fois ensemble au sein de l’école, en prenant par pur fun le nom de la team ZBLAH. Il s’agissait pour nous de notre toute première expérience de game jam, et également de notre premier jeu publié. Cette fois-ci, il n’y a pas que nos connaissances qui peuvent y jouer, mais tous le monde. Inutile de dire que nous avions tous la pression !

Ce fut une excellente expérience qui nous a donné beaucoup à réfléchir, et c’est ce qui me pousse à en écrire un postmortem.

La préparation

J’ai tenté de participer à plusieurs game jams auparavant, mais ce fut à chaque fois un échec (annulation de l’évènement, hasards du calendrier…). Aussi, quand j’ai pris connaissance de la date de la LD, à peine quelques jours avant, je n’ai pas hésité à contacter des amis, également étudiant à Aries, avec qui j’ai déjà travaillé avant. Nous avons très vite rassemblé un groupe de quatre game designers et deux game artists.

La composition du groupe fut :

  • Sylvain Barbaza : Game design, Programmation
  • Emmanuel Blanc : Art (3D)
  • Valentin Mehu : Game Design, Particules
  • Elodie Mondoloni : Art (2D, 3D)
  • Iannis Rosset : Game design, Sound Design
  • Et moi même : Game design, Programmation

Les outils s’imposaient d’eux-mêmes : Unity étant le moteur de jeu que nous connaissions le mieux et Maya l’outil de modélisation le mieux maîtrisé par les graphistes.

Nous avons pu utiliser plusieurs plugins qui nous ont grandement facilité le travail, comme le bundle ProBuilder et ProGrid, qui constituent l’ensemble de nos colliders et nous ont permis de faire les metrics. J’en ai profité pour tester quelques-uns des plugins gratuits les plus populaires de l’asset store.

Pour la petite histoire

Quand le thème est tombé, on a passé un bon moment à nous creuser la tête. Nous voulions absolument répondre à la contrainte par le gameplay et non uniquement visuellement, mais “Ancient Technology” ne nous disait pas grand chose.

On a fini par tomber d’accord sur un sujet : la roue. Nous avions vu pour la plupart une vidéo de Dirtybiology, expliquant pourquoi les animaux n’ont pas été dotés de roue par l’évolution. En deux mots, une roue nécessite beaucoup d’énergie pour avancer dans un terrain non adapté. Pour pallier à ce problème, les humains construisent des routes, mais ce faisant, dépensent ironiquement tout autant d’énergie, si ce n’est plus. En conclusion, les animaux n’ont pas de roues car la biologie a jugée plus efficaces de nombreux autres moyens de locomotions.

L’intention est simple : donner au joueur les commandes d’une roue dans un level design fastidieux à parcourir. Nous souhaitions que le joueur se bloque fréquemment, le poussant à recommencer à partir du dernier checkpoint, disposés heureusement en de nombreux endroits. La fin du jeu le met au commande d’un canard pouvant sauter, et ainsi traverser à nouveau le niveau sans aucun challenge.

Il y a eu beaucoup de discussions concernant la difficulté du jeu, s’il fallait privilégier le fun ou le message, si celui-ci allait être bien compris… Mais quand le prototype fut bien avancé et que le titre avait été trouvé, nous avons été plus rassuré.

A la lecture des commentaires, il semblerait que le message ait bien été perçu par les joueurs. Un manque de feedbacks sur la route à prendre a cependant rendu confus la fin du jeu, la cachant pour certains joueur. Les bulles d’aides sont également devenues invisibles pour certaine résolutions d’écrans.

Bon point / Mauvais points

Après cette expérience, il y a quelques points dont j’aimerais me souvenir pour la prochaine fois :

  • Le groupe a bien fonctionné et chacun a pu contribuer au jeu, mais nous étions trop nombreux à partager les mêmes compétences. Deux game designers aurait certainement été plus efficaces que quatre, et le prototype ne nécessitait pas deux programmeurs. En revanche, un ou deux personnes en plus en 3D aurait allégé le boulot de dingue qu’il y a eu.
  • Les expériences passées ont été très bénéfiques : nous avons gardé une ambition mesurée tout le long du projet et il n’aurait pas fallu de plus. Nous avions déjà appliqué ce workflow et utilisé tous les outils que nous souhaitions, il n’y a donc pas eu de phase de recherches ou d’apprentissage.
  • Il n’y a pas de projet qui ne nécessite pas de nomenclature. A chaque fois, on se dit que le projet n’est pas assez long pour prendre la peine de se réunir dix minutes pour harmoniser les noms, mais ça a toujours fini par nous faire perdre du temps en fin de production. Il aurait été plus prudent que l’un de nous se dévoue à trancher les décisions de production.
  • Pour les mêmes raisons, il n’y a pas de projet qui ne nécessite pas un minimum de gestion de tâches. On s’en est plutôt bien sorti, mais il n’y a aussi eu aucun problème bloquant qui aurait pu nous retarder.
  • Communiquer avec le monde : pour cette première fois, on est resté un peu à l’écart de la communication sur le site de la LD. Nous sommes restés simples observateurs, car nous n’avions aucunes idées de la manière de faire des habitués. Il a été très intéressant de lire les discussions des participants, les choix de technologies ou leurs idées. Pour la prochaine expérience, cela pourrait être bénéfique que notre groupe tienne un journal de développement, comme beaucoup l’on fait.
  • 72h, c’est très long. J’ai eu l’occasion de faire des projets en rush durant 48h, mais un jour supplémentaire épuise plus que ce que je croyais. Mais comme nous étions assez nombreux, nous avons pu avoir de nombreuses phases de détente, et par chance, nous n’avons pas été pris de court.
  • Certaines technologies ont des comportements encore obscurs. A la fin de la production, il y avait plus de quatre heures de prévues pour baker la lightmap, mais nous n’avions aucune visibilité sur le temps restant. Pris de cours alors que la deadline approchait, nous avons préféré rendre une version avec toutes les lumières dynamiques. En conséquence, Le jeu est malheureusement largement trop gourmands sur les petites configurations. Après le rendu du jeu, j’ai lancé un bake jusqu’à la fin, mais le rendu n’a pas fonctionné et causait des artefacts visuels. Avec le peu d’informations trouvés sur le net à ce sujet et la lenteur extrême de chaque bake, je n’ai pas encore pu résoudre le problème.

En conclusion, ce fut trois jours très enrichissants, et j’espère pouvoir participer aux prochaines game jams pour renouveler l’expérience. J’attends la fin du vote pour afficher les résultats ici, et j’espère pouvoir mettre bientôt à jour une version optimisée et exempte de bugs.