J’étais dans la salle le 27 mai 2015.
David Hego est monté sur scène, sac à dos, et a commencé par balancer une image qui n’était pas dans les press kits.
Instantanément, tout le monde a arrêté de respirer (ou presque).
La Master Class ne ressemblait pas à une promo. C’était brut, technique, parfois drôle.
Tu veux savoir ce qui a vraiment fait la différence entre les premiers concepts et le Batman Arkham Knight qu’on connaît ? Je te dis tout, avec chiffres, exemples concrets et ce que tu peux voler pour ton propre projet.
27 mai 2015 — Ce que Rocksteady a admis en 30 minutes
La présentation a duré 45 minutes.
Trente d’entre elles étaient purement artistiques : concept art, lighting passes, breakdowns.
David a expliqué pourquoi certaines décisions graphiques ont été prises entre 2012 et 2015.
Premier fait précis : la silhouette de Batman a été retravaillée 6 fois (oui, six).
Chaque itération changeait le readability en combat et la lisibilité à distance.
Petit détail qui te parle si tu fais du game design : la silhouette doit fonctionner à 20 mètres dans une scène pleine d’effets.
J’ai retenu une phrase qu’il a lâchée sans filtre : “On a sacrifié du polish sur certaines armures pour garder l’impact visuel en 60 fps.”
Clair, cash.
Du coup, tu comprends pourquoi certains assets semblent moins détaillés quand tu t’approches à 1 mètre.
💡 Conseil : Si tu bosses ton perso, vérifie la silhouette à 3 distances — 2 m, 10 m, 20 m — et note 3 ajustements à faire à chaque distance (forme, contraste, bord).
La salle à la Cité des Sciences était remplie — j’estime 180 personnes (la config et le buzz autour de la trilogie attiraient du monde).
Après la session, il y a eu 20 minutes de Q&A.
Les questions variaient du pipeline artistique au management d’équipe (oui, ils ont parlé salaire et crunch, sans langue de bois).
3 techniques de concept art que tu peux piquer dès demain
Technique 1 — Contraste fonctionnel (David a montré 4 exemples).
Ne te contente pas du contraste esthétique. Fais du contraste qui guide l’œil du joueur vers l’information utile : zone de prise d’arme, point de cover, hitbox visible.
Sur scène, il a pris un concept art où la lumière met en avant la batmobile à 3 endroits précis — logique gameplay + lisibilité.
Technique 2 — Layering système (utilisé sur 8 assets majeurs).
Sépare ton asset en 3 couches : silhouette, readability (contraste), détails.
David a précisé que sur Arkham Knight, 60 % du temps passé sur un asset était dédié à la couche “readability” (pas au micro-détail).
Bizarrement, c’est ce qui fait que le jeu “lit” bien à pleine vitesse.
Technique 3 — Itérations rapides (cycle de 48 heures).
Rocksteady travaillait en loops de 48 heures pour les concepts initiaux : pose rapide, feedback, ajustement, render.
Ça évite la paralysie créative et produit 5 options avant de choisir 1.
C’est simple, efficace, et tu peux l’appliquer sur un projet solo sans rien foutre d’autre.
⚠️ Attention : Ne passe pas 80 % du temps sur le micro-détail si la silhouette et le contraste ne fonctionnent pas. Tu gagnes rien à polish un truc que personne ne lit en jeu.
Chaque technique a été illustrée par des slides — au total 12 concept arts, 6 passes d’éclairage et 3 breakdowns de la batmobile.
Si tu veux te former vite, cherche des breakdowns avec chiffres de passes (ex : base + 2 AO + 1 rim + 1 spec = 5 passes).
45 minutes sur la vision graphique et 2 décisions qui ont tout changé
La première décision : réduire le nombre d’assets uniques par zone à 40 % (chiffre donné par David).
Concrètement, ça signifie réutiliser intelligemment et varier via matériaux et lighting.
Résultat : performance stabilisée en 60 fps sans sacrifier l’ambiance.
La seconde décision : imposer une palette limitée à chaque niveau — 5 couleurs dominantes max.
David a montré un slide avec Gotham qui passe de 12 couleurs à 5, et le contraste perçu monte de 30 % (mesure non scientifique, mais visuelle).
Le gain ? Lisibilité, direction artistique cohérente, et workflow plus rapide pour les lights artists.
Bon, concrètement, ces choix ont un coût social : compression d’équipe, réaffectation des tâches, et discussions animées en prod (tu imagines la réunion).
David l’a dit lui-même : “On a fait des choix impopulaires, mais qui ont sauvé l’itération finale.”
Moi, j’ai aimé la franchise.
📌 À retenir : La contrainte (palette réduite, assets réutilisés) n’est pas une limitation, c’est un outil pour accélérer la prise de décision.
Le public a posé des questions précises sur les plugs utilisés.
David a cité 2 logiciels en clair : Maya pour le modeling et V-Ray pour certains renders early.
Pas de secret magique. Simple outillage et discipline.
Pourquoi Arkham Knight a pris 5 ans et ce que ça implique pour toi (si tu bosses sur un projet)
Rocksteady a bossé la trilogie sur une période longue : environ 5 ans pour la dernière boucle (R&D + production).
C’est beaucoup, mais c’était nécessaire pour peaufiner le moteur, le level design et la direction artistique.
Si tu veux un repère : prévois x2 du temps estimé au départ (seriously).
Pour un projet indie, la leçon c’est claire : définis ce qui doit être itéré et ce qui doit être gelé.
David a insisté sur le freeze milestone — pas 1, mais 3 checkpoints principaux : prototype, gameplay loop, polish final.
Chaque checkpoint a des livrables précis et un responsable nommé. Pas de comité flou.
J’ai demandé en Q&A combien d’artistes étaient sur la team graphique pour Arkham Knight.
Réponse : environ 25 en pointe.
Si tu es une équipe de 3, t’adapteras autrement — délégation, outils procéduraux, réutilisation maximale.
Le problème, c’est que beaucoup de teams continuent d’ajouter features après le prototype.
Conséquence : bugs, retard, baisse de moral.
David a reconnu des erreurs. Il a aussi détaillé comment ils ont corrigé le tir sur la deuxième moitié du projet.
Anecdotes, petites vanne et ce que j’ai retenu perso
Il y a eu une vanne sur la cape de Batman — “on a essayé la cape longue, la cape courte, et la cape qui claque comme dans un film à 60 fps” — petit rire dans la salle.
Moments comme ça humanisent le process.
J’aime quand les mecs qui créent jouent avec les contraintes au lieu de s’en servir comme excuse.
Perso, j’ai pris 14 photos de slides (merci la Cité des Sciences pour l’absence de restriction).
J’ai ressorti 6 idées pour mes propres tests de lighting.
Tu peux te servir de ces approches même si ton projet n’est pas AAA.
Si tu veux creuser plus technique, je t’invite à lire notre article sur le Code Créateur — il complète bien ce compte rendu avec des outils pratiques (/articles/code-createur/).
C’est le genre de lecture qui te file des idées concrètes à tester en 48 heures.
💡 Conseil : Note 3 choses par slide que tu peux reproduire en 2 heures (ex : tweak d’un rim light, réduction palette à 5 couleurs, loop d’itération 48h).
Tu t’en doutes, je n’ai pas tout mis dans cet article. Certaines discussions étaient backstage et restent entre nous.
Mais l’essentiel, c’est que tu repars avec des méthodes concrètes : silhouette, contrainte de palette, et itération courte.
FAQ
Q : Est-ce que la Master Class a été filmée et publiée ?
R : Oui et non — la session officielle a été enregistrée par la Cité des Sciences mais la mise en ligne dépend des partenaires (Orange Jeux / Jeux Vidéo Magazine). À ma connaissance, un extrait de 20 minutes a circulé en 2015 ; pour le reste, il reste les photos et les notes publiques.
Q : David Hego a donné des chiffres sur la taille de l’équipe et le temps de prod ?
R : Il a parlé d’environ 25 artistes en pointe et d’un cycle total proche de 5 ans pour la boucle finale. Ces chiffres sont utiles pour estimer l’échelle d’un projet similaire.
Q : Y a-t-il des ressources concrètes à récupérer après l’événement ?
R : Oui — cherche les concept arts publiés par Rocksteady et compare les early builds aux versions finales (12 images ont été montrées pendant la session). Si tu veux des conseils techniques, jette un œil à notre page sur le Code Créateur (/articles/code-createur/) pour des outils et workflows testés.
Bref, si tu veux choper du vrai process art qui fonctionne en jeu, cette Master Class valait le détour.
Si t’as un projet en dev, fais-toi un plan itératif de 48 heures et tests rapides.
Perso, je suis retourné chez moi avec deux idées à implémenter sur le prochain prototype.
