Former les game designers de demain (Part 1/5)
Par Pascal Luban - Game designer & creative director, freelance
De nombreuses écoles offrent des formations de qualité portant sur le game design. Mais être formé au game design n'est pas suffisant pour être game designer.
Pour pleinement s'intégrer dans une équipe et s'y épanouir, un game designer doit développer des savoir-être et de nouveaux savoir-faire qui ne sont pas systématiquement proposés dans les formations scolaires.
L'objet de cette série de publication est de mieux préparer les futurs game designers à leurs missions. Je m'appuie sur mon expérience, en tant que game designer et lead designer, mais aussi en tant que formateur.
Être ou ne pas être …
S'il y a bien un aspect qui différencie les vétérans des novices, c'est la maîtrise des savoir-être.
De quoi s'agit-il ?
Les savoir-être correspondent aux qualités personnelles et aux comportements d'un individu au sein d'une équipe. Appelés soft skills en anglais, ils deviennent de plus en plus importants lors du recrutement d'un futur membre d'une équipe de développement.
Vous trouverez facilement des généralités sur les savoir-être indispensables en studio, comme avoir l'esprit d'équipe, respecter à la lettre les demandes ou être très exigeant concernant son propre travail. Mais, aujourd'hui, je souhaite partager avec vous d'autres savoir-être très concrets qui sont le fruit de mon expérience de 28 ans comme game designer.
Savoir-être 1 - Suivez toujours l'implémentation de votre design
Ce n'est pas parce que vous avez écrit un document de design que ce dernier va être développé à la lettre. Les raisons peuvent en être multiples : Le programmeur ou l'artiste peut mal comprendre vos intentions de design et ne pas vous demander d'explication, un impératif technique peut empêcher son implémentation exactement telle que vous l'envisagiez, votre document de design peut manquer de clarté, ou tout simplement, ne pas être lu ! J'ai personnellement vécu toute ces situations.
Dans de telles circonstances, vos collègues les plus consciencieux vous poseront des questions ou vous demanderont des instructions mais tous ne le feront pas. Il est donc de votre responsabilité de vous assurer que votre design est correctement compris et implémenté. N'oubliez jamais que si le gameplay est médiocre, c'est vous que l'on blâmera, pas les membres de l'équipe qui l'auront mis en place, même si ces derniers n'ont pas respecté votre cahier des charges !
Les bonnes pratiques
Pour éviter ce genre de problème, les bonnes pratiques sont les suivantes :
- Rédigez des documents de design aussi précis que possible Et faciles à lire
- Ne développez pas un énorme document de design ; personne ne le lira. Rédigez plutôt plusieurs documents de design, chacun étant centré sur une expérience de jeu, et faites-les implémenter les uns après les autres.
- Ne vous contentez pas d'envoyer vos documents de design aux membres concernés de l'équipe ; présentez-leur, oralement et avec le support de schémas, les grandes lignes de votre design.
- Vérifiez que la fonctionnalité développée corresponde bien à ce que vous avez défini
- Passez beaucoup de temps à tester, tester et encore tester le jeu.
Etude de cas
Pour illustrer mon propos, je vais partager avec vous des situations dont j'ai été le témoin ou que j'ai vécu. Bien entendu, les noms sont fictifs afin de préserver l'anonymat de chacun.
Luigi est game designer sur un jeu d'action-aventure ou le personnage principal est accompagné d'un équipier. Luigi rédige le design de la mécanique qui gère le comportement de l'équipier, les endroits où il se rend, l'attitude qu'il adopte et l'action qu'il entreprend. Cette mécanique repose sur le positionnement, par l'équipe de level design, de points de passage (waypoints).
Luigi s'est contenté d'écrire un document de design détaillé et a fait confiance au reste de l'équipe pour implémenter correctement son design.
Mais l'équipe artistique passe après le level designer et modifie la topologie de la map : Certains points de passage se retrouvent sous le sol ou sont masqués par des éléments de décor rajoutés.
En conséquence, la fonctionnalité marche mal et le gameplay parait inconsistant. Luigi ne se rend pas compte de ce qui s'est passé car il ne consacre pas assez de temps à tester les nouveaux contenus. Mal mise en valeur, la fonctionnalité est finalement abandonnée.
Savoir-être 2 - Préparez intelligemment les réunions auxquelles vous êtes convié
Si une réunion est bien organisée, elle a un agenda, une liste de sujets qui seront abordés. Si vous êtes convié à une réunion, c'est que l'on estime que votre contribution a de la valeur. Vos idées et opinions sont donc attendues.
Si, lors de la réunion, un sujet est mis sur la table et que vous n'avez pas eu le temps d'y réfléchir au préalable, votre contribution sera superficielle, voire contre-productive. Vous risquez de passer pour quelqu'un "qui compte pour du beurre", un simple exécutant, quelqu'un qui n'apporte aucune valeur-ajoutée. Et si vous improvisez une réponse pour faire acte de présence, vous risquez de dire quelque chose sans aucun intérêt, quelque chose qui va finalement ternir votre image.
Les bonnes pratiques
Si vous êtes convié à une réunion, voici les bonnes pratiques à suivre :
- Lisez attentivement l'agenda de la réunion ; S'il n'y en a pas, demandez à l'organisateur de la réunion de préciser les sujets qui seront abordés ; vous pourrez alors vous préparer et vous donnerez de vous l'image d'un bon professionnel.
- Prenez du temps pour réfléchir aux thèmes qui seront abordés et qui ressortent de votre domaine d'expertise. Le simple fait de réfléchir à tête reposée vous permettra de faire des propositions plus pertinentes mais surtout de construire un argumentaire pour les défendre.
Etude de cas
Voici un nouvelle illustration de ce qu'il faut faire … et ne pas faire :
John est convié à une réunion organisée par le directeur créatif du projet. Les autres game designers seront aussi présents. L'agenda précise qu'on traitera d'une fonctionnalité présente dans le jeu mais qui ne donne pas satisfaction : l'action coop entre deux joueurs du même camp.
Lorsque le directeur créatif met le sujet sur la table et demande leur avis aux game designers présents, John, qui n'a pas vraiment réfléchi au problème, est mal à l'aise et se contente d'une proposition très générale. Mais, Emma, l'autre game designer, fait une autre proposition et l'illustre avec un schéma. Un dessin est beaucoup plus compréhensible qu'un discours et elle renforce sa proposition en citant des jeux qui utilisent la solution qu'elle propose.
John a affaibli sa position dans l'équipe tandis qu'Emma est apparue comme apportant une meilleure contribution au projet. Sa solution est retenue, non parce qu'elle est meilleure, mais parce qu'elle est présentée de manière plus convaincante.
Savoir-être 3 - Soyez humble et ouvert aux changements
Un game designer est toujours attaché à son travail, à ses idées. C'est normal. Mais un mécanisme de jeu reste une simple vue de l'esprit ; tant qu'il n'a pas été développé et intégré dans le jeu, on ne peut jamais être sûr de son intérêt. Autrement dit, une idée peut paraitre très bonne, sur le papier, mais peut se révéler décevante une fois implémenté.
Cette situation est fréquente.
En effet, la qualité de l'expérience du joueur résulte de l'interaction entre de nombreux aspects du jeu : Ses mécaniques, ses réglages, son rythme, les objectifs du joueur, sa complexité, etc. Une mécanique peut contribuer avec efficacité à une expérience de qualité dans un jeu mais se révéler préjudiciable dans un autre.
Un game designer doit donc faire preuve de modestie et développer son esprit d'auto-critique. Il doit analyser de manière objective la pertinence de ses choix de design. Il doit écouter les avis des autres membres de son équipe et surtout, il doit tenir compte des retours des playtests.
Il doit donc être prêt à repartir d'une feuille blanche si une mécanique de jeu ne donne pas satisfaction. D'ailleurs, l'expérience montre que si une mécanique de jeu ne marche pas, de simples améliorations peuvent ne pas être suffisantes ; il est souvent préférable de repartir sur une nouvelle mécanique.
Certains jeunes game designers ont tendance à défendre, contre vents et marées, leurs idées ; ils en font une affaire personnelle. Ils se trompent. Leur intérêt c'est que leur nom soit associé à un jeu publié et efficace, plutôt que leurs idées aient été retenu dans un jeu médiocre ou qui n'a jamais été publié.
Conseil de bon sens ? Ce n'est pas le cas pour tout le monde. Voici une nouvelle illustration des conséquences lorsqu'un designer s'obstine à défendre "sa" vision du jeu.
Etude de cas
Igor est lead level designer sur un jeu multijoueur pour consoles de salon. Les premiers playtests, effectués avec des joueurs extérieurs au studio et représentatifs de l'audience ciblée, valident les mécaniques de jeu mais pointent des problèmes dans les maps : Elles sont trop grandes par rapport au nombre de joueurs, ces derniers s'y perdent facilement et elles comportent trop de goulots d'étranglement.
Les sessions de playtest se succèdent. Chaque session est constituée de joueurs qui n'ont jamais joué au jeu et tous, font part des même problèmes liés au level design. Les problèmes cités par les playtesteurs sont pourtant systématiquement remontés à Igor après chaque session de playtest mais les modifications apportées aux maps sont mineurs et ne changent pas les retours des playtesteurs.
Au bout de plusieurs mois, devant la réticence d'Igor a changer en profondeur les maps, la direction du studio le démet de ses fonctions et le remplace par un autre membre de l'équipe.
A suivre …
Dans la prochaine partie de cette publication, j'aborderai les autres savoir-être indispensables, à mes yeux, à un game ou level designer.