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 première nous vient de la Game Developer Conference qui a eu lieu en mars dernier. Deux types de Bioware expliquent en détails le processus de conception de maps pour Mass Effect 2. Mass Effect, c’est un jeu énormément conduit par la narration, et c’est en toute logique qu’ils démarrent la production de leurs niveaux avec un bout de scénario qui va agir comme fil rouge jusqu’à la version finale de la map concernée. On retrouve toutefois des étapes classiques, habilement masquées sous d’autres noms.
La seconde provient du Game Developer eXchange, prise en février 2009. C’est Andrew Bains d’Epic qui s’y colle et détaille les étapes de construction d’un niveau. Ca reste classique mais c’est toujours bon d’avoir un avis extérieur sur ce sujet.
Le processus LD pour Gears of War 2
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 :
Vue d’ensemble : plan 2D, visuels de réference
Shelling / Whiteboxing : proto en BSP ou équivalent
Alpha : truc un peu moins dégueu où le gameplay ressemble à quelque chose
Beta : truc propre où le gameplay et les visuels sont quasi-terminés
Polish : polissage du gameplay et des visuels, derniers réglages.
La guerre est déclarée sur Mapcore, un forum composé de nombreux Level Designers et Level Artists professionnels à propos le l’obsolescence du format BSP, notamment sous Unreal. Le débat vire rapidement sur les méthodes de prototypage. Morceaux choisis :
by Pericolos0 (GRIN Suède) on Tue Mar 17, 2009 8:12 pm
you guys are still using bsp???? lmao
Proto BSP avec quelques meshes
Etant moi-même un inconditionnel du BSP, en phase de prototypage, ça m’intrigue, d’autant plus que 2d-chris (CrytekFrancfort) semble abonder dans ce sens :
by 2d-chris on Tue Mar 17, 2009 8:38 pm
but yes peris, we’re not artists remember, we need to prototype levels before making it look good~! it’s a darn sight quicker doing it in a bsp editor than max.maya and importing all the time.
by Steppenwolf (GRIN Suède) on Wed Mar 18, 2009 11:23 am
Why do you think so? I really see no advantage that bsp has these days. Maybe a bit more control and freedom for the level designer but thats something that gets lost anyway with the job becoming more and more specialized. Visualy it doesn’t make a difference on what your engine is based as long as the renderer, art assets and everything is top notch. The main difference is in the workflow and in that regard bsp is just a painfull thing from the past.
Oui, on sait bien que tout la géométrie va être remplacée par des meshes au final, mais malgré tout on continue à prototyper en BSP, même si c’est vieux. Amusant tout de même de constater que deux collègues de chez GRIN ne sont pas d’accord. Peris intervient et marque des points :
by Pericolos0 on Wed Mar 18, 2009 11:38 am
no it’s not, its an ancient, extremly slow and limiting workflow for modelling your level geometry. You guys just don’t want to learn how to model. Learn how to model some simple modular geometry and your whiteboxing will be way faster and free. You could even do it in sketchup. Modelling is easier than working with brushes!
also bsp is just really expensive to render with all its material swithces and whatnot. Batched modular geometry is where its at now. Bsp is dead i tell you!!
Mmh, BSP contre géométrie modulaire, ça commence à devenir intéressant. Je n’arrive pas à voir comment produire et importer des modèles 3D pourraient accélérer le processus de prototypage. Robert Briscoe reste sceptique:
by robert.briscoe (DICE Suède) on Wed Mar 18, 2009 11:43 am
I strongly disagree, I have years of 3d modelling experience and if you are blocking out and prototyping a level there is a high amount of iteration and testing and bsp is the most durable, fast and efficient method of doing this. Going back and forth between two programs and reimporting etc is not good workflow.
by Pericolos0 on Wed Mar 18, 2009 11:55 am
Well having to compile a level and then start up the game to play it is not a good workflow either imo. Working in unreal editor with max open next to it to work on the geometry of your meshes works pretty well i think, importing and exporting takes just a few clicks, and you’ll be doing most of the actual leveldesign work in unrealed anyway, moving around modular meshes. I’ve felt alot more free and capable doing leveldesign once i stopped using brushes. And yes you’ll be doing iterations on the geometry, but changing around geometry is way faster in a modelling program than changing around brushes, so the extra 5 seconds it takes for importing/exporting is no problem at all really, you can set up a really good workflow for this if your editor has good asset management. Like unreal’s unit browser or cryengine which will export it straight from max into the editor basically.
Pas mal d’avantages en effet sur l’utilisation de la géométrie modulaire, car en effet, construire des blocs de meshes qui tilent et qui snappent permet de les agencer comme on le souhaite, sans avoir à rebuilder la géométrie. Par contre, il ne parle pas des collisions, le sujet fâche peut-être 🙂 J’ai quelques doutes sur le fait que compiler la géométrie et lancer le jeu ne soit pas un bon workflow; après tout c’est un processus obligatoire il me semble.
by Hourences (Starbreeze, Suède) on Wed Mar 18, 2009 12:18 pm
Modeling a mock up IS easier, but as said, export importing etc is indeed not exactly very fun. I rather rebuild/compile BSP than exporting importing meshes all the time really.
So for me the way to go would be an engine that can read for example .max files, and auto reload that file as soon as it is modified. That way you can just do ctrl s in Max, and your changed floorplan shows up in the game. Unity does this I believe, and I believe this is the next big thing for tools to do really. It is a shame Unreal, however simple its importing process is, doesn’t allow you to speed up that process even more.
Hourences va un peu plus loin et pointe les manquements des moteurs actuels à ne pas faciliter le réimport des modifications effectuées sur un modèle 3D. Sous Unreal, le système de packages est un peu lourdeau et force de nombreux réimports au fur et à mesure que l’on itère sur son mesh. Je me demande si d’autres moteurs qu’Unity proposent ce genre de fonctionnalité.
by Steppenwolf on Wed Mar 18, 2009 12:26 pm
What you discuss now is really more of concern for the artists. In Diesel engine i don’t necessarely have to switch around modeling program and level editor as a level designer. We have like a set of legos (different sized and shaped models) that we use for doing the map layouts. This works _a lot_ faster then doing the map layouts with brushes.
And i would estimate that if all art assets are provided i can create a whole map in like 10-20% of the time that a similarly detailed map would take me in Source or Radiant.
Vu comme ça, il est évident que ça fonctionne. Utiliser un set de briques modulaires gabarisées comme des Legos rend la création d’un layout très rapide. Et surtout facilite la vie des graphistes derrière. Mais est-ce que ça marche pour tous les types de jeux ?
by Pericolos0 on Wed Mar 18, 2009 12:35 pm
That would be a nice feature, but making your entire floorplan in max is a really bad idea imo and not at all what im talking about =). My workflow now is more like: making a bunch of simple modular meshes, constructing a crude level out of them, and then iteration, adding extra meshes where i need them and iterating on the geometry of my modular set. The nice thing is your working on just a few pieces of instanced geometry that you reference to for your entire level. This makes the process of detailing and iterating on your level so much faster than compared to a level uniquely made out of brushes.
Really dont understand why you rather rebuild BSP than import a simple mesh though, its really a very easy process in unreal, not ideal, it could be a few clicks less, but very very easy and fast.
by Hourences on Wed Mar 18, 2009 12:55 pm Using modular content is not modeling. Well it was made through modeling of course, but if you say « model a mock up » that for me means doing what you would have done with brushes, but in a modeling package. Using existing modular meshes is more like a third way of building a mock up/real level. Could work as well of course.
I dont see why modeling an entire floorplan is such a bad idea. Plenty of studios do this. It would basically work the same as using BSP in combination with some meshes. There are certainly some cons to this approach, just like there are also some cons to using just modular bits and pieces everywhere. Kind of depends on the situation really. Indoor basement level vs large open landscape for example.
Nous y voilà. Au fur et à mesure, les deux méthodes prouvent leur avantages, le type de jeu ciblé va probablement permettre de les départager.
by 2d-chris on Wed Mar 18, 2009 2:14 pm
I don’t think anyone suggested that BSP is still alive from an artistic or even performance point of view. The only real advtange of using solids for game development is for fast prototypes of layouts, scales and player leading.
[…] Yes you CAN use max/maya for rough layouts, but i’d rather have the option to adjust everything in seconds than have to fart around in a 3d program. I’ve had experience making everything in maya and exporting to Unreal, it’s not a bad approach but defintely slower. it depends on what stage of a project you are working on, how much your expected to change a layout and when you consider a whitebox ready for an art pass.
Just when you consider the game engine and pipeline to be so important, take a look at Valve … the ability to change a layout drastically AFTER an art pass is done undoubtably helps them create some of the best games in the industry.
Effectivement, Valve possède sa manière de monter les niveaux, même si leur façon de prototyper a été décrite en détails par Dario Casali dans ce post sur tf2maps.net et ne diffère pas énormément du prototypage par BSP. La faute aux outils archaïques fournis avec le moteur. Seul avantage de Source ? Probablement les textures gabarisées collées sur les BSP (Les Orange Boxes). Mais c’est inapplicable à des meshes qui ont leur propres UVs.
by Steppenwolf on Wed Mar 18, 2009 2:50 pm
Chris, as i already wrote for Diesel we use a set of lego like models for the rough layout. That is way faster then brushing because we will just overlap and wildly angle stuff to get the shapes that we want. It doesnt matter at this stage because it will be replaced anyway. And there is no fear that something could break the map or hurt performance like this would be the case for bad brushwork.
This is a really bad example because this is exactly where i feel that source is way behind. You have to fix so many tiny things afterwards alone to make the map compilable again. I did some serious layout changes for bionic commando within a couple of hours. When i was on Insurgency stuff like this always took 1-2 days to fix and was a real pain in the ass to do.
by Minotauro (Ubisoft Sao Paulo) on March 18th, 2009, 2:07 pm
It all really depends on beforehand planning imo. Both methods have their cons and pros but if you don´t have a big picture of what you want before you start you will have definitely troubles, with both approaches. You can´t model with a BSP mentality and the other way around is also true. It´s just a matter of getting used and learning the shortcuts. A few years ago the idea of making an entire level in max scared the shit out of me, but I can see it completely doable now. It would be perfect if it had an a-la Hammer texturing tool. Adding UVW map modifier to each piece is a real pain in the butt. Oh and a decent texture browser would also be neat.
I really like Grin´s solution to prototyping levels, maybe I´ll try that myself next and build a non-bsp level in Unreal 3.
by Pericolos0 on March 18th, 2009, 1:58 pm
again, im not saying to create an entire layout in max or maya, I also think thats a very bad workflow. I’m suggesting using modular meshes to create your layouts with. Quick pieces of geometry you block out in a modelling program and place as if they were brushes. This way it also takes seconds to move around stuff in your editor, except your not working with blocks but nicely defined pieces of geometry that can be made into good artwork. No flat surfaces everywhere with tiling textures but an organised set of instanced geometry. Nicely defined pieces of geometry you can give to an artist. This is where level design is inevitably heading, and alot of companies are working this way. But yeah you guys can be the dinosaurs of game development and keep using brushes, sorry to sound like hessi here .
Anyway i’m just saying i really believe this is a way more efficient way of creating levels, and you should really try it more, good recent example i’ve seen on mapcore was nurb’s unreal3 level in the wip thread.
by Pericolos0 on March 18th, 2009, 2:11 pm 2d-chris wrote:
There are tons of ways you can make levels, but suggesting that BSP (solids) is a dated and doomed method is not really correct, if you keep it in perspective of what it’s used for
yeah making 90 degree corner hallways and rooms. You could be making so much more interesting stuff!
Il n’a pas tort. On est souvent limité à la grille et du coup on se retrouve à faire des morceaux de BSP orientés à 0, 45 ou 90°, et l’utilisation de modules de meshes permet effectivement de se retrouver avec des morceaux de géométrie mieux foutus que s’ils avaient été faits avec du BSP. Ah putain ils sont en train de me convaincre !
by Hourences on March 18th, 2009, 4:04 pm
So Peris, exactly how would you build a large open landscape with a large surrounding mountain ring a la demon army camp in Spellborn Chronicles with using just modular pieces and lets say you had no actual unreal terrain available to make the floor with? Sure it is doable, but would it be that much easier/nicer in that specific situation? I dont think so really.
Thats where modeling the entire thing comes in, even when it is only just a mock up. Now the details on top would be modular of course.
The same thing can be extrapolated to small indoor levels. And that is what Unreal does, and has been doing for 6 years now. Unique shells, with modular details. Instead of all modular.
If you go all modular, you get a game like Oblivion or Fallout, and it is cool, but it does look less defined sometimes.
The bottom line is that it is not just black and white. This sucks, that rules. This depends on the specific game, the specific needs, the skills of the artists and designers, the budget, the time, etc. A game like Fallout benefits from it as they need this approach to save time since the game is so huge. A game like Spellborn benefits from it because it is lower budget and a small team, thus you need to speed it up as much as possible. A big budget title however does not neccy require this. They can take the time to get a higher level of quality going, and that is good. Killzone for example was built like this, even its mockups. And I am not saying that is the best game ever, or that they had a very speedy production, but if you have the budget and money for it is not neccy a bad thing.
Shades of grey… Hourences pointe à juste titre les spécificités des différents jeux, qui peuvent très bien être open space à la Crysis ou bien très confinés. Du coup une méthode pourrait être plus adaptée qu’une autre, en prenant également en compte les impératifs de production (prototyper reste un luxe de nos jours, et les outils sont bien souvent merdiques à ce niveau). Il s’agit donc de bien identifier le type de lieu qui sera représenté dans votre niveau et de choisir la méthode de prototypage adéquate.
by Pericolos0 on March 18th, 2009, 6:24 pm That demon army camp is a fun example because i think in retrospect i would have done it different. Not having terrain editing would be annoying in that example since the level is basically a big terrain, but for the rocks i would have made just a set of rock faces that i’d place around everywhere the player can get close to. Like 4-5 different large pieces, then i could make them pretty detailed and good looking and just place them around in the editor, I’t wouldnt look all lowpoly and tiling like it is now, and it would be a lot less work than uniquely modelling and unwrapping the entire thing. We did it like this in bionic commando: http://www.bioniccommando.com/img/site/ … ghtbox.jpg I could build the terrain out of modular terrain patches too if terrain editing was really out of the question =). Like 4-5 different terrain meshes just placed everywhere mashed inside each other, the use some vegetation or decals to cover up the seams. All of this could be LODed, instanced, would occlude away nicely, so it would end up looking more detailed while still being very cheap to render.
Of course you shouldn’t use modular stuff for everything, you could make unique geometry for some special areas or whatever. It’s just a way of organizing your workflow and a very efficient way of making stuff detailed in a short ammount of time. And if you are good at making good modular meshes that can be used in various ways, you can really achieve big budget looks!
Intéressant. Méthode un peu crade (empiler les meshes les uns au dessus des autres et masquer les transitions avec du foliage), mais qui a le mérite de proposer une autre solution au même problème.
Pour conclure, parce que j’ai été un peu long. Il n’y a pas de méthodo absolue et divine. Ca dépend d’un certain nombre de facteurs (qualité du moteur, des outils, temps de prod, ressources humaines), mais ce qui semble émerger est l’utilisation conjointe de modules modélisés à l’aide d’un éditeur polygonal et de BSP (ou approchant).
Le but à atteindre :
Faciliter la vie des graphistes enviro qui vont habiller votre map : avoir des pièces gabarisées, qui snappent sur la grille, de taille en puissance de 2
Faciliter la vie des level designers, qui vont assembler ces pièces comme des Legos, et itérer le plus aisément possible sur leur map.
Du coup, on a accès à l’éditeur et également à la façon dont l’équipe de DICE s’y est prise, pour monter leurs niveaux. C’est l’occasion de voir des choses complètement aberrantes comme le fait de quasiement tout avoir balancé dans le Persistent et de gérer le stream via des scripts kismet, mais aussi des choses assez intelligentes comme une gestion de préfabs bien foutue et un système de navpoints upgradé permettant aux hélicos de se comporter ‘normalement’ dans les airs.
Une vue familière
Par contre, il n’y a pas eu énormément de développement niveau ergonomie de l’éditeur,et du coup les LDs de DICE ont du un peu galérer. Difficile de distinguer une map normale de sa version Time Trial par exemple. La plupart des éléments custom se retrouvent en Kismet, il n’y a pas des masses de nouveaux actors.
On se rend compte également des contraintes de prod, notamment avec le système de collisions un peu foireux qui les à conduit à remplacer les coll créées dans Max par de simple Blocking Volumes afin d’économiser en mémoire sur console (chose que l’on a nous aussi vécue en interne).
Si vous voulez vous amuser avec, gardez à l’idée que les maps sont assez lourdes (entre 900 et 1,2Go de RAM prise et près de 2Go de SWAP). Les systèmes 32bits crasheront donc plus souvent. Les forums de On Mirror’s Edge sont bourrés de tips, servez-vous en 🙂
Nofrag en a parlé il y a quelques temps, et c’est passé relativement inaperçu, mais Valve semble avoir compris comment mettre la tech au service du game design, et de ce fait possèdent une avance non négligeable sur le reste de l’industrie du jeu vidéo. Pas moins.
Gabe Newell a posté sur la version électronique du magazine britannique Edge un compte-rendu sur les rouages internes de Left 4 Dead et notamment sur les mystères de son AI Director, une entité permettant de changer le contenu du jeu en temps réel. Pour faire simple, l’AI Director agit à la fois sur la narration, la difficulté et le rythme.
Collection de données
On sait que par le passé Valve utilisait un outil interne de tracking afin de déterminer où les joueurs mourraient dans leur jeu. Une fois la collecte de statistiques effectuée, des deathmaps sont générées et permettent de régler la difficulté du jeu post-playtests et également post-release. Cet outil est là depuis Half-life 2.
Des améliorations y ont ensuite été apportées pour Episode 1 et Episode 2, en ajoutant les taux de réussite map après map, les temps de jeu, etc.
Au final, l’outil est réparti sur les paramètres suivants :
– Le Completion Time : le temps moyen pour finir une map
– Le Total Play Time : le temps moyen de jeu à date
– La Highest Played Map : la map la plus populaire
– L’Average Deaths : combien de fois meurt-on par map
– Les Deaths Maps : un plan de la map vu de haut avec des couleurs représentant les zones où l’on meurt le plus souvent
Pour Left 4 Dead, qu’ont-ils ajouté ?
En partant du postulat qu’aucune partie ne devrait ressembler à une autre, il leur fallait 2 choses que le multiplayer n’offrait pas à l’heure actuelle :
– La narration dynamique, capable d’endurer plusieurs revisites sans bouffer les mêmes lignes de dialogue
– L’adaptation du rythme, afin de ne pas rencontrer les mêmes ennemis toujours au même endroit
Les grands principes de l’adaptation de la difficulté sont déjà connus, il ne reste qu’à s’assurer qu’elle ne soit pas trop basse ou trop élevée.
Il s’agit de collecter de nouveaux paramètres.
Quels sont les paramètres d’entrée de l’AI Director ?
Pour que le jeu adapte la difficulté et le rythme en fonction du joueur, il lui faut des paramètres d’entrée.
We tried to note as many interesting contexts of their actions as possible. Are they moving together as a group or are they splitting up? Is their mouse jerking around a lot, or are they interacting smoothly? Are they agitated or are they relaxed? How much damage are they taking? How accurate is their shooting? – Gabe Newell
D’où :
– La position dans l’espace des survivants
– Les mouvements de la souris (fluides ou hachés)
– La posture des survivants (marche, accroupi ou course)
– Le chemin parcouru (plus il est grand plus le survivant concerné peut être qualifié d’explorateur)
– L’état de santé, les munitions etc
et d’autres choses plus subtiles :
– Le nombre de fois où le joueur a été incapacité
– etc etc
Certains de ces chiffres semble familiers : ils apparaissent en effet lorsque l’on fini une campagne. D’autres sont directement liés à des achievements.
A partir de là, il s’agit de dresser le profil des joueur en temps réel. Le joueur peut être qualifié de confiant, stressé, prudent, débordé, ou bien au bord de la mort à partir des paramètres d’entrée.
La narration quant à elle, dépend directement du rythme. Le jeu cherche à trouver des temps de pause où le rythme tombe pour lancer les répliques des survivants.
La difficulté puise directement dans les outils initiaux de Valve. On regarde esentiellement le nombre de morts et l’endroit où l’on meurt, et l’on ajuste les spawns d’IA en conséquence.
Quels sont les outputs de l’AI Director ?
Les données sont collectées et analysées en temps réel, tous les profils sont dressés, et désormais, il s’agit de regarder dans la base de donnée quel genre de réponse prédéfinie on veut donner au joueur.
Ce groupe-ce est éclaté ? Les 4 survivants avancent moyennement, mais n’ont plus beaucoup de vie ? : on fait spawer un Smoker. Ce groupe-là au contraire est soudé, avec une bonne précision au tir ? Prenez un tank dans la gueule.
Même chose pour la narration. En fonction du temps estimé (ex: un des survivants se heale, ou bien sont dans la spawn room, ou bien entre 2 hordes) ou du stimuli envoyé par la proximité de zombies spéciaux, l’AI Director défini un budget temps probable, et regarde dans sa base de données pour voir si une réplique correspond à ce budget temps. Si oui, la ou les répliques sont lancées.
Pourquoi Valve est-il loin devant ?
Les mises à jour du jeu sont facile à faire : le plus dur était de dresser les profils pour le rythme, et de définir le temps pour la narration. Il ne s’agit plus que de remplir davantage les bases de données de réponses pour offrir un jeu plus riche offrant une variété de situations de jeu incomparables.
De plus, Valve a une autonomie que peu de studios et d’éditeurs peuvent se targuer d’avoir. Leur politique met la R&D au centre de la conception des jeux avec une seule contrainte : la tech doit être au service du gameplay.
Question subsidiaire : est-ce que l’on tue le level designer ?
Réponse subsidiare : partiellement. Le travail du LD consistait auparavant à poser à la main les monstres et les kits de soins. Désormais, son rôle va davantage être orienté sur la création du fichier de réponses dans la base de données (et ouais, ce sont des situations de jeu), sur la circulation du jeu et s’intéresser davantage aux problématiques architecturales (= comment j’ammène le joueur à cet endroit sans qu’il s’en rende compte).
EDIT: comparaison avec la concurrence oui, mais avec de meilleurs exemples + ajout de qqs paramètres en entrée en exemple + un mot sur la difficulté dynamique.
Le type derrière World Of Level Design.com (fort bon site au passage) s’est lancé dans un pari un peu foufou : concevoir et réaliser une map pour Unreal Tournament 3 en 11 jours.
A l’aide d’un planning surchargé, il va créer ses premiers concepts, poser ses volumes dans l’éditeur, affiner la circulation, poser ses éléments de gameplay, et itérer sur l’habillage.
Même si son but n’est pas d’avoir une map au gameplay en béton armé, tout le processus de conception et de construction me parait intéressant à suivre.
Quelques références visuellesPremiers concepts
Cet article fête ma migration vers Wefrag ! Merci à ced pour le transfert de mes articles 🙂
(Je mets des bis sinon je vais me retrouver avec 253 parties…)
Aujourd’hui, 2-3 choses supplémentaires :
– Texturing rapide
– Pose d’une ambient light placeholder pour les intérieurs
– Pose d’une seconde ambient pour les extérieurs
– Pose des lumières (les point lights)
– Pose d’un player start
– Création de la Caulk box
– Compilation basique
– Vérification des proportions ingame
Le but est, encore une fois, de rester à l’état placeholder pour avancer plus vite.
– Texturing : On ne se fait pas chier : 1 texture pour les murs, 1 autre pour le sol, une dernière pour le plafond
– Ambient Light : Une seule suffit, on l’appelle comme une entité, via le bouton droit de la souris -> Light > Ambient Light. Dans les propriétés, on change la valeur ambientCubemap de No Default Given en area22_interior_office_building02. Y’a des centaines de presets d’ambient, tapez les premières lettres et faites jouer l’auto-complétion. Vous pouvez prévisualiser les résultats en appuyant sur F3 dans la camera view.
– Ambient Light (extérieur) : On passe par une atmosphere (Click Droit -> Atmosphere -> Atmosphere). Dans les propriétés, vous changerez la valeur atmospheredecl en sewer_bright. Même chose ici, ce sont des presets. Nous verrons plus tard comment créer nos propres atmosphères.
– Point Lights : On n’en n’abuse pas, elles servent à réhausser un peu le niveau lumineux (ou à poser des ambiances colorées précises) au cas où l’ambient fasse mal son boulot.
– Le Player Start : Rien de sorcier : Click Droit -> Info -> Info_player_start.
– La caulk box : On crée 6 pans de murs afin de former un cube texturé avec caulk, qui se trouve dans le dossier « common » du Media Browser. La box doit englober toute votre map sinon vous allez vous manger un leak.
– On compile : L’option « 1 – Normal Compile » suffit pour la plupart des cas (ceux où vous modifiez la géométrie ET les entités).
– Et on regarde si on est bon… : On appelle la fenêtre ingame avec F2, on cherche la console, et puis devmap nomdelamap :
Next Steps:
Bah va bien falloir scripter un jour hein…
Aujourd’hui, on attaque la phase de prototypage, qui consiste à construire rapidement dans l’éditeur nos batiments et un terrain sommaire, afin de vérifier ingame si on est bon.
Sur Shore, je m’attaque à la construction du premier objectif : Le hack du générateur du champ de mines sur la falaise.
Pour rappel, le plan 3D ressemblait à ceci :
Les skills requis sont peu nombreux, et les raccourcis-clavier sont directement issus de GTKRadiant :
– Drag & Drop avec Bouton Souris Gauche dans la 2D View : Ca crée un brush aux dimensions voulues. Vous pouvez ensuite le redimensionner de la même manière.
– Sélection d’un d’un brush : Shift+Click Droit
– Cacher un brush : H
– Montrer un brush : Shift+H
– Découper un brush : on utilise le clip tool, accessible via 2 poses de points avec Ctrl+Clic Droit de la souris dans la vue 2D. Shift+Entrée coupe le bloc en 2. Vous pouvez choisir quel côté enlever (liseré bleu) avec Ctrl+Entrée.
– Duplication de brush : via la barre espace.
– Poser les helpers pour être sûr de respecter l’échelle : Click Droit dans la 2D view -> New Model Static -> Mapobjects -> Helpers -> .lwo
– Appliquer une texture à la con : Ctrl+Shift+Click Gauche sur la texture à changer, puis Middle Click sur la texture de votre choix.
– Tourner un brush : via la Touche « R » on utilise ensuite le helper similaire à 3dsmax
– Déplacer des arètes ou des sommets d’un brush : Touche « V » ou « E », puis drag&drop
Quelques Tips :
– Garder la grille élevée (8 ou 16 unités MAX)
– Faire au plus simple, vous habillerez graphiquement plus tard. Pas besoin de ciseler un brush de manière trop précise
– Ici, j’ai appelé mon niveau ref_objective1.world. Il sera ensuite référencé par mon niveau principal. Il faut tirer parti de ce système de références qui est fort pratique pour travailler sur des structures individuelles.
– Les espaces de circulation à respecter. Si un perso fait 32u de large, faites des portes d’au moins 96u voire 128u de large, histoire que 2 persos puissent passer en même temps.
En quelques heures, on peut aboutir facilement à la structure de notre objectif :
Prochaines étapes :
– Le script du premier objectif 😮
– L’éclairage basique
Ce générateur de terrain à base de blocs et de connecteurs façon Kismet ou FlowGraph, s’il parait un peu rudimentaire, fait parti des outils les plus complets du marché. Les développeurs de Quake Wars s’en sont servi pour créer leur terrains.
– La preview du terrain en temps réel est beaucoup plus détaillée que l’actuelle, elle n’est limitée que par le hardware
– Edition du terrain par modules en WYSIWYG directement dans la fenêtre de preview
– Générateur de routes
– Sélection directe dans le render viewport par lasso et courbes de bézier
– Gestion de l’érosion sous-marine, de la neige
– Export du mesh généré à partir du terrain
– Support du Script, du Multithread et du 64bits dans la version Pro (payante)
L’export de mesh devrait nous rendre de grand services (si les options sont souples, genre contrôler la densité des triangles ça serait bien), il ne resterait plus qu’à l’optimiser sous Blender pour venir l’importer sous EditWorld avant un MegaTexturing en règle.
Pour info, la version de base est toujours gratuite, son gros inconvénient étant la résolution à laquelle il exporte le heightmap (512 x 512 pixels), qui empèche d’avoir un bon niveau de détail sur les grands terrains comme Refinery ou Area22. Il est prévu un discount sur l’upgrade en 2.0 pour les acheteurs de la 1.25 (40 dollars, soit 25 euros, profitez-en ffs!).
Cette série d’article sera mise à jour régulièrement. Elle consiste simplement à poster des screenshots de la map à différents niveaux d’avancement. 56k heavy.
Ici, c’est le LD micro du premier objectif à accomplir : Hacker le générateur du champ de mines Strogg.
Mxyzptlk avait implémenté un workaround sous forme de mod, à tâche pour les développeurs d’implémenter la source dans leur propres mods, ce qui pouvait prendre un certain temps…
La bonne nouvelle vient du staff d’ETQWPro, qui annonce avoir implémenté ce mod dans la nouvelle beta 0.55 de leur mod taillé pour la compétition, releasée hier.
Le mod de course de bagnoles façon Interstate « Wheels of War » aura le même système dans leur future alpha 0.2.
Il ne manque plus qu’à Splash Damage de l’implémenter également, ce qui pourrait prendre un certain temps…
