Ceci est la partie 4 du post mortem de mon jeu, L’Antre du Protecteur. Elle fait suite à la Partie 3 – Apprendre ou créer ?

Nous arrivons à la moitié de ce post mortem ! Le titre de cette partie pourrait paraître surprenant au vu des 3 premières parties qui sont déjà remplies d’apprentissages en tout genre. Je ne vais pas revenir sur ces apprentissages dans cette partie-ci. Cependant, il y a aussi pas mal de choses que j’ai apprises qui ne rentraient dans aucune des autres parties. Cette partie 4 est donc l’occasion pour moi de mettre par écrit toutes les petites choses que j’ai découvertes durant ces 4 ans, sur des sujets divers et variés.

Il s’agit surtout pour moi de faire le point sur ma progression et de noter mes apprentissages pour mieux les garder en tête. Néanmoins, si ces conseils peuvent être utile à qui que ce soit d’autre, j’en serais ravi. C’est parti.

Général

• Apprendre les raccourcis claviers est important. Que ce soit sur Photoshop, Visual Studio Code ou Unity, apprendre certains raccourcis m’a été systématiquement bénéfique. D’une part, parce que cela fait gagner du temps. D’autre part, parce que cela permet de moins briser le flow et gagner en confort.
• La cohérence est primordiale. Avoir quelque chose de simple mais cohérent est une meilleure option que quelque chose de complexe et détaillé, mais incohérent. Au début du projet, je n’avais pas de vision d’ensemble sur mes niveaux. Chaque élément était dessiné indépendamment des autres, puis je les assemblais comme je pouvais. Cela menait à tout un tas de problèmes : des épaisseurs de contours très différentes d’un objet à un autre, des couleurs qui n’allaient pas ensemble, et globalement l’impression d’avoir un gros fouillis plutôt que quelque chose d’harmonieux. Autre exemple : un personnage n’avait que 4 frames pour son animation de marche, tandis que le personnage principal en avait 8. Lorsqu’ils marchaient ensemble, la différence était flagrante. En faisant attention à ce genre de détails et en faisant une ébauche des scènes à l’avance, j’ai pu obtenir quelque chose de bien plus propre.

• Avoir un bon matériel est important. Sur les 4 ans de développement, j’ai fait 3 changements matériels important. D’abord, j’ai eu un second écran. Passer d’un seul écran (laptop) à un grand écran + laptop a considérablement augmenté le confort de développement, en particulier avec Unity qui contient beaucoup d’informations pour un seul petit écran de laptop. Ensuite, j’ai acheté une nouvelle tablette graphique. Là aussi, cela a augmenté mon confort, mais aussi la précision et la rapidité de mes dessins à l’ordi. Enfin, j’ai remplacé ma souris filaire tremblotante par une souris sans fil bien plus précise. Même conclusion : plus de confort, plus de précision, plus de rapidité. Tout ça pour dire que les contraintes matérielles peuvent considérablement limiter la motivation et la productivité sans qu’on ne se rende compte. Lorsque c’est possible, un upgrade peut être vraiment bénéfique.

Level Design

• Tout le monde n’active pas le son. Certaines énigmes du jeu dépendaient purement de certains indices sonores. Cela s’est avéré problématique lorsqu’une personne a testé mon jeu avec le volume sonore à 0. Que la personne soit malentendante, ou simplement dans un environnement qui ne lui permet pas d’activer le son, il est au moins important de préciser que le son est nécessaire. Ou mieux, de proposer une alternative qui ne dépende pas du son (ce que j’ai fait en ajoutant des indices visuels pour les passages concernés).
• On oublie vite les problèmes de physique en cours de développement. C’était principalement vrai pour ma première démo en 2017, mais aussi un peu sur la version finale. Des petits soucis dans les déplacements du personnage ou autres problèmes physiques peuvent être mis de côté pendant trop longtemps. Rapidement, on s’y fait et on finit par inconsciemment adapter sa manière de jouer lorsqu’on teste le jeu. Les joueurs, par contre, le verront très vite.
• Tester tôt. On peut réfléchir pendant des heures à un niveau et, au moment de le faire tester par quelqu’un, se rendre compte que quelque chose d’anodin pose en fait un énorme souci. Ou encore que quelque chose qui semblait évident ne l’est pas pour la plupart des joueurs. Mieux vaut s’en rendre compte le plus tôt possible. Dans mon cas, j’ai attendu très tard et je vais réfléchir à des manières de minimiser cela la prochaine fois.
• Tester sur des résolutions et des machines différentes. Certains éléments de mon jeu étaient malencontreusement sensibles à la puissance du CPU et du GPU, rendant certains passages presque impossibles avec un processeur trop puissant. La résolution influait aussi sur l’affichage de certains éléments à l’écran. Si possible, tester sur des configurations différentes avant la sortie est une bonne idée.

Graphismes

• Tout faire à la tablette permet de gagner beaucoup de temps. Auparavant, je faisais la quasi-totalité des graphismes de la manière suivante : dessin sur papier au crayon, photo du dessin, mise au propre et en couleur sur le PC. Ayant acquis une meilleure tablette, dessiner directement à l’ordi est devenu possible et sur la fin, je ne faisais quasiment plus que ça. J’aime beaucoup pouvoir m’éloigner des écrans quand c’est possible, donc je pense continuer à dessiner sur papier pour tous les dessins préparatoires (character design, etc.). Mais pour le reste, dessiner directement sur tablette fait gagner beaucoup de temps.
• Un style graphique ne plaira jamais à tout le monde. En postant le trailer de mon jeu sur divers forums, j’ai reçu des avis très contraires sur le style graphique. Beaucoup de gens disaient l’adorer, d’autres disaient clairement qu’ils ne joueraient jamais à un jeu qui ressemble à ça. J’ai souvent observé la même chose sur mes précédents jeux. La leçon à tirer je pense, c’est qu’il faut éviter de penser que son jeu est moche sur base d’un seul commentaire, car les goûts et les couleurs varient d’une personne à une autre.

Écriture

• Ne pas aller trop vite à l’essentiel. On me dit souvent que ce que j’écris est « straight to the point », que c’est concis et que ça va droit à l’essentiel… ce qui peut être une bonne chose pour un rapport technique, mais pas pour des dialogues qui se veulent naturels. Dans les conversations de tous les jours, les digressions sont souvent nombreuses, les informations n’arrivent pas forcément dans l’ordre et les gens racontent souvent bien plus que le strict nécessaire.
• Définir le caractère et le background des personnages même s’ils sont très secondaires. Au début de mon jeu, il y a un long dialogue impliquant trois personnages en plus du joueur. Après ce dialogue, le joueur quitte le village et ne les revoit plus jamais. Pour cette raison, je ne m’étais pas du tout intéressé à eux en écrivant la première version du dialogue, car l’important pour moi était juste de communiquer l’objectif pour la suite du jeu. Mais il faut bien admettre que cela rendait le dialogue plat et inintéressant. En imaginant, même légèrement, le caractère des personnages, leur fonction, et les relations entre eux, cela a permis de très largement dynamiser le dialogue et rendre l’univers plus convaincant.

Sound Design

• Écouter les longs sons atmosphériques en entier. Pour l’ambiance sonore des différents lieux du jeu, j’ai récupéré (en majeure partie sur freesound.org) des très longs enregistrements naturels. Étant donné que ce n’est pas particulièrement fun d’écouter 5 minutes de bruits de vent et d’oiseau, j’ai parfois intégré des sons sans me rendre compte qu’une voiture ou d’autres bruits parasites étaient audibles à certains moments.
• Les bruits de fond sont rapidement noyés dans la masse. Il m’est arrivé de rejeter des sons car je trouvais le bruit de fond trop audible. Cependant, je me rends compte que mélangés aux autres sons qui sont joués en permanence, ce genre de grésillement de fond est rarement audible.
• Certains bruits de fond peuvent être atténués même sans période de silence. Bon, ça va un peu à l’encontre du point précédent, mais cela peut être utile quand même. Le filtre Audacity que j’ai toujours utilisé pour supprimer un bruit de fond nécessite d’isoler une période ou seul ce bruit de fond est audible, puis d’appliquer le filtre. Mais parfois, je me suis retrouvé avec des pistes sans période de silence. Dans ces cas-là, j’ai réalisé qu’il y avait tout de même moyen d’atténuer le bruit de fond en déterminant sa fréquence et en l’atténuant. C’est ainsi que j’ai fait disparaître un oiseau un peu trop bruyant !

Musique

• Créer de la musique est difficile. Et pour apprendre, il faut y aller petit à petit et ne pas griller les étapes. Ce qui m’a permis d’avoir 3 minutes de musique plutôt que zéro, c’est d’avoir commencé à apprendre un instrument. Au lieu de chercher à composer immédiatement (ce que j’ai essayé maintes fois auparavant), cela m’a forcé à reprendre les bases, et gagner une meilleure intuition graduellement. Aussi, de manière plus fun qu’un logiciel qui devient très vite agaçant quand il ne fait pas ce que tu veux.

Conclusion

Cette liste ne contient que les grandes leçons qu’il est possible de mettre à l’écrit. J’en ai certainement oublié d’autres, et j’aurais pu ajouter des tas d’autres détails qui auraient été bien trop spécifiques. J’aurais pu aussi parler d’UI, de game design, de traduction, de programmation, de marketing… Pour ce dernier, je réserve le dernier post de cette série à ce sujet.

Une chose est sûre : si j’ai appris beaucoup dans tous ces domaines, je suis encore extrêmement loin d’en maîtriser un seul. C’est ce qui me plaît dans le développement de jeu : la possibilité de toucher à tout, de découvrir plein de domaines différents. Cela permet, je pense, d’avoir beaucoup plus de respect pour tous les professionnels de ces domaines.

À l’heure où les équipes de développement se font encore insulter dès qu’un jeu a du retard, des bugs ou d’autres soucis, réaliser la complexité que peut représenter la création d’un jeu est d’autant plus important. Créer des jeux et y jouer sont deux activités différentes, et être bon dans l’un n’implique pas forcément de s’y connaître dans l’autre. D’un autre côté, je réalise que c’est important de continuer à jouer, même si j’ai tendance à ne pas avoir envie de jouer durant les périodes où je crée beaucoup.

En parlant de complexité, je constate aussi bien souvent que beaucoup de gens vont voir un seul aspect du jeu comme représentant la majeure partie du travail. Quand je parle à d’autres programmeurs, c’est bien souvent cet aspect-là qui semble primer dans leur esprit… alors que cela n’a dû représenter qu’environ 15 à 20% de mon temps. Il est clair qu’entre du développement software « classique » et le jeu vidéo, il y a des différences marquantes. C’est cette différence que j’ai voulu creuser dans la partie suivante de ce post-mortem : Partie 5 – Hobby vs Travail.