Le mapping, où comment exploiter au mieux les secrets des cartes.

Au commencement, lorsque l’on fait sa première carte, généralement, il existe deux sortes de finalités :
- on la termine mais elle est pour ainsi dire complètement à chier.
- on ne la termine pas mais on acquiert en revanche une expérience non négligeable pour la suite.

Me concernant, ça a été la seconde possibilité qui a dirigé mon mapping. Et plutôt deux fois qu’une. J’ai donc d’abord travaillé sur deux cartes qui n’ont jamais vu le jour, avant de sortir une première map qui n’était certes pas extraordinaire, mais quand même parfaitement jouable.
Cette façon de progresser m’a très vite permis d’en apprendre beaucoup sur le mapping et les difficultés à réaliser ce que l’on souhaite, dans les limites du moteur de half-life... Sans que ça rame quoi. Et ce constat était encore plus d’actualité lorsque j’ai commencé à mapper... Il y aura bientôt 5 ans.

Pourquoi est-ce que je vous parle de tout ça? Et bien tout simplement parce que lorsque l’on souhaite faire une belle carte, qui affiche un maximum de détails, tout en évitant que cela rame, on s’intéresse très vite à l’optimisation. Un bien grand mot qui permet de découvrir moult techniques permettant de réduire les r_speeds et donc d’augmenter les FPS. Oulà, je commence peut être à parler chinois pour certains. Qu’est ce que c’est que ces r_speeds?

Bon et bien les r_speeds correspondent à une commande que l’on active via la console, et qui permet de connaître le nombre de polygones calculés à l’écran (et non pas affichés), qu’il s’agisse de polygones de murs (world polygons ou wpolys) ou de polygones de modèles (entities polygons ou epolys). Voici quelques images qui vous aideront à visualiser de quoi je parle :

 


 Voilà une première image de ce qu’affichent les commandes r_speeds 1 (avec developer 1) & la commande gl_wireframe 2 (mode fil de fer). Ici, seul le wireframe de l’eau est affiché.  Si vous n’arrivez pas à vous situer, prenez l’image d’en dessous, je me suis juste placé derrière une caisse du site de bombe pour prendre cette screen. Et regardez comment la belle eau de de_aztec est calculée en profondeur, au grand dam de nos fps :(  

    Sur cette image, on voit mieux toutes les faces en fil de fer qui sont affichées simultanément, et qui génèrent autant de world polygons. Les epolys sont ceux des plantes (voir plus loin).
 

 La commande r_drawflat 1 (uniquement accessible en software) affiche les faces sans leurs textures. J’ai tâché de cadrer mon image en fonction de la précédente, pour que vous puissiez faire le parallèle entre les deux modes. C’est de toute beauté, n’est ce pas?        Ce qu’affiche la commande developer 1 : un tas d’informations très utiles... pour qui sait les décrypter.

Après avoir tapé developer 1 & r_speeds 1 dans la console, on obtient donc cette ligne de code qui s’affiche en haut à gauche de votre écran (les deux premières images). La première valeur indique les FPS, la seconde le temps de latence par rapport au rafraîchissement de l’image, et les deux dernières valeurs sont les plus importantes. Les wpolys correspondent aux worlds polygons, c’est à dire les polygones des murs, sol, caisses, etc. C’est à dire tout ce qui compose les objets physiques. Les epolys correspondent quant à eux aux entity polygons, c’est à dire les polygones des armes, des joueurs et de certains modèles comme des arbres ou plantes :




 Sur cette image, il y a 6 modèles : 3 modèles de plantes (2 juxtaposées au premier plan, et une au second plan), 2 modèles de squelettes, et le dernier, c’est vous et votre couteau (ce qui constitue un modèle à part entière). Si d’autres joueurs étaient présents sur l’image, il aurait fallu les additionner eux aussi, ainsi que les armes qu’ils utilisent. A chaque fois, on ajoute de nouveaux epolys... Bref, quand il y a une foule de modèles et de joueurs aux mêmes endroits, si votre PC ne suit pas, ça fait mal aux FPS.


Vous l’aurez compris, plus les epolys & wpolys sont élevés, et plus la carte risque d’être injouable. En gros, les r_speeds, par convention, ne doivent pas dépasser 650-700, surtout lors des phases de combats. Car c’est lors de ces phases de jeu que les epolys montent en flèche (à cause des présences des joueurs justement). Bref, un bon mappeur veillera à ne pas charger sa carte de détails dans les endroits où les joueurs se rencontrent, pour ainsi éviter que cela rame. Vous comprenez maintenant pourquoi, lorsque vous êtes nombreux sur une carte comme aztec, ça rame. Beaucoup de joueurs affichés en même temps et une carte non optimisée... Les r_speeds grimpent.


Pour continuer un peu sur les epolys, j’aimerai vous montrer la différence entre modèles et sprites. Un modèle, comme nous venons de le voir, est une entité volumétrique, c’est-à-dire en trois dimensions dans le jeu. A l’inverse, un sprite est une simple image, en 2D. Pour ceux qui s’en souviennent encore, les ennemis dans doom 1 et 2 étaient des sprites. C’est à dire des images fixes. Une fois à terre, peu importe l’angle de vue que vous aviez sur les cadavres de vos ennemis, ceux-ci vous apparaissaient toujours de la même manière. C’est quake 1 qui a révolutionné le "quake-like" justement, en introduisant des adversaires en 3D, et non plus en 2D. D’ailleurs Half-Life n’est rien d’autre que le moteur de quake 1 amélioré... Mais ça c’est une autre histoire. Voyons un peu mieux ce qu’est un sprite, et ensuite la différence entre un sprite et un modèle :


 

Sur cette double image, je fixe le sprite, et je tourne autour. Comme vous pouvez le voir, j’en ai toujours la même perception : il s’agit bien d’une image fixe.  



Sur ce petit montage, on voit distinctement la différence entre un sprite et un modèle, avec à gauche leur représentation dans le jeu, et à droite leur représentation dans les logiciels qui permettent de les visualiser à part. Dans le cas du sprite on a bien une image, dans celui du modèle, un volume.



Bon après, ce petit discours vous devinez un peu mieux les quelques bases du mapping, les objets et difficultés qu’un mappeur doit apprendre à maîtriser. Et surtout, vous distinguez mieux les environnements dans lesquels vous évoluez.

Le nombre de polygones des joueurs étant impossible à modifier (on ne peut pas demander à tous les joueurs d’utiliser des High FPS models), la seule chose que l’on puisse faire contre les epolys c’est d’éviter d’ajouter trop de modèles dans les cartes. En revanche, les sprites ne prennent pas de ressources, mais ils sont clairement moins intéressants comparés aux possibilités d’un modèle (ben oui, c’est de la 2D).

Vous l’aurez compris, le gros du travail d’un mappeur se situe donc au niveau des worlds polygons, car c’est là le coeur même de la carte. Savoir optimiser son mapping prend alors toute son importance.

Et c’est en optimisant ses cartes que l’on utilise diverses techniques, qui peuvent ensuite être exploitées par ceux qui les connaissent en cours de partie...

Enfin!, vous vous dites, on arrive à la partie la plus intéressante de ce dossier.