Développeur et concepteur de jeux vidéo — tâches, une par une

Concevoir mécaniques, missions et énigmes

Les modèles de langage peuvent énumérer sur demande des idées de mécaniques et d'énigmes, mais ces idées viennent de la recombinaison de jeux qui existent déjà, et le difficile n'est pas de produire une idée : c'est de savoir si elle est amusante, ce qui n'apparaît que lorsque des gens y jouent. Une conception doit aussi tenir dans le budget de l'équipe, le moteur et l'identité du jeu, et quelqu'un doit en répondre devant le directeur créatif et l'éditeur. Les studios ont peu de raisons de confier ce jugement à un outil : l'outil nourrit le brainstorming et c'est toujours le concepteur qui choisit.

Ceci dit qui décide, pas combien de concepteurs il faut à un studio : si les outils permettent à chaque concepteur d'explorer des idées plus vite, une équipe peut garder sa taille et produire davantage, ou se réduire. Ce qui le ferait bouger : un jeu commercial sorti dont les mécaniques centrales ont été choisies par un système génératif, les concepteurs se contentant de relire, ou des studios supprimant des postes de conception en citant ces outils comme raison.

Équilibrage et playtests

Une partie de ce travail était automatisée bien avant les modèles de langage : les tableaux de bord de télémétrie montrent où les joueurs abandonnent, et des scripts simulent combats et économies. Des agents entraînés à jouer à un jeu peuvent désormais enchaîner de nombreuses parties et explorer les niveaux plus vite que des testeurs humains, ce qui fait apparaître tôt les déséquilibres et les exploits. Ce qu'ils ne peuvent pas rapporter, c'est la sensation du jeu — si un pic de difficulté est frustrant ou gratifiant —, donc le concepteur continue d'observer de vrais joueurs, décide de ce qu'il faut changer et en répond à la sortie du jeu.

Un réglage plus rapide raccourcit le travail sans dire qui perd les heures : les groupes de test externes et les postes juniors d'équilibrage ont plus de chances de le ressentir que le lead designer. Le jugement bougerait si des studios publiaient des changements d'équilibrage décidés par des agents automatiques sans validation d'un concepteur, ou remplaçaient les sessions avec de vrais joueurs par des sessions simulées.

Prototypes et maquettes

C'est ici que la technologie atteint le plus fortement le travail quotidien. Les assistants de code écrivent des scripts de moteur, le code de liaison de l'interface et la logique de jeu courante à partir d'une description, et les générateurs d'images et de 3D produisent rapidement des visuels provisoires et des environnements sommaires : un prototype qui demandait autrefois une petite équipe peut souvent être construit par une seule personne. Un prototype doit toujours tourner en temps réel sur le matériel cible, le code généré échoue de façons que seul quelqu'un qui comprend le moteur peut repérer, et ce que le prototype doit prouver reste décidé par la personne qui le construit.

Augmenter peut quand même signifier moins de monde : si un développeur peut prototyper ce qui en demandait plusieurs, les premiers postes à se raréfier sont ceux de programmation débutante et de greyboxing. Les assets générés ici sont surtout provisoires ; ceci ne dit pas qu'ils arrivent dans un jeu fini. Un cas daté de studio sortant un jeu dont le code ou les niveaux ont été majoritairement générés, ou réduisant ses effectifs de prototypage à cause de ces outils, ferait basculer ce jugement vers l'automatisation.

Documents de conception et spécifications de test

Une fois les décisions prises, les mettre en forme dans un document structuré est le genre d'écriture que les modèles de langage font déjà bien : ils rédigent des spécifications à partir de notes, gardent les sections cohérentes, transforment une conception en cas de test et produisent des logigrammes à partir d'une description. Les studios peuvent l'adopter à faible coût dans des outils qu'ils utilisent déjà, et un document erroné est repéré en revue plutôt que par les joueurs. Ce que l'outil prend en charge, c'est la rédaction, pas les décisions que le document consigne, et quelqu'un doit encore vérifier que le document correspond à ce qui a été construit.

Ceci retire des heures, pas un poste : peu de gens sont embauchés uniquement pour rédiger des documents de conception, donc l'effet se voit chez des concepteurs qui passent moins de temps sur la paperasse, ou dans un nombre réduit de concepteurs juniors dont le premier travail était de tenir les documents à jour. Il reviendrait en arrière si les studios constataient que les documents générés s'écartent assez souvent de ce qui a réellement été construit pour cesser de les utiliser.

Histoire, personnages et textes du jeu

Les modèles de langage écrivent un texte fluide dans n'importe quel registre, ce qui rend peu coûteux le premier jet de l'essentiel des textes d'un jeu — descriptions d'objets, répliques secondaires, variantes d'une même remarque. L'histoire et les personnages, c'est autre chose : ils portent l'identité du jeu, les joueurs remarquent une réplique faible, et de nombreux joueurs réagissent mal à un texte qu'ils croient généré. Les contrats des scénaristes et les règles sur la possibilité de posséder un texte généré par une machine freinent aussi son usage dans les jeux publiés : le scénariste retravaille des brouillons plutôt que de céder la voix.

Il y a une ligne de partage à l'intérieur de cette tâche : les textes en masse peuvent passer à l'automatisation tandis que l'histoire principale reste aux humains, et ce jugement couvre les deux. Il ne dit pas combien de postes d'écriture subsistent. Une sortie datée dans laquelle la majorité du texte a été générée à grande échelle et acceptée par les joueurs, ou un changement des règles sur la propriété du texte généré, le ferait bouger.

Revues de conception et direction de l'équipe

Ce travail consiste à persuader et à arbitrer entre des personnes qui veulent des choses différentes : artistes, programmeurs, producteurs et l'éditeur. Les outils résument les réunions et suivent les tâches, mais la valeur tient à décider quelle fonctionnalité est coupée, à maintenir une équipe sur une seule vision et à avoir la confiance nécessaire pour trancher, ce qui vient de la place d'une personne dans l'équipe. Rien dans la technologie actuelle ne donne à un studio une raison de laisser une machine régler ces désaccords.

Mené par des humains signifie que le rôle de coordination subsiste, pas le nombre de coordinateurs : si les équipes se réduisent parce que construire va plus vite, il faut moins de monde pour les diriger. Cela changerait si des studios se mettaient à piloter la production avec des outils de planification automatique qui prennent les décisions de calendrier et de coupe, les responsables ne faisant que les approuver.

Fixer les règles du contenu généré

Dès que des assets et des personnages générés entrent dans un pipeline, quelqu'un doit décider de ce qui est permis : quels visuels sont provisoires et lesquels peuvent sortir, ce qu'un personnage qui improvise ses dialogues ne doit jamais dire, et comment garder une trace de l'origine de chaque asset pour les détenteurs de plateformes et les éditeurs. C'est un travail de conception aux enjeux juridiques et de réputation, et il revient aux concepteurs et aux leads techniques parce qu'ils connaissent les systèmes.

Une nouvelle tâche n'est pas un nouveau métier : dans la plupart des studios, elle fait partie de la semaine d'un concepteur ou d'un lead déjà en poste, et elle ne grandit que dans la mesure où du contenu généré sort réellement. Elle deviendrait des postes à part entière si les détenteurs de plateformes ou les règles se mettaient à exiger que les jeux déclarent le contenu généré et tiennent des registres de provenance.