Déjà 5 ans que le bootcamp Level Design s’invite à la GDC de San Francisco. Vous connaissez désormais la chanson, c’est l’heure du récap !
Game Developers Conference
Déjà 5 ans que le bootcamp Level Design s’invite à la GDC de San Francisco. Vous connaissez désormais la chanson, c’est l’heure du récap !
Et c’est parti pour un récap de la quatrième édition du level design in a day, qui autant le dire tout de suite, a été plus décevante que les précédentes.
Sur World of Level Design vous trouverez un transcript de la session Questions & Réponses de l’atelier Level Design in a Day réalisé par mes soins. Beaucoup de sujets sont abordés, de la conception à la réalisation en passant par le contenu d’un bon portfolio… Très intéressant pour les étudiants, un peu moins pour les designers un peu plus aguerris. Bonne lecture !
Petit compte rendu des conférences que j’ai vues à San Francisco le mois dernier. Une grande majorité d’entre elles est orientée technique, vous êtes donc prévenus ! A noter également que la plupart des vidéos sont hébergées sur le GDC Vault, ce qui veut dire qu’elles sont…payantes. Ca craint je sais, mais une majorité des slides sont dans la section gratuite, ce qui devrait compenser.
C’est établi, la conférence sur le Level Design de San Francisco fera désormais son apparition chaque année pour la GDC (voir aussi les compte-rendus des éditions 2011 et 2010), la grand-messe des développeurs de jeux respectables, noyés au milieu des businessmen pitchant leur énième jeu pay-to-win à l’envi. Le principe n’a pas changé, une journée complète de présentations consacrées aux problématiques rencontrées par les Level Designers de tout bord, saupoudrée de quelques nouveautés pour cette édition 2012.
« And basically what he goes on to say is that he wished that early on in his career, someone had told him that you gonna fail. You gonna fail often, you gonna fail a lot but that’s OK, because you’re supposed to fail, and if you don’t fail you’re not going to learn, you’re not going to evolve, and you’re not gonna get better. » Jim Brown
Il y a eu pas mal de conférences vraiment folles a la GDC cette année. Je pense notamment à celle du pipeline des persos sur Brink (les mecs ont vraiment un skill de psychopathe) ainsi que celle dont je vais vous parler aujourd’hui. Cet article est un peu particulier, dans le sens où il ne risque d’intéresser qu’un nombre restreint de personnes (des level designers, travaillant chez EA, lisant mon blog ? mmmh), mais qu’importe !
Devant le succès du tutorial l’année dernière (lire cet article), l’équipage du LD in a Day a décidé de remettre le couvert pour les 25 ans de la GDC, le mois dernier. Le principe, une journée complète de conférences sur le level design par les ténors du secteur. Cramponnez-vous au clavier, ce qui suit est hautement calorique !
« At the end of the day, I don’t want to be remembered for my name. I don’t want my name to be a household name, but I want my games and my levels to be. If I’m remembered at all, I certainly don’t want it to be because of my name; I want to be remembered because I did my job well, or, in the scheme of things, I want NOT to be remembered because I did my job SO well and my hope is that you and everybody who are my peers understand what it means, to be a level designer. » Jim Brown
Cette année j’ai eu le privilège de partir à San Francisco pour la GDC. Ca tombe bien puisque mercredi 10 j’ai eu droit à une conférence d’une journée complète sur le level design.
Et pas n’importe laquelle: une belle brochette de level designers respectés en assurait le déroulement. On y trouve notamment Ed Byrne, l’auteur de Game Level Design; Neil Alphonso, lead LD de Killzone 2 et de Brink; Joel Burgess, lead LD de Fallout 3; Matthias Worch, Senior LD sur Dead Space 2; Jim Brown, lead LD de Gears of War 1 et 2, ainsi que Coray Seifert, Game Designer et Forrest Dowling, Lead LD multijoueur, tous deux chez Kaos Studios.
Autant dire que j’attendais cette conférence avec impatience. Et je n’ai pas été déçu, puisque globalement elle fut à la hauteur de mes espérances. En voilà un résumé.
C’est Coray qui démarre la session, en effectuant plusieurs sondages auprès de l’assistance. Qui sommes nous ? Pas mal d’étudiants, de chômeurs, la plupart sont des LDs. Quelques GD, quelques programmeurs, quelques artistes. Depuis combien de temps on bosse. La majorité depuis au moins un an. Un seul type a plus de 15 ans d’expérience (respect !). Pour qui on bosse. La plupart pour des éditeurs classiques. Une bonne portion est indépendante.
Ed Byrne prend la suite. Il est lead LD chez Zipper interactive (MAG, SOCOM 4), et il est dans le milieu depuis 13 ans ! Il parle de tout le processus de pré-production en level design, c’est à dire comment partir du concept jusqu’à la « manufacture » pour tous les niveaux d’un jeu. Sans rentrer dans les détails (mes notes franglaises dégueulasses sont disponibles à la fin de l’article), c’était extrêmement intéressant, même s’il faut tout de même réussir à convaincre sa hiérarchie d’instaurer un réel processus dédié à la préproduction en level design. Bon après, ça dépend du poids qu’on a dans sa boite. Dans des structures modestes ça passe plus facilement.
C’est au tour de Matthias Worch, de Visceral Games (Dead Space 2) de prendre la parole. Il parle de la création des espaces de jeu et du « level flow ». C’était globalement en dessous de la première conférence, malgré un début pas trop mal sur la façon dont l’environnement est au service du gameplay dans Bioshock. Mais le reste de sa présentation était trop superficielle par rapport aux nombreux thèmes qu’il voulait aborder. Du coup il ne faisait que survoler ou répéter ce qui avait été dit l’heure d’avant. Ceci dit, une autre conférence sur la narration environnementale était prévue le lendemain. Sauf qu’elle était pleine à craquer et que je n’ai pas pu y assister 🙁 Heureusement les slides de sa présentation sont disponibles (voir plus bas) !
Après la pause déjeuner, c’est Jim Brown d’Epic Games qui nous raconte comment les outils peuvent sauver la vie d’un level designer. Selon lui, les outils vont vous permettre de faire de meilleurs jeux, grâce au temps que vous aller gagner. Même si le gain n’est pas aussi signifiant. Il prend en exemple un outil lambda qui permet à une personne de gagner 2 minutes 40 par jour. Si on multiplie cette valeur par le nombre de gens qui vont l’utiliser (ici, une centaine), ça fait gagner à l’équipe 4 heures par jour, soit 20 heures par semaine. Si on étend cela à 1 an, ça fait gagner 6 mois !! Qu’est ce que vous êtes capable de faire avec 6 mois en rab ? Pas mal de choses 🙂 Chez Epic, ils l’ont compris et à chaque fin de projet ils font un bilan sur les outils parmis les responsables et les autres membres clés de l’équipe (une douzaine de personnes au total).
Jim fait ensuite un bilan des outils utilisés par l’Unreal Engine: le BSP, qui permet de prototyper/whiteboxer sans prise de tête et sans avoir besoin d’un programmeur; le Generic Browser, qui permet de rester organisé parmi les dizaines de milliers d’assets graphiques, son, anims, …; la prévisualisations en temps réel, on a le résultat de ce que l’on fait directement dans les viewports; Lightmass (leur moteur de GI), qui permet d’éviter de se prendre la tête à poser des contre-lumières pour simuler la radiosité; Kismet (script nodal) qui permet aux designers de prototyper. (Tous les protos chez Epic sont faits en kismet).
Jim conclut en disant que si on maîtrise un outil, il ne faut pas hésiter à évangéliser ce qu’on a appris à son équipe. C’est grâce à cela que l’on gagne du temps. Partagez votre savoir nom de dieu ! Et surtout allez vois vos pairs qui maitrisent d’autres tools et APPRENEZ. Vous n’en sortirez que meilleurs.
Dernier truc intéressant chez Epic, leurs Free Fridays. Tous les vendredis suivant la livraison d’une milestone, les employés sont libres de prototyper ce qu’ils veulent. Grâce à cela ils ont pu ajouter des ennemis dans Gears 2 qui n’étaient pas prévu dans le design à l’origine.
Neil Alphonso, le lead LD de Splash Damage (Brink) prend la parole. Il a également été lead LD sur Killzone 2. Sa conférence est sur l’équilibrage des maps multijoueurs et sur le placement de covers. Les 3 choses à retenir pour de l’équilibrage sont les temps de parcours, les lignes de vue et les distances de combat. Il a également fait l’apologie des caisses (!!!). En effet, les metrics (c’est à dire toutes les variables du joueur – taille debout, accroupi, allongé…-) changent constamment durant la prod. Les caisses sont parfaites pour s’adapter aux metrics, et c’est pour ça que de nombreux jeux en abusent. Quant au placement des covers, il a été assez évasif sur le sujet. C’est dommage, j’en attendais clairement plus. Il a également fait un post-mortem assez critique sur ETQW. Notamment sur la map The Ark. Le jeu était trop compliqué à cause de ces milliards de rewards à appréhender.
Ensuite, c’est le lead designer de Kaos Studios (Desert Combat, BF2, Frontlines: Fuel of War), Forest Downling, qui parle des pipelines et des workflow. Ce qui était intéressant c’est leur façon d’être parti d’une petite équipe de modmakers (12 personnes) et d’avoir monté un studio où travaillent désormais plus de 80 développeurs. Pour le reste c’était du classique. Lisez les notes en bas pour en savoir plus. Forest passe ensuite la parole à Joel Burgess, le lead LD de Bethesda sur Fallout 3. Et il nous a appris des choses assez effarantes. Par exemple sur Oblivion, ils étaient 5 artistes et 3 LDs, pour faire 255 donjons ! Du coup ils se sont organisés pour faire tomber les niveaux le plus vite possible. Leur rythme de croisière était de 15 donjons terminés par semaines ! Ils ont fait énormément de réutilisation. Sur Fallout 3, il y avait 148 « niveaux LD ». Cette fois ils étaient 6 LDs et 4 artistes. Beaucoup de collaboration pour mener le projet à son terme, et surtout l’ajout d’une 2ème couche de polish pour solidifier le tout.
Pour finir la journée, Joel va parler de la narration environnementale. En tant que LD, on peut conduire le joueur et lui distiller des informations sur la richesse des mondes qu’il va parcourir. Utiliser du texte n’est pas la solution ultime alors que l’on peut faire passer davantage de choses visuellement. Le mot d’ordre : brieveté et qualité du contenu ! “vigorous writing is concise” (William Strunk Jr). Il a pris comme exemples Bioshock (un cas d’école) et les safe rooms de Left 4 Dead. L’idée est que nous avons à disposition énormément de techniques visuelles de narration (architecture des niveaux et des bâtiments, éclairage, comportement des IA, les particules et autres FX, …). L’idée est de se baser sur la cognition du joueur (qu’il appelle Gestalt) pour faire en sorte que le joueur rassemble les pièces du puzzle narratif par lui-même.
Références :
Monter un « bon » pipeline LD n’est pas chose facile, encore moins dès qu’il s’agit de trouver des matériaux de référence sur Internet. Pour mémoire, un pipeline sert à identifier les différentes étapes de production (plan 2D, BSP, optim, …) et les acteurs qui vont interagir avec (LDs, Graphistes, QA, …).
Heureusement, depuis quelques temps, 2 vidéos ont fait leur apparition sur la toile et facilitent grandement la tâche. J’en profite pour vous les faire partager: leur visionnage est assez instructif, même si l’on se fout de la façon dont on fabrique des jeux vidéo 🙂
La vidéo est disponible dans une résolution respectable. (Sur le GDC Vault, accès payant) | On peut aussi télécharger le Powerpoint 2007 (.pptx)
Voir la vidéo. – lien mort désolé – (Le stream a l’air assez capricieux, et je n’ai pas réussi à récupérer la vidéo pour la mettre sur un serveur plus costaud. Si quelqu’un connait une manip’, qu’il me fasse signe 🙂 – EDIT : Merci Revanger !
Pour ceux qui cherchent à rentrer dans l’industrie du jeu, il y a pas mal de conseils pertinents sur la façon de réussir un entretien à la fin de son speech. Evidemment, tout n’est pas à prendre pour argent comptant. On peut dire que chaque production dispose de son propre pipeline, défini en fonction de besoins précis et parfois uniques. Il est par exemple rigolo de constater qu’aucune des présentations ne mentionne les retours de playtests comme un élément faisant partie intégrante du processus (cf Valve et la façon dont ils bossent en itératif).
On peut toutefois dégager les grands axes :
Ca a l’air simple hein ?