Vérifier un BSP avant publication : la checklist pour les maps GMod

Avant une publication, tu vérifies ta map dans un ordre fixe : compilation finale, cubemaps, contenu packé, test sur un client vierge, puis nom et version. Les erreurs de publication typiques sont les textures manquantes, les reflets cassés et les spawns défectueux, et toutes les trois passent souvent inaperçues sur ta propre machine. La checklist ci-dessous te fait passer par chaque point d’une seule traite.

La checklist en un coup d’œil

Compilation finale et cubemaps

Une compilation de test avec VVIS en fast ou VRAD en fast ne suffit pas pour une publication. VVIS en fast ne calcule la visibilité que grossièrement, ce qui coûte des performances en jeu. Pour la publication, VVIS tourne en mode normal et VRAD avec -final. Avec -both, VRAD calcule l’éclairage pour LDR et HDR en un seul passage. Les ajouts courants pour un meilleur éclairage des props sont -StaticPropLighting et -StaticPropPolys. Ensuite, lis le log en entier. La marche à suivre est décrite dans comment lire un compile log.

Tu génères les cubemaps en jeu après la compilation, avec buildcubemaps. Une map compilée en LDR et HDR demande deux passes, une avec mat_hdr_level 0 et une avec mat_hdr_level 2, chacune après avoir rechargé la map. Deux choses comptent :

• Chaque nouvelle compilation jette les cubemaps. Tu dois les générer de nouveau ensuite.
• Les cubemaps dépendent du nom de fichier de la map. Si tu renommes le BSP plus tard, les reflets sur les models et les props sont perdus.

Les détails sur les problèmes typiques se trouvent dans corriger les reflets des cubemaps.

Packer le contenu custom et tester sur un client vierge

Tout ce qui ne fait pas partie du jeu doit être livré avec la map. Le moyen le plus fiable est de packer le contenu directement dans le BSP. Le guide se trouve dans packer du contenu custom dans un BSP. Ce qu’on oublie souvent :

• les textures de la skybox et de la zone de skybox 3D
• les detail sprites et les sons custom
• le script de soundscapes scripts/soundscapes_<mapname>.txt
• le manifeste de particules maps/<mapname>_particles.txt
• le fichier de navmesh maps/<mapname>.nav, livré le plus souvent comme fichier à part à côté du BSP

Le VMF, les compile logs et les fichiers de sauvegarde n’ont rien à faire dans le BSP.

Vient ensuite le test le plus important : charge la map sur un client qui n’a pas ton contenu. Ce peut être un second PC, un ami ou une installation dont tu retires temporairement tes addons. Guette les surfaces roses et noires, les models error et les sons manquants, et lis la console. Si la map utilise du contenu d’autres jeux, comme Team Fortress 2, indique-le clairement dans la description.

Nettoyage : textures, entités, spawns

Dans Hammer, cherche précisément les restes de la phase de construction :

1. Remplace les textures de développement du dossier dev/ sur les surfaces visibles.
2. Retire les entités de test, par exemple les lumières temporaires, les NPC de test ou la logique de debug.
3. Lance Map > Check for Problems (Alt+P) et traite la liste point par point.
4. Vérifie les points de spawn. Il devrait y avoir assez d’entités info_player_start pour un serveur plein, et chaque spawn doit se trouver nettement au-dessus du sol.
5. Pour les modes de jeu qui ont leurs propres entités de spawn, place les entités correspondantes.

Si des NPC ou des NextBots doivent fonctionner sur la map, il te faut respectivement des AI nodes ou un navmesh. Tu génères le navmesh en jeu avec nav_generate.

Performances, taille du fichier et gestion des versions

Parcours les endroits où l’on voit le plus de choses à la fois : grandes places, longues rues, points de vue en hauteur. cl_showfps 1 affiche le nombre d’images par seconde, +showbudget montre où le moteur passe son temps. Avec mat_wireframe 1 (nécessite sv_cheats 1), tu vois ce qui est encore rendu derrière les murs. Garde à l’esprit qu’un serveur plein, avec ses joueurs et ses props, génère bien plus de charge que ton test en solo.

La taille du fichier détermine combien de temps les joueurs attendent à leur première connexion. Ne packe que le contenu que la map utilise vraiment.

Pour le nom : des minuscules, pas d’espaces, un préfixe de mode de jeu et un tag de version, par exemple rp_example_v2. Chaque modification publiée reçoit un nouveau nom de fichier. Sinon, les joueurs ont l’ancien fichier sous le même nom et le serveur les refuse avec un message indiquant que les versions de la map diffèrent. Conserve le VMF et le BSP exact de chaque version publiée.

Scan et protection facultative

Un dernier contrôle technique attrape les erreurs que tu ne vois pas en jeu. Pour un BSP, le Map Scanner vérifie la cohérence du header, de la table des lumps et des offsets, cherche les entités à risque comme point_servercommand ou lua_run, vérifie la présence d’un spawnpoint et liste les fichiers Lua et les assets intégrés au pakfile. La liste du pakfile est un bon moyen de contrôler ton packing. Le scan est gratuit, et le fichier peut peser jusqu’à 50 Mo.

Si tu vends la map, tu peux la protéger ensuite. BSP Protection propose les niveaux Audit, Cleanup, Fingerprint, Obfuscation et Server-Exclusive. Aucune protection complète contre la copie n’est garantie. L’ordre compte : la protection vient tout à la fin, sur le fichier fini et testé. Après chaque nouvelle compilation, tu dois l’appliquer de nouveau.

Questions fréquentes

Dois-je régénérer les cubemaps après chaque compilation ?

Oui. Une nouvelle compilation réécrit le BSP, et les cubemaps générées sont perdues au passage. Ne les génère qu’une fois la géométrie et l’éclairage définitifs.

Puis-je renommer le BSP après avoir généré les cubemaps ?

Mieux vaut éviter. Les données des cubemaps sont liées au nom de la map, et les reflets sur les models et les props disparaissent après un renommage. Renomme plutôt le VMF, recompile et régénère les cubemaps.

Une compilation en fast suffit-elle pour une publication ?

Non. VVIS en fast entraîne de moins bonnes performances, VRAD en fast un éclairage plus grossier. Pour une publication, compile avec VVIS en mode normal et VRAD avec -final.

Comment repérer du contenu manquant quand tout a l’air correct sur mon PC ?

Sur ta machine, le contenu se trouve dans le dossier du jeu, donc une erreur de packing n’y apparaît pas. Tu ne peux en être sûr qu’après un test sur un client sans tes fichiers. La liste du pakfile fournie par un scan aide aussi.