La myriade de choix des développeurs

Avant d’en faire mon métier, je pensais qu’il y avait une façon optimale de coder quelque chose et qu’un bon développeur était celui capable de la trouver et de l’appliquer. Aujourd’hui, je suis convaincue que dans le domaine du jeu vidéo, c’est bien plus compliqué que ça.

Programmer un jeu, c’est choisir entre plusieurs manières de faire

En prenant en compte des facteurs qui peuvent varier d’un jeu à l’autre :

• optimiser la mémoire ou le temps d’exécution,

• apprendre à utiliser des outils tiers ou développer les siens,

• préparer au maximum l’arrivée d’un futur contenu,

• se concentrer sur l’amélioration de l’essentiel,

• décider du degré de rigidité du code (moins faillible mais moins modifiable sur le long terme),

• etc.

La liste est longue.

C’est parce que les manières de coder sont plurielles qu’il y a rarement une façon de faire “ultime” qui surpasse les autres en tout point. Chaque choix vient avec ses avantages, ses inconvénients et son coût. Et comme vous vous en doutez, il n’y a pas que les contraintes techniques à prendre en compte pour décider quel choix adopter, loin de là.

Au-dessus de tout, il y a la contrainte du temps.

Comme le dit Solune, qui programme chez Unexpected :

"En programmation, tout est possible, ce n’est qu’une question de temps.”

C’est tout à fait vrai.

Et un studio indépendant développe un jeu en un temps limité. Il n’est pas impossible que la solution parfaite sur le plan technique soit hors de portée ou qu’il faille renoncer à pouvoir tout faire. Il faut savoir le reconnaître et faire avec en choisissant judicieusement ce à quoi on renonce.

Et la course contre la montre ne s’arrête pas à la sortie du jeu !

Nous avons fait face à une avalanche de bugs à la sortie de looK INside, il a fallu prioriser lesquels résoudre en priorité. Pour cela, j’ai trié les bugs selon leur gravité (s’ils empêchaient de jouer ou non)...

... Et leur fréquence (s’ils apparaissaient souvent et chez beaucoup de joueurs ou non) afin de les répartir en plusieurs patchs.

En plus de cette contrainte, il faut savoir que le choix d’une certaine méthode peut ajouter ou enlever du travail aux autres membres de l’équipe.

C’est valable pour plusieurs programmeurs qui travaillent ensemble, un code pouvant être plus ou moins lisible, mais également lorsque l’on travaille avec d’autres corps de métiers. En cherchant à préserver une structure de code, on peut involontairement compliquer la tâche aux autres et leur faire perdre du temps.

Inversement, un programmeur peut “perdre du temps” de son côté pour en faire gagner à l’équipe, par exemple en développant des outils qui facilitent des tests ou la création de nouveaux éléments de jeu.

De plus, il y a dans les petites équipes des myriades de tâches à cheval entre les corps de métiers, que l’équipe répartit comme elle peut. Il faut constamment faire des choix en fonction de la technique, en fonction du temps et en fonction des autres.

L'exemple de l'intégration des dessins sur looK INside

L’intégration des dessins d’Audrey sur le moteur de jeu Unity nécessite que les images soient d’une taille particulière pour être compressibles. J’ai donc créé un script photoshop qui permet qu’une image soit convertie à la bonne taille sans qu’Audrey ne s’en soucie. Aujourd’hui, nous avons encore amélioré notre processus pour travailler sur la suite...

Fut un temps où looK INside était un jeu bien plus axé sur la palpabilité.

C’était sans compter le fait que le développement est souvent fait de tâtonnements : parfois une chose est fonctionnelle mais ne produit pas une bonne expérience de jeu.

Elle remplit le cahier des charges, mais l’équipe en testant réalise qu’elle ne suscite pas d’émotions ou qu’elle est trop fastidieuse. Alors il faut croiser les doigts pour que le code rédigé soit adapté aux nouveaux objectifs... ou recommencer.

Selon l’avancée du développement, on peut être obligé d’ajouter une exception, car il est trop tard ou risqué de remanier le code de manière plus structurelle.

Les actions du joueur étaient nombreuses et impliquaient une structure de code particulière qu’il a fallu abandonner au cours de la pré-production. En effet le temps pris par le prototypage et les premiers tests nous ont montré que c’était un gameplay irréalisable pour notre équipe dans le temps imparti, mais aussi très difficile à “apprendre” au joueur.

Et je ne parle ici que du domaine de la programmation. Ce processus existe en parallèle dans chacun des métiers.

Développer un jeu, c’est faire une multitude de micro-choix interdépendants qui sont autant de potentielles erreurs que de futurs coups de génie.

C’est ce qui fait du développement de jeu un long casse-tête extrêmement jouissif à résoudre. Mais c’est aussi pourquoi tant de jeux laissent derrière eux cette sensation douce-amère d’imperfection.

Ambre Lacour - Programmeuse looK INside & dWARf

(Game Developer - Freelance)