Après un stage chez Phoenix Interactive cet été, j’ai enchainé sur ma dernière année d’études. Le premier semestre a été éreintant avec le projet de fin d’études. Je n’en ferai pas de post mortem mais j’aurai beaucoup appris et découvert quelques personnes avec qui j’espère retravailler un jour sur de beaux projets.

Ce projet s’appelle Géant et repose sur « L’Urbanurgie » qui est la base de notre gameplay : l’interaction avec les structures de la ville. Vous pouvez trouver quelques vidéos du résultat final ici mais celles des walkthroughs n’ont pas de son.

Vous pouvez voir l’ensemble des trailers de notre promo sur le blog de Olivier Penot. Comme il le dit si bien, le but de chaque promo est de surpasser la précédente en terme de production. Je crois qu’on y est arrivé et qu’on peut souhaiter bonne chance à la promo suivante car on on a placé la barre très très haute. De mon côté, même si le niveau de réalisation de Paperplane est exceptionnel, j’ai été vraiment bluffé par Nowhere et Goju.

Après le projet de fin d’études, il y a le stage. En Décembre, j’ai répondu à une annonce de Ubisoft Montpellier qui cherchait un Associate Producer avec un bon bagage technique et 2 ans d’expérience dans l’indsutrie. Je cherchais un stage et je n’avais pas réellement deux ans d’expérience dans l’industrie mais j’ai essayé, n’ayant rien à perdre. J’ai eu la surprise d’être rapidement rappelé et après quelques entretiens, de me voir proposer un stage. Aujourd’hui, cela fait deux semaines que j’ai commencé et je dois avouer que cela me plait beaucoup. Evidemment, je n’ai pas le droit d’en parler plus que ça, mais travailler dans un des studios français les plus renommés, sur un projet très ambitieux et avec des gens d’une telle qualité me ravit. Je pense avoir aussi eu la chance de tomber dans une équipe dans laquelle j’apprends beaucoup et j’espère que cela va durer longtemps. En plus, il y a plus difficile que de vivre à Montpellier !

A côté de ça, je vais reprendre mes projets personnels pour continuer à me former et essayer de communiquer plus régulièrement sur ma veille et mes recherches quotidiennes.

The Pub – ENJMIN – 2009 from Ronan Kergosien on Vimeo.

Merci à lui et à tous ceux qui ont participé à cette vidéo.

Peu de temps en ce moment pour faire un article mais je donnerai des nouvelles d’ici quelques semaines. J’ai fait plein de choses chouettes que j’aurais dû partager… mais les journées ne font toujours que 24h et le projet de 2ème année me prend pas mal de temps et d’énergie !
A bientôt.

Introduction

Les équipes sont de tailles variables et en règle générale, chaque personne est sur deux projets (plus pour les sound designers qui sont indispensables à un projet et en nombre limité). Ces projets durent 3 mois environ et les étudiants ont des cours et des travaux à rendre à côté de ces projets.

C’est la première véritable expérience d’un projet rencontrée par un étudiant de l’ENJMIN. Même si cette année nous avions eu un aperçu avec les projets Game Maker, la consistance de ces minis projets donnent plus d’horizons aux problématiques que l’on peut rencontrer.

Il est évident que j’ai appris un tas de choses, qu’une grande partie me servira dans ma vie future et qu’une autre partie est plus relative au contexte de l’ENJMIN.

Mes deux projets

« The Pub »

« The pub » est un jeu de combat en 2D traditionnelle à 2 joueurs (1 vs 1) dont la principale originalité se situe dans l’utilisation de la voix. Afin de pousser l’expérience (de jeu et de développement) plus loin, nous avions fabriqué deux sticks arcades.

L’équipe était composée de deux game designers, deux graphistes, un programmeur, un ergonome et un chef de projet (moi). Un sound designer extérieur à l’école nous a apporté son aide, suppléé par un sound designer de notre promotion en fin de projet.

Nous nous sommes appuyés sur le cours de Mr Arnaudo pour structurer notre gameplay. Nous avons donc rapidement pu déterminer ce que nous souhaitions. Au fur et à mesure de l’avancée du projet et du code notamment, nous avons retouché le design pour le simplifier pour coller à ce que nous pouvions vraiment faire.

Techniquement, le projet comportait deux difficultés majeures. Tout d’abord, le nombre d’assets graphiques (200 sprites notamment) était très important. Il a fallu trouver une méthode permettant de produire de façon rapide tout en gardant un niveau de qualité satisfaisant. Nous avons donc utilisé la méthode de la rotoscopie (utilisée par exemple pour Prince Of Persia (premier du nom) ou Flashback). Ensuite, la gestion de la voix est plus compliquée qu’il n’y parait. Même si plusieurs middlewares sont accessibles (FMod, System Speech, Voxler…), aucune solution n’est réellement satisfaisante. Que ce soit pour la gestion d’une double entrée (un micro par joueur), pour la reconnaissance des syllabes, ou pour la compatibilité avec XNA, chaque solution apportait son lot de complication. Au final, nous avons du nous résoudre à revoir à la baisse les ambitions de design.

Ainsi, nous avons choisi de faire de la façon suivante. Lorsque les combattants se touchent, une jauge se remplit. Lorsqu’elle est remplit, le joueur appuie sur une énorme touche et crie dans son micro. Plus il crie, plus le coup spécial est puissant. Il y a trois paliers qui sont de plus en plus durs à atteindre à mesure que le joueur utilise son coup spécial.

Malgré ces difficultés, notre objectif de produire un jeu fun (la convivialité d’un jeu de combat renforcée par l’utilisation de la voix) a été atteint. Imaginez une soirée entre amis où deux joueurs s’égosillent dans un micro régulièrement pour se mettre joyeusement sur la tronche !

« Vertige »

« Vertige » est un jeu de « programmation ». Il s’agit d’entrer une séquences de commandes et de la valider pour que notre avatar les exécute. Hors mis cette caractéristique déphasée, le gameplay était en 2,5D (à la manière de Little Big Planet) et les niveaux étaient conçus en cercle. Une réelle volonté de l’équipe était de réaliser un jeu avec une ambiance particulière.

L’équipe était composée d’un game designer, d’un ergonome (à l’origine du projet), d’un sound designer, d’un modeleur 3D, d’un animateur (mexicain !), d’un programmeur, d’un sound designer et donc d’un chef de projet. Le jeu a été réalisé sous Unity3D.

Je pense que l’idée du gameplay déphasé est réellement intéressante. Malheureusement, nous ne sommes pas parvenus à réellement montrer le potentiel. Ce mécanisme est peu habituel et nous n’avons pas réussi à le rendre totalement intuitif. Le résultat final a des qualités mais il lui manque un petit quelque chose pour que l’expérience soit réellement mémorable.

Cependant, l’ambiance du jeu est plutôt réussie. Il a été particulièrement intéressant de travailler avec les artistes de ce projet. Si évidemment nous avons dû revoir certaines ambitions artistiques à la baisse, notamment au niveau sonore, le résultat final est vraiment bon pour un projet étudiant. Notamment le character design qui n’a cessé de progresser tout au long du projet. La réalisation finale était à hauteur des artworks prometteurs du début de projet. Que ce soit le passage de la note d’intention aux artworks, des artworks à la modélisation ou l’animation de ce modèle 3D, la progression a été constante et les artistes ont su faire avec les contraintes techniques ce qui nous a permis de ne pas revoir à la baisse les ambitions.  Les décors sont eux aussi réussi mais les contraintes techniques ont été moins maitrisées, surtout au niveau de l’intégration, ce qui nous a obligé à recommencer un nombre de fois important la production de certains assets. Le temps monopolisé par ces innombrables retakes n’a donc pas pu être investi dans l’amélioration globale des différents éléments du décor.

Il a été de plus très intéressant de travailler avec un middleware professionnel (Unity3D). Ainsi, j’ai pu découvrir les avantages et les inconvénients d’un tel outil ainsi que de son influence sur le pipeline de production.

Conclusion

Globalement, ce furent deux expériences très enrichissantes. Même si les conditions de travail étaient encore éloignées d’un contexte professionnel, j’ai pu prendre conscience de l’importance de certaines choses que je sous estimais auparavant (notamment : scaling up, suivi de projet, intégration des assets). De plus, les deux projets étaient assez différents (équipes, philosophie de conception, technologie…) : le premier a fini par se rapprocher d’un dispositif interactif alors que le second s’est plus orienté comme la production d’un jeu plus classique.

Un post mortem est un regard sur une expérience passée, quelle qu’elle soit. L’expression est habituellement utilisée pour désigner un article fait par un développeur à propos d’un projet auquel il a participé et dans lequel il liste ce qui a marché et ce qui n’a pas marché, ce qui lui a plu et ce qui lui a moins plu.

Contexte.

La création de « Murmur » s’est faite dans le cadre d’un exercice lors de mon M1 à l’ENJMIN. La consigne de départ n’est pas réellement importante car elle a été largement dépassée par les 8 groupes. Un thème (« dérober », avec tous ses homophones), une technologie (Game Maker 7) et des délais (2 semaines pour fournir une version jouable et 1 semaine de plus pour présenter une version finale (20 minutes de présentation, 10 minutes de questions)) étaient donnés. L’équipe de « Murmur » était composée de deux graphistes, d’un game designer, d’un ergonome, d’un programmeur, d’un sound designer (qui était sur un autre projet en même temps) et d’un chef de projet (moi-même). L’équipe n’était pas à temps plein mais travaillait sur le projet en plus des cours quotidiens.

Description.

« Murmur » est une expérience interactive à utilisation unique. C’est à dire que le gameplay a été utilisé comme un outil de mise en scène interactive afin de véhiculer un message. L’utilisation est dite unique car la construction du message est séquentielle : lorsque l’utilisateur reçoit une information, il est supposé l’interpréter sans connaître la suite des évènements. Je ne rentrerai pas plus dans les détails, car les problématiques relatées dans ce post mortem concernent le déroulement du développement et se veulent donc compréhensibles par tout le monde, même, et surtout, ceux qui ne connaissent pas « Murmur ».

Pour plus d’informations à proprement parler sur « Murmur » :

• L’application avec ses sources
• Dossier de soutenance de l’exercice
• Support de présentation

Les difficultés identifiées en amont.

Dès la mise en place du projet, j’avais identifié trois difficultés majeures.

En premier lieu, les délais serrés promettaient d’être le facteur le plus contraignant. Deux livraisons étaient prévues : la première au bout de deux semaines qui devaient être une version jouable (mais éventuellement ni finale, ni complète) accompagnée d’un dossier décrivant divers éléments de conception et la seconde une semaine qui était la présentation de la version finale. De plus ces délais limitaient la possibilité de mettre en place une méthode de management projet complète.

Ensuite, j’étais inquiet au sujet de la technologie imposée (Game Maker 7 Pro). Une présentation conséquente nous en avait été faite mais si elle permettait de répondre en partie à la question de la faisabilité, il était encore difficile d’évaluer la charge de travail que représentait l’implémentation des fonctionnalités proposées par l’équipe.

Enfin, même si au final cela s’est avéré peu préjudiciable, je prenais au sérieux le manque d’expérience collective de l’équipe. Il s’agissait du premier travail de groupe qui allait de la conception à la présentation de l’objet réalisé. Si chacun d’entre nous possédait déjà des aptitudes certaines dans son domaine de compétences, il était nouveau pour tous de réaliser un projet nécessitant des compétences pluridisciplinaires et donc demandant à chacun de collaborer avec quelqu’un ayant un profil totalement différent du sien. De plus, cela signifie aussi que je ne connaissais pas réellement les membres de mon équipe dans un tel contexte.

Lever l’ancre malgré le brouillard

En temps normal, dans cette configuration (« faites quelque chose pour telle date avec telle équipe »), j’aurais déterminé le périmètre du projet en fonction des délais et des moyens de l’équipe en l’adaptant régulièrement en fonction des évènements durant le développement. Dans le cas présent, il m’était difficile d’évaluer les moyens. Que permet et que requiert la technologie? Quel est le degré de compétences des différents membres de l’équipe et notamment du programmeur sur qui l’implémentation du travail des autres repose? Quelles sont leur force de travail et leur motivation? Autant de questions sans réponses précises qui ont rendu la définition des contours initiaux du projet ardue.

De plus, dès le début de sa conception, le projet s’est voulu porteur de sens. Modifier le périmètre du projet en cours de développement aurait fortement remis en cause sa qualité car sa compréhension au près de l’utilisateur passait par le développement d’un tout cohérent et maîtrisé.

Mais ce dont j’étais réellement sûr était finalement assez simple. Les délais étaient serrés et ne nous laissaient pas vraiment le temps de tergiverser, surtout vue l’ambition de l’équipe. Ne pas tergiverser signifie deux choses : il faut faire quelque chose et ce qui est fait doit être nécessaire.

La discussion au sein du processus de création

J’avais choisi de mettre la discussion en équipe au sein du processus créatif. Cela m’a permis deux choses. D’abord, l’équipe adhérait à chacun des choix de conception et la cohésion, innée en majeure partie, s’en trouvait renforcée. Ensuite, cela me permettait d’être sûr que les choix faits engendreraient des charges de travail que l’équipe allait assumer. Dans l’idée, c’était parfait. Dans les faits, c’était beaucoup moins simple à gérer.

Le premier des écueils est que la discussion est un contact concret entre plusieurs personnes. Ce contact peut être agréable et n’être que positif. Mais ce contact peut parfois irriter et se transformer en tension. Souvent, le basculement entre ces deux cas est difficile à anticiper et s’il survient, cela devient difficile à corriger. Heureusement, l’équipe s’est montrée intelligente et mature. Les caractères se sont peu télescopés et quand le choc était proche, les personnes concernées ont su prendre sur elle. Aurais-je pu trouver cet équilibre avec une autre composition d’équipe ou ai-je eu de la chance d’avoir cette composition d’équipe ?

Toujours en lien avec les caractères des membres de l’équipe, ce projet, qui était donc la première expérience du genre pour chacun d’entre nous, était aussi un terrain d’étalonnage quant à la place de chacun. Pour ma part, je pense qu’il n’existe pas de définition stricte et universelle quant aux délimitations du rôle de chacun car cela peut varier selon le projet et l’équipe. De plus, en mettant le dialogue au sein de la démarche de création, j’incitais chaque participant à donner son avis sur chaque décision, sur chaque idée (non technique) et à proposer des solutions, même si elles n’étaient pas totalement dans son champ de compétences.

Pour finir, le souci de la discussion est qu’elle n’est pas fondamentalement productive. Elle peut aider à l’être mais en soit, le temps qu’on parle, on ne le passe pas à développer à proprement parler. Par contre, on a évidemment besoin de communiquer pour savoir dans quel sens avancer. J’ai parfois eu du mal à sentir que la discussion tournait en rond et nécessitait une synthèse de laquelle je pouvais déduire des tâches de développement pour chaque membre de l’équipe.

Malgré tous ces écueils, je reste persuadé que la discussion doit être l’essence du processus de création. En plus de fédérer (adhésion de chacun au projet, assomption de chacun à ses tâches…), ces discussions limitent les risques de « tour d’ivoire ». Mettre à une idée, une opinion, un avis à l’épreuve de la critique dans un cercle fermé et connu est indispensable. Si jamais l’idée d’un membre de l’équipe ne passe pas ce premier filtre, quelles sont les chances qu’elle soit bien accueilli par le public cible ? Une idée doit avoir une raison d’être plus qu’une simple envie, plus qu’un simple désir profond, plus qu’une intuition. De plus, la confronter aux autres permettra de l’enrichir au contact des idées du reste de l’équipe.

Quelques éléments à corriger pour le futur.

L’élément qui me semble le plus important à corriger est un manque de formalisme. Si cela n’a pas porté à conséquences, c’est, d’après moi, dû à la taille réduite du projet en termes de délais, d’objectifs et de participants. Déjà quelque peu englués par la discussion omniprésente, j’avais peur d’alourdir encore plus le processus. Cependant, il m’apparaît comme indispensable que chaque réunion soit suivie d’un compte rendu synthétique qui, en une vingtaine de lignes, indique ce qui a été décidé et l’orientation générale des choses. De la même façon, chaque tâche doit être l’accomplissement d’une consigne validée par le chef de projet et les développeurs concernés afin de se prémunir des travaux qui seraient effectués sur une incompréhension.

Une seconde amélioration à apporter concerne la préparation de la présentation. Même si en soit elle n’était pas mauvaise et répondait aux attentes, elle aurait du être tout aussi soignée que le reste du projet et du temps de préparation conséquent aurait dû lui être consacré. La communication sur ce qu’on fait est aussi importante que ce qu’on fait.

Un autre point à améliorer réside dans l’intégration des recherches en ergonomie dans le processus de développement. C’est une partie essentielle du développement mais aussi une des plus difficiles, d’autant plus quand l’interaction en question doit soulever un propos.

Pour finir, j’aurais surement dû essayer d’alterner les moments détendus et les moments de rigueur lorsque l’équipe était réunie. Même si l’ambiance était bonne, certaines réunions auraient surement gagné à se passer autour d’un verre par exemple.

Et à propos du résultat ?

Je dois bien admettre que je suis satisfait de ce projet. En tenant compte des contraintes, le résultat me parait intéressant même s’il pourrait largement être amélioré. Ma plus grande satisfaction provient surement de l’identité (visuelle, sonore et conceptuelle) que l’équipe a réussi à donner au projet. Même si on est loin des problématiques de gameplay à proprement parler, l’utilisation de l’interactivité comme outil de mise en scène et vecteur de sens a été enrichissante.

Ayant pu observer des utilisateurs face à « Murmur », j’ai pu voir que les réactions espérées avaient bien lieu ce qui m’a rassuré. Cependant, j’ai toujours peur que l’expérience ne soit pas réellement accessible. Les informations données à l’utilisateur sur ce qu’il doit faire et pourquoi il doit le faire sont encore améliorables, sans tomber dans quelque chose de didactique qui dénaturerait l’expérience.

Conclusion.

Il n’y a rien d’exceptionnel à conclure, j’aurais surement pu écrire cette conclusion avant même le projet. Il m’aura permis de « me rendre compte de ce dont je me doutais ». Donc, cette expérience aura été très enrichissante car j’ai pu mesurer l’ampleur de la difficulté de gérer une équipe aussi éclectique et un projet de cette nature en situation réelle. La seule question est : est ce que je parviendrai à me servir de cette expérience pour être meilleur lors du prochain projet ?

ULO est un projet qui, à défaut d’avoir mené à quelque chose de concret, a été un déclencheur dans mon parcours. C’est mon premier travail en commun avec Bruno Urbain (ex 10Tacle Belgium, maintenant indépendant) avec qui je travaille toujours. De la même façon, Brice Tingaud (Game Deisgner chez Quantic Dream) a participé et fourni quelques esquisses d’artworks. Tous deux étaient encore à SupInfoGame à l’époque. J’ai pu pour la première fois commencer à coucher sur le papier des idées issues de l’analyse de ce qui existait et de choisir une direction d’évolution. Ayant la chance d’avoir un contact proche de Atari France, j’ai aussi pu, de façon informelle, faire parvenir à une équipe pro le document final. Les retours furent assez encourageants nous incitant à développer un prototype, ce qui était évidemment impossible pour nous à l’époque.

Avec le recul, je suis assez fier de ce document. Certains concepts (comme Empire Of Sports) mettant la simulation sportive au centre du concept (comme ULO) ont été développés même s’ils ne sont pas très médiatisés (et que d’après moi, ils ne vont pas au bout des choses). Maintenant, le concept de ULO parait assez ordinaire mais pour l’époque, il était vraiment original. Ce qui m’amène à la question : est ce que mes idées actuelles sont aussi pertinentes que celle de ULO? J’espère avoir la même clairvoyance maintenant qu’à l’époque.

Il y a aussi dans ce concept une manifestation de mon goût pour les univers virtuels. C’est vraiment le pan des jeux vidéo qui me passionne le plus, celui qui semble porter le plus de promesses, le plus de potentiel… J’en parlerai surement plus longuement plus tard.

ULO, c’est donc mon premier fait d’armes (maigre certes ! mais le premier), les premières caresses d’une ambition professionnelle et surtout le début de la construction d’un réseau dans lequel je trouverai relations, conseils et motivations.