Ceci est la partie 5 du post mortem de mon jeu, L’Antre du Protecteur. Elle fait suite à la Partie 4 – Apprentissages

Il fut un temps où j’ai envisagé de faire de la création de jeux vidéo mon métier. Face aux peu d’options en Belgique, aux conditions de travail mal réputées dans l’industrie et aux risques que représentaient la création d’un jeu en indépendant, j’ai préféré faire une croix temporairement sur cette idée. J’ai aussi toujours eu peur qu’en en faisant mon métier, et en étant potentiellement limité à un rôle de programmeur, je perde le plaisir que j’ai à créer des jeux.

Si au moment de commencer L’Antre du Protecteur j’étais toujours au études, ce n’est plus le cas depuis déjà 3 ans. Je travaille donc depuis tout ce temps sur un projet de data engineering, dans une équipe et une société grâce auxquelles j’ai énormément appris. En travaillant en parallèle sur ce projet professionnel et sur mon jeu, j’ai d’ailleurs relevé un certain nombre de différences notables que j’aimerais développer dans cette cinquième partie. Je remercie d’ailleurs certains collègues à qui j’ai exposé ces points et qui m’ont permis d’avoir un avis plus éclairé sur ces questions.

C’est parti pour une comparaison projet perso vs projet pro !

Qualité du code

Si ma conscience professionnelle et les pratiques de review mises en place dans notre équipe m’imposent de fournir du code de qualité, ce n’est pas le cas lorsque je code sur mon temps libre. Dans le premier cas, je dois faire avec les autres membres de mon équipe qui travaillent sur la même codebase. Bien nommer ses variables et fonctions, structurer correctement le code, le documenter, etc. est donc crucial. Seul, la seule autre personne dont je dois me soucier est mon moi du futur, qui risque de repasser un jour par le code que je suis en train d’écrire. Pas question de faire n’importe quoi donc, mais la qualité du code reste néanmoins bien inférieure.

Je serais tenté de me sentir un peu honteux de cela, mais est-ce bien grave après tout ? Si la qualité était suffisante pour me permettre de progresser sans obstacle et d’aller plus vite, chercher à obtenir un code parfait ne serait-il pas une perte de temps ?

Une question se pose cependant, est-ce qu’en codant moins bien sur mon temps libre, je ne risque pas d’impacter négativement mon niveau au travail ? Probablement pas. D’un part, le changement de contexte fait que mon cerveau se met en mode « professionnel » automatiquement. D’autre part, comme dit précédemment, les pratiques mises en place dans l’équipe (code review, etc.) font que cela ne passerait tout simplement pas. Dans un autre cadre, la question pourrait se poser néanmoins.

Il est à noter aussi que l’expérience gagnée au travail m’a aussi permis de mieux coder sur mon temps libre, car certaines bonnes pratiques deviennent naturelles. Dans l’autre sens, je me rends compte qu’avancer très rapidement sans réfléchir des heures à la beauté du code peut être une bonne chose, et que je m’inquiète parfois trop de détails superficiels au travail.

Tests

S’il y a bien une chose que j’ai dû apprendre en commençant à travailler, c’est écrire des tests. Chaque changement dans le code est accompagné de changements dans les tests, ces tests sont exécutés automatiquement à chaque git push, et bien entendu, il n’est pas question d’intégrer ces changements si les tests ne passent pas. Certains pourraient penser qu’il suffit de tester manuellement après tout, et que tous les efforts à mettre en place pour les tests n’en valent pas la peine. Mais au fur et à mesure que la taille de la codebase augmente, comment être sûr que tout fonctionne toujours ? Est-ce vraiment raisonnable de re-tester tout manuellement pour être sûr qu’un changement n’a rien cassé ailleurs ? Est-ce raisonnable d’attendre qu’une régression apparaisse en production pour le corriger ?

Pourtant, sur mon jeu, je n’ai pas écrit un seul test. Je ne doute pas que Unity soit lui-même testé et, mon code se basant largement sur les fonctionnalités de Unity, c’est déjà un premier filet de sécurité non négligeable. Mais pour mon propre code, rien. Cela m’a poussé à faire beaucoup plus de tests manuels, mais aussi à mettre le jeu dans les mains d’autres personnes avant de l’ouvrir à un plus large public. Avec le recul, je me rends compte que je teste beaucoup plus de cas en testant manuellement que si j’avais dû écrire des tests unitaires, tout simplement parce que c’est plus rapide à faire. Cela me donne pas mal de réflexions sur la manière dont je pourrais améliorer cela dans mon travail.

Néanmoins, cela n’enlève rien à l’utilité des tests automatisés. Et donc, pourquoi ne pas en avoir écrit ? Mes impressions sont / étaient les suivantes :

• Je n’ai jamais ressenti le besoin sur mes précédents jeux. Et au moment de commencer ce projet, je n’avais même jamais vraiment dû écrire de tests dans ma vie.
• Tester un jeu paraît plus compliqué. Comment tester le rendu du jeu ? L’IA des personnages ? La UI ?
• Créer un jeu est une histoire de feeling. Il y a rarement des specs clairement établies. Souvent, j’implémente quelque chose, le teste manuellement, change ce qui ne me plaît pas et ainsi de suite. Je ne sais pas exactement à l’avance ce que je veux obtenir. Le fun, l’ergonomie, les sensations de jeu sont la somme des milliers de micro-changements qu’on peut difficilement mesurer automatiquement.

En me renseignant, il paraît clair que c’est la vision de nombreux développeurs de jeux vidéo, y compris chez les pros. Comme en témoignent cet article (écrit par Ron Gilbert, connu pour son travail chez LucasArts) ou les nombreux commentaires sur ce post Reddit. De manière générale, mes recherches sur « video game test » m’ont mené surtout vers des reviews de jeu, et « video game programming test » vers des articles sur comment faire tester son jeu par d’autres personnes. Les tests automatisés semblent bien moins courants.

Moins courants, mais pas inexistants ! J’ai tout de même trouvé tout un tas d’articles et de commentaires en parlant, notamment celui-ci ou encore celui-là. Il en ressort plusieurs conclusions :

• Tout ne doit pas être testé. La UI, les choses évidentes ou tout ce qui a trait au « fun » ou au « feel » du jeu doivent être testés manuellement.
• De nombreuses choses peuvent néanmoins être testées : parsing de fichiers, helpers, sérialisation des sauvegardes, … Tout ce qui contient de la logique pure.
• Écrire des tests unitaires permet alors de mieux structurer son code, en isolant la logique pour la rendre testable.
• Il faut trouver le bon ratio entre les bénéfices apportés par les tests et le temps passé à les écrire.

Il existe aussi le crash testing ou des méthodes plus complexes utilisant des IA jouant au jeu. Cela paraît tout de même beaucoup plus complexe. De plus, dans un jeu comme le mien reposant beaucoup sur des énigmes, je doute qu’une IA serait capable de progresser.

Au vu de tout cela, il paraît clair qu’il y a un travail d’éducation et de mise en place de bonnes pratiques à faire dans le domaine du jeu vidéo. Selon le domaine, certains types de tests auront plus de sens que d’autres et trouver la bonne méthode n’est pas forcément évident. J’aimerais explorer cet aspect lors de mes prochains projets.

Version control

Contrairement aux tests, j’ai commencé à utiliser du version control (git) bien avant d’avoir commencé mon jeu. Même si je ne maîtrise git que depuis quelques années. Je n’ai jamais douté de son utilité. Pour collaborer, déjà, c’est bien plus simple que de s’envoyer des fichiers. Mais aussi pour garder une trace des changements dans le code au fil du temps, pouvoir revenir en arrière et se rappeler dans quel contexte tel ou tel changement a été fait, ou encore créer une branche pour travailler sur une fonctionnalité en parallèle sans casser tout.

Ici aussi, je n’ai pas pris le temps de mettre ça en place pour mon jeu. Si l’aspect collaboration était moins important, tous les autres avantages m’auraient pourtant aidé maintes fois, et je regrette un peu de ne pas avoir pris le temps. Je compte bien m’y intéresser dans l’avenir.

Il faut noter cependant que Git n’est pas vraiment un outil adapté pour le jeu vidéo. Si Git est suffisant pour du code, il devient vite inadapté dès lors que des fichiers plus volumineux apparaissent, comme des images, des sons ou les fichiers générés par Unity. Il existe bien Git LFS pour gérer les fichiers volumineux, mais de ce que j’en sais, ce n’est pas le plus pratique non plus. D’autres outils tels que Perforce ou Plastic SCM sont recommandés par Unity. Ne les ayant pas (encore) testé, je ne pourrais en parler plus ici.

Reviews

J’en parlais déjà dans la partie « Qualité du code » : au travail, tout changement dans le code est d’abord soumis à un code review avant d’être validé. Cela permet, d’une part, de trouver des erreurs et autres problèmes dans le code. D’autre part, cela permet de partager la connaissance de la codebase à travers l’équipe, pour éviter qu’une seule personne aie connaissance de telle ou telle partie du code. C’est une méthodologie que je trouve extrêmement utile et efficace, et qui m’a permis de progresser énormément.

Travaillant seul sur mon jeu (et sans version control), cela n’était pas vraiment possible. Je trouve cependant intéressant que malgré l’absence de review du code, j’ai tout de même fini par recevoir des reviews du jeu, qui en somme n’est que l’output de mon code. Cela me fait réaliser que même dans le développement logiciel, une review du code uniquement n’est potentiellement qu’à moitié efficace, et qu’accorder plus de temps à tester manuellement le résultat (quand c’est possible bien entendu, ce qui est surtout le cas pour les aspects UI) est certainement bénéfique.

Tracking des issues

Parlons à présent de la gestion de projet, en particulier du suivi des tâches en cours : les fonctionnalités restant à implémenter, les bugs à corriger, ou encore les graphismes à réaliser. Étant habitué à utiliser GitLab depuis mes études, et notamment son système de tracking d’issues, j’ai décidé de créer un projet GitLab uniquement pour ça. Avec l’idée initiale de potentiellement y mettre mon code et d’utiliser d’autres fonctionnalités, même si ça n’a jamais été le cas. Finalement, j’aurais aussi bien pu utiliser Trello ou d’autres outils du même genre qui se limitent à ça : la possibilité d’ouvrir des tâches, avec un titre, une description, des tags et des commentaires. Chaque tâche pouvant être placée dans une colonne (typiquement « terminé », « en cours » et « pour plus tard »).

J’ai donc utilisé ce système pendant plusieurs mois (plus ou moins 2 ans je crois). Mais étant seul sur le projet, cela s’est rapidement avéré inutilement complexe. Beaucoup de tâches ont été faites sans jamais avoir été créées dans GitLab, et commenter mes propres issues me procurait un étrange sentiment de solitude et d’inutilité. J’avais beaucoup de mal à avoir une vision claire de ma progression avec ce système, et ce n’était pas très motivant.

En particulier, j’avais du mal à savoir comment organiser les tâches concernant les personnages et créatures du jeu. Il y en avait en tout une trentaine, et chacun d’eux nécessitait toute une série de tâches : dessin initial, mise en couleur, animation, intégration dans Unity, avatar, écriture du dialogue, sons, entrée dans le recueil, IA, … Certaines tâches ne s’appliquant pas forcément à tous. Alors quoi faire ? Une issue par personnages ? Une issue par « type de tâche » ? Une pour chaque paire « personnage-tâche » ? Dans tous les cas, cela faisait beaucoup d’issues et difficile d’avoir une vue claire avec GitLab.

Finalement, j’ai opté pour une solution bien plus simple : un tableau Excel. Ce tableau m’a accompagné sur les 5-6 derniers mois du développement et étonnamment, ce fut une méthode bien plus efficace. La progression visible en un seul écran. La possibilité d’avoir une vue « par créature » et « par tâche ». Et dans les rares cas où j’avais besoin d’ajouter quelques commentaires, écrire directement dans une case était largement suffisant pour moi. Au-delà de ça, voir les cases devenir vertes au fur et à mesure était bien plus jouissif que de fermer des issues. Au point où j’ai abandonné GitLab et ouvert d’autres feuilles Excel pour les autres aspects du jeu.

Loin de moi l’idée de critiquer les systèmes plus complexes offerts par Trello ou GitLab. Ils ont définitivement du sens sur des projets d’équipe nécessitant des discussions techniques complexes. Et dans le cas de GitLab, l’intégration avec le reste (Merge Requests, code, CI) est un atout majeur. Mais quand tout cela n’est pas nécessaire, il peut être utile de s’orienter vers quelque chose de plus léger.

Conclusion

Soigner son code, écrire des tests, committer son code, faire des reviews, organiser les tâches… Si tous apportent leur lot de bénéfices, ils demandent également du temps et de l’énergie. Au-delà de cette pathologie courante nommée « la flemme », il faut aussi prendre en compte l’impact que cela peut avoir sur la spontanéité et le plaisir de créer. Le jeu vidéo, sans doute plus qu’un autre type de logiciel, ne se résume pas à une série de spécifications à implémenter. Il demande une révision constante car les sensations de jeu et le fun ne s’obtiennent jamais du premier coup. Le tout est de trouver la bonne balance et de lutter contre des intuitions parfois erronées. Dans tous les cas, je vois ça comme une force d’avoir pu apprendre des deux côtés car le domaine du jeu vidéo et celui du logiciel « traditionnel » ont certainement des choses à apprendre l’un de l’autre.

On se retrouve à présent pour la sixième et dernière partie : Partie 6 – Communication et feedback.