En bref : la boîte à outils du level design est plus petite que ne le suggère internet. Il te faut un moteur pour construire, quelque chose pour blockouter, un modeleur et un outil de texturing, un moyen de scatter et de placer à l'échelle, un moyen de mesurer, et un moyen de retrouver tes assets. Tout le reste est optionnel. Cet article parcourt cette stack, à quoi sert vraiment chaque partie, quel outil choisir à chaque étape, et le test honnête pour savoir si un nouvel outil mérite une place dans ton pipeline.
Un pipeline est un échafaudage, pas de l'architecture. Les outils existent pour que l'espace soit construit : dès qu'un outil devient le but plutôt que le moyen, il te coûte plus qu'il ne donne.
Commence par le moteur, pas par la liste d'outils
Ton moteur décide de la majeure partie de ta boîte à outils, car le level design est un travail temps réel et le moteur est là où le niveau vit vraiment. Choisis le moteur d'abord (Unreal, Unity ou Godot) et laisse-le dicter le reste.
Le level design n'est pas de la modélisation avec des étapes en plus ; c'est construire un espace jouable dans un moteur de rendu temps réel. Ça fait du moteur le centre de la boîte à outils, pas une destination vers laquelle tu exportes à la fin. Unreal Engine est le défaut pour les environnements à grande échelle et les visuels de type AAA, avec l'outillage landscape, foliage et éclairage intégré le plus fort. Unity est plus léger, plus rapide à itérer, et dominant sur mobile et en production de taille moyenne. Godot est open source et de plus en plus capable, surtout pour les petites équipes qui tiennent à posséder leur stack. Aucun n'est faux ; l'erreur est de choisir une chaîne d'outils d'abord puis d'essayer de forcer un moteur à l'accepter.
Sur Unreal en particulier, les outils intégrés t'emmènent loin mais laissent deux lacunes récurrentes : placer du détail naturel à l'échelle sans traîner chaque rocher à la main, et retrouver l'asset dont tu as besoin dans une library qui a dépassé ce que le Content Browser gère confortablement. C'est pour cette lacune que [Numivo] (/features) a été construit : peindre du scatter et de la végétation qui bake en instances natives du moteur (pour que la sortie soit la chose bon marché et batchée que le GPU veut déjà), un navigateur de contenu conçu pour de très grandes libraries, et un outil de mesure dans le palier gratuit pour vérifier de vraies distances au lieu de les estimer à l'œil. Si tu travailles sous Unreal et que tu places de la nature ou domptes une grosse library d'assets, c'est l'ajout qui vaut le coup.
Blockout : construis la forme avant l'art
Blockoute in-engine avec de la géométrie simple : les outils de modélisation d'Unreal, ProBuilder dans Unity, ou de simples primitives. Le but est de tester l'espace en y jouant, alors utilise ce qui fait tenir des formes debout le plus vite.
La phase de blockout (ou greybox) est là où le niveau est réellement conçu, et elle veut les outils les plus bruts et les plus rapides que tu aies. Le mode de modélisation intégré d'Unreal et ProBuilder d'Unity te laissent tous deux pousser de la géométrie sans quitter le moteur, ce qui compte plus que la liste de fonctionnalités : rester in-engine signifie que tu peux playtester l'espace toutes les quelques minutes au lieu de faire des allers-retours vers un DCC. Garde-le gris, garde-le laid, et garde-le à l'échelle réelle : tout le travail d'un blockout est de répondre à « est-ce que cet espace fonctionne pour s'y déplacer » avant que quiconque passe une semaine à le rendre joli.
Modélisation et texturing : le côté asset
Blender (gratuit) ou Maya pour la modélisation, Substance pour le texturing, plus une library de photogrammétrie ou de scans pour les matériaux de base. C'est là que les assets individuels sont faits, pas là où les niveaux sont conçus.
Une fois que la forme fonctionne, il te faut de vrais assets. Blender est devenu le défaut pour la plupart des équipes indépendantes et de taille moyenne : gratuit, rapide, et pleinement capable pour le travail d'environnement. Maya persiste là où les pipelines de studio et l'animation l'exigent. Houdini entre en jeu quand tu as besoin de génération procédurale (kits modulaires, destruction, systèmes de rochers et de falaises) et il ne mérite sa courbe d'apprentissage raide que quand tu produis des variations en volume. Pour les surfaces, Substance Designer et Painter restent le standard, appuyés par une library de scans pour des matériaux de base crédibles. Garde ce côté du pipeline séparé dans ta tête du level design proprement dit : ces outils font des choses, le moteur les arrange.
Chaque projet devient tôt ou tard un problème de trouvabilité. L'outil qui te laisse localiser le bon asset en secondes économise plus d'heures sur une production que la plupart des plus flamboyants de ta stack.
Scatter, placement et mesure
Placer la nature à la main ne passe pas à l'échelle : utilise un outil de scatter qui bake en instances du moteur, et garde un outil de mesure à une touche de distance pour que l'échelle reste honnête.
Deux outils sans glamour décident silencieusement de la vitesse du travail d'environnement. Le premier est le scatter : forêts, herbe, champs de rochers et sous-bois sont des milliers de placements, et le faire à la main est à la fois lent et moins beau qu'une distribution peinte en densité avec une randomisation correcte. Ce qui compte techniquement est ce vers quoi le scatter bake : des meshes instanciés natifs, pour que des centaines de copies coûtent une poignée de draw calls plutôt que de noyer le CPU. Le second est la mesure : le level design tourne sur de vraies distances (largeurs de portes, écarts de saut, lignes de vue, espacement de couvert) et un outil qui te laisse cliquer deux points et obtenir un nombre transforme l'échelle d'un pari en quelque chose que tu peux vérifier. Ces deux-là sont au cœur de ce que fait Numivo dans Unreal, et les deux valent d'être dans n'importe quelle stack, quoi que tu utilises pour les construire.
Gestion d'assets : l'outil que personne ne budgétise
Passé quelques milliers d'assets, retrouver les choses devient le goulot. Un navigateur de contenu qui gère de très grandes libraries (recherche rapide, vignettes cohérentes, vrai filtrage) rachète plus de temps qu'un modeleur de plus.
Chaque projet d'environnement fait pousser une library, et chaque library finit par dépasser l'outillage qui convenait au début. Le symptôme est familier : tu sais que tu as un rocher approprié, mais le re-modéliser est plus rapide que le retrouver. C'est une pure fuite de productivité, et elle s'élargit à mesure que le projet réussit. Quoi que tu utilises, les exigences sont les mêmes : une recherche qui retourne des résultats instantanément à l'échelle, des vignettes qui rendent réellement pour que tu reconnaisses les assets visuellement, et des filtres assez tranchants pour réduire des dizaines de milliers d'éléments à la poignée que tu veux. C'est l'élément le moins excitant de la stack et souvent celui au plus haut rendement.
Chiffres de terrain à voler
- Choisis le moteur d'abord : il décide de la majeure partie de ta boîte à outils
- Blockoute in-engine, pas dans un DCC ; la vitesse de playtest bat le confort de modélisation
- Le scatter doit baker en instances natives, sinon il te coûte au runtime
- Garde un outil de mesure à une touche de distance : l'échelle à l'œil dérive
- L'outil que personne ne budgétise : la trouvabilité des assets à l'échelle de la library
Mini-FAQ
Quelle est la boîte à outils minimale viable ? Un moteur, ses outils de blockout intégrés, Blender, un outil de texturing, et une solution de scatter. C'est assez pour construire et livrer un environnement complet. Tout ce qui va au-delà devrait mériter sa place en supprimant un goulot spécifique que tu peux nommer.
Ai-je besoin de Houdini ? Seulement si tu produis du contenu procédural en volume : variations de kits modulaires, destruction, grands systèmes de terrain. Pour un seul environnement ou une petite équipe, c'est un gros investissement pour un problème que tu n'as peut-être pas encore.
Outils gratuits ou payants ? Blender et Godot prouvent que les outils gratuits sont capables en production, et la plupart des outils payants ont des paliers gratuits ou indie. Le coût est rarement le facteur décisif ; le facteur décisif est de savoir si l'outil s'accorde au moteur auquel tu t'es déjà engagé.
Comment savoir qu'un nouvel outil vaut d'être adopté ? Il devrait supprimer un goulot que tu peux nommer à voix haute : « placer la végétation prend des jours », « je ne trouve pas les assets », « je devine les distances ». Si tu ne peux pas nommer le goulot, l'outil est une distraction, aussi bonne que paraisse la démo.
Un bon outillage de level design est ennuyeux exprès : un moteur que tu connais, un moyen rapide de blockouter, une création d'assets solide, du scatter qui bake bon marché, une mesure honnête, et une library que tu peux vraiment fouiller. Réussis cette stack et les outils disparaissent à l'arrière-plan, ce qui est exactement leur place, car l'espace que tu construis est la seule chose que le joueur verra jamais.