Un mois après mon retour d’une magnifique opportunité de participer à une game Jam à Shenzhen grâce à la collaboration entre TAG et Indienova, voici en quelques mots mon retour d’expérience, mélangeant commentaires sur le vif et réflexion depuis mon retour.
Plongeon dans la compétition :
Entouré par la foule de gratte-ciels que constitue notre ville hôte et à l’ombre du siège social de Tencent, la jeune ville de Shenzhen a un côté intimidant par rapport à la petite Montréal. L’accueil est chaleureux et tous les participants sont motivés mais dès les premières minutes nous comprenons que la communication et les problèmes qui en découleront seront des éléments clés de cette jam. La majorité des participants de la Jam sont Chinois, parlent Mandarin (et sont souvent étudiants à Beijing) avec un niveau d’anglais très variable (du très bon au débutant) et la majorité des participants visiteurs n’ont pas non plus l’anglais pour langue première et donc par conséquent parfois un profond accent (j’en suis un bon exemple).
Un autre constat qui sera, je pense, partagé par les autres participants est que l’expérience en création de jeu des participants était souvent assez limitée. Dans mon équipe, l’un des membres avait fait un stage Level Design à Tencent, d’autres avaient participé à la GGJ (ou même Critical Hit), mais tous étaient d’un niveau undergraduate dans un cursus n’ayant parfois aucun rapport avec le jeu. Cela étant dit, je contrebalancerai cet état de fait par le constat que le niveau technique des membres de mon équipe était au-delà du niveau de mes étudiants au baccalauréat.
Néanmoins, de ce manque d’expérience à la fois du travail en équipe et du travail dans le jeu vidéo découle une situation potentiellement problématique que j’ai observée dans un grand nombre d’équipes : les jammeurs étrangers (TAG d’un côté et Sweden games de l’autre), au vu de leur plus grande expérience, étaient très souvent en position de lead, manager, coordinateur ou tout autre quasi-synonyme (ce fut le cas dans mon équipe entre autre). Le potentiel risque de cette situation prend sa source dans les limites de communication mentionnées plus haut mais aussi dans la différence de culture de travail et de management entre la Chine et les pays invités. Le coordinateur ne partage ni la langue, ni la culture de travail de la majorité des membres de son équipe.
Cette situation de différence de langage combinée à cette position de coordinateur pouvait en outre renvoyer l’image très désagréable du donneur de leçon, « du missionnaire étranger » qui vient instruire de son savoir. De ce que j’ai pu en voir, je pense que nous avons tous réussi à dépasser cette situation potentiellement inconfortable. Mais plus fondamentalement, ces obstacles de communication pouvaient créer une dynamique particulière en cas de conflits éditoriaux dans lesquels le traducteur joue un rôle clé dans lequel il risque de produire une traduction orientant vers la décision qu’il préconise. 
Si la collaboration était plus longue qu’une jam, il aurait été facile de comprendre qui traduit réellement et qui interprète plus librement, sauf qu’en jam les minutes sont rares et – à mon sens – la règle d’or est la confiance en ses collaborateurs. Sur ce point, tout s’est très bien passé avec dans équipe avec deux membres chinois plus aguerris à l’anglais étaient en mesure de traduire dans les deux sens et ce dès le début de la jam.
Cependant, je noterai une certaine propension des membres de mon équipe à discuter des détails qui ne concernent pas directement leur partie créative (le programmeur qui questionne la direction artistique par exemple). Pour être un peu plus clair, il est évident que les créateurs doivent trouver un accord sur la direction artistique que prendra le projet (au sens large). Cependant, le jeu vidéo étant une œuvre collaborative basé sur cet accord préalable, il est à la fois nécessaire de laisser libre chaque créateur dans la sous-partie dont il est responsable, mais aussi accepter et suivre les décisions communes même si elles ne nous ravissent pas intégralement. Et ce encore plus en game jam où les secondes sont comptées.
Notre équipe a su relever ces défis avec un certain succès, nous avons rencontré par ailleurs d’autres difficultés.
Notre jeu : « Sundown » :
Rapidement, nous nous sommes mis d’accord sur notre projet : Sundown, un jeu traitant du syndrome d’Alzheimer à travers un jeu d’aventure narratif, 2D side-scroller avec des mécaniques de puzzle-game (notamment inspiré de la logique du Sokoban). L’objectif « sérieux » du jeu est double. Le premier est de permettre à de jeunes joueurs de comprendre cette maladie en expérimentant ses symptômes et conséquences (notamment la perte de repères spatio-temporels, la perte du langage, l’oubli des personnes et de la chronologie, l’agitation émotionnelle et la paranoïa). À travers un jeu simple nous cherchons à accompagner des enfants susceptibles d’être confrontés à cette maladie au sein de leur famille afin de les aider à en comprendre le fonctionnement et en quoi leurs comportements d’apparence anodine susceptibles d’être néfastes. Le second objectif de notre projet était de présenter un modèle de limitation d’action inspiré des free-to-play facebook (limitation du nombre d’action/parties pour un laps de temps défini) permettant de créer une frustration évoquant le fait que les personnes âgées ont un rythme de vie qui doit être respecté, mais aussi une potentielle source de financement à des organismes de soutien aux personnes victimes d’Alzheimer.
Notre projet comportait initialement cinq chapitres narratifs présentant la progression de la maladie et introduisant une nouvelle fonctionnalité ludique. Nous étions cependant très clairs sur l’idée que nous ne développerons que le premier (l’introduction-tutorial) et le dernier dans le but de présenter un prototype représentant le spectre de notre projet. Ainsi, nous nous sommes concentrés sur ces deux parties. Le choix du genre puzzle-game vient de la volonté de produire des situations complexes et longues à résoudre sans pour autant proposer un gameplay et des contrôles compliqués, ni de porter le défi sur la dextérité. Le but était aussi de montrer qu’une situation d’apparence très simple (regrouper des objets, se déplacer quelque part etc.) devient très complexe avec une mobilité réduite. 
Dans ce cadre, le joueur peut pousser des objets, en briser et en déplacer dans le but de créer un chemin vers un objectif donné. Un certain nombre de facteurs vont augmenter ou réduire le stress de la femme âgée qu’incarne le joueur, rendant les effets de la maladie d’Alzheimer plus ou moins importants (sentiment d’être pourchassé par des PNJ, perte de repères par transformation du niveau en temps réel, modification des fonctionnalités que renvoie la représentation physique d’un objet etc.). Malheureusement, en raison de la fin de notre Jam que je vais exposer dans quelques lignes, cette fonctionnalité fondamentale à la mise en valeur de notre propos, fait partie des absents de notre prototype.
Compte tenu du style graphique des deux artistes de l’équipe, le choix du-dit « Pixel Art » semblait évidant. Cela nous permettait d’avoir une production vaste et rapide susceptible de servir à la fois la narration et le Level design. Par contre, dès le début du projet nous avons été confrontés à un dilemme qui fut la source de nos futurs déboires : faire le projet sous Construct 2 que j’étais le seul à connaitre (ce qui impliquait que je n’aurai ni le temps de coordonner l’équipe, ni celui de faire du Game ou du Level design) ou alors le faire sous Unity, dont la connaissance était plus partagée, mais qui est un logiciel qui me semble très peu adapté au 2D side scroller en game jam. Compte tenu de la quantité d’ordinateur sous IOS dans notre équipe, nous nous sommes rapidement tournés vers Unity.
Mais catastrophe. Fin de la dernière après midi de Jam, là où nous étions sensés debuggés le programme, notre programmeur principal en difficulté cette dernière journée disparu (sans revenir le lendemain) nous abonnant avec un morceau de projet Unity avec les asset intégrés mais ni fonctionnel, ni documenté et donc inutilisable. Après discussion avec l’équipe épuisée et abattue, nous choisîmes la seule solution envisageable pour présenter quelque chose le lendemain : utiliser les quelques heures qui nous restaient avant la présentation pour produire, Ghazi et moi-même, un très simple prototype sur construct 2 (décidément le logiciel parfait pour les Game jam) afin de mettre un tant soit peu en avant la qualité et quantité des assets et Levels Design produits durant les jours passés. Durant ce temps, le reste de l’équipe c’est occupé de la présentation.
Ce fut un succès partiel dans le sens où le prototype produit en six heures de rush était plus abouti que le programme sous Unity. Prouesse d’autant plus grande lorsque l’on prend en compte l’état de fatigue accumulé. Cependant on ne rattrape pas une Jam entière en quelques heures et même si le travail de toute l’équipe existe, il ne peut être évalué, par manque de fonctionnalités de jeu fondamentales.
Quelques mots pour finir :
J’utiliserai ce chapitre de conclusion pour d’abord remercier les membres de l’équipe : Hohan, Noc, MI Jintao (Mitoo), Yiming et plus particulièrement Ghazi pour sa participation active et son redoublement d’effort en fin de projet, malgré la fatigue, la déception et le fait de savoir que malgré tous les efforts, il serait impossible de rattraper les erreurs dont nous n’étions pas responsable. Tous ont travaillé très dur et avec passion. Le prototype ne serait représenter notre engagement.
J’aimerais aussi remercier TAG (bien sûr) et Indienova qui a mis en place cette Game Jam et assuré son bon déroulement. Mes sincères remerciements vont avant tout à «Oncle» qui a toujours su être là pour nous faciliter le travail. Si l’opération venait à se répéter outre le fait que je serais honoré de ”prendre ma revanche” , j’aimerais souligner deux points qui à mon sens pourraient être améliorés et un élément qui fut un atout fondamental de cette jam.
Le premier est l’équilibre des équipes et la visibilité des compétences. Je sais qu’un travail a déjà été fourni sur ce point, notamment le fait que les participants étrangers étaient répartis sur toutes les équipes, par contre ça semble être moins le cas pour ce qui est de l’expérience et des compétences.
Le second est le rythme de la jam. Comme tout game designer -je pense- je suis de ceux qui sont sincèrement convaincus que la structure influence les comportements. Si 5 jours peuvent sembler longs par rapport à une jam classique de 48h, le temps effectif se révéla plutôt être entre un maximum de 30 heures et un minimum de 20h (repas, transport et réunions inter-groupes inclus). Si certaines contraintes horaires étaient incompressibles comme le repas ou le bus pris dans les embouteillages, d’autres comme les échanges intergroupes ou les réunions de présentation de planning prenant plus d’une heure chaque jour auraient trouvé leurs utilités uniquement dans une Jam non compétitive basé sur l’échange et le partage de connaissances. Or la functionnal Game Jam avait pour visée une présentation publique jugée et primée par des professionnels. Dans ce contexte, ces espaces d’échange théorique ajoutaient une charge de travail à toutes les équipes dont une grande partie des participants étaient contraints de continuer à travailler durant ce laps de temps (encore une fois, je m’inclus dans cette critique). De plus, cela impose un rythme de travail spécifique composé de jalons qui dirigent la production vers un certain type d’objets. En somme une cohabitation de deux systèmes intéressants en soi mais fondamentalement antinomiques.
Pour finir, le point de cette jam qui me semble faire toute la différence était la réactivité de la logistique autour des équipes. Si nous avions besoin de matériel spécifique ou si nous avions un problème technique, les équipes d’Indienova trouvaient rapidement une solution (nous pourrions notamment mentionner “l’inter”-net chinois quelque peu limité). De même, Indienova était à l’écoute si nous avions des idées originales pour promouvoir notre projet. Dans cette logique, l’équipe de Gina a eu l’intelligence de faire imprimer un poster promotionnel très esthétique (elle en parlera mieux que moi). Pour tout dire, de notre côté, même si nous avions eu l’idée, nous n’aurions jamais eu le temps tellement nous étions dans le rush.
Cette attention particulière portée aux jammeurs c’est vue aussi par la mise à disposition d’un transport aller et retour, et de très bons repas –en quantité astronomique- enlevant par la même occasion l’un des dilemmes du jammeur : se nourrir ou coder (ce dilemme étant généralement résolu par un mélange particulièrement sain de chips et de redbull). Cette organisation combinée aux sessions de travail assez courtes (pour une jam) font que la majorité des participants ont pu reprendre une vie normale après la jam sans avoir à prendre des jours entiers de repos. Un atout considérable.
Voici ce que nous avons produit durant la jam. Évidemment, c’est loin de nos attentes, mais compte tenu qu’il a fallu reprendre le code de zéro à six heures de la fin, le résultat illustre ce que nous cherchions à faire mais ne présente que le début du tutorial, mais peu de fonctionnalité de jeu (qui auraient été importantes pour illustrer Alzheimer) et encore moins l’objectif narratif. Il permet d’illustrer l’ambiance que nous cherchions à installer. J’ajouterai que j’ai corrigé quelques-uns des milliers de bugs durant le trajet en avion, c’est jouable à condition d’être clément avec les boites de collision et à ne pas chercher le bug.
Note : le jeu est intégralement en chinois pour l’instant et ne comporte pas le niveau de l’hopital ci-contre … et il restera jusqu’à la fin de mon doctorat (ce message s’adresse aux membres de mon comité qui passeraient par ici).
https://drive.google.com/open?id=1t1DPyv2tL0iYg9Y9l4VzUYAU8z09kO-o